📘 Cluster Guide: This article supports our pillar guide on Smart Contract Development. For security patterns, see Smart Contract Security Best Practices.

Smart Contract Gas Optimization: 25 Techniques Guide

Why Gas Optimization Matters [AEO Target]

Direct Answer: Gas optimization reduces the transaction fees users pay to interact with your smart contract. On Ethereum mainnet, well-optimized contracts save users 30-90% on transaction costs — a direct competitive advantage. On Layer 2s (Polygon, Arbitrum), optimization extends to higher throughput and lower infrastructure costs. Top optimizations include storage packing (saves 20,000 gas per slot), immutable variables (2,100 → 3 gas per read), and Merkle proofs (90%+ savings for allowlists).

Key Takeaways

✅ Storage is the most expensive operation: 20,000 gas to write, 5,000 to read — packing structs saves 20K per slot
✅ Immutable/Constant variables: 3 gas per read vs 2,100 for storage — use for values set at construction
✅ Merkle Proofs: O(log n) verification vs storing full arrays — 90%+ gas savings for allowlists
✅ Custom Errors: 50+ gas saved per revert vs require strings
✅ Layer 2 deployment: 95-99% cost reduction vs Ethereum mainnet

The 25 Optimization Techniques

Tier 1: High Impact (30-60% savings)

1. Storage Packing

// BAD: 3 storage slots (3 × 20,000 = 60,000 gas to write)
struct Bad { uint128 a; uint128 b; uint256 c; }

// GOOD: 2 storage slots (2 × 20,000 = 40,000 gas)
struct Good { uint128 a; uint128 b; uint256 c; } // a+b packed into one slot

2. Immutable Variables

// BAD: 2,100 gas per read
address public owner;
constructor() { owner = msg.sender; }

// GOOD: 3 gas per read
address public immutable owner;
constructor() { owner = msg.sender; }

3. Calldata over Memory

// BAD: copies data to memory
function process(uint256[] memory data) external { ... }

// GOOD: reads directly from calldata
function process(uint256[] calldata data) external { ... }

4. Unchecked Math

// BAD: overflow check on every operation (+80 gas)
for (uint256 i = 0; i < arr.length; i++) { ... }

// GOOD: overflow impossible for loop counter
for (uint256 i = 0; i < arr.length;) {
    // ... process arr[i]
    unchecked { ++i; }
}

5. Custom Errors

// BAD: string costs more gas
require(balance >= amount, "Insufficient balance");

// GOOD: custom error saves 50+ gas per revert
error InsufficientBalance(uint256 available, uint256 required);
if (balance < amount) revert InsufficientBalance(balance, amount);

6. Batch Operations

// BAD: N transactions, N × 21,000 base cost
for (uint i; i < recipients.length; i++) {
    token.transfer(recipients[i], amounts[i]);
}

// GOOD: 1 transaction, 1 × 21,000 base cost
function batchTransfer(address[] calldata recipients, uint256[] calldata amounts) external {
    for (uint i; i < recipients.length;) {
        token.transfer(recipients[i], amounts[i]);
        unchecked { ++i; }
    }
}

7. Merkle Proofs for Allowlists

// BAD: Store 10,000 addresses = 200,000+ gas
mapping(address => bool) public allowlist;

// GOOD: Store root hash = 20,000 gas, verify in O(log n)
bytes32 public merkleRoot;
function claim(bytes32[] calldata proof) external {
    require(MerkleProof.verify(proof, merkleRoot, leaf(msg.sender)));
    // ...
}

Tier 2: Medium Impact (10-30% savings)

8. Short-Circuit Booleans: Order || / && cheapest-first 9. Bitmap Storage: Pack 256 booleans in one uint256 10. Events over Storage: Historical data in events (8 gas/byte) vs storage (625 gas/byte) 11. Minimal Proxy (Clones): Deploy clones for 700 gas vs 2.1M for full deployment 12. Pre-compute Hashes: Cache keccak256 results when used multiple times 13. Prefer mapping over array for lookups: O(1) vs O(n) 14. Use ++i not i++: Post-increment costs extra gas 15. Pack function selectors: Minimize external interface surface

Tier 3: Advanced (Assembly-level)

16. Inline Assembly for hot paths: Direct SLOAD/SSTORE, bypass Solidity overhead 17. Transient Storage (EIP-1153): Temporary storage that auto-clears — 100 gas vs 20,000 18. Yul optimizer: Fine-grained control over memory layout 19. Pre-deployed Libraries: Reuse deployed logic to avoid re-deployment costs 20. CREATE2 for deterministic addresses: Avoid re-deployment for same logic

Tier 4: Architecture-Level

21. Layer 2 deployment: Polygon/Arbitrum = 95-99% cheaper than mainnet 22. Pull-over-push payments: Users claim (batch) vs contract distributes 23. Off-chain computation + on-chain verification: ZK proofs, signatures 24. State channels: Off-chain interaction, on-chain settlement 25. Rollup-friendly design: Batch L2 transactions for amortized costs

Benchmark Results

Optimization	Gas Before	Gas After	Savings
Storage packing (3 vars)	60,000	40,000	33%
Immutable vs storage read	2,100	3	99.9%
Calldata vs memory (10 items)	45,000	22,000	51%
Custom errors vs strings	3,500	3,400	3%
Merkle vs stored allowlist	200,000	20,000	90%
Batch vs individual (100 txs)	2,100,000	350,000	83%
Mainnet vs Polygon	100%	1-5%	95-99%

FAQ Section

1. How much can gas optimization save?

30-90% on Ethereum mainnet with Tier 1-2 optimizations. 95-99% by deploying on Layer 2 (Polygon, Arbitrum). For high-frequency contracts (DEXs, lending), optimization directly impacts profitability — every gas unit saved is margin earned.

2. What is storage packing in Solidity?

Storage packing arranges struct fields so multiple variables fit in one 32-byte storage slot. Example: two uint128 values pack into one slot (saving 20,000 gas per write). This is the single highest-impact optimization for contracts with multiple state variables.

3. Should I use assembly for gas optimization?

Only for hot paths called thousands of times per day. Inline assembly saves 20-40% on specific operations but sacrifices readability and increases bug risk. For 90% of contracts, Tier 1-2 optimizations (storage packing, immutables, calldata) deliver sufficient savings without assembly.

4. Is Layer 2 deployment better than optimization?

Layer 2 deployment gives 95-99% cost reduction — far more than any code optimization. However, both are complementary: optimized contracts on L2 mean even lower costs and higher throughput. Deploy on L2 first, then optimize for scale.

5. Can EifaSoft optimize my existing contracts?

Yes. We have reduced gas costs by 30-90% across 120+ contracts through storage optimization, assembly hot paths, and Layer 2 migration. Typical engagement: 2-4 weeks, ₹2L-₹5L, with before/after benchmarks for every function. Contact us for a gas audit.

Optimize Your Smart Contracts

EifaSoft Technologies — 120+ contracts optimized, 30-90% gas reduction, with before/after benchmarks.

Request a Gas Optimization Audit →

Related Resources:

Smart Contract Gas Optimization: 25 Techniques Guide 2026