How to Build a Smart Contract in Solidity: 2026 Guide

Solidity remains the dominant language for writing smart contracts on Ethereum, Arbitrum, Base, Polygon, Optimism and most other EVM chains. Building one is easy. Building one that handles real money in production, and survives an audit, is a different sport. This guide walks through the workflow we use at Alher Tech to ship Solidity smart contracts that are gas-efficient, upgrade-aware and secure by design.

When You Actually Need a Smart Contract

A smart contract is the right tool when you need verifiable, on-chain enforcement of rules between parties that don't trust each other. Token issuance, vesting, escrow, marketplaces, governance, lending and tokenization of real-world assets all qualify.

If your use case is just a database with a wallet attached, a smart contract is overkill. We've turned down projects where a Postgres table and a JWT would deliver 95% of the value at 10% of the cost.

Multi-party value transfer with no intermediary
Verifiable rules (auctions, vesting, royalties, payouts)
Tokenization of assets, securities or rights
Permissionless access to a system (open marketplaces, DEX)
Public auditability is part of your value proposition

Smart contract code is forever. Once deployed and used, fixing bugs is expensive, sometimes impossible. Every line you write should justify its cost.

The 2026 Solidity Workflow

Modern Solidity development is no longer about Remix and a faucet. Production teams use a pipeline that catches mistakes 1000x cheaper than mainnet does:

Foundry as default toolchain: Faster than Hardhat, native fuzz testing, invariant tests, gas snapshots and forge script for deployment. Hardhat still wins for rich JS tooling integrations, but Foundry is the standard for serious Solidity work.
Solidity 0.8.24+ with named storage: Built-in overflow checks, transient storage, custom errors and the new layout-aware patterns. Version 0.6 contracts are now legacy.
OpenZeppelin v5 contracts: Battle-tested implementations for ERC-20, ERC-721, ERC-1155, AccessControl, UUPS upgradability. Don't roll your own when these exist.
Slither + Mythril + Aderyn in CI: Run static analysis on every PR. Catches reentrancy, uninitialized storage and dozens of common bugs before code review.
Tenderly + Anvil for local debugging: Anvil for blazing-fast local nodes, Tenderly for production-like simulation, mainnet forking, and transaction replay when something breaks.

The Anatomy of a Production Contract

Below is the skeleton we start from for any non-trivial contract. It deliberately uses upgradability, role-based access, custom errors and reentrancy guards: the four things you regret skipping later.

Inherit from OpenZeppelin's UUPSUpgradeable + AccessControlUpgradeable
Use custom errors (revert MyError(arg)) instead of require strings; saves 50-200 gas per revert
Mark all state-mutating functions with explicit role checks
Use ReentrancyGuard on every external function that touches balances
Emit events for every state change, because indexers and off-chain analytics depend on them
Pause functionality (Pausable) for the first 6-12 months post-launch

Storage layout is part of your public API once you're upgradable. Document the slot order. Never reorder existing variables; only append new ones.

Gas Optimization That Actually Matters

Most gas optimization advice on the internet is premature. Here's what actually moves the needle in 2026:

Storage packing: Pack uint128 + uint128 into a single slot instead of two uint256. Saves 20,000 gas on every SSTORE. The single highest ROI optimization.
Custom errors over require strings: Saves 50-200 gas per revert. Removes ~10KB from contract size, helping you fit under the 24KB Spurious Dragon limit.
Calldata over memory for read-only arrays: Function parameters that aren't modified should be calldata. Saves gas on every call.
Cache storage reads in memory: Reading the same storage variable twice in a function costs 2x. Cache it once at the top.
Use unchecked blocks where safe: Solidity 0.8+ adds overflow checks everywhere. In tight loops where overflow is impossible, unchecked saves 30-50 gas per iteration.

Don't optimize until you've profiled with forge snapshot. Most of the time the savings are 5,000 gas on a 200,000-gas function and not worth the readability hit.

Security: The 8 Bugs That Drain TVL

Across the $2B+ lost to exploits in 2024, eight bug classes account for over 80% of incidents. Internalize these.

Reentrancy: External call before state update lets the called contract re-enter and drain funds. Use checks-effects-interactions and ReentrancyGuard. The bug that killed The DAO and many others since.
Access control mistakes: Missing onlyOwner on initialize, public functions that should be internal, role transfer functions without two-step confirmation. Audit every external/public function.
Integer overflow / underflow: Solidity 0.8+ checks by default, but unchecked blocks reintroduce the risk. Be very careful in low-level math.
Oracle manipulation: Using spot price from a low-liquidity AMM is a free-money exploit waiting to happen. Use Chainlink, TWAPs over 30+ minutes, or multiple sources.
Frontrunning / MEV: Public mempool means anyone can sandwich your transactions. Use commit-reveal schemes, MEV-Boost-aware routing or private RPC for sensitive flows.
Signature replay: Off-chain signed messages without nonce or chain ID can be replayed across chains or transactions. EIP-712 with proper nonces is the fix.
Approval / allowance griefing: ERC-20 race condition between approve and transferFrom. Use increaseAllowance/decreaseAllowance or Permit2.
Logic errors in business rules: The hardest class. No tool catches a wrong rounding direction in a fee calculation. This is what manual audits exist for.

Deployment and Verification

Mainnet deployment is the riskiest 30 minutes of a contract's life. The pipeline we use:

Deploy to Sepolia or Holesky first. Run integration tests for at least 7 days against the testnet contract.
Use a deployment script (forge script) that's been peer-reviewed. Never deploy from a developer's local terminal.
Verify on Etherscan immediately after deploy. Unverified contracts kill user trust and break tooling.
Lock initial admin to a Gnosis Safe multisig from minute zero. Never deploy with EOA admin and 'plan to migrate later'.
Time-lock all upgradeable functions for at least 24 hours so users can react to malicious proposals.
Monitor with Tenderly Alerts or Forta on the first month. Get paged the moment something abnormal happens.

Build Once, Build Right

Smart contracts are infrastructure that handles real money in an adversarial environment. The cost of getting it wrong is not a bug ticket. It's a TVL drain on Twitter.

If you're shipping a protocol in 2026, you don't need a freelancer with a Solidity tutorial under their belt. You need engineers who have survived audits, run incident response and shipped to mainnet without losing user funds.

Frequently asked questions

How long does it take to build a smart contract?

A simple ERC-20 with vesting takes 1-2 weeks including tests. A multi-contract DeFi protocol with audit prep is 8-16 weeks. The audit itself adds another 3-6 weeks depending on the firm.

Should I use Hardhat or Foundry?

Foundry for new projects in 2026. Faster, better testing, native gas reporting. Hardhat still wins if you're heavily integrated with a JS/TS frontend or need plugins that don't exist in Foundry.

How much does a Solidity smart contract cost to build?

$15K-$40K for a simple token + vesting. $60K-$200K for a custom protocol. Add $25K-$150K for a serious audit. Multiply by 1.5-2x for projects with complex tokenomics or novel mechanisms.

Do I need an audit if my code is forked from a battle-tested protocol?

Yes. Forks introduce subtle bugs at integration points and parameter choices. Even a 'simple' Uniswap fork has cost millions when small modifications interacted badly with the rest of the protocol.

What chain should I deploy on?

Ethereum mainnet for prestige and TVL. Arbitrum or Base for cheap UX. Polygon for emerging markets and gaming. Optimism for ecosystem grants. Choose based on where your users actually are, not what's cheapest.