SMART CONTRACT / GAS OPTIMISATION
PROPELOO engineers smart contract gas optimisation — from storage layout and opcode analysis through assembly optimisation, batching patterns and the benchmarking infrastructure that measures real improvement. Gas optimisation is not code golf. It is systematic engineering that makes your contracts cheaper to use without making them harder to audit.
On Ethereum mainnet, gas cost is a user experience and accessibility problem. A smart contract that costs 200,000 gas to interact with at 50 gwei costs $10 per transaction. Optimising it to 100,000 gas cuts that to $5. For NFT mints during high-demand launches, for DeFi operations that users perform frequently, and for any protocol competing on user adoption, gas efficiency is product quality. Gas optimisation requires understanding: storage slot packing (SSTORE is the most expensive opcode), calldata compression (each non-zero byte costs 16 gas), loop unrolling trade-offs, assembly for hot paths and ERC-721A-style deferred initialisation. PROPELOO delivers measurable, benchmarked gas reductions with no regression in security.
Struct packing to minimise storage slots (uint128 + uint128 in one slot vs two separate slots), replacing mappings with arrays where iteration is needed, using bytes32 instead of string where possible, and eliminating redundant storage writes.
Using calldata instead of memory for function parameters, compressing multi-call data, ABI encoding optimisation, using bytes calldata over bytes memory for external functions.
unchecked blocks for arithmetic where overflow is provably impossible (loop counters, array index increments), pre-increment vs post-increment, removing redundant zero checks.
ERC-721A for batch NFT minting, EIP-2929 warm/cold access patterns, lazy initialisation of arrays, bitmap usage for boolean flags, multicall patterns for batching user operations.
Custom errors via assembly (cheaper than require strings), optimised transfer loops in Yul, low-level staticcall for view functions, custom storage slot access for proxy patterns.
Foundry gas snapshots for all public functions, function-level gas reports, pre/post optimisation comparison, worst-case scenario testing (full storage writes) and gas profiling with --gas-report.
Gas optimisation is a readability-cost trade-off. Aggressively optimised contracts are harder to audit. The goal is the optimal point — not minimum gas regardless of consequences.
Writing to storage (SSTORE) costs 20,000 gas for a new slot, 5,000 for modification. Reads (SLOAD) cost 2,100. Everything else is cheap by comparison. Optimise storage access patterns first — eliminate redundant writes, pack structs, cache storage values in memory within a function. Storage layout changes compound across every transaction for the lifetime of the protocol.
Axiom:
"This optimisation should save gas" is not a result. Foundry gas snapshots measure the gas cost of every function call before and after each change. Every optimisation PR includes a gas comparison table. Without measurement, you are guessing.
Axiom:
A contract optimised to the point where auditors cannot follow the logic is a contract that will have undetected vulnerabilities. Inline assembly is powerful but opaque. unchecked blocks remove safety checks that prevent integer overflow. Every optimisation that reduces readability must be justified by a measured gas improvement worth the increased audit risk.
Axiom:
require(condition, "Error message string") costs gas proportional to the string length — the string is stored in the contract bytecode and included in the revert reason. Custom errors (error InsufficientBalance(uint256 available, uint256 required); + revert InsufficientBalance(balance, amount)) cost 4 bytes for the selector versus 32+ bytes for a string. This is one of the easiest, safest and highest-impact optimisations.
Axiom:
Impact: Profile first. Foundry gas report identifies the most expensive functions. Custom errors are always safe and provide immediate wins. Storage packing for contracts with complex structs. Assembly only for proven hot paths.
Impact: Manual struct ordering first (no readability cost). Automated detection for large contracts. Bitmap patterns for boolean flag arrays. Storage elimination for data that does not need to be queried on-chain.
Impact: Loop counters and index increments in unchecked blocks are universally safe — the upper bound is array length. Wider unchecked use requires case-by-case proof that overflow cannot occur.
Impact: ERC-721A for PFP/batch-mint collections. The gas savings on mint (5x for minting 10 at once) far outweigh the slight increase in transfer cost for most collection types.
Impact: Custom errors via assembly are universally recommended. Broader assembly use requires explicit audit by someone fluent in EVM opcodes — inline assembly vulnerabilities are the hardest to detect in audit.
Impact: Security is not negotiable. Readability is a proxy for security — it affects how well the contract can be audited. Profile-guided optimisation of demonstrably hot paths is the pragmatic production approach.
ERC-721A migration, struct packing, custom errors and calldata optimisation to reduce mint cost by 30-60%.
Storage layout redesign, loop optimisation and assembly for hot paths in AMM, lending or staking contracts.
Transfer, approve and transferFrom gas reduction — critical for tokens with high daily transaction volume.
Comprehensive gas report for all contract functions — current cost, optimisation opportunities and expected savings.
Full gas optimisation pass before mainnet deployment — profile, optimise, benchmark and document.
Batching patterns for user operations — reducing multiple separate transactions to a single call with multicall or ERC-4337 batching.
Stack: Foundry gas-report, Hardhat gas-reporter, eth-gas-reporter, Tenderly gas profiler
Stack: Slither (storage analysis), Remix (opcode viewer), evm.codes (opcode reference), EVM Playground
Stack: ERC-721A, solmate, OpenZeppelin v5, solady
Stack: Foundry (fuzz + invariant), Gas snapshots, Differential testing
Stack: Dune Analytics (on-chain gas tracking), Tenderly, Blocknative (gas estimation)
Stack: Gas comparison tables, Per-function benchmarks, Optimisation rationale docs
unchecked blocks remove Solidity 0.8+ overflow protection. Each use must be accompanied by a proof that overflow is impossible — typically a comment with the invariant. Missing or incorrect unchecked blocks are a critical vulnerability class.
Inline assembly bypasses Solidity type safety and compiler checks. Every assembly block requires a security review by someone with EVM opcode expertise. Assembly errors are invisible to automated tools.
Manual storage slot manipulation in proxy contracts or optimised patterns can create slot collisions — where two variables share the same slot unexpectedly. Verify storage layout with forge inspect before deployment.
Aggressively optimised contracts are harder to audit. Measure the audit cost increase against the gas saving per transaction across expected lifetime volume. For low-volume contracts, readability often wins.
Every optimisation must have a comprehensive test suite that passes before and after the optimisation. Gas improvements that break functionality are not improvements.
For complex mathematical optimisations (fixed-point arithmetic, curve calculations), differential testing compares optimised output against a reference implementation across a large random input set.
Foundry gas-report for all public functions. Identify top 20% of functions by gas cost.
Categorise optimisation opportunities by impact, safety and implementation effort.
Custom errors, calldata parameter types, storage packing — high impact, low risk.
ERC-721A migration, multicall, bitmap patterns — moderate complexity, high impact.
unchecked blocks with proofs, inline assembly for hot paths — high impact, requires audit.
Full test suite pass, invariant testing confirms no security regressions.
Per-function before/after comparison, total gas savings estimate and documentation.
Depends heavily on the starting point. Contracts written without gas awareness: 30-60% reduction is common. Contracts already following basic best practices: 10-25% improvement. The highest-impact single change is usually storage struct packing (eliminating redundant storage slots) followed by custom errors and calldata parameter types. ERC-721A for batch mint contracts is typically a 40-60% reduction in batch mint gas.
It can. The optimisation techniques with no security tradeoff: custom errors, calldata vs memory for function parameters, storage struct packing, caching storage values in memory within a function. Techniques that reduce readability and require careful security review: unchecked arithmetic, inline assembly, custom storage slot management. We document which optimisations were applied and why for each PR, so auditors can review the reasoning.
Optimise when: the contract has high daily transaction volume (even small per-transaction savings compound), the gas cost creates a user affordability barrier (NFT mints, DeFi operations), or the contract is already deployed and high gas is driving users to competitors. Accept higher gas costs when: the contract is rarely called, the optimisation significantly reduces readability, or the contract is in a security-critical path where auditability is paramount.
solmate is a gas-optimised alternative to OpenZeppelin contracts — ERC-20, ERC-721 and other primitives written for maximum gas efficiency rather than maximum readability and safety features. solady is even more aggressively optimised. OpenZeppelin prioritises safety, documentation and broad compatibility. For production protocols: start with OpenZeppelin (audited, battle-tested), profile, then selectively migrate specific implementations to solmate/solady if gas analysis justifies the readability tradeoff.