feat(bridge): record the treasury fee divisor in force at reveal

[mswilkison]

Deploy deferred by request. Bundle deployment and the historical re-sync with the next release rather than tagging a release for this PR.

Problem

treasuryFee: 0 cannot distinguish a deposit made while protocol fees were disabled from a deposit whose fee was waived. Consumers need the treasury fee divisor that applied when the deposit was revealed.

A contract call in the reveal handler returns end-of-block state. If a reveal is followed by a governance update from 0 to 500 in the same block, that call records divisor 500 for the earlier no-fee deposit and incorrectly makes it look fully waived.

Change

• Add nullable Deposit.treasuryFeeDivisorAtReveal and snapshot the tracked divisor at each reveal.
• Seed BridgeState.depositTreasuryFeeDivisor to the initializer's value of 2000 on Initialized(1), then apply DepositParametersUpdated in event order. Both configured start blocks include initialization; commit-pinned deployment receipts and initializer sources are documented in docs/treasury-fee-divisor.md.
• Preserve existing state across reinitialization. If initialization history is unavailable, leave the snapshot null until a parameter update supplies the value.

A reveal, update from 0 to 500, and second reveal in one block now retain divisors 0 and 500 respectively. Later updates cannot change either snapshot. This removes the per-reveal parameter call and does not hardcode a fee activation date.

Consumers can distinguish a zero divisor from a positive divisor when interpreting the recorded fee. Null means the historical divisor is unknown. Historical deposits require a re-sync, and consumers must query the new field after deployment.

Validation

• yarn install --frozen-lockfile, yarn codegen, yarn build-mainnet, and yarn build-sepolia pass.
• Nine handler regression tests pass on Node 22 and 26. They cover initialization, both zero/nonzero transitions within one block, successive updates, missing history, reinitialization, unrelated singleton state, and unreadable legacy deposit records. CI runs these alongside the existing builds.
• The ordering regression detects the original bug: the previous mapping records 500 for both deposits where the expected snapshots are 0 and 500.
• All 58 existing toolchain and cutover tests pass; git diff --check passes.

The handler tests execute the mapping with mocked Graph dependencies; code generation and both network builds check schema, ABI, and AssemblyScript compatibility.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: a3342615-ee1e-4a8a-9931-3a57c7b16491

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}