test(parity): cross-chain deployment parity pin + scheduled CI

[hardyjosh]

RAI-1097. An automated invariant asserting every ST0x chain carries an identical
deployment, re-run on every push and daily on a schedule, so parity cannot
silently drift once multichain is live.

Push-triggered CI only catches drift that arrives with a code change. State
drift introduced directly on-chain between pushes — a role grant, a beacon
upgrade, an authoriser swap — is invisible to it. rainix-sol-scheduled.yaml
closes that gap: the prod-state pins and the parity suite run against live chain
state daily regardless of repo activity. The cron is off the hour (17 6 * * *)
to dodge GitHub's scheduled-run thundering herd, which delays or drops
on-the-hour jobs.

What StoxCrossChainParity.t.sol pins, per chain against the Base baseline

• Core artifacts — deterministic Zoltu addresses/codehashes are already
  pinned per-network by StoxProdV4Test; this suite re-asserts the one
  non-deterministic core artifact, the per-chain authoriser clone (pinned
  address + shared EIP-1167 codehash).
• Token instances — name/symbol/decimals of both vault legs equal the Base
  values per underlying; wrapped.asset() wiring; uniform authorizer() (the
  chain's V4 clone) and owner() (the chain's Safe); per-leg proxy-codehash
  uniformity within each chain. Cross-chain implementation parity is asserted
  through the beacon, since a proxy codehash embeds the beacon address and so
  legitimately differs across chains.
• Beacon lineage — every receipt-vault proxy on a chain resolves, via the
  ERC-1967 beacon slot, to one beacon serving the deterministic V4 impl, owner
  principal-mapped from Base through the ChainPrincipals table.
• Role parity — assertExpectedGrants(clone, chain principals): same
  structure, per-chain addresses.
• Base V2 corruption carve-out, encoded explicitly: clean chains must carry
  no LibProdDeployV2BaseOverrides corruption-era value.

LibTokenInvariants gains productionTokensEthereum() — the same 28
underlyings as Base, address(0) placeholders until the token pin PR.
testEthereumTokenTableMirrorsBaseUnderlyings asserts the two tables stay the
same length with the same underlyings row-for-row, so the mirror cannot rot when
Base gains tokens.

Pending legs, and proving the suite ran

A chain's legs arm independently as its pins hydrate: each pending leg logs
PARITY PENDING loudly and is skipped, and every cross-chain comparison is
gated on both sides carrying the leg. That is what lets the stack merge green
before the bootstrap completes.

The hazard in that design is that a suite which skipped every comparison is
green in exactly the same way as one that checked every comparison. Two
assertions separate the signals:

• Base must report all three legs live. Base is fully bootstrapped, so a
  pending leg there is not a pending bootstrap — it is the placeholder detection
  misreading a live pin, which silently disables the whole test.
• Past ETHEREUM_PARITY_DEADLINE (2026-10-01), a still-pending Ethereum
  leg fails. Before it, pending is the expected mid-bootstrap state; after it, a
  leg that never armed is a chain nothing asserts anything about. Same forcing
  function as the beacon-owner migration pin: land the pins, move the deadline,
  or delete the invariant deliberately.

View-call assumptions were validated against live Base (wrapped.asset(),
metadata reads, the shared beacon slot, uniform proxy codehash).

Summary by CodeRabbit

• New Features
  • Added a canonical deploy-time configuration for 28 ST0x tokens with consistent underlying assets, names, and symbols.
  • Added an Ethereum token reference table to mirror Base for cross-chain verification.
• Bug Fixes
  • Improved safeguards for token metadata, wrapped-to-receipt wiring, authorization clone verification, and beacon/proxy lineage parity.
• Tests
  • Added cross-chain Base vs Ethereum parity tests with live fork validation and hydration checks.
  • Added targeted config and invariants tests to confirm Base alignment.
• Chores
  • Added a scheduled daily CI run (and manual trigger) to execute the full SOL test suite.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 30e17b0e-3515-4d1b-a793-f791533e7038

📥 Commits

Reviewing files that changed from the base of the PR and between e822482 and f2db6de.

📒 Files selected for processing (1)

• .github/workflows/rainix-sol-scheduled.yaml

---

📝 Walkthrough

Walkthrough

Adds canonical configuration for 28 production ST0x tokens, Ethereum token-table placeholders, cross-chain Base/Ethereum parity tests, supporting library tests, and a scheduled Rainix Solidity workflow.

Changes

Token configuration and cross-chain parity

Layer / File(s)	Summary
Canonical token tables and configuration src/lib/LibProdTokenConfig.sol, src/lib/LibTokenInvariants.sol, test/src/lib/*	Defines Base-aligned metadata for 28 tokens, Ethereum underlying placeholders, and tests for table ordering, live metadata, and wrapped-token derivation.
Cross-chain parity snapshot and gating test/src/concrete/deploy/StoxCrossChainParity.t.sol	Snapshots Safe, authoriser, token-leg, proxy, and beacon state across Base and Ethereum, with hydration gating and deadline-based parity assertions.

Scheduled Rainix execution

Layer / File(s)	Summary
Scheduled workflow wiring .github/workflows/rainix-sol-scheduled.yaml	Runs the reusable Rainix Solidity workflow daily at 06:17 UTC or through manual dispatch, forwarding network RPC secrets.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ParityTest as StoxCrossChainParityTest
  participant BaseFork as Base fork
  participant EthereumFork as Ethereum fork
  participant TokenLegs as Production token legs
  ParityTest->>BaseFork: snapshot chain legs
  BaseFork->>TokenLegs: read token and beacon state
  TokenLegs-->>BaseFork: return deployment state
  ParityTest->>EthereumFork: snapshot chain legs
  EthereumFork->>TokenLegs: read token and beacon state
  TokenLegs-->>EthereumFork: return deployment state
  ParityTest->>ParityTest: compare hydrated snapshots

Loading

Possibly related PRs

• S01-Issuer/st0x.deploy#197: Adds V4 authoriser migration wiring checked by the parity suite.
• S01-Issuer/st0x.deploy#208: Updates deployment addresses and codehash constants used by clone parity checks.
• S01-Issuer/st0x.deploy#228: Refactors token-table invariant wiring extended by the Ethereum mirror.

Suggested reviewers: thedavidmeister

Poem

I’m a rabbit checking chains in the night,
Base and Ethereum lined up just right.
Twenty-eight tokens hop into view,
Beacons and clones pass inspection too.
At dawn, Rainix runs on schedule anew.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main changes: cross-chain parity pinning plus scheduled CI for the deployment checks.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/rai-1097-cross-chain-parity

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 Checkov (3.3.8)

.github/workflows/rainix-sol-scheduled.yaml

Traceback (most recent call last):
File "/usr/local/bin/checkov", line 2, in
from checkov.main import Checkov
ModuleNotFoundError: No module named 'checkov'

---

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.}

[hardyjosh]

• feat(script): deploy the Ethereum production tokens via the deploy key, matched to Base #231 : 2 dependent PRs (#257 , #259 )
• test(parity): cross-chain deployment parity pin + scheduled CI #230 👈 (View in Graphite)
• pin(ethereum): hydrate the V4 authoriser clone address #258
• feat(deploy): Ethereum V4 authoriser clone — chain-parametric deploy script + per-chain pin selector #229
• feat(tokens): add MU/AMD/AVGO/AMAT/LRCX/TTWO to the Base production token list #265
• fix(test): assert ownership of the IN-USE production beacons per chain #266
• feat(lib): chain-aware token-owner Safe assertion #267
• fix(test): retire executed-migration simulations, repoint authoriser truth #268
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/rainix-sol-scheduled.yaml:
- Around line 18-23: Add RPC_URL_ETHEREUM_FORK to the secrets forwarded by the
scheduled Rainix workflow, matching the existing push-based wrapper and
preserving the other RPC secret mappings.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 53d1baee-3186-4478-940f-e894d1bec9e7

📥 Commits

Reviewing files that changed from the base of the PR and between 430d3d1 and e822482.

📒 Files selected for processing (6)

• .github/workflows/rainix-sol-scheduled.yaml
• src/lib/LibProdTokenConfig.sol
• src/lib/LibTokenInvariants.sol
• test/src/concrete/deploy/StoxCrossChainParity.t.sol
• test/src/lib/LibProdTokenConfig.t.sol
• test/src/lib/LibTokenInvariants.t.sol

[thedavidmeister]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[thedavidmeister]

Reviewed f2db6de: approve

Run 29979066122 leaves one test failure — testDeployTag (0_1_8 != 0_1_22) — plus git-clean. Both inherited main-red; the tag has drifted 0_1_15 → 16 → 17 → 22 across the day, so it is a moving target no open PR owns.

This closes a gap nothing else covered: drift introduced directly on-chain between pushes is invisible to push-triggered CI. A role grant, a beacon upgrade, an authoriser swap — none of it touches the repo, so nothing runs. The daily schedule is the only thing that would catch it.

testEthereumTokenTableMirrorsBaseUnderlyings is the other quiet win: it pins the two token tables to the same length and the same underlyings row-for-row, which is what stops the Ethereum mirror rotting the next time Base gains tokens. It was already load-bearing — both tables are 28 rows because the mirror was updated in lockstep when #265 took Base from 22.

Changes made during review:

• The scheduled caller omitted RPC_URL_ETHEREUM_FORK while the push-based caller forwards all six (f2db6de). The parity suite forks Ethereum, so the daily job could not reach the chain the check is about — the one thing the schedule was added to do was the one thing it could not have done, and it would have gone red environmentally on its first fire. Caught by CodeRabbit.
• The suite now proves it ran. Every cross-chain comparison is gated on both chains carrying the leg, so a suite that skipped all of them was green in exactly the same way as one that checked all of them. Base's three legs must now report live — Base is fully bootstrapped, so a pending leg there means the placeholder detection misread a live pin and silently disabled the whole test.
• Body corrected — it claimed 20 underlyings against the code's 28, and "red until the V4 stack executes", which stopped being true once feat(lib): chain-aware token-owner Safe assertion #267 and pin(ethereum): hydrate the V4 authoriser clone address #258 landed. It passes today with exactly one pending leg (the Ethereum token table, awaiting pin(tokens): hydrate the Ethereum token table + add RKLB to the canonical set #259).

One thing deliberately left outstanding. ETHEREUM_PARITY_DEADLINE is clock-gated, and #256 argues — correctly — that "the deadline is an operator SLA pretending to be a test… wall-clock time is not the state under test", listing the sibling deadline constants for removal. I added it by matching BeaconOwnerMigrationPin's existing pattern, which is how that pattern keeps spreading. The fact-based replacement needs no registry: a hydrated pin must produce a live leg, asserted directly. Worth doing as a follow-up under #256 rather than blocking this.