EIP-7708 Log every ETH transfer (ETH Transfers Emit a Log)
No call decision · EVM & execution · EIP status Last Call · created 2024-05-17
For every ETH transfer with a nonzero value, the protocol automatically emits a log in the same format as an ERC-20 Transfer, so ETH movements from smart contract wallets can be tracked in a single way.
Why it is needed
On Ethereum, asset movements are usually tracked through logs. An ERC-20 token leaves a Transfer event log on every transfer, so exchanges and wallets can easily detect deposits and withdrawals. ETH itself, however, has no such log. ETH sent by an externally owned account (EOA) can be read from a block's transaction list, but ETH sent by a smart contract wallet is not recorded automatically anywhere. As a result, early exchanges did in fact fail to properly support deposits from smart contract wallets, or processed them much later. This EIP has the protocol automatically create a log whenever a value-moving CALL or SELFDESTRUCT executes, and attach the same log to the ETH transfer of a transaction, so that every ETH movement can be tracked through a single mechanism.
What changes
Today
- ETH sent by an EOA can be seen only in a block's transaction list
- ETH sent by a smart contract wallet is not automatically recorded anywhere
- Exchanges have failed to support contract wallet deposits or have processed them late
After EIP-7708
- Every ETH transfer with a nonzero value leaves a log in the same format as an ERC-20 Transfer
- Transactions, CALL, SELFDESTRUCT and CREATE are all tracked through a single mechanism
- Transfer records can be accessed through RPC calls or Merkle branch requests hashed into the block root
Who is affected
- Exchanges and indexers: ETH deposits and withdrawals can be detected in the same Transfer log format as ERC-20 tokens.
- Wallet & app developers: ETH movements of smart contract wallets can be checked through logs without a separate tracking mechanism.
- Client teams: Logic that emits a log at the time of a value transfer must be implemented, and the average number of logs increases somewhat.
- Users: Cases where deposits sent from contract wallets were not recognized properly become less frequent.
In depth
Four points where logs are emitted
A log identical to LOG3 is emitted for four kinds of nonzero ETH transfers. First, a transaction that sends value to another account. This log is placed before all other logs produced by EVM execution. Second, a CALL that sends value to another account, emitted at the time the value transfer executes. Third, a SELFDESTRUCT whose beneficiary is another account. Fourth, CREATE and CREATE2 that send value to the account being created. According to the test case list, no log is emitted for zero-value transfers, reverted executions, rolled-back inner calls or fee payments, and the Transfer logs of nested CALLs are recorded in the chronological order in which the calls occur.
The log format is identical to ERC-20 Transfer
The address that emits the log is 0xfffffffffffffffffffffffffffffffffffffffe (SYSTEM_ADDRESS). topics[0] is 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef, the value of keccak256('Transfer(address,address,uint256)'). topics[1] is the from address and topics[2] is the to address, both left-padded with zeros to the size of a uint256. data holds the amount in Wei as a big-endian uint256. This format matches the ERC-20 Transfer event definition and so is compatible with the ERC-20 token standard, but it does not pull ERC-20-specific features such as ABI encoding into the specification. SYSTEM_ADDRESS is reused as the sender to stay consistent with protocol-originated behavior such as EIP-4788 and to distinguish these logs from logs emitted by user contracts.
Why fee and withdrawal logs are left out
A log for the priority fee paid to the coinbase was also considered but excluded. It is a different category from transfers, and including it would make the log volume explode, raising the intrinsic cost of a transfer log, that is, the transaction cost, and placing excessive load on the network. Clients can already compute this amount from the block header and transaction receipts. The burned portion of the base fee was excluded for the same reason. The burned amount can already be derived from the block header. Validator withdrawals were also considered, but they were excluded because they are not attached to a transaction and so have no natural emission point, and because they are easy to derive from block information. Clients that want to offer a unified view MAY expose a new aggregating RPC.
The SELFDESTRUCT burn edge case is not specified
After EIP-8246, ETH can no longer be burned by executing SELFDESTRUCT on the account itself or by sending ETH to an account marked as selfdestructed. This EIP therefore does not specify that edge case. The conditions for emitting a log are also limited to transfers sent "to another account" for transactions, CALL and SELFDESTRUCT alike.
The simplest implementation and gas cost
This design is the simplest implementation that makes every ETH transfer leave a record in some form and makes that record easy to access through node RPC calls or Merkle branch requests hashed into the block root. On the security side, an ETH transfer already costs at least 6700 gas, which is much more than the cost of the LOG3 opcode (1500 gas). The worst case for the number of logs that fit in one block therefore does not increase with this EIP. The average number of logs does increase somewhat.
Status and tests
The source status is Last Call, with a deadline of 2026-11-01. Test cases are provided in eip7708_eth_transfer_logs of the execution layer spec test suite and, by repository path, sit in the amsterdam test directory. The tests cover emission by transaction type, sender attribution for the CALL family, CREATE initcode and failure modes, and behavior at the fork transition boundary. In the call records, it was discussed at 08.29 AMA #14 and no decision was made.