Add ERC: ERC-20 Pre-initialization (Sentinel Storage)

[ariutokintumi]

This ERC proposes an optional ERC-20 extension that allows token contracts to implement a preInitializeAddress(address) function. This function lets users or dApps pay the high SSTORE gas cost of first-time balance initialization in advance, when gas is low, by writing a sentinel (magic) value to the balance slot.

The balance mapping is stored as bytes32 internally, and the sentinel is treated as 0 for all ERC-20 reads/writes. When the user later receives tokens, the sentinel is overwritten at the cheaper 5k gas rate instead of the full 20k.

We use bytes32 because writing zero to a slot does not save gas for the first real (nonzero) balance write. EVM only discounts overwrites of already-allocated slots with nonzero value.

This approach mirrors ERC-721A "gas timing" concept but in reverse: high gas now, low gas later, giving users more control over when they incur expensive storage writes.

Discussion thread: https://ethereum-magicians.org/t/erc-tbd-erc-20-pre-initialization-extension-sentinel-storage-gas-savings-for-first-time-token-receivers/24993

Repository including contracs, testing and tooling: https://github.com/ariutokintumi/ERC-20-Pre-initialization

[eip-review-bot]

File ERCS/erc-8003.md

Requires 1 more reviewers from @g11tech, @samwilsn, @xinbenlv

[xinbenlv]

Overall look like a really interesting proposal! Just onething, i want to check if the Math still works in this new approach. Left a technical comment in EthMagic https://ethereum-magicians.org/t/erc-8003-erc-20-pre-initialization-extension-sentinel-storage/24993/6?u=xinbenlv. Please let me know when it's answered

[github-actions[bot]]

The commit 55eaf4860a430208e9bc3348244a194b8f43cec5 (as a parent of 183ed30ea5889397e72c61d5b915d8792a8a3561) contains errors. Please inspect the Run Summary for details.

[ariutokintumi]

Also please address bot failure

Done!

[lucemans]

So what if the wild case occurs where a user's balance does end up matching the MAGIC value? The contracts would start returning 0's no?

[ariutokintumi]

So what if the wild case occurs where a user's balance does end up matching the MAGIC value? The contracts would start returning 0's no?

Hello @lucemans, thanks for taking the time to review my proposal.

This case is not happening because the 'MAGIC value' is not a number (and MUST not be). That means that there is no potential collision between balance and per-initialization values.

This also makes the accounting to be safe. If we use a number for the 'MAGIC value' it will bring a lot of problems besides that one as well.