Future

Cover image for Testnet to Mainnet: The Checklist Every Developer Needs Before Deploying Real Money
Ribhav
Ribhav

Posted on • Originally published at Medium

Testnet to Mainnet: The Checklist Every Developer Needs Before Deploying Real Money

#crypto #blockchain #testnet #mainnet

The $13.5 Million Wake-Up Call

On January 27, 2026, Matcha Meta users lost $13.5 million in a security breach at an integrated protocol. Just two weeks earlier, on January 14, Futureswap's contract on Arbitrum was drained through a reentrancy attack that exploited a three-day cooling period vulnerability.

These weren't obscure testnet experiments. These were live protocols handling real money. The code worked. The tests passed. The audits happened. But attackers still found gaps.

In 2025 alone, crypto hacks surged past $3.4 billion, already exceeding 2024's total. Access control exploits drove 59% of losses, while reentrancy attacks remain #1 on OWASP's Smart Contract Top 10 vulnerabilities list. The Cetus hack drained $223 million in just 15 minutes during Q2 2025, marking DeFi's worst quarter since early 2023.

This is Day 35 of the 60-Day Web3 journey, still in Phase 3: Development. You've learned to write Solidity, test with Foundry, audit with Slither, and query with The Graph. Now comes the moment that separates hobbyists from professionals: deploying contracts that hold real value.

Today's checklist isn't theoretical. It's built from the post-mortems of protocols that deployed in 2025-2026 and learned the expensive way.

Why Testnet Success Doesn't Guarantee Mainnet Safety

Testnets are practice environments where:

  • ETH is free and worthless
  • Attackers don't exist (or don't care)
  • Mistakes cost nothing but time
  • Gas optimization doesn't matter much
  • MEV bots aren't watching your transactions

Mainnet is a hostile environment where:

  • Every transaction costs real money
  • Attackers scan every new contract within minutes
  • Exploits are automated and instant (Cetus lost $223M in 15 minutes)
  • Gas inefficiency drains user funds
  • Front-runners, MEV bots, and arbitrageurs are constantly monitoring

The difference: Sepolia forgives. Mainnet doesn't. Remember the security vulnerabilities we explored in Day 30? Those don't just exist in theory. Reentrancy alone was responsible for the Futureswap attack in January 2026 and remains the #1 vulnerability on OWASP's list.

The Pre-Deployment Checklist (Don't Skip Any)

1. Security Audits & Reviews

Internal review (mandatory):

  • Run Slither on your contracts: slither .
  • Run Aderyn if using Foundry: aderyn .
  • Check for common vulnerabilities: reentrancy, integer overflow, access control, front-running
  • Review the code manually using the audit framework we covered in Day 29
  • Have at least one other developer review your code line-by-line

External audit (highly recommended for anything holding >$10k):

  • Hire a professional audit firm (OpenZeppelin, Trail of Bits, Consensys Diligence, Cyfrin)
  • Budget: $5k-$50k+ depending on complexity
  • Timeline: 2-4 weeks minimum
  • Expect them to find issues, that's the point

Public review:

  • Open-source your code on GitHub
  • Post in security-focused communities (Ethereum Security, Secureum)
  • Offer a small bug bounty even before mainnet launch

Why this matters in 2026: AI-related exploits surged 1,025% compared to 2023, with 98.9% of attacks targeting insecure APIs. Access control flaws drove 59% of total losses in 2025. Automated security tools catch known patterns, but human review catches logic errors that AI misses.

2. Access Control & Admin Keys

Critical question: Who can upgrade, pause, or drain the contract?

Bad practice:

address owner = 0x742d35Cc6634C0xxxxxxb844Bc9e7595f0bEb; // Single EOA
Enter fullscreen mode Exit fullscreen mode

Better practice:

// Multi-sig with timelock
address public constant MULTISIG = 0x...; // 3-of-5 Gnosis Safe
uint256 public constant TIMELOCK = 2 days; // 48-hour delay on admin actions
Enter fullscreen mode Exit fullscreen mode

Checklist:

  • [ ] Use a multi-signature wallet (Gnosis Safe) for admin functions
  • [ ] Implement timelocks for critical operations (48 hours minimum)
  • [ ] Document which addresses control what functions
  • [ ] Consider making the contract immutable if possible
  • [ ] If upgradeable, use transparent proxy patterns with strict governance

2026 context: Access control vulnerabilities were the #1 cause of losses in 2025, accounting for $1.77 billion stolen. Single points of failure in admin keys are the easiest target for attackers. This is why we emphasized testing frameworks in Day 31. Catching these issues before deployment is critical.

3. Gas Optimization & Cost Testing

On testnet, gas is free. On mainnet, inefficient contracts die because users abandon them.

Test with real gas prices:

  • Check current mainnet gas prices (gwei)
  • Calculate cost per transaction at current rates
  • Optimize loops, storage operations, and external calls
  • Use forge snapshot to track gas usage over time

Example comparison:

// Expensive (reads storage multiple times)
function badTransfer(address to, uint amount) public {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount;
    balances[to] += amount;
}

// Optimized (cache storage in memory)
function goodTransfer(address to, uint amount) public {
    uint senderBalance = balances[msg.sender];
    require(senderBalance >= amount);
    balances[msg.sender] = senderBalance - amount;
    balances[to] += amount;
}
Enter fullscreen mode Exit fullscreen mode

Target: Keep common operations under 50,000 gas when possible.

4. Oracle & External Dependency Checks

If your contract relies on external data (Chainlink price feeds, The Graph, other contracts):

Checklist:

  • [ ] Test oracle failure scenarios (what if Chainlink goes down?)
  • [ ] Implement circuit breakers for stale or extreme price data
  • [ ] Have fallback mechanisms or emergency pause functions
  • [ ] Verify oracle addresses are correct for mainnet (not testnet addresses!)
  • [ ] Test what happens if an external contract is upgraded or paused

Common mistake: Hardcoding a Sepolia Chainlink address and deploying to mainnet.

5. Event Logging & Monitoring

You need to know immediately if something goes wrong.

Essential events:

event Deposit(address indexed user, uint256 amount, uint256 timestamp);
event Withdrawal(address indexed user, uint256 amount, uint256 timestamp);
event EmergencyPause(address indexed admin, string reason);
event AdminAction(address indexed admin, bytes4 indexed functionSig);
Enter fullscreen mode Exit fullscreen mode

Set up monitoring before deployment:

  • Use The Graph to index your contract events. We covered how this works in Day 34
  • Set up alerts on Tenderly or OpenZeppelin Defender
  • Monitor for unusual patterns (large withdrawals, repeated failed transactions)
  • Have a Discord/Telegram alert bot for critical events

Real-world lesson: The Cetus hack in Q2 2025 drained $223 million in 15 minutes. Without real-time monitoring and automated circuit breakers, there's no time for manual intervention.

6. Emergency Procedures & Incident Response

Before deploying, answer these questions:

  1. Who can pause the contract in an emergency?

    • Must be available 24/7
    • Should be a multi-sig, not a single EOA

  2. What's the escalation path if an exploit is detected?

    • Who gets notified first?
    • Who has authority to pause?
    • How do you communicate with users?

  3. Do you have a bug bounty program ready?

    • Better to pay a whitehat $50k than lose $13.5M like Matcha Meta
    • Use Immunefi or Code4rena

  4. Is there an emergency withdrawal mechanism for users?

    • Even if the protocol is paused, users should be able to retrieve their funds

7. Deployment Script & Verification

Use a deployment script (don't deploy manually):

// script/Deploy.s.sol
pragma solidity ^0.8.20;

import "forge-std/Script.sol";
import "../src/MyContract.sol";

contract DeployScript is Script {
    function run() external {
        uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
        vm.startBroadcast(deployerPrivateKey);

        MyContract myContract = new MyContract(
            vm.envAddress("MULTISIG_ADDRESS"),
            vm.envUint("INITIAL_SUPPLY")
        );

        vm.stopBroadcast();

        console.log("Deployed at:", address(myContract));
    }
}
Enter fullscreen mode Exit fullscreen mode

Deploy to mainnet:

forge script script/Deploy.s.sol --rpc-url $MAINNET_RPC --broadcast --verify
Enter fullscreen mode Exit fullscreen mode

This deployment script uses Foundry, which we explored in Day 32 when testing AI-generated contracts. The same testing rigor applies to your deployment process.

Immediately after deployment:

  • [ ] Verify contract source code on Etherscan
  • [ ] Transfer ownership to multi-sig
  • [ ] Renounce deployer key privileges
  • [ ] Document deployment transaction hash and contract address

8. Post-Deployment Monitoring (First 48 Hours Are Critical)

Monitor these metrics:

  • Transaction volume and patterns
  • Gas usage compared to estimates
  • Failed transaction rate
  • Unusual wallet interactions
  • Social media mentions (Twitter, Discord, Telegram)

Red flags:

  • Multiple failed transactions from the same address (possible exploit attempt)
  • Sudden large withdrawals
  • Unusual contract interactions
  • Community reports of strange behavior

2026 reality: Attackers scan every new deployment within minutes. Nearly 150 hacks occurred in 2025, with illicit flows hitting a record $15.8 billion. Your first 48 hours are when you're most vulnerable.

The Gradual Launch Strategy

Don't go from zero to millions of dollars in TVL overnight.

Phase 1: Mainnet deployment with caps (Week 1)

  • Deploy to mainnet but limit deposits (e.g., max 10 ETH total)
  • Invite small group of testers
  • Monitor everything obsessively

Phase 2: Increased caps (Week 2-3)

  • If no issues found, increase limits (100 ETH total)
  • Expand to wider community
  • Keep monitoring

Phase 3: Full launch (Week 4+)

  • Remove caps only after sustained safe operation
  • Announce publicly
  • Still maintain monitoring and incident response

Real-World Example: Aave's Deployment Process

Aave, one of DeFi's most successful protocols, follows this process:

  1. Internal testing on private testnet
  2. Public testnet deployment (Sepolia, Goerli) for 2-4 weeks
  3. Security audits from 3+ firms (OpenZeppelin, Trail of Bits, Consensys)
  4. Bug bounty program launched before mainnet
  5. Mainnet deployment to a low-risk chain first (Polygon)
  6. Gradual rollout with conservative caps
  7. Ethereum mainnet deployment only after months of safe operation elsewhere
  8. Continuous monitoring via OpenZeppelin Defender and The Graph

Result: Billions in TVL with minimal security incidents, even as the overall DeFi space lost billions to exploits in 2025.

Common Mistakes That Cost Millions in 2025-2026

Mistake 1: "Our tests passed, we're ready"

  • Tests prove your contract works. They don't prove it's secure.
  • You can't test for vulnerabilities you don't know exist.
  • The Futureswap reentrancy attack passed all tests but exploited a logic flaw in the cooling period.

Mistake 2: "We'll audit after launch if it gets traction"

  • Attackers audit your code the moment it's deployed.
  • Professional auditors need weeks. Attackers need minutes (or 15 minutes if you're Cetus).

Mistake 3: "We'll use a multi-sig after we prove product-market fit"

  • If you prove PMF, you'll have enough TVL to make hacking worthwhile.
  • By then it's too late. 59% of 2025's losses came from access control failures.

Mistake 4: "Gas optimization doesn't matter for our use case"

  • It matters to your users, who will abandon your dApp if transactions cost $50.
  • It matters during network congestion (remember when gas hit 500 gwei?).

Key Takeaway

Testnet is where you learn. Mainnet is where you prove you learned.

The checklist isn't paranoia, it's professionalism. Every item exists because someone lost money by skipping it. In 2025, crypto thefts reached $3.4 billion across nearly 150 hacks. Security audits, multi-sigs, timelocks, monitoring, incident response plans: these aren't optional luxuries for "serious" projects. They're the baseline for deploying any contract that holds value.

Your Day 9 contract was deployed to Sepolia in 60 seconds with zero precautions. That's fine for learning. But if you're deploying to mainnet, even if it's "just" a $1000 NFT collection, you're now responsible for other people's money.

Treat it accordingly.

Think About This

Before deploying your next contract to mainnet, answer honestly:

  1. Has anyone other than you reviewed the code?
  2. Have you run automated security tools (Slither, Aderyn)?
  3. Is admin control in a multi-sig with a timelock?
  4. Do you have monitoring and an incident response plan?
  5. Have you tested with realistic gas prices?

If you answered "no" to any of these, you're not ready for mainnet yet. And that's okay. Better to launch late and secure than fast and exploited.

What's Next

You now know how to safely bridge testnet experimentation to mainnet deployment. Day 36 will focus on gas optimization strategies. Not just making your contract cheaper, but understanding why certain patterns cost more and how to architect for efficiency from the start.

We're 35 days into this 60-day journey, and we've shifted from "how does Web3 work?" to "how do I build in Web3 professionally?" The next phase will focus on project builds: a DAO voting contract, a token with vesting, and real-world deployment patterns.

Resources

Come hang out in Web3ForHumans on Telegram.
Follow me on Medium | Twitter | Future

Read the previous article: The Graph: How Blockchain Apps Query Data Without Running Nodes

Top comments (0)