How to Deploy Smart Contracts on Ethereum, Testnets, and Layer 2 Networks

Deploy smart contracts on Ethereum by following a simple production path: build locally, test on a public testnet, fund the right wallet, deploy with Hardhat or Remix, then verify the contract on the correct block explorer. The same pattern works on Ethereum mainnet, Sepolia, Arbitrum, Base, and zkSync Era. What changes is the detail: RPC URLs, gas funding, bridges, and explorer verification.

If you are learning this for a developer role or certification, do not skip the boring parts. Most failed deployments are not Solidity bugs. They are wrong chain IDs, empty wallets, stale RPC URLs, or a private key accidentally pasted into source control. I have watched candidates lose an hour to the exact Hardhat error insufficient funds for intrinsic transaction cost when the wallet held Sepolia ETH but the script was pointed at mainnet.

Smart Contract Deployment Workflow Across Networks

Whether you deploy to Ethereum mainnet, a testnet, or a Layer 2 network, the workflow is mostly the same.

1. Set up your development environment: Install Node.js, Hardhat, Solidity tooling, and testing libraries.
2. Configure RPC access: Use a provider such as Alchemy, Infura, Moralis, or your own node endpoint.
3. Connect a wallet: MetaMask and Coinbase Wallet are common choices for deployment accounts.
4. Fund the wallet: Use real ETH for Ethereum mainnet. Use faucet ETH for Sepolia or L2 testnets.
5. Compile and test locally: Run unit tests before broadcasting a transaction.
6. Deploy with a script or Remix: Use Hardhat for repeatable workflows, or Remix for quick browser-based deployments.
7. Verify the contract: Publish source code and constructor arguments on Etherscan, Arbiscan, BaseScan, or the relevant explorer.

This staged process is the one you should use in real teams: local network first, public testnet second, production last. It is slower than clicking Deploy in Remix right away. It also saves money.

Tools You Need Before Deployment

Hardhat for repeatable deployments

Hardhat is the practical default for scripted Ethereum deployments. It lets you compile contracts, run tests, configure multiple networks, and run deployment scripts with commands such as:

npx hardhat run scripts/deploy.js --network sepolia

A minimal Hardhat network configuration usually includes an RPC URL and a private key pulled from environment variables:

require('@nomicfoundation/hardhat-toolbox'); require('dotenv').config(); module.exports = { solidity: '0.8.24', networks: { sepolia: { url: process.env.SEPOLIA_RPC_URL, accounts: [process.env.PRIVATE_KEY] } } };

Keep the private key in a .env file, then add that file to .gitignore. Never commit it. That sounds obvious until someone pushes a test wallet that later receives real funds.

One version detail matters: many older tutorials use contract.deployed(). With ethers v6, common in newer Hardhat setups, you will often use waitForDeployment() instead. If you see TypeError: contract.deployed is not a function, this is usually the reason.

Remix for quick tests

Remix is useful when you want to deploy a simple contract without setting up a local project. Open Remix, compile the Solidity file, select Injected Provider - MetaMask in the Deploy & Transact panel, confirm the wallet is on the target network, then deploy.

Use Remix for education, prototypes, and quick demonstrations. For production, use Hardhat or Foundry so your deployment is repeatable and reviewable.

How to Deploy Smart Contracts on Ethereum Mainnet

Ethereum mainnet deployment is the same technical process as a testnet deployment, but the risk profile is different. You pay real ETH. The deployed bytecode is public. If your constructor parameters are wrong, you cannot quietly edit the contract later unless you designed an upgrade path.

Mainnet checklist

• Use Ethereum mainnet chain ID 1.
• Fund the deployment wallet with enough ETH for gas under EIP-1559 fee mechanics.
• Configure a mainnet RPC URL from a reliable provider.
• Run the exact deployment script against a fork or testnet first.
• Verify the contract on Etherscan after deployment.
• Record the contract address, transaction hash, compiler version, and constructor arguments.

To be blunt, do not deploy to mainnet from a laptop project folder you have not tested in CI or reviewed with another developer. Even a simple ERC-20 or ERC-721 contract can fail operationally because of ownership settings, missing roles, or wrong metadata URIs.

If your goal is professional readiness, Blockchain Council's Certified Smart Contract Developer™ and Certified Ethereum Expert™ are relevant learning paths to pair with hands-on deployment practice.

How to Deploy to Ethereum Testnets

Ethereum testnets give you realistic wallet behavior, gas estimation, block explorers, and public transaction history without spending real ETH. For most application testing, use Sepolia. Holesky is widely used for validator and staking infrastructure testing. Goerli appears in many older tutorials, but it has been deprecated and most teams have moved off it.

Sepolia deployment steps

1. Create or choose a deployment wallet: Use a dedicated MetaMask account, not your personal mainnet wallet.
2. Get Sepolia ETH: Use a faucet from a provider such as Alchemy or another trusted faucet.
3. Create an RPC endpoint: Set up a Sepolia endpoint in Alchemy, Infura, Moralis, or your provider of choice.
4. Configure Hardhat: Add a sepolia network entry with the RPC URL and private key.
5. Compile: Run npx hardhat compile.
6. Deploy: Run npx hardhat run scripts/deploy.js --network sepolia.
7. Verify: Use Sepolia Etherscan and provide the source, compiler version, license, and constructor values.

Testnet verification is not just cosmetic. Front-end developers can pull the ABI from the explorer, auditors can inspect the source, and teammates can call read and write functions without asking you for build artifacts.

How to Deploy Smart Contracts on Layer 2 Networks

Layer 2 networks reduce costs and increase throughput by processing activity away from Ethereum mainnet while still connecting back to Ethereum's security assumptions in different ways. For deployment, they feel familiar because many are EVM-compatible. You still compile Solidity. You still use wallets. You still verify contracts. The extra step is often bridging funds.

Arbitrum deployment flow

Arbitrum deployments with Hardhat follow the Ethereum testnet pattern, with L2-specific RPC and explorer settings.

1. Get Sepolia ETH on Ethereum Sepolia.
2. Use the official Arbitrum bridge to move test ETH to Arbitrum Sepolia.
3. Add the Arbitrum Sepolia RPC URL to Hardhat.
4. Store PRIVATE_KEY, ARBITRUM_RPC_URL, and explorer API keys in .env.
5. Deploy with npx hardhat run scripts/deploy.js --network arbitrumSepolia.
6. Verify on Arbiscan with the correct compiler version and constructor arguments.

The bridge step is where beginners get caught. If your wallet shows ETH on Sepolia L1, that does not mean you have ETH on Arbitrum Sepolia. They are different networks with different balances.

Base deployment flow

Base, Coinbase's Ethereum Layer 2, uses a similar EVM workflow. Add the Base network to your wallet, fund the account on the target Base environment, then deploy through Hardhat, Foundry, Remix, or a deployment platform.

Older guides often mention Base Goerli. In current projects, check the latest Base documentation before choosing a testnet, because L2 testnet names and support windows change. The principle stays the same: configure the chain, bridge or request test funds, deploy, then verify on the matching explorer.

zkSync Era deployment flow

zkSync Era can be tested quickly through Remix and MetaMask for simple contracts such as SimpleStorage. Configure MetaMask for the zkSync Era testnet, obtain test ETH from a faucet, select Injected Provider - MetaMask in Remix, and deploy.

For serious zkSync projects, check compiler and tooling requirements carefully. Not every EVM habit transfers perfectly to every zk-rollup environment, especially when specialized compilers or account abstraction features are involved.

Mainnet, Testnet, or L2: Which Should You Choose?

• Use a local Hardhat network when you are writing and breaking code quickly.
• Use Sepolia when you need public Ethereum-style testing with faucets and Etherscan verification.
• Use Ethereum mainnet only when contracts have passed tests, review, and operational checks.
• Use Arbitrum or Base when your application needs lower transaction costs and broad EVM compatibility.
• Use zkSync Era when you are specifically testing zk-rollup deployment behavior or applications suited to that ecosystem.

My practical recommendation: learn on Sepolia first, then repeat the same deployment on Arbitrum Sepolia or Base. That gives you the mental model for both L1 and L2 without spending meaningful gas.

Security Practices Before You Deploy

• Use a dedicated deployment wallet for each environment.
• Store secrets in environment variables, never in source files.
• Run unit tests and at least one public testnet deployment.
• Verify source code immediately after deployment.
• Check the selected network in MetaMask before approving.
• Keep a deployment log with addresses, transaction hashes, and compiler settings.
• Do not rely on upgradeability unless you understand proxy patterns and admin key risk.

For teams, add automated tests and security review before mainnet. If the contract holds user funds, get an external audit. A green Hardhat test suite is helpful, but it is not an audit.

Build Your Next Deployment Pipeline

Start with a small contract, deploy it locally, then deploy the same contract to Sepolia, Arbitrum Sepolia, and one more L2 of your choice. Verify each deployment and write down what changed: RPC URL, chain, faucet or bridge, explorer, and gas behavior.

If you want a structured path, pair this exercise with Blockchain Council's Certified Blockchain Developer™ or Certified Smart Contract Developer™. Your next concrete task is simple: create a Hardhat project, deploy one Solidity 0.8.x contract to Sepolia, and verify it on Etherscan before moving to an L2.