feat(multichain): HyperEVM V4 authoriser clone pin plumbing (RAI-1511)

[hardyjosh]

• LibSafeInvariants.HYPEREVM_CHAIN_ID = 999.
• BuildPointers emits STOX_PROD_AUTHORISER_V4_CLONE_HYPEREVM = address(0)
  into the generated lib — the unhydrated pin, symmetric with the Ethereum
  clone pin's pre-deploy state.
• 20260619 clone-deploy script's activeChainClonePin() gains the HyperEVM
  branch, so the same broadcast (already dispatchable on hyperevm via
  manual-broadcast) deploys + configures the HyperEVM authoriser once its
  upstream gates land, and refuses re-deploys after the pin hydrates.

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 workflow option to provision an additional service signer on Base or Ethereum.
  • Added safeguards that validate authoriser readiness, Safe permissions, and required grants before provisioning.
  • Added support for generating Safe transaction artifacts and verifying provisioning results.
  • Added HyperEVM support for V4 authoriser deployment and chain configuration.
  • Expanded grant configuration to include the additional service signer.

• Bug Fixes

  • Updated deployment checks to reflect the expanded set of required grants.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds a Safe-based additional service signer provisioning script for Base and Ethereum. It expands canonical grants, adds HyperEVM deployment support, updates workflow network selection, and adds live-fork validation.

Changes

V4 signer provisioning

Layer / File(s)	Summary
Canonical grant and chain contracts src/lib/LibAuthoriserInvariants.sol, src/lib/LibSafeInvariants.sol	The canonical grant map includes three grants for the additional service signer. The signer cannot hold DEFAULT_ADMIN_ROLE.
Clone configuration and deployment pins script/20260619-deploy-v4-authoriser-clone.s.sol, script/BuildPointers.sol, test/script/20260619-deploy-v4-authoriser-clone.t.sol	V4 clone configuration mirrors nine grants. HyperEVM uses a generated clone pin. The consistency test expects nine mirrored grants.
Safe signer provisioning flow script/20260723-provision-additional-service-signer.s.sol, test/script/20260723-provision-additional-service-signer.t.sol	The script validates authoriser, grant, Safe, and role state; simulates missing grants; writes a Safe Tx Builder artifact; and checks revoke/re-grant reversibility. Tests cover Base, Ethereum, fully provisioned state, and partial provisioning. Existing swap live-fork test files are removed.
Multi-network workflow dispatch .github/workflows/run-script.yaml	The workflow registers the new script, accepts base or ethereum, separates concurrency by network, and passes the selected RPC endpoint to forge script.

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

Possibly related PRs

• S01-Issuer/st0x.deploy#197: Shares V4 authoriser grant invariants and clone pinning.
• S01-Issuer/st0x.deploy#273: Shares HyperEVM support and network/RPC workflow plumbing.
• S01-Issuer/st0x.deploy#280: Matches the workflow, provisioning, invariant, deployment, and test changes.

Suggested reviewers: thedavidmeister

Poem

A rabbit checks each grant in line,
Then signs a Safe bundle fine.
Base and Ethereum paths now gleam,
HyperEVM joins the deployment stream.
Revoke, re-grant, the checks all prove:
The signer is ready to approve.

🚥 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 summarizes the primary HyperEVM V4 authoriser clone pin plumbing changes.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/hyperevm-authoriser-pin

---

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
• feat(multichain): HyperEVM token-owner Safe pin plumbing (RAI-1511) #275
• feat(multichain): HyperEVM V4 authoriser clone pin plumbing (RAI-1511) #274 👈 (View in Graphite)
• feat(authoriser): additional service signer — canonical pin + provisioning #280
• main

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

[coderabbitai]

Actionable comments posted: 3

🤖 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 `@script/20260619-deploy-v4-authoriser-clone.s.sol`:
- Line 134: The grant-slice documentation must match the 16-entry map: in
script/20260619-deploy-v4-authoriser-clone.s.sol lines 134-134, update
references from six grants and range 7..12 to nine grants and 7..15, and from 13
entries to 16 entries; in test/script/20260619-deploy-v4-authoriser-clone.t.sol
lines 335-335, update the replica description from six grants and 7..12 to nine
grants and 7..15.

In `@src/lib/LibSafeInvariants.sol`:
- Around line 197-198: Add the correct HyperEVM token-owner Safe address and
include HYPEREVM_CHAIN_ID in safeForChainId alongside the existing BASE_CHAIN_ID
and ETHEREUM_CHAIN_ID mappings. Ensure DeployV4AuthoriserClone.run() can pass
assertActiveChainTokenOwnerSafe(block.chainid) on chain 999, and add a HyperEVM
fork test covering this pre-flight deployment path.

In `@test/script/20260723-provision-additional-service-signer.t.sol`:
- Around line 59-65: Make the provisioning tests deterministic: in
test/script/20260723-provision-additional-service-signer.t.sol lines 59-65, use
fixed pre-provisioning fork blocks for the happy path or assert the
already-provisioned outcome; in lines 88-102, construct a controlled
partial-grant state so DEPOSIT and WITHDRAW are genuinely missing instead of
mocking CERTIFY alone. Update the PENDING and post-execution lifecycle text in
script/20260723-provision-additional-service-signer.s.sol lines 35-71 to match
the chosen test strategy and current deployment state.

🪄 Autofix

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 Plus

Run ID: d54f26c1-08bc-4925-b030-082ebb88b993

📥 Commits

Reviewing files that changed from the base of the PR and between 985dfdd and b4ea3ba.

⛔ Files ignored due to path filters (1)

• src/generated/LibProdDeployV4.sol is excluded by !**/generated/**

📒 Files selected for processing (10)

• .github/workflows/run-script.yaml
• script/20260619-deploy-v4-authoriser-clone.s.sol
• script/20260723-provision-additional-service-signer.s.sol
• script/BuildPointers.sol
• src/lib/LibAuthoriserInvariants.sol
• src/lib/LibSafeInvariants.sol
• test/script/20260619-deploy-v4-authoriser-clone.t.sol
• test/script/20260722-swap-remaining-vault-authorisers.t.sol
• test/script/20260722-swap-rklb-authoriser.t.sol
• test/script/20260723-provision-additional-service-signer.t.sol

💤 Files with no reviewable changes (2)

• test/script/20260722-swap-remaining-vault-authorisers.t.sol
• test/script/20260722-swap-rklb-authoriser.t.sol

[coderabbitai]

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Keep grant-slice documentation consistent with the 16-entry map.

• script/20260619-deploy-v4-authoriser-clone.s.sol#L134-L134: update six-grant, 7..12, and 13-entry descriptions to nine grants, 7..15, and 16 entries.
• test/script/20260619-deploy-v4-authoriser-clone.t.sol#L335-L335: update the replica description from six grants and 7..12 to nine grants and 7..15.

📍 Affects 2 files

• script/20260619-deploy-v4-authoriser-clone.s.sol#L134-L134 (this comment)
• test/script/20260619-deploy-v4-authoriser-clone.t.sol#L335-L335

🤖 Prompt for 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.

In `@script/20260619-deploy-v4-authoriser-clone.s.sol` at line 134, The
grant-slice documentation must match the 16-entry map: in
script/20260619-deploy-v4-authoriser-clone.s.sol lines 134-134, update
references from six grants and range 7..12 to nine grants and 7..15, and from 13
entries to 16 entries; in test/script/20260619-deploy-v4-authoriser-clone.t.sol
lines 335-335, update the replica description from six grants and 7..12 to nine
grants and 7..15.

[coderabbitai]

🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Add the HyperEVM Safe mapping before enabling this chain ID.

safeForChainId in this file handles only BASE_CHAIN_ID and ETHEREUM_CHAIN_ID at Lines 473-480. DeployV4AuthoriserClone.run() calls assertActiveChainTokenOwnerSafe(block.chainid) before deployment, so block.chainid == 999 always reverts with UnsupportedChainForTokenOwnerSafe. The new HyperEVM clone branch is therefore unreachable. Add the correct HyperEVM Safe address and mapping, then add a HyperEVM fork test for this pre-flight path.

🤖 Prompt for 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.

In `@src/lib/LibSafeInvariants.sol` around lines 197 - 198, Add the correct
HyperEVM token-owner Safe address and include HYPEREVM_CHAIN_ID in
safeForChainId alongside the existing BASE_CHAIN_ID and ETHEREUM_CHAIN_ID
mappings. Ensure DeployV4AuthoriserClone.run() can pass
assertActiveChainTokenOwnerSafe(block.chainid) on chain 999, and add a HyperEVM
fork test covering this pre-flight deployment path.

[thedavidmeister]

Reviewed b814c8e: pass

Root of the five-PR HyperEVM stack (274 → 275 → 276 → 277 → 278), reviewed as a stack root rather than in isolation.

Two findings I raised and then retracted, both verified against the chain rather than the repo.

I first read STOX_PROD_AUTHORISER_V4_CLONE_HYPEREVM = address(0x66566cc9…) as a copy-paste of the Ethereum pin, because the PR body says it emits address(0). It is neither stale nor wrong: the clone was deployed after the body was written, and identical addresses across chains is what Zoltu CREATE2 produces from the same init code and salt. eth_getCode on HyperEVM returns the EIP-1167 proxy 0x363d3d373d3d3d363d73**2ea0d35d0b1f57c42e6130f298930228bcbfde9b**5af43d…, byte-identical to Ethereum at the same address, so the single pinned STOX_PROD_AUTHORISER_V4_CLONE_CODEHASH covers both. The pinned != address(0) guard at line 200 therefore reads as intended — the pin is hydrated because the deploy happened, and re-dispatch is correctly refused.

I then reported that the PR adds a production pin with no prod check behind it: StoxCrossChainParity.t.sol forks Base and Ethereum only, and no test file mentions HyperEVM. True of this PR alone, and wrong about the change. #277 (pin/hyperevm-invariant-surface) adds 101 lines to that exact parity test plus 16 to StoxProdV4.t.sol. The stack sequences the assertions after the things they assert exist — pin the address, pin the Safe, migrate beacon ownership, then assert the surface, then deploy tokens. Judging a stack root as if it were standalone was my error.

What remains is an 11-line pin-plumbing change: the chain id, the generated pin, the generator line that emits it, and one branch in activeChainClonePin(). The generator and the generated file agree, which is what the copy-artifacts gate exists to prove.

Rulings-conformance: checked against this repo's conventions and the standing rulings for this work.

• Deterministic deploys are CREATE2 and idempotent — an identical address on a second chain is the expected artifact, not a duplication defect.
• Enumerate authority from the chain, never from repo greps. OBEYED: both retractions came from eth_getCode against live RPCs, not from reading the constant.
• *.deploy repos are audited code, internally consistent, tag-released. The pin is generated by BuildPointers.sol and committed to src/generated/, matching byte-for-byte.
• Coverage, not manual verification. The guarantee this stack owes is at 277, and reviewing that is the check that this pin is actually asserted rather than merely present.

CI: all checks pass — rainix-sol / test, static, legal, build-artifact, git-clean, Graphite mergeability, CodeRabbit. Merging with --merge per the standing no-squash rule for Graphite stacks; 275 is based on this head branch and will need retargeting to main.