refactor(script): merge the per-chain token-copy scripts into one

[hardyjosh]

Merges the two per-chain token-copy scripts into one. 20260722-deploy-missing-tokens-ethereum and -hyperevm were byte-identical apart from the chain each hardcoded; both are replaced by 20260807-deploy-missing-tokens, which resolves the target chain's token table, authoriser and Safe from block.chainid.

Net −180 lines. Onboarding a target chain is now a table plus an authoriser pin, rather than another copy of the script.

"Missing" is redefined

Before: a canonical config row whose entry in the target chain's table is all-zero, joined by index.

After: an underlying present in productionTokensBase() and absent from the target chain's table, matched by key.

Base is the source of truth for what the token set is — a ticker is deployed there first, pinned, then copied outward — so a target chain's table simply lags Base until this script runs.

The index-join required every table to be the same length at all times. That meant a ticker could not exist on Base without simultaneously existing as an all-zero placeholder row on every other chain, and it made a partially-filled table an error state that the invariants and the parity pin both had to be taught to tolerate. Matching by key removes all of that: the tables are allowed to differ in length in the window between a Base deploy and its copies, and a new ticker is simply added to the config and Base tables when it is deployed on Base.

Cross-chain parity is red in that window. That is accurate rather than unfortunate — the chains genuinely do differ until the copy lands — so nothing here teaches the suite to tolerate it.

Rollout this supports

1. Tokens are deployed on Base and pinned into productionTokensBase().
2. This script is dispatched per target chain, deploying the difference.
3. Each run's logged tuples are pinned into that chain's table, and parity goes green.

Dispatch

Actions → manual-broadcast, script = 20260807-deploy-missing-tokens, network set to the target chain.

One dispatch covers one chain, because the workflow supplies a single RPC per run. The selection is chain-generic, so the same script serves every target chain.

Per token the deploy is identical to the scripts it replaces: deploy via the 0.1.1 unified deployer (initialAdmin = deploy key) → read back the ERC-1155 receipt → setAuthorizer(target chain's V4 authoriser) → transferOwnership(target chain's token-owner Safe), in one deploy-key broadcast with no Safe signature. Each (underlying, receipt, receiptVault, wrapped) tuple is logged for the pin.

Guard rails

• NoMissingTokens — the target already has every Base token. Also what stops a re-dispatch minting duplicates.
• UnsupportedTargetChain(chainId) — dispatched against Base (the source, not a target) or a chain with no token table. Rejected rather than resolving to an empty table, which would otherwise read as "copy everything".
• TokenTableMisaligned(index, ...) — the config table and the Base table have drifted out of row alignment. Every name/symbol deployed is read from the config row at the Base row's index, so a misaligned pair would deploy a token under the wrong underlying's strings.
• AuthoriserNotReady(address) — the chain's V4 authoriser is unpinned, has no code, or has the wrong codehash.

Reviewer note — an append-only convention is broken here

manual-broadcast.yaml's script dropdown documents itself as append-only, so that a signer or auditor can re-dispatch a historical script's pre-flight against on-chain reality. Merging the scripts deletes the two files, so their dropdown entries are removed too.

The alternative is to keep both files as executed historicals and let the new script supersede them going forward. Flagging it rather than deciding it silently.

Verification

CI steps run locally in nix develop before pushing:

• forge build — clean
• rainix-sol-static — slither 0 findings, forge fmt --check clean
• rainix-sol-legal — REUSE compliant

769 tests passing. Seven new tests cover the selection: an empty target (copies everything), a target missing one token (copies exactly that one, chosen by dropping a row from a copy of Base rather than hardcoding a ticker so it does not go stale), a fully-matched target (NoMissingTokens), per-chain table resolution, and both rejection paths. Failures were diffed against a baseline run of the parent branch; the only non-RPC failures are pre-existing on this stack and unrelated to this change.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 4 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: ee7f8f0c-fa8a-4b03-a852-19544ccc1a74

📥 Commits

Reviewing files that changed from the base of the PR and between 7dee561 and 0d2aa12.

📒 Files selected for processing (13)

• .github/workflows/manual-broadcast.yaml
• CHANGELOG.md
• script/20260722-deploy-missing-tokens-ethereum.s.sol
• script/20260722-deploy-missing-tokens-hyperevm.s.sol
• script/20260807-deploy-missing-tokens.s.sol
• src/lib/LibTokenInvariants.sol
• test/script/20260722-deploy-missing-tokens-ethereum.t.sol
• test/script/20260722-deploy-missing-tokens-hyperevm.t.sol
• test/script/20260807-deploy-missing-tokens.t.sol
• test/script/DeployMissingTokensEthereumHarness.sol
• test/script/DeployMissingTokensHarness.sol
• test/script/DeployMissingTokensHyperEvmHarness.sol
• test/script/ProvisionAdditionalServiceSignerHarness.sol

---

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(tokens): add AAPL, GOOGL, INTC, LLY, MSFT, PTY across Base, Ethereum and HyperEVM #304
• feat(tokens): add HOOD, ORCL, SMCI, BABA, TQQQ across Base, Ethereum and HyperEVM #294
• refactor(script): merge the per-chain token-copy scripts into one #291 👈 (View in Graphite)
• ops(script): HyperEVM token deploy (RAI-1511) #278 : 1 other dependent PR (#284 )
• 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]

Reviewed 0d2aa12: approve

Restacked onto main (the Graphite base was a rebased copy of the HyperEVM
stack, all since landed under different SHAs), so the diff against main is
exactly the script merge. Verified with git cherry that 12 of the 13 base
commits are patch-identical upstream and that the 13th was superseded by
90c0933 with main strictly ahead on every path it touches.

Both main-only commits that touched the deleted files are subsumed rather than
lost: 5248ac4's six chain-name doc corrections have no analogue in a script
that resolves its chain from block.chainid, and 95c4331's harness
extraction is already the shape the unified test ships.

Five review findings addressed in f639081: the config/Base length check no
longer misfires when the config table legitimately runs ahead of Base,
TokenTableTooShort replaces the misalignment error's "<length>" sentinels,
both alignment guards became reachable from tests, run 30114307165 is pinned
into productionTokensHyperEvm(), and the append-only rule now states the
exception the two deletions were made under.

Four coverage gaps closed in 0d2aa12, all traceable to the gap-fill scripts
having dropped checks that 20260706-deploy-tokens-ethereum carries:
assertHandoffLanded is back, DeploymentEventMissing is back,
_assertAuthoriserReady has coverage on all four branches, and the second and
third _assertDeployer calls are shown to fire. 22 tests, up from 10.

One thing this does not close, filed as #297: every live-state check starts from
the pinned tables, so a vault deployed but never transcribed into them is
invisible — and under the new "missing" definition a re-dispatch would deploy a
duplicate for that ticker. That predates this PR and needs enumeration from
chain to answer.

[thedavidmeister]

Reviewed 0d2aa12: approve

Rulings-conformance: checked against the repo CLAUDE.md convention sections and
every instruction stated for this work.

Repo CLAUDE.md:

• Compiler Settings (=0.8.25 in contracts, ^0.8.25 in libraries): the
  unified script, its harness and its test all carry pragma solidity =0.8.25;
  no library pragma changed. foundry.toml is untouched, so the optimizer /
  via_ir / bytecode_hash settings and the single-profile codehash-pinning
  rule are unaffected — this change adds no deployed contract, so the
  StoxReceiptVault EIP-170 margin is not in play.
• Deployment (production deploys run the audited version-specific script,
  never current source; candidate is never a deploy target): untouched. The
  script here is an operational manual-broadcast script, not the audited
  DeployProdV4_0_1_1 path, and no generated snapshot changed.
• Naming Conventions (test helpers must be descriptively named, no
  _foo/_bar/_helper placeholders): the one helper added is
  _deploymentLog, named for what it builds; the script's internals keep the
  leading-underscore visibility convention production code is allowed.
• License (LicenseRef-DCL-1.0, REUSE-compliant): every added and modified
  file carries the SPDX pair; rainix-sol-legal is green.

Instructions stated for this work:

• "restack 291" — restacked by merging main in, never rebase and never
  force-push, which is the standing rule for this Graphite stack. The branch
  moved by fast-forward only.
• "apply 1-5" — all five applied in f639081, none re-argued.
• "add test coverage" — all four gaps covered, not the subset I had
  recommended sequencing; the unqualified instruction widened the scope and it
  was taken as stated. 22 tests, up from 10.
• "file it for a followup" — Nothing verifies the token tables are COMPLETE — enumerate deployments from chain, not from the pins #297 filed and stopped there; the check it
  describes is deliberately NOT implemented in this PR.
• "merge 291" — merged with --merge, never --squash, because feat(tokens): add HOOD, ORCL, SMCI, BABA, TQQQ across Base, Ethereum and HyperEVM #294 is
  stacked on this branch and a squash breaks its restack. No branch deleted.

The one thing knowingly left open is #297: the pinned tables are the query set
for every live-state check, so a deployed-but-never-pinned vault is invisible.
Filed rather than folded in, as instructed.