gas-optimization

Gas Optimization

Overview

Reduce the gas a contract spends without changing its observable behavior. Every proposed saving is a hypothesis until measured. The core discipline is: find candidates, rewrite one at a time, prove the behavior is unchanged, and prove the gas actually went down — discard anything that fails either proof.

The Iron Rule: never claim a gas saving you have not measured. A rewrite that "should" be cheaper but isn't, or that subtly changes behavior, is a regression. No exceptions for "obvious" wins.

When to Use

• Lowering deployment or runtime gas of Solidity/Vyper/Yul contracts
• Symptoms: "gas too high", expensive SSTORE/SLOAD, large for loops, structs with many fields, string memory/bytes memory external args, repeated .length reads, i++ in loops
• Considering unchecked, constant/immutable, mappings-over-arrays, bitwise tricks, or transient storage

Do NOT use for: correctness bugs or security audits (use vulnerability-scanning), or micro-tweaks to code that isn't on a hot path and isn't deployed at scale — readability usually wins there.

Workflow

Run these four steps in order. They are reasoning steps you perform, not scripts.

1. Seek — Read the target contract and match it against the known waste patterns in reference/patterns.md. List every candidate with its location. Ground every later idea in the EVM cost facts in reference/cost-model.md.
2. Innovate — For each candidate, propose one concrete rewrite. You may also propose novel rewrites beyond the library, but only if you can name the exact opcode/cost reason it's cheaper. Reject ideas you cannot justify from the cost model.
3. Execute — Apply rewrites one at a time, then verify each (see below). If verification fails, revert that rewrite and move on. Do not batch unverified changes.
4. Manage — After the loop, report each accepted change: location, pattern, measured gas delta (before → after), and any behavioral caveat. Be honest about rewrites you discarded and why.