EIP-7708 makes all ETH transfers emit logs automatically. Transactions, CALLs with value, and SELFDESTRUCTs would generate LOG3 events with sender, recipient, and amount. The log format matches ERC-20 Transfer events for consistency.
Unlike ERC-20 tokens, native ETH transfers from contracts don't create logs. Exchanges and services must trace transactions to catch deposits, often missing smart contract wallet transfers. Automatic logging would make ETH as trackable as any token, improving wallet UX and exchange support.
All ETH transfers and burns emit a log.
Logs are often used to track when balance changes of assets on Ethereum. Logs work for ERC-20 tokens, but they do not work for ETH. ETH transfers from EOAs can be read from the transaction list in the block, but ETH transfers from smart contract wallets are not automatically logged anywhere. This has already led to problems in the past, eg. early exchanges would often not properly support deposits from smart contract wallets, or only support them with a much longer delay. This EIP proposes that we automatically generate a log every time a value-transferring CALL or SELFDESTRUCT happens. We also add a similar log for transfers in transactions, so that all ETH transfers can be tracked using one mechanism.
A log, identical to a LOG3, is issued for:
CALL to a different account, at the time that the value transfer executesSELFDESTRUCT to a different account, at the time that the value transfer executes| Field | Value |
|---|---|
address emitting log | 0xfffffffffffffffffffffffffffffffffffffffe (SYSTEM_ADDRESS) |
topics[0] | 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef (keccak256('Transfer(address,address,uint256)')) |
topics[1] | from address (zero prefixed to fill uint256) |
topics[2] | to address (zero prefixed to fill uint256) |
data | amount in Wei (big endian uint256) |
This matches the ERC-20 Transfer event definition.
A log, identical to a LOG2, is issued for:
SELFDESTRUCT to self by a contract created in the same transaction, at the time the opcode is invokedBurn logs are emitted after all other logs created by EVM execution and the payment of the EIP-1559 priority fee to the coinbase. When multiple accounts are marked for deletion, burn logs are emitted in lexicographical order of account address.
| Field | Value |
|---|---|
address emitting log | 0xfffffffffffffffffffffffffffffffffffffffe (SYSTEM_ADDRESS) |
topics[0] | 0xcc16f5dbb4873280815c1ee09dbd06736cffcc184412cf7a71a0fdb75d397ca5 (keccak256('Burn(address,uint256)')) |
topics[1] | address (zero prefixed to fill uint256) |
data | amount in Wei (big endian uint256) |
This is the simplest possible implementation that ensures that all ETH transfers are implemented in some kind of record that can be easily accessed through making RPC calls into a node, or through asking for a Merkle branch that is hashed into the block root. The log type is compatible with the ERC-20 token standard, but does not introduce any overly-specific ERC-20 features (eg. ABI encodings) into the specification.
address? For address: (a) 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee (same as eth_simulateV1), (b) 0xfffffffffffffffffffffffffffffffffffffffe (SYSTEM_ADDRESS), (c) zero addressNo backward compatibility issues found.
TODO
ETH transfers already cost a minimum of 6700 gas, which is much more expensive than the LOG3 opcode (1500 gas). Hence, this EIP does not increase the worst-case number of logs that can be put into a block. It will somewhat increase the average number of logs.
Copyright and related rights waived via CC0.