Ethereum smart contract development involves more than writing Solidity. A team chooses between mainnet and layer 2 networks, designs around gas and storage costs, decides whether the contract can be upgraded, and plans verification, monitoring and audits. This guide covers those Ethereum-specific decisions, and the general principles are in the smart contract development guide.
Where to deploy: mainnet or layer 2
Ethereum mainnet has the highest security and the deepest liquidity, and it charges higher fees. Rollups such as Arbitrum, OP Mainnet, Base and ZKsync Era run the EVM with small differences, cost a fraction of mainnet fees and settle on mainnet.
The Dencun upgrade in March 2024 added blob data for rollups (EIP-4844), and rollup fees fell sharply. The Fusaka upgrade in December 2025 added PeerDAS (EIP-7594), under which each node stores only part of the blob data, so Ethereum can carry more blobs. Most consumer apps now deploy on a layer 2 first.
| Deploy on | Typical use | Points to check |
|---|---|---|
| Ethereum mainnet | High-value DeFi, core protocol contracts, assets that must be as neutral as possible | Gas cost affects every design decision |
| Optimistic rollups | General dApps, DeFi, consumer apps | Withdrawals to mainnet take days. Most sequencers are run by one operator. |
| ZK rollups | Apps that need faster finality on mainnet | Some EVM differences. Check opcode and precompile support. |
Many teams deploy the same contracts on several chains, and CREATE2 through a standard factory gives identical addresses on each chain. A contract at the same address on another chain is not necessarily the same contract, so never assume that two contracts match because their addresses match. See scaling with layer 2 networks for the trade-offs.
Ethereum upgrades that change contract design
The ethereum.org roadmap lists Dencun (March 2024), Pectra (May 2025) and Fusaka (December 2025) as live, while Glamsterdam is in development with a Q4 2026 target. These changes matter most for contract code:
| Change | Upgrade | Effect on contracts |
|---|---|---|
| Transient storage (EIP-1153) | Dencun | Cheap storage that clears at the end of the transaction. Suits reentrancy locks and accounting within one transaction. |
| SELFDESTRUCT limits (EIP-6780) | Dencun | A contract can only be destroyed in the transaction that created it. Do not build upgrade or cleanup patterns on SELFDESTRUCT. |
| Account code delegation (EIP-7702) | Pectra | Normal accounts can delegate to contract code. A caller with no code is no longer surely a human wallet. The check tx.origin == msg.sender no longer proves that a caller is not a contract. |
| Per-transaction gas cap (EIP-7825) | Fusaka | One transaction can use at most 16,777,216 gas (224). Split very large deployments or batch jobs. |
| CLZ opcode (EIP-7939) | Fusaka | Counts leading zero bits in one cheap step, which simplifies bit-scanning code. |
| secp256r1 precompile (EIP-7951) | Fusaka | Verifies P-256 signatures at address 0x100. Passkey and device signatures can be checked on mainnet. |
| MODEXP input limit (EIP-7823) | Fusaka | Each MODEXP input can be at most 8,192 bits. Larger inputs fail. |
The mainnet block gas limit was 60 million on October 19, 2026, up from 30 million at the start of 2025. The 24 KiB limit on deployed contract code (EIP-170) still applies, so large systems split logic across several contracts or libraries.
Designing an Ethereum smart contract for gas
Storage drives most gas costs. Writing a new storage slot costs much more than updating one, and reading cold storage costs more than reading warm storage. These rules keep costs down:
- Pack related small values into one storage slot.
- Emit events for data that only off-chain systems need, instead of storing it.
- Avoid loops over arrays that users can grow without limit.
- Let recipients withdraw payments, instead of pushing payments to many addresses in one call.
Measure gas with Foundry's gas reports, and remember that on layer 2 networks the cost of posting data to mainnet can exceed the cost of execution.
Tools for Ethereum smart contract development
- Foundry (forge, cast, anvil) is the default for many teams. Tests are written in Solidity, and Foundry runs fast fuzz tests, invariant tests and mainnet forks.
- Hardhat is common in teams that work mostly in TypeScript.
- OpenZeppelin Contracts provides audited code for ERC-20, ERC-721, ERC-1155, ERC-4626 vaults, access control and proxies.
- Slither and other static analyzers catch common bugs early.
- Etherscan-family explorers and Sourcify publish verified source code, so verify at deployment so users can read the code they call.
Upgradeability
Users can check an immutable contract once and trust that it stays the same. An upgradeable proxy, such as a UUPS or transparent proxy, lets the team fix bugs, but it also gives an admin power over user funds.
If you use a proxy, use ERC-7201 namespaced storage to avoid storage layout collisions. Put the upgrade role behind a multisig with a timelock, and publish who holds the role. Many protocols keep core contracts immutable and make only peripheral contracts upgradeable.
A development workflow
- Write a specification with invariants, such as "total shares always match total assets."
- Build on standard libraries and keep the code plain.
- Write unit, fuzz and invariant tests, plus fork tests against the real protocols you integrate.
- Run static analysis and an internal review, then order an external smart contract audit.
- Deploy with scripts that anyone can rerun, verify the source and move admin roles to a multisig.
- Monitor events and invariants in production, and run a bug bounty.
For language detail, see Solidity development, and for token contracts, see ERC-20 token development.
Choosing an Ethereum blockchain development company
An Ethereum blockchain development company usually delivers a specification, the contracts, tests, deployment scripts, a front end, and support during the audit. The firm should not audit its own code. Ask each firm these questions:
- Which deployed contracts can the firm show on a block explorer, with verified source?
- Which audit reports cover the firm's past code, and how many high-severity findings did they contain?
- Does the firm write invariant and fork tests, and will you receive the full test suite?
- Who holds admin keys after launch, and how does the firm hand them over?
- Has the firm handled EIP-7702 callers and the Fusaka gas cap in its current code?
Cost depends on novelty and on the value at risk more than on lines of code. A standard token built from OpenZeppelin code can take days, while a DeFi protocol with new logic can take a senior team several months plus more than one audit.
Frequently asked questions
What is an Ethereum smart contract?
An Ethereum smart contract is a program stored at an address on Ethereum. The EVM runs its code when a transaction calls it, and every node checks the result. The code cannot change after deployment unless a proxy pattern was used.
Solidity or Vyper?
Solidity has more tools, libraries and auditors. Vyper is a smaller, simpler language, and several major protocols use Vyper.
Do Ethereum contracts work unchanged on layer 2 networks?
Usually yes. Check differences in block numbers and timestamps, precompiles, gas pricing and chain-specific system contracts, and test on the target chain.
Can a deployed contract be changed?
The code cannot change unless the contract sits behind a proxy, so teams test and audit before deployment.