The fork test in test/prod/CycloSiteTokens.prod.*.t.sol verifies vault decimals(), underlying decimals(), and vault.asset() linkage for every entry in canonical/cyclo-site-tokens.json. The receiptAddress field is not verified — older vault implementations (cysFLR's PROD_FLARE_VAULT_IMPLEMENTATION_CYSFLR = 0x35ea13bB...) don't expose receipt() as a getter, and the receipt itself doesn't expose a vault() accessor. Need a way to verify the receipt linkage that works across all vault impl versions: either (a) a per-impl-version branch in the test that uses a specific accessor, (b) reading the manager-owner storage slot of the receipt and asserting it matches the vault, or (c) calling a vault-only function on the receipt from the vault and observing the result. Currently a manual review of canonical/cyclo-site-tokens.json is the only way to catch a wrong receiptAddress.
The fork test in
test/prod/CycloSiteTokens.prod.*.t.solverifies vaultdecimals(), underlyingdecimals(), andvault.asset()linkage for every entry incanonical/cyclo-site-tokens.json. ThereceiptAddressfield is not verified — older vault implementations (cysFLR'sPROD_FLARE_VAULT_IMPLEMENTATION_CYSFLR = 0x35ea13bB...) don't exposereceipt()as a getter, and the receipt itself doesn't expose avault()accessor. Need a way to verify the receipt linkage that works across all vault impl versions: either (a) a per-impl-version branch in the test that uses a specific accessor, (b) reading the manager-owner storage slot of the receipt and asserting it matches the vault, or (c) calling a vault-only function on the receipt from the vault and observing the result. Currently a manual review ofcanonical/cyclo-site-tokens.jsonis the only way to catch a wrongreceiptAddress.