Pre-Mainnet Security Checklist for Smart Contract Teams

By the Guardian team Updated November 2026 5 min read

Quick answer. Before mainnet, confirm that the deployed code is the audited, fix-reviewed commit, every parameter matches a reviewed spec, and admin roles sit with a timelocked multisig. Then confirm monitoring and a tested pause are live before deposits.

Watch: Pre-Mainnet Security Checklist for Smart Contract Teams 1:46

Video transcript

Launch is the last moment a mistake costs nothing. Many failures need no new bug, just audited code deployed, configured or owned wrong.

Freeze the code at the audited commit plus reviewed fixes. Close every finding, have the auditor review every fix, and pin compiler settings.

Fix reviews matter. Across 125 onchain reports in Guardian's published portfolio, remediation rounds surfaced 18 Criticals.

Correct code with wrong settings is still a vulnerability. Review every parameter independently, start with low caps, and test on a mainnet fork.

Map every privileged role. Upgrades sit behind a timelocked multisig, the pauser can only pause, and the deployer keeps nothing.

Drift moved to a two of five multisig with zero timelock, Chainalysis reported. Days later, an estimated 285 million dollars was drained.

Before the first deposit, have alerts live, named people on call, a rehearsed pause, a bug bounty and an incident runbook ready.

On launch day, deploy and initialize each proxy atomically and read its implementation slot. Verify exact bytecode, activate markets in one batch, then open with caps.

Attackers have front-run proxy initialization, and Sonne Finance lost about 20 million dollars to a non-atomic market activation. Rekt's lesson? Be atomic.

Vanguard adds two independent audit teams and an invariant suite. Read the full checklist, or get a Vanguard quote at guardian.security.

Launch is the last moment a mistake costs nothing. After it, users' deposits are on the line.

Many launch failures need no new bug. Audited code gets deployed wrong, configured wrong or owned by the wrong key.

Work through this checklist before the deployment window opens, and again on the day. Not audited yet? Start with how to prepare for a smart contract audit.

Code Freeze and Audit Closure

Freeze the code at the audited commit plus reviewed fixes. Nothing else ships.

Every finding fixed, or acknowledged with a written reason.
Every fix reviewed by the auditor, not just merged.
Compiler version and optimizer settings pinned to the audited build.
Tests, invariant suite and coverage passing on the final commit.
Known issues written down, ready for your bounty scope.
Any later change sent back through your change process.

Fix reviews are not a formality. In Guardian's published portfolio, remediation rounds in 125 onchain reports surfaced 18 Criticals and 119 Highs.

Changes after an audit carry the same risk: see what 49 update reviews found.

Configuration and Parameters

Correct code with the wrong settings is still a vulnerability. Put every value in a deployment spec that someone other than its author reviews.

Constructor and initializer arguments, per contract and per chain.
Oracle addresses, decimals, heartbeats and stale-price handling.
Caps, fees, collateral factors and liquidation thresholds.
Token addresses and decimals on every chain.
Cross-chain peers, endpoints and message settings.
External addresses: routers, bridges, treasuries and fee receivers.

Start conservative. Low caps and collateral factors can be raised after a clean period.

Then test the spec, not just the code. Run end-to-end tests on a fork of mainnet with the real deployment parameters.

Roles, Keys and Ownership

List every privileged role before launch: who holds it, what it can do, and how fast.

Role	Should sit with	Delay
Upgrader and proxy admin	A high-threshold multisig	Long timelock
Parameter setter	A multisig, within coded bounds	Medium timelock
Pauser	A small, always-reachable signer set	None, pause only
Minter or treasury	A separate multisig with limits	Per policy
Deployer	Nobody, once launch is done	Rights revoked

Put signer keys on hardware wallets, and have signers decode calldata on the device.

Then verify each multisig onchain before its first real use. SEAL's framework says the deployed setup must match the plan: owners, threshold, modules, delegated proposers and network.

Drift shows the cost of no delay. On March 26, 2026, it migrated to a new 2-of-5 Security Council multisig with zero timelock, Chainalysis reported.

On April 1, two pre-signed transactions transferred admin control, and an estimated $285M was drained. See how the Drift exploit worked.

Monitoring and Pause Readiness

Monitoring has to be live before the first deposit, not after the first incident.

Alerts on upgrades, role changes, parameter changes and large flows.
Invariant checks on live state: supply, solvency, collateral.
Alerts routed to named people on call, with an escalation path.
A pause rehearsed on a fork by the signers who will run it.
Backup RPCs and signing interfaces, tested in advance.
A bug bounty live from day one, with known issues listed.
An incident runbook with contacts, including SEAL 911.

SEAL's framework asks for 24/7 availability of a threshold of emergency signers. It recommends bi-annual paging tests and an annual full emergency simulation with all signers.

SEAL 911 describes itself as "24/7 cryptocurrency incident response for the crypto ecosystem". Know how to reach it before you need it.

For tooling, see the best smart contract monitoring tools.

Deployment Day Steps

Deploy from a reviewed, scripted run. Record every address.
Deploy and initialize each proxy in the same transaction.
Read each proxy's implementation slot directly and confirm the address.
Verify source, and check for an exact match with the audited build.
Confirm every role holder onchain, and that the deployer holds nothing.
Activate markets and parameters in one atomic transaction or batch.
Run smoke tests with small amounts.
Open with caps, then publish the verified addresses.

Sourcify calls it an exact match when the deployed bytecode is "byte-by-byte the same (excluding libraries and immutables)" as the compiled output, metadata included.

Why atomic initialization matters

In July 2025, Dedaub reported an attack it named CPIMP, for "Clandestine Proxy In the Middle of Proxy". Attackers front-ran the initialization of new proxies.

It had already infected "several tens of contracts" across chains, and it misled Etherscan about which implementation was live.

Nethermind's guidance: deploy and initialize in a single transaction, and "read the ERC1967 implementation slot directly" rather than trusting explorer pages.

For other initializer mistakes, see five upgradeable contract vulnerabilities.

Why atomic activation matters

In May 2024, Sonne Finance queued a proposal to activate a new VELO market at a 35% collateral factor. Once the timelock expired, anyone could execute it.

An attacker executed it together with a known donation attack in one transaction, taking about $20M, Rekt reported. Its lesson: "be atomic".

The Checklist at a Glance

Area	Done when
Code	Deployed bytecode exactly matches the audited, fix-reviewed commit
Configuration	Every value matches a reviewed spec, tested on a fork
Roles and keys	Deployer holds nothing; upgrades sit behind a timelocked multisig
Monitoring	Alerts, on-call, bounty and a rehearsed pause are live
Deployment	Proxies initialized atomically; markets activated in one batch

How Guardian Helps Before Launch

Vanguard puts two independent teams on one scope, one of them powered by Helix, Guardian's AI auditor. Guardian also writes an exhaustive invariant suite around your safety properties.

After the audit, Guardian funds a $100,000 Defender contest on the same scope, non-blocking for deployment. It also hosts your bug bounty, with $50,000 in Critical matching.

Deployment is its own discipline. Since February 2025, Guardian has verified every step of USDT0's omnichain rollout, from bytecode and peers to the multisig transactions that carry it out.

On Polygon in August 2025, the contracts were correct but the migration playbook was not. The queued transactions would have left more USDT0 circulating than USDT backing it.

Guardian flagged it, and it was fixed before the transactions ran. Read the USDT0 deployment verification case study.

Frequently Asked Questions

What should a team check before deploying smart contracts to mainnet?

Check that the deployed code is the audited, fix-reviewed commit and that parameters match a reviewed spec. Admin roles belong with a timelocked multisig, not the deployer. Monitoring, a bounty and a rehearsed pause should be live.

Should you deploy and initialize a proxy in the same transaction?

Yes. An uninitialized proxy can be taken over by whoever calls its initializer first. Pass the initialization data to the proxy constructor, then read the implementation slot directly to confirm it points where you expect.

Who should hold admin roles at launch?

Not the deployer. Upgrade rights belong with a high-threshold multisig behind a timelock. Parameters go to a multisig limited to coded bounds, and pausing to a small, always-reachable signer set that can only pause.

How do you confirm deployed code matches the audit?

Rebuild the audited commit with the same compiler settings and compare bytecode, for example through Sourcify, where an exact match includes the metadata. For proxies, check the implementation each proxy actually points to.

Sources

Launch with every surface reviewed

Vanguard audits your code with two teams and an invariant suite, then keeps reviewing every change for six months after production.

Get a Vanguard quote See how Vanguard works