feat(script): deploy the Ethereum production tokens via the deploy key, matched to Base

[hardyjosh]

Stands up the full ST0x production token set on Ethereum in a single
deploy-key broadcast, matched to Base — no Safe signature required.

• 20260706-deploy-tokens-ethereum.s.sol — one operation (run()),
  broadcast from the CI deploy key. Mirrors the authoriser-clone deploy
  pattern: the deploy key deploys, configures, then self-relinquishes. Per
  token, in order:

  1. StoxUnifiedDeployer.newTokenAndWrapperVault with initialAdmin = the
     deploy key and the Base-verbatim name/symbol — the deploy key transiently
     owns the receipt vault (the wrapped vault has no owner).
  2. setAuthorizer(clone) on the receipt vault while the key is still owner.
  3. transferOwnership(Safe) — single-step OZ Ownable, so ownership lands
     on the Safe with no accept step. The deploy key then holds nothing.

  Pre-flight requires the core deployers, the V4 authoriser clone (the
  setAuthorizer target) and the Safe (the handoff target) all live, so the
  bootstrap order (Safe → clone → tokens) is enforced. Deployed addresses are
  nonce-based (not known ahead), so it logs each (underlying, receiptVault, wrapped) for the post-execution pin PR to hydrate
  productionTokensEthereum().

• Name/symbol come from the canonical LibProdTokenConfig (introduced in the
  branch below), validated against live Base — SGOV's leading-space name and
  all — so the tokens reproduce Base byte-identically.

• Workflow — listed in manual-broadcast.yaml (the deploy-key broadcast
  dispatcher), targeting the chosen network. It is NOT a Safe-artifact
  script, so it is not in run-script.yaml.

Pre-flight guard test fires while the pins are pending; red until the Ethereum
Safe + clone are live, by design.

🤖 Generated with Claude Code

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: 12 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

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: c683b7b5-a339-4fa7-a350-d29ff9249a45

📥 Commits

Reviewing files that changed from the base of the PR and between bd2f5c0 and 12bf0dc.

📒 Files selected for processing (3)

• .github/workflows/manual-broadcast.yaml
• script/20260706-deploy-tokens-ethereum.s.sol
• test/script/20260706-deploy-tokens-ethereum.t.sol

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/rai-1095-ethereum-token-deploy

---

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 ) 👈 (View in Graphite)
• test(parity): cross-chain deployment parity pin + scheduled CI #230
• 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.

[thedavidmeister]

Reviewed 12bf0dc: approve

Run 29981094045 leaves one test failure — testDeployTag (0_1_8 != 0_1_22) — plus git-clean. Both inherited main-red.

The wiring is right, and the pre-flight is the strongest in the stack: the chain guard reverts unless the resolved Safe is Ethereum's (so a misdispatched network cannot deploy a duplicate set elsewhere), the authoriser is checked by codehash rather than a bare code.length, in-use beacon ownership is asserted before anything deploys, and the ordering is correct — setAuthorizer while the deploy key still owns, then single-step transferOwnership so nothing is left pending.

Two gaps found in review, both now fixed on this head:

No run-once guard. The sibling clone script refuses to re-run via V4AuthoriserClonePinAlreadyHydrated; this had no equivalent. Once the deploy succeeds every other pre-flight passes — deployers live, authoriser live, Safe live — so a re-dispatch would mint 28 more production tokens, nonce-addressed and indistinguishable from the real ones except by deploy order, and hand them to the Safe. The only thing in the way was a human reading a dropdown that says outright it lists which scripts exist, not which have run. This compounds with the loop shape: forge script --broadcast sends one transaction per call, so a failure at token 15 leaves 14 live with no resume, and the only recovery duplicates them. The token table is the record of what a previous run produced, so the guard reads it and refuses on any hydrated leg.

No post-handoff verification. setAuthorizer and transferOwnership are now read back per token. Both happen in the same broadcast, and the acceptance test that would catch a silent miss does not run until the pin PR lands — until then a missed handoff is a production vault owned by a CI key.

Also added DeploymentEventMissing, so an unresolved Deployment event fails by name mid-broadcast instead of faulting on a zero address.

Both checks take their subject as an argument rather than reaching for pinned state, which is what makes them testable — a check reachable only from inside a broadcast loop can be shown not to fire and never shown to fire. 8 tests, and all three mutants killed against a committed baseline: guard-checks-row-0-only, receiptVault-check-disabled, and handoff-assert-disabled (which survived until the assertion was made drivable).

Two issues filed from this review, neither blocking: rainix#278 on whether the one-contract-per-file gate should count interfaces, and rain.vats#330 — IAuthorizableV1 publishes authorizer() but not setAuthorizer, which is why this script and the 20260623 one each hand-mirror the same selector under different names.