Deploying a smart contract to Ethereum mainnet is the moment when the cost of error is highest. Every line of code, every gas parameter, and the choice of proxy pattern directly impact security and budget. Imagine: you've written the contract, run tests, everything looks good. You deploy to mainnet and... the transaction stalls due to incorrectly set gas, or you discover that the constructor is called with wrong arguments and the contract needs to be redeployed. Such mistakes cost time and money. Our approach minimizes risks. Over many years, we have deployed more than 200 contracts with a combined TVL exceeding $50M. Mainnet deployment is a point of no return: a contract without an upgradeable pattern cannot be changed, logic errors cost real money, and incorrectly set gas parameters can lead to a stuck transaction during peak network load. That's why we offer turnkey deployment with full verification.
How to Prepare for Mainnet Deployment?
Before sending the transaction, we go through a mandatory checklist. It includes audit and testing, compiler verification, and network configuration.
Pre-deployment checklist:
-
Audit and testing:
- Test coverage ≥95% by statement coverage (Hardhat Coverage or Foundry
forge coverage). - Run Slither — a static analyzer that detects reentrancy, integer overflow, unused return values. Slither documentation
- Check with Mythril or Aderyn for deep symbolic execution.
- For contracts with TVL >$100k, mandatory external audit.
Compiler verification:
- Fixed Solidity version: use
=0.8.20instead of^0.8.20. - Optimizer runs: standard 200 for balance of deployment gas and call gas; for frequently called contracts, 1000+.
- Bytecode determinism check: compiling twice yields identical bytecode.
- Test coverage ≥95% by statement coverage (Hardhat Coverage or Foundry
Why Are Audit and Testing Important?
A logic error can lead to loss of user funds or the project itself. There is a known case where the lack of msg.sender verification in an ERC-20 token allowed an attacker to drain all liquidity. We guarantee that every contract passes at least static analysis and stress testing. For large projects, we engage external auditors.
Step-by-Step Deployment via Hardhat
// hardhat.config.ts const config: HardhatUserConfig = { networks: { mainnet: { url: process.env.MAINNET_RPC_URL!, // Infura/Alchemy/Quicknode accounts: [process.env.DEPLOYER_PRIVATE_KEY!], gasPrice: 'auto', }, }, etherscan: { apiKey: process.env.ETHERSCAN_API_KEY!, }, }; // deploy script async function main() { const [deployer] = await ethers.getSigners(); console.log('Deployer balance:', ethers.formatEther( await deployer.provider.getBalance(deployer.address) )); const Contract = await ethers.getContractFactory('MyContract'); const contract = await Contract.deploy(/* constructor args */); await contract.waitForDeployment(); const address = await contract.getAddress(); console.log('Deployed to:', address); // Verification on Etherscan await run('verify:verify', { address, constructorArguments: [/* args */], }); } Steps:
- Configure network and RPC.
- Compile with a fixed compiler.
- Deploy via script with constructor args.
- Automatic verification via hardhat-etherscan.
Gas and Priority Fees (EIP-1559)
After EIP-1559, transactions use maxFeePerGas and maxPriorityFeePerGas. Our engineers dynamically estimate parameters:
const feeData = await provider.getFeeData(); // maxFeePerGas: baseFee * 2 + maxPriorityFeePerGas (2x buffer for baseFee growth) // maxPriorityFeePerGas: 1-3 Gwei for normal deployment | Situation | maxPriorityFeePerGas | Strategy |
|---|---|---|
| Deployment in calm network | 1–3 Gwei | Save gas, longer wait |
| Urgent deployment during congestion | 5–10 Gwei | Fast transaction, higher cost |
Monitor current gas price: eth_gasPrice via blockchain explorers or APIs. Configuring EIP-1559 can save up to 30% on gas compared to fixed gasPrice.
Managing the Deployer Private Key
We never deploy with a key used for other operations. The scheme:
- Separate wallet for deployment only.
- Fund it via a multisig (Safe) with the exact deployment amount plus a small buffer (5–10%).
- After deployment, transfer ownership to multisig:
contract.transferOwnership(safeAddress). - Deployer private key stored in a secrets manager (AWS Secrets Manager, HashiCorp Vault), not in
.env.
After Deployment
- Verify source code on Etherscan (via
hardhat-etherscanorhardhat-verify). - Record the contract address in a deployment manifest with chainId, blockNumber, txHash.
- Check all view functions (often 20+) via Etherscan Read Contract.
- Test call each write function (3-5) with minimal parameters.
- Set up monitoring (Tenderly Alerts or OpenZeppelin Defender) for critical events.
What's Included in Our Turnkey Deployment
| Stage | Result |
|---|---|
| Audit and testing | Slither, Mythril report, test coverage |
| Configuration | Hardhat/Foundry config, RPC, gas |
| Deployment | Contract address, Etherscan link |
| Verification | Confirmed source code |
| Ownership transfer | Ownership to customer's multisig |
| Monitoring | Tenderly/Defender dashboard |
| Documentation | Deployment manifest, usage instructions |
When to Use Upgradeable Contracts?
If you need the ability to update logic, deploy via a proxy pattern (UUPS or Transparent Proxy from OpenZeppelin). This adds complexity and gas overhead but allows fixing bugs after deployment. UUPS is preferred over Transparent Proxy — upgrade logic resides in the implementation contract, saving ~30% gas on each call via the proxy.
We use battle-tested libraries and patterns. Our experience: over 10 years in blockchain development, certified Solidity engineers. We guarantee the contract will be deployed securely and gas-optimally. Discuss your project with our engineers. Order turnkey deployment: get a consultation and accurate estimate.







