Hello Ethereum Magicians!
I’m excited to open up discussion on a new optional ERC-20 extension designed to make gas costs more predictable for ERC-20 users, especially those interacting with new or trending tokens for the first time during periods of high network congestion.
TL;DR
This ERC-20 extension adds a function to pre-initialize your balance slot in advance, paying the 20k gas “first write” storage cost when gas is cheap. Later, when you actually receive tokens, the cost is only ~5k gas.
The trick: store a unique sentinel value (in a bytes32 mapping) that ERC-20 reads interpret as 0. First real transfer/mint simply overwrites it. Fully ERC-20 compatible; invisible to wallets, explorers, and integrators.
This is conceptually the reverse of ERC-721A:
- ERC-721A: low gas now / higher gas later (cheap mint, costlier first transfer).
- This EIP: higher gas now / low gas later (pre-pay storage, cheap first receive).
Background / Motivation
On Ethereum, the first write to a new storage slot costs ~20,000 gas. Setting the slot to 0 early doesn’t help because only a nonzero value marks it as allocated. With this extension, the slot is allocated without affecting accounting, letting the user choose when to pay.
While this cost is well understood, it’s become more significant in practice, as users often try to buy into trending tokens right as gas prices spike, resulting in high transaction costs or even failed buys due to underestimated fees.
A common intuition is to “pre-initialize” your token balance slot by setting it to zero early, but (as many have learned) this doesn’t actually help, the EVM only discounts subsequent writes if the slot has already been set to a nonzero value.
This is analogous to ERC-721A’s approach of “gas smoothing” but in reverse: instead of low gas now/high gas later (mint/transfer), we enable high gas now/low gas later for ERC-20s, putting the timing choice in the user’s hands.
This ERC offers a safe, fully compatible workaround.
Proposal
Key idea:
Use a bytes32 mapping for balances, and introduce a contract-wide sentinel (“magic”) value, e.g. keccak256("preinit"). A new external function preInitializeAddress(address user) lets anyone set their slot to the sentinel (if currently unset).
All normal ERC-20 reads/writes (balanceOf, transfer, etc) continue to interpret the storage value as a uint256, treating the sentinel as zero for accounting. When the user later receives tokens, the sentinel is overwritten (at a cheap SSTORE cost), and all functionality is unchanged.
This enables:
- Pre-initializing your address for a token contract when gas is low, making future first buys/claims/transfers much cheaper even if network gas spikes later.
- dApps/wallets to offer this as a service (“optimize my gas for token X”).
- All ERC-20 compatibility and UX preserved, no “phantom” tokens, no risk of broken accounting.
Specification
ERC-20 contracts implementing this extesion MUST:
- Store balances as
mapping(address => bytes32). - Provide a public/external function:
/// @notice Pre-initialize an address' balance slot with a sentinel value /// @param user The address to pre-initialize function preInitializeAddress(address user) external;
- Treat the sentinel as zero in all ERC-20 logic.
- Overwrite sentinel on first real transfer/mint.
Rationale, code, and live calculator:
- Extension Draft & Rationale
- Reference Implementation (Solidity)
- Conceptual Savings Calculator (live)
- Real Testing Results
Example Savings
Based on real Sepolia testnet measurements:
- Pre-initialize: 44,221 gas
- First transfer to non-initialized: 52,146 gas
- Transfer to pre-initialized: 35,050 gas
With strategic timing, users can save >30% ETH in high-gas scenarios.
Check this example Pre-initializing with 0.3 gwi and buying the token at 20 gwei using the Conceptual Savings Calculator (live):
Use Cases
- Presales, airdrops, major launches: Users prepay SSTORE when gas is low, so when the event starts (and gas spikes), their first buy/claim is much cheaper.
- Pro traders and power users: Batch pre-initialize expected tokens as a cost-saving measure.
- Wallets/bots: Offer “pre-initialize my address” for trending tokens as a value-added feature.
Relation to ERC-721A and Gas Timing
Some developers may be familiar with ERC-721A (originally from the Azuki team), which reduces minting gas for NFTs by deferring part of the gas cost to the first transfer, effectively betting that “gas will be lower later” (or users prefer to mint cheaply even if transfers are a bit costlier).
This proposal applies the same philosophy, but in reverse:
It allows users to optionally “prepay” the storage cost for receiving tokens when gas is low, so their first real transfer (often at a busier time) is much cheaper. Neither approach saves total gas in a fixed-cost world, but both give users more control over when they pay expensive storage, helping users and dApps align costs with actual network conditions and their own strategies.
Compatibility & Security
- 100% ERC-20 interface compatibility (balanceOf always returns uint256).
- The sentinel value is invisible to external callers, never appears as a “phantom” balance.
- No risk of funds loss, overflows, or nonstandard balances.
- Slightly more complex contract logic (all reads/writes check for the sentinel).
- This pattern is opt-in and only affects new contracts.
Discussion / Feedback Welcome
- Is there a way to further generalize or simplify this pattern?
- Are there other use cases where pre-initialization would provide value?
- Would you consider adopting this in new ERC-20 launches?
- Any security or edge-case scenarios you’d want addressed?
This proposal is not intended as a “must-implement” for all tokens, but as a tool for teams and users who want to minimize gas costs and give power users more options, especially in an era of high volatility and rapid launches.
Feedback, suggestions, and peer review are very welcome!
Thanks for reading!
- German Maria Abal Bazzano (a.k.a. ariutokintumi)
Contact me @ariutokintumi on X & @llamame on Telegram
Check the full Extension Proposal, code, and tools repo
