Out of gas on deployment: should a low-traffic contract trade revert reason strings for custom errors?

Question

I am finalizing a small Solidity contract that will be deployed once and called only occasionally, so the dominant cost is deployment rather than per-call execution. Since an out-of-gas failure consumes all supplied gas while reverting state, I want the deployed bytecode as small as reasonably possible before I commit to a compiler configuration.

The documented tension I cannot resolve is around error handling. Custom errors (available since Solidity 0.8.4) are cheaper than revert reason strings, because strings are stored in the deployed bytecode and ABI-encoded at runtime. But switching to custom errors means off-chain tooling must decode a 4-byte selector instead of reading a human-readable message, and identical selectors across contracts can be misattributed by decoders.

There is also the optimizer runs parameter, which trades deployment cost against call cost; with uncertain future call volume I am unsure what value is defensible.

My questions:

For a low-traffic contract, does removing revert strings in favor of custom errors meaningfully reduce deployment gas, or is the saving marginal compared to overall bytecode size?
How do teams handle frontend and monitoring error decoding when the human-readable string is gone?
Given unknown call volume, is there a reasonable default for the optimizer runs setting, or should I benchmark both extremes?

Tasadduq Burney · Answer

The Direct Answer
Yes, you should trade revert reason strings for custom errors. For a contract where deployment cost is the primary concern, the savings are meaningful because every character in a revert string increases the deployed bytecode size. Custom errors replace these strings with a 4-byte selector, significantly reducing the contract's footprint and the associated deployment gas.

Deployment vs. Runtime Impact
The difference in gas consumption is rooted in how the Ethereum Virtual Machine (EVM) handles data:

Revert Strings: The compiler embeds the full string literal directly into the bytecode. If you have ten 32-byte error strings, you add roughly 320 bytes to your contract size, increasing deployment costs linearly.
Custom Errors: These use a 4-byte function selector (the first four bytes of the Keccak-256 hash of the error signature). This remains constant regardless of how descriptive the error name is in your source code.

While the runtime gas saving per call is also lower for custom errors, the primary win for low-traffic contracts is the reduction in the CREATE or CREATE2 transaction cost.

Handling Off-Chain Decoding
The loss of human-readable strings in the bytecode does not mean the loss of readability for the user. Modern development workflows handle this via the ABI:

ABI Mapping: The contract ABI contains the mapping of the 4-byte selector to the error name and its parameters.
Frontend Integration: Libraries like ethers.js or viem automatically decode these selectors into human-readable errors if the ABI is provided to the provider.
Block Explorers: Etherscan and similar tools decode custom errors automatically once the contract source code is verified.

Optimizer Runs Configuration
The runs parameter tells the compiler whether to optimize for deployment cost (low runs) or runtime cost (high runs). For a low-traffic contract where deployment is the dominant cost, a low value (e.g., 200) is the standard defensive default. This instructs the compiler to avoid duplicating code to save gas on calls, thereby keeping the bytecode smaller.

Verification Steps
To quantify the exact savings for your specific contract, perform the following checks:

Bytecode Comparison: Compile your contract twice—once with require(condition, "Error Message") and once with if (!condition) revert CustomError(). Compare the length of the resulting bytecode hex string.
Local Deployment: Deploy both versions to a local environment (Hardhat or Anvil) and compare the gasUsed field of the deployment transaction.

Missing Diagnostic: To provide a more precise optimizer recommendation, it would be necessary to know if your contract contains many small, repeated internal functions, as this significantly changes how the runs parameter affects bytecode size.

Out of gas on deployment: should a low-traffic contract trade revert reason strings for custom errors?

1 answer

The Direct Answer

Deployment vs. Runtime Impact

Handling Off-Chain Decoding

Optimizer Runs Configuration

Verification Steps

Your perspective belongs here.

1 question comment