ops(script): HyperEVM token deploy (RAI-1511)

[hardyjosh]

The HyperEVM token bootstrap (RAI-1511), landing as the provenance record of
a deploy that has already run: EXECUTED 2026-07-24 by manual-broadcast run
30114307165, which deployed all 29 canonical tokens, wired them onto the
HyperEVM V4 authoriser, and handed them to the HyperEVM Safe. The resulting
tuples are pinned in productionTokensHyperEvm() by #277.

The script is self-scoping — it joins the canonical config against
productionTokensHyperEvm() and selects only the all-zero rows — so against
the now fully-hydrated table _selectMissing() reverts NoMissingTokens.
It is therefore inert as merged: it cannot re-mint what it already deployed.
What it still carries is the record of how those 29 tokens came to exist,
plus live machinery for a token added to the canonical set later — such a
token lands as an all-zero HyperEVM row, and a re-dispatch picks it up
automatically with no edit to this script.

Per token, identical to the executed Ethereum flow: 0.1.1 unified deployer
(initialAdmin = deploy key) -> receipt readback -> setAuthorizer(HyperEVM
V4 authoriser) -> transferOwnership(HyperEVM Safe). Pre-flight hard-gates
encode the RAI-1511 ordering: 0.1.1 core deployed, in-use beacons
HyperEVM-Safe-owned (beacon-owner migration), authoriser pin hydrated,
Safe pin hydrated — an early dispatch is a typed revert, never a partial
deploy. Registered in manual-broadcast (dispatch on network = hyperevm).

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

Summary by CodeRabbit

• New Features

  • Added a deployment process for missing tokens on HyperEVM.
  • Validates deployment readiness and configuration before proceeding.
  • Automatically deploys, configures, and transfers ownership of missing tokens.

• Bug Fixes

  • Added safeguards for unavailable infrastructure, invalid configuration, and already-complete token tables.

• Tests

  • Added coverage for complete token tables and missing core deployments.
  • Enabled HyperEVM RPC access in scheduled and standard test workflows.

[coderabbitai]

📝 Walkthrough

Walkthrough

Changes

HyperEVM gap-fill deployment

Layer / File(s)	Summary
Selection and preflight validation script/20260722-deploy-missing-tokens-hyperevm.s.sol, test/script/DeployMissingTokensHyperEvmHarness.sol, test/script/20260722-deploy-missing-tokens-hyperevm.t.sol	The script validates pinned HyperEVM infrastructure and selects all-zero token rows that match canonical configuration. Tests cover hydrated tables and missing core deployment.
Deployment and ownership wiring script/20260722-deploy-missing-tokens-hyperevm.s.sol	The script deploys each missing token, configures receipt-vault authorization, transfers ownership to the Safe, and logs deployment tuples.
Workflow and RPC integration .github/workflows/manual-broadcast.yaml, .github/workflows/rainix-sol-scheduled.yaml, .github/workflows/rainix-sol.yaml	The manual workflow registers the deployment script. Solidity workflows receive the HyperEVM fork RPC secret.

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

Possibly related PRs

• S01-Issuer/st0x.deploy#271: Adds a related chain-specific missing-token deployment flow.
• S01-Issuer/st0x.deploy#275: Adds HyperEVM Safe infrastructure used by this script.
• S01-Issuer/st0x.deploy#277: Adds HyperEVM token rows consumed by this deployment flow.

Suggested reviewers: thedavidmeister

Poem

I’m a rabbit with tokens to sow,
Through HyperEVM’s tables they go.
The Safe takes the keys,
Vaults wire with ease,
And workflows now help them all grow.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
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.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the main change as the HyperEVM token deployment script and includes the relevant issue identifier.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ops/hyperevm-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]

• ops(script): HyperEVM token deploy (RAI-1511) #278 : 2 dependent PRs (#284 , #291 ) 👈 (View in Graphite)
• pin(invariants): HyperEVM invariant surface (RAI-1511) #277
• ops(script): HyperEVM beacon-owner migration + 0.1.1 beacon lib generalisation (RAI-1511) #276
• 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]

Two documentation defects fixed. No executable Solidity, test, or workflow changed — the diff is six /// lines.

1. Chain-name references corrected in script/20260722-deploy-missing-tokens-hyperevm.s.sol

The script was authored from its Ethereum sibling and carried the source chain's name into text describing its own subject. Six, not five — the @param tableUnderlying line was an extra one:

Line	Was	Context that makes it wrong
38	fully-hydrated Ethereum table entry	NoMissingTokens is raised off the HyperEVM table
43	the Ethereum token table have drifted	TokenTableMisaligned compares against the HyperEVM table
49	The Ethereum table's underlying at that row	same error's @param tableUnderlying
96	Assert the Ethereum V4 authoriser	body returns STOX_PROD_AUTHORISER_V4_CLONE_HYPEREVM
110	Ethereum table entry is all-zero	body reads productionTokensHyperEvm()
146	still missing from the Ethereum table	run() deploys against the HyperEVM table

Deliberately left alone, because they name a real other script rather than this one's subject:

• the contract NatSpec naming 20260722-deploy-missing-tokens-ethereum as the shape this one copies (lines 62-63);
• "identical to the executed Ethereum flow" (line 70), whose own clause then correctly says HyperEVM authoriser and HyperEVM Safe;
• the ISetAuthorizer pointer at "the 20260706 script" (line 234).

"Ethereum" and "HyperEVM" are both 8 characters, so no comment re-wrapping was needed and every line stayed within its existing wrap.

2. PR body rewritten to describe the post-execution state

The body described a pre-execution world: it called the table "(all-zero)" and said "the first dispatch deploys the whole 29-token canonical set". Both were true when written and are false now — the deploy executed 2026-07-24 (manual-broadcast run 30114307165, a successful workflow_dispatch at 2026-07-24T17:46:18Z), and productionTokensHyperEvm() was pinned fully hydrated by #277 (8be65e553bf5d5027e4146838228cbd69614a834).

I verified the hydration directly rather than taking it on trust: all 29 rows are populated and the table contains zero zero-addresses, so _selectMissing() reverts NoMissingTokens and the script is inert as merged. That matches what testSelectionRevertsWhenTableFullyHydrated already asserts.

The rewritten body records the execution, the inertness, and the remaining value (provenance plus the machinery a late-added token would re-dispatch into), and keeps the pre-flight ordering paragraph, which is still accurate.

Gates

Run under the repo's own nix develop toolchain (forge 1.6.0-nightly):

• forge build — pass
• forge fmt --check — pass
• forge test — pass
• pre-commit run --all-files — the Solidity-relevant hooks pass. deadnix and nixfmt fail on flake.nix, which is byte-identical to main and untouched by this PR; CI's static job is green on the same file, so that is local toolchain drift, not a regression here.

Note for anyone reproducing locally: a fresh clone needs forge soldeer install before forge build, otherwise the build dies with several hundred unresolved-import errors.

[thedavidmeister]

Reviewed 5248ac4: approve
Rulings-conformance: checked against every ruling stated for this work. (1) "agent both" on the two findings I raised — both fixed and nothing else: six /// lines corrected from Ethereum to HyperEVM (the agent found one more than my list of five — @param tableUnderlying at line 49, a second wrong reference inside TokenTableMisaligned), and the body rewritten to describe what this PR lands today rather than a pre-execution state. No executable Solidity, test or workflow logic touched. (2) "never invent scope" — the three deliberate cross-references to sibling scripts were left alone: 20260722-deploy-missing-tokens-ethereum in the contract NatSpec, "the 20260706 script" on ISetAuthorizer, and "identical to the executed Ethereum flow" at line 70, whose own clause correctly names the HyperEVM authoriser and Safe. The two findings I deliberately excluded — no pranked fork test over the state-changing half, and the transient hot-key initialAdmin = deploy key pattern — are untouched and unmentioned, and remain open decisions about the NEXT dispatch rather than the executed one. (3) "coverage, not manual verification" — the local forge test red was verified as a single class rather than waved through: 270 [FAIL: lines (forge prints each twice), all vm.createSelectFork: environment variable <CHAIN>_RPC_URL not found, enumerated against the completed log rather than a mid-run grep. Zero real failures; this PR's own two tests pass explicitly, and CI's test job is green here. (4) "verify all CI failures before admin-merge" — no red: all six checks SUCCESS, 0 unresolved threads. (5) "no squash-merge for Graphite stacks" — merging with --merge; this is the last of the RAI-1511 stack (274/275/276/277 already merged). (6) Workflow-change check: the RPC_URL_HYPEREVM_FORK lines in rainix-sol.yaml and rainix-sol-scheduled.yaml are already on main from #275 — both files are byte-identical to main at this head with exactly one occurrence of the key each, so there is no duplicate mapping key and the merge is a no-op for them. The only CI-config line this PR actually lands is the script name in manual-broadcast.yaml's dropdown; 'hyperevm' as a network and the HYPEREVM_RPC_URL mapping already exist there. (7) Provenance: EXECUTED 2026-07-24 is checkable — manual-broadcast run 30114307165 is a successful workflow_dispatch at 2026-07-24T17:46:18Z, and this PR is the record that #277's pinned table lacked. The script is inert as merged: _selectMissing() reverts NoMissingTokens against the hydrated table, which its own test asserts.