Keep contract addresses in sync

[rvagg]

We have 3 pieces where contract addresses get involved, discounting the current sdk constants.ts which is slowly being eaten away into oblivion.

• wagmi.config.ts which fetches ABIs from a pinned GIT_REF for ABI and an address each for FWSS on mainnet and calibnet. When run it makes a generated.ts with the addresses for the contracts it discovers via a multicall and their ABIs.
• chains.ts which imports generated.ts to build viem Chain objects
• filecoin-services deployments.json which has canonical addresses updated on release of new contracts.

How do we make sure we have the right ABI and addresses here and we don't get out of sync?

One challenge is that we have been bumping that commit to pull in newer ABIs than are released, maybe we need to change that, or do it on feature branches that only get merged once we have a release. We could make that a practice post-v1.

Some options:

• Build-time validation script - pnpm build could fetch deployments.json and do an update for you and get everything in sync.
• CI linter in synapse-sdk - fails you when you're out of sync

Both of those options are reactive rather than proactive, they require someone to be making a change for anything to get updated, and they'd get mixed up in PRs that are entirely unrealted to the contract updates.

• Cron GHA in Synapse that opens a PR when it detects a change
• Release trigger on filecoin-services that opens a PR, or delegates to Synapse, to open a PR when a release has been cut
• Publish a new package, @filoz/contract-addresses from filecoin-services whenever we cut a release there and include deployments.json data in it, versioned the same as filecoin-services, depend on it in Synapse (but then what .. do we rebuild here, do we put the wagmi / generated stuff into that package so it does the building?)

[hugomrdias]

1. and 2. are the same, come from the some place.

Our CI currently fails when an address changes in FWSS contract.

Feature branch sounds good!

• synapse master always in sync with filecoin-services master
• synpase next in sync with filecoin-services next

Questions:

• what is the source of truth for abi and addresses? git ref for abis, deployments.json for addresses?
• deployments.json probably does work for development, we will only have calibration
• is devnet the solution for development?

[rvagg]

• Source of truth: git ref, I'd use a version tag but we can use a hash if we want to be uber-secure, it'll have ABIs and deployments.json is now the place they'll be recorded.
• I haven't tried deployments.json for development (in fact I've not really used it much myself yet since it's newish) but I imagine that if you were deploying your own to calibnet then you'd at least have a local version that would have it. An interesting workflow to try out; but ...
• Devnet is the solution for development. I've not bothered using calibnet dev for a while when it involves more than just the SDK, it's just too hard to spin everything up that you need and it's only getting harder as we add more pieces and complexity. So foc-devnet Chain builder in synpase-core #589 will be part of solving for that.