Multisig Rollout (LI.FI Contracts)

Multisig Rollout (LI.FI Contracts)

Drives the production rollout lifecycle in two modes:

• deploy mode — get a facet/periphery contract (version currently in the repo) on-chain across production networks and proposed to each Safe. The deploy itself (preflight, target resolution, the deploy, diamond-called-periphery allowlist sync, explorer verification) is delegated to the deploy-contract skill; this skill owns the proposal lifecycle around it.
• whitelist mode — given a merged whitelist PR, sync config/whitelist.json onto the affected chains' diamonds, proposing the changes to each chain's Safe.

Both modes converge on the same tail: capture proposals → (deploy mode only) draft PR with addresses → hand off hardware-wallet signing → verify signatures in MongoDB → post the #dev-sc-multisig-proposals Slack thread.

PolymerCCTP add-on: a PolymerCCTPFacet rollout that adds a chain or CCTP corridor also has to propagate its chainId→CCTP-domain mapping to every already-live chain — extra Safe proposals that ride through the same tail. See Phase 3b.

Signing model (Safe threshold is 3): a freshly created proposal already carries one signature. The user running this skill adds a second via confirm-safe-tx.ts. The Slack thread then recruits the remaining signer(s) to reach the threshold, the last of whom executes. So the verification gate before posting is "the runner has signed" — signatureCount >= 2 — deliberately short of the threshold; recruiting the rest is the whole point of the Slack ask.

See also: the wallet-rotation orchestrators rotate-deployer-wallet and offboard-sc-dev drive this skill to propose Safe owner / CANCELLER-role swaps.

Hard rails

• Never run confirm-safe-tx.ts yourself. Signing uses the user's hardware wallet; only the human can do it. Your job ends at giving the exact command.
• Never post to Slack before the signature verification gate passes. The Slack message asks the team to spend their time signing — it must be accurate.
• Production double opt-in: the entry scripts (deployContractToNetworks.sh via deploy-contract, and syncWhitelistToNetworks.sh) require --production on the CLI and PRODUCTION=true in .env. Do not edit .env to satisfy this — if it mismatches, stop and tell the user.
• SEND_PROPOSALS_DIRECTLY_TO_DIAMOND must NOT be true (it would bypass the Safe). Abort if set.
• Confirm the resolved plan (contract/version/networks or PR/networks) with the user before executing — deployments cost gas and mint Safe proposals on many chains.

Phase 0 — Preflight

Proceed optimistically — do not pre-gate on tunnel or signing. Assume the human has the lifi-connect tunnel up (per docs/Setup-agents.md). Do not ask "how should we run this given I can't open the tunnel / sign" — just execute. The MongoDB scripts fail fast (list-pending-proposals.ts exits 2) if the tunnel is actually down, and signing is handed off in Phase 6 when it's actually needed. The only up-front gate is confirming the resolved plan (contract/version/networks) in Phase 2, since it costs gas across many chains.

Run from the repo root. Check and report (don't fix silently) the lifecycle prerequisites:

• .env exists, PRODUCTION=true, SEND_PROPOSALS_DIRECTLY_TO_DIAMOND not true, MAX_CONCURRENT_JOBS set.
• gh auth status OK; Slack MCP connected (needed in Phase 8 — warn early if missing, posting falls to the user).
• Working tree clean enough to branch later (deploy mode creates a PR from deployment-log changes).
• lifi-connect tunnel: verified implicitly later — list-pending-proposals.ts exits 2 with a clear message when the tunnel is down; relay that to the user when it happens.

In deploy mode, deploy-contract re-checks the deploy-side prerequisites (Foundry, deployer balances, the .env/--production agreement) before touching any network — don't duplicate that here.

Phase 1 — Resolve targets

Do not invoke deploy-contract yet. Phase 1 is target-resolution only; the deploy runs in Phase 2 after the user confirms the plan.