Deploy Contract (LI.FI Contracts)

Deploy Contract (LI.FI Contracts)

Non-interactive deploy of a single contract to N networks via script/deploy/deployContractToNetworks.sh (scriptMaster use case 1, repeated). Per network it deploys (CREATE3), verifies on the explorer, and registers in the LiFiDiamond:

• facet → diamondCut (a Safe proposal in production, direct cut in staging)
• periphery → diamondUpdatePeriphery
• diamond-called periphery → the above plus an allowlist sync (a second proposal in production)

It stops once the contract is deployed, verified, and registered (production: proposal created carrying the deployer's signature). In the standalone staging path it also lands the resulting deployment-log changes via a draft PR (Phase 4). It never drives hardware-wallet signing or posts to Slack — and in production it leaves the PR to multisig-rollout.

See also: rotate-pauser-wallet calls this skill to redeploy EmergencyPauseFacet with the new pauser when rotating the pauser wallet.

When to use this vs multisig-rollout

Hard rail — don't strand production proposals. A standalone production deploy creates Safe proposals carrying a single signature and then stops; with no PR, no signing hand-off, and no Slack thread, those proposals sit forgotten below threshold. So: if this is a production deploy (--production) and you are not running it as a step inside multisig-rollout, stop and route the user to /multisig-rollout. Only proceed with --production here when multisig-rollout is driving the full lifecycle around you.

PR ownership. The staging path opens its own deployment-log PR (Phase 4). The production PR is not this skill's job — when multisig-rollout drives, skip Phase 4; it opens the single combined PR (logs + nonce table) after capturing proposals.

Environment

The target environment is a double opt-in enforced by the script: staging unless both --production is passed and PRODUCTION=true is in .env. Default standalone use is staging. Never edit .env to flip this — if --production and .env disagree, the script aborts; relay that to the user.

Phase 0 — Preflight

Tron gate — check first. If the target network list includes tron or tronshasta, split them out: this skill's pipeline (deployContractToNetworks.sh, Foundry, CREATE3) has no Tron support at all. Hand those networks to /deploy-contract-tron (a different repo checkout — contracts-tron — and a different toolchain) and continue here only with the remaining EVM networks, if any.

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

• .env exists; PRODUCTION matches the intended environment (true only for a production run); SEND_PROPOSALS_DIRECTLY_TO_DIAMOND not true for production (it bypasses the Safe — legitimate only when bootstrapping a new production network before ownership transfers to the Safe; abort otherwise); MAX_CONCURRENT_JOBS set.
• Foundry available (forge --version); gh auth status OK.
• Working tree state noted — the deploy writes deployments/<net>.json (and, for diamond-called periphery, config/whitelist.json), which the caller commits later.

Phase 1 — Resolve targets

The target list comes from one of two sources: