Smart Contract Deployment Checklist: From Testnet to Mainnet

The release runbook

Follow the dependency order. Post-deployment checks cannot be completed before transactions exist, so distinguish permission to begin deployment from permission to enable user activity.

The owner column names responsibilities. Assign actual people before using the runbook.

A wallet can execute a transaction. It cannot resolve an unanswered product decision or assume responsibility for operating the result.

What belongs in the release manifest

The manifest identifies the release's inputs and resulting deployment. Record the source revision, dependency versions and compiler configuration, including optimizer and target settings when relevant. Store build artifacts with digests so a later investigation can identify which outputs were used.

Review constructor arguments or initializer inputs against the specification. Asset addresses, fee recipients and governance controllers should come from an approved target-network configuration. Compare human-readable names with the actual encoded values before signing. A testnet token address is not evidence of the correct mainnet asset.

After deployment, append transaction references and the address register. For a proxy deployment, identify the user-facing proxy and its implementation, plus any administrative component the chosen architecture uses. Do not reduce a multi-contract release to one explorer link.

Source verification checks correspondence between source/build inputs and deployed bytecode. Ethereum's verification documentation explains that compilation metadata and matching methods affect the result. Record the verifier's actual match status and any limitation. A source match does not itself assess the safety of the contract's business logic.

Rehearse failures, not just the successful sequence

Run the intended deployment and role transitions in an appropriate rehearsal environment. Record which production conditions the rehearsal does not represent, such as live governance availability or a dependency state that may change.

Include interruptions. If implementation deployment succeeds but a later initialization or configuration step fails, the operator needs to know what was already created and what remains incomplete. Review the current chain state before resuming. Blindly repeating a transaction sequence can create a different release or attempt an action that is no longer valid.

For an upgradeable design, confirm the initialization protections and compatibility checks appropriate to it. OpenZeppelin's upgradeable-contract guidance explains why proxy state initialization differs from constructor initialization. Use the project's chosen tooling and versioned process rather than copying an unrelated command from a tutorial.

The testing and acceptance matrix covers contract behavior. Rehearsal adds evidence about the concrete release sequence, configuration and operators. Both need to reference the approved candidate.

Verify who controls the deployed system

List every privileged action and its controller: upgrade, pause, fee change, mint, asset rescue or other product-specific authority. Some releases have only a subset. The register must describe what the deployed contracts can actually do.

Verify authority after transfer through the applicable on-chain reads and agreed non-destructive checks. Record the new controller's ability to perform its role and the removal of temporary privileges. The safe order of grant, transfer and revocation depends on the access-control model. Review that sequence before signing.

OpenZeppelin's access-control guidance describes the responsibilities of owners, roles and timelock participants. A governance configuration also needs available operators. A multi-signature wallet and a delay do not resolve an unavailable proposer or an unclear incident approval process.

Keep production signing keys within the approved custody arrangement. Give the deployment team only the authority the scope requires, with its duration and removal evidence recorded. Source-code handoff and administrative handoff should have separate completion checks.

Monitor the release before opening it to users

Confirm the application, indexer and operational dashboards use the address register for this network. Reconcile a constrained smoke test with the expected events and state changes. Use an approved exposure limit and transaction plan. Do not improvise a production test with unrestricted user funds.

Deliver an alert to the person expected to handle it.

Agree which events or conditions matter, how alerts are routed and what happens if the primary recipient is unavailable. Monitoring that produces a dashboard but no actionable notification does not complete DEP-11.

External dependencies need their own operating checks. If the product relies on an oracle, bridge or keeper, define the dependency's health criteria and response owner. These checks are additions to the runbook, not evidence supplied by an ordinary contract deployment receipt.

OpenZeppelin's mainnet preparation guide treats key management, governance and ongoing operations as production concerns. The runbook assigns those concerns to release-specific evidence and people.

Recovery must fit the deployed architecture

Separate pausing a feature, updating permitted configuration, upgrading logic and migrating to a new deployment. Only use a mechanism the reviewed architecture actually exposes. A product with fixed code may still have mutable parameters or external dependencies. State its recovery limits at that level.

Returning a proxy to an older implementation is not automatically a safe rollback. The current state and any changed layout or initialization must be compatible with the code being restored. A migration may need a new address, asset movement and user coordination. Neither approach reverses transactions that have already changed balances elsewhere.

For each incident action, identify the authority, preconditions, effect on users and point at which the action is complete. Leave unimplemented recovery options marked unavailable. The upgradeability decision guide helps establish those boundaries before development.

Use Pharos smart contract development to scope release preparation and handoff alongside implementation. At handoff, the receiving owner should be able to locate the live manifest, reproduce the build and identify who can authorize the next production change.