What this prompt does
This prompt optimizes gas for a Solidity contract methodically, since on mainnet gas is a real cost to your users. You describe the [contract_type], its [current_gas] per typical transaction on [target_chain], the [function_count], and [storage_variables], and it works through storage packing, calldata versus memory, loop optimization, custom errors, batch operations, targeted assembly, and Foundry benchmarks.
The structure works because gas savings have a clear priority order. Repacking [packable_variables] into single slots, replacing bool arrays with a [bitmap_implementation], switching [memory_params] to calldata, optimizing [hot_loops] with cached length and unchecked{++i}, and replacing revert strings with custom errors usually deliver the biggest wins before you reach for assembly on [assembly_candidates]. By demanding Foundry before/after benchmarks for [benchmark_scenarios], the prompt keeps the savings proven rather than assumed. Knowing the [current_gas] baseline and the [function_count] and [storage_variables] count helps the model target the functions where optimization actually pays off.
When to use it
- You have a mainnet contract where gas cost materially affects your users
- You want storage layout analyzed and
[packable_variables]repacked into shared slots - You need
[hot_loops]optimized or replaced with lazy evaluation - You want revert strings swapped for custom errors across the contract
- You want a
[batch_function]so users can amortize base transaction cost - You are considering assembly for
[assembly_candidates]and want it justified and verified - You need Foundry benchmarks proving the savings on
[benchmark_scenarios]
Example output
Expect an optimization report: a storage-layout analysis repacking [packable_variables] into single slots with a [bitmap_implementation] for boolean state, a list of [memory_params] to switch to calldata and [fixed_strings] to swap for bytes32, optimized versions of [hot_loops] with [loop_alternatives] like lazy reward accounting where applicable, a custom-error rewrite saving roughly [estimated_savings] per revert, a [batch_function] using [batch_pattern] to amortize base cost, optional Yul implementations for [assembly_candidates] with equivalence notes, and a Foundry test using vm.snapshotGas comparing before and after across [benchmark_scenarios]. Each change comes with a before/after gas figure so you can prioritize by payoff.
Pro tips
- Chase the cheap wins first: storage packing of
[packable_variables]and custom errors usually beat assembly on effort-to-savings - Prefer lazy evaluation in
[loop_alternatives]over micro-optimizing[hot_loops]— updating rewards on user interaction beats iterating every staker - Convert
[memory_params]to calldata for external functions; it is a near-free saving that is easy to overlook - Replace short
[fixed_strings]used as keys with bytes32, since string storage and comparison are far more expensive than a fixed-size type - Reserve assembly for
[assembly_candidates]where the saving is real and verify Yul equivalence against the Solidity version with tests - Always insist on
vm.snapshotGasbefore/after benchmarks for[benchmark_scenarios], so savings are measured, not guessed - Re-test correctness after every optimization; gas tricks like
uncheckedblocks and tight packing are exactly where subtle bugs hide
