ops(script): HyperEVM beacon-owner migration + 0.1.1 beacon lib generalisation (RAI-1511)

[hardyjosh]

• Rename LibProdBeaconsEthereum -> LibProdBeacons0_1_1: the set is
  Zoltu-deterministic, so it is the SAME addresses on every chain that
  bootstraps at 0.1.1 — Ethereum yesterday, HyperEVM next. Consumers
  updated; docs record the rename rationale.
• prodBeaconsForChainId: HyperEVM branch (resolves the same 0.1.1 set).
• 20260722-migrate-beacon-owners-hyperevm: the HyperEVM leg of the
  beacon-ownership migration executed for Base (fix(tests): beacon-ownership migration executed on Base — update test reality #253) and Ethereum
  (20260716). Deploy-EOA broadcast (beacons come up EOA-owned), --legacy
  noted for HyperEVM's fee-estimation quirk, chain-id guarded, PENDING.
  Ordering per RAI-1511: after impl suites + Safe pin, before tokens (the
  token-deploy pre-flight hard-gates on beacon ownership).
• HyperEvmBeaconOwnershipTest: the migration's forcing function, mirroring
  the Ethereum pin, with loud PENDING gates on the Safe pin + the missing
  rainix HyperEVM RPC secret slot.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01VPs1hCTxusmaSeFKvoc4Kr

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 44 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 7347a8c8-40d6-49f0-8378-6d69d9aeae06

📥 Commits

Reviewing files that changed from the base of the PR and between 1c4eceb and 15ea985.

📒 Files selected for processing (9)

• script/20260706-deploy-tokens-ethereum.s.sol
• script/20260716-migrate-beacon-owners-ethereum.s.sol
• script/20260722-migrate-beacon-owners-hyperevm.s.sol
• src/lib/LibBeaconInvariants.sol
• src/lib/LibProdBeacons0_1_1.sol
• src/lib/LibProdBeaconsBase.sol
• test/src/concrete/deploy/EthereumBeaconOwnership.t.sol
• test/src/concrete/deploy/HyperEvmBeaconOwnership.t.sol
• test/src/lib/LibBeaconInvariants.t.sol

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ops/hyperevm-beacon-owner-migration

---

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]

• ops(script): HyperEVM token deploy (RAI-1511) #278 : 2 dependent PRs (#284 , #291 )
• pin(invariants): HyperEVM invariant surface (RAI-1511) #277
• ops(script): HyperEVM beacon-owner migration + 0.1.1 beacon lib generalisation (RAI-1511) #276 👈 (View in Graphite)
• feat(multichain): HyperEVM token-owner Safe pin plumbing (RAI-1511) #275
• feat(multichain): HyperEVM V4 authoriser clone pin plumbing (RAI-1511) #274
• feat(authoriser): additional service signer — canonical pin + provisioning #280
• main

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

[thedavidmeister]

Deliberate experiment: removed the PENDING gates so the HyperEVM beacon-owner invariant actually runs

This was pushed on purpose to find out whether the invariant is red, not as a routine cleanup. A red here would have been a legitimate result — this test is a forcing function and its docstring says it is RED until the HyperEVM beacon-ownership migration runs. Recording the outcome so nobody reads it as an accident either way.

What was removed

15ea985 deletes both early-return gates and their emit log lines from testHyperEvmBeaconsAreSafeOwned in test/src/concrete/deploy/HyperEvmBeaconOwnership.t.sol:

• the safe == address(0) gate — STOX_TOKEN_OWNER_SAFE_HYPEREVM is pinned non-zero at 0x3840aeDaEc8e82f79d8F6a8F6ADCa271E13E0329;
• the HYPEREVM_RPC_URL gate — feat(multichain): HyperEVM token-owner Safe pin plumbing (RAI-1511) #275 forwards RPC_URL_HYPEREVM_FORK to the shared rainix workflow from both rainix-sol.yaml and rainix-sol-scheduled.yaml.

Both premises the gates waited on are now false, and the docstring's own stated condition ("Remove the env gate once CI carries the secret") is met. The @dev paragraph that documented the two gates was rewritten to describe what the test does now; the forcing-function paragraph is unchanged, because it is still accurate and still the point of the test.

Nothing else is touched — no change to the migration script, LibProdBeacons0_1_1.sol, LibBeaconInvariants.sol, or the Ethereum test.

Result: GREEN

No local pre-run; CI is the observation.

Ran 1 test for test/src/concrete/deploy/HyperEvmBeaconOwnership.t.sol:HyperEvmBeaconOwnershipTest
[PASS] testHyperEvmBeaconsAreSafeOwned() (gas: 41118)
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 3.05s (3.05s CPU time)

Whole run green: Ran 83 test suites in 487.68s: 807 tests passed, 0 failed, 0 skipped. rainix-sol / test / test succeeded in 9m43s, alongside legal, static and git-clean.

Two things confirm this is a real pass rather than a silent no-op:

• the job's RPC preflight step passed and the suite took 3.05s with 41,118 gas, i.e. it forked HyperEVM and made real calls (compare the Ethereum sibling at 41,095 gas);
• the string PENDING: appears zero times in the job log — with the guards gone there is no skip path left.

So all three HyperEVM production beacons are deployed, carry the OZ UpgradeableBeacon codehash, point at their pinned 0.1.1 implementations, and are owned by the HyperEVM token-owner Safe. That matches 20260722-migrate-beacon-owners-hyperevm.s.sol being marked EXECUTED 2026-07-24 in 43080d8: the migration was broadcast out-of-band, and this test is the first thing to independently verify it against chain state rather than take the script header's word for it.

The invariant has now flipped from "pending, unverifiable" to "green and load-bearing" — from here it guards against later ownership drift on HyperEVM the same way the Base and Ethereum ones do.

[thedavidmeister]

Reviewed 15ea985: approve
Rulings-conformance: checked against every ruling stated for this work. (1) "remove guards and run ci so we can see if it is red" — executed exactly: both PENDING: return guards and their emit log lines deleted from HyperEvmBeaconOwnership.t.sol, pushed non-force, CI read once. Nothing else touched — no deadline constant, no change to the migration script, LibProdBeacons0_1_1.sol, LibBeaconInvariants.sol, or the Ethereum sibling. (2) "i didn't say run locally" — no local run was performed. (3) "red is never dead-stated" / "main-red is fixable on the branch" — the answer came back GREEN, not red, so there is nothing to route: [PASS] testHyperEvmBeaconsAreSafeOwned() (gas: 41118), whole suite 807 passed / 0 failed / 0 skipped. (4) "coverage, not manual verification" — the green is proven non-vacuous rather than asserted: the RPC preflight step passed so the HyperEVM secret is genuinely present, 41,118 gas and 3.05s mean it forked and made real calls (the Ethereum sibling costs 41,095), and PENDING: appears zero times in the job log because no skip path survives. (5) "no keep-with-caveat" — no guard was reinstated, no skip added, no assertion weakened. (6) "comments: no process" — the @dev paragraph that documented the guards now describes current behaviour (invariant runs unconditionally, Safe pinned, CI supplies HYPEREVM_RPC_URL from RPC_URL_HYPEREVM_FORK) rather than narrating their removal. (7) "no squash-merge for Graphite stacks" — merging with --merge. Substance: the guards were masking a test that passes. All three HyperEVM beacons exist, carry the OZ UpgradeableBeacon codehash, point at their pinned 0.1.1 implementations, and are already owned by 0x3840aeDaEc8e82f79d8F6a8F6ADCa271E13E0329 — so the EXECUTED 2026-07-24 annotation on 20260722-migrate-beacon-owners-hyperevm.s.sol, previously an unverified claim in a script header, is now checked against chain state on every run and the invariant is live against future ownership drift.