--- eip: 7708 title: ETH transfers emit a log description: All ETH transfers emit a log author: Vitalik Buterin (@vbuterin), Peter Davies (@petertdavies), Etan Kissling (@etan-status), Gajinder Singh (@g11tech), Carson (@carsons-eels), Jared Wasinger (@jwasinger) discussions-to: https://ethereum-magicians.org/t/eip-7708-eth-transfers-emit-a-log/20034 status: Draft type: Standards Track category: Core created: 2024-05-17 requires: 1559, 4788, 6780, 8246 --- ## Abstract All ETH transfers emit a log. ## Motivation Logs are often used to track when balance changes of assets on Ethereum. Logs work for [ERC-20](./eip-20.md) 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. ## Specification ### ETH transfer logs A log, identical to a LOG3, is issued for: - Any nonzero-value-transferring transaction to a different account, before any other logs created by EVM execution - Any nonzero-value-transferring `CALL` to a different account, at the time that the value transfer executes - Any nonzero-value-transferring `SELFDESTRUCT` to a different account, at the time that the value transfer executes - Any nonzero-value-transferring `CREATE` or `CREATE2` to the created account, at the time that the value transfer executes | Field | Value | | - | - | | `address` emitting log | `0xfffffffffffffffffffffffffffffffffffffffe` ([`SYSTEM_ADDRESS`](./eip-4788.md)) | | `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](./eip-20.md) Transfer event definition. ## Rationale 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. The `SYSTEM_ADDRESS` is reused as the log emitter for consistency with other protocol-originated operations (e.g. [EIP-4788](./eip-4788.md)) and to distinguish these protocol-generated logs from logs emitted by user contracts. Fee payment logs for priority fees paid to the coinbase were considered. However, they are a distinct category from transfers, and adding these logs to this EIP would explode the log volume in a way that raises the intrinsic cost of transfer logs (and therefore transactions), putting an unreasonable load on the network. Clients can already compute these fee amounts from the block header and transaction receipt, so it is unnecessary to log them. The base fee burn is excluded for the same reason: the burned amount is already derivable from the block header. Withdrawals were also considered, but they are not attached to a transaction, which means there is no natural emission point. Additionally, they are already easily derivable from block information. Adding these kinds of logs would duplicate data already available to clients. Clients who wish to provide a unified view for consumers MAY expose a new aggregating RPC. ## Backwards Compatibility ### ETH burns via `SELFDESTRUCT` After [EIP-8246](./eip-8246.md), ETH can no longer be burned via `SELFDESTRUCT` to self or by sending ETH to an account marked for selfdestruction. Therefore, this EIP does not specify this edge-case. ## Test Cases - Transfer log emission for plain transactions, EOAs, delegated EOAs, and across all transaction types - Transfer logs across the `CALL` family and how the executing context attributes the sender - Transfer logs for `CREATE` / `CREATE2` endowments, initcode behavior, and failure modes - Transfer logs for `SELFDESTRUCT` to self vs. a different beneficiary, including pre-existing and cross-tx contracts - Log ordering: Transfer logs appear before any EVM-emitted logs in a transaction, and nested-`CALL` Transfer logs appear in chronological call order - Negative cases where no log is emitted (zero-value, reverts, rolled-back inner calls, fee payments) - Transfers to special-purpose addresses (precompiles, the system address, the coinbase) - Fork transition behavior at the EIP-7708 activation boundary Test cases for this EIP can be found in the Execution Layer Specification suite [`eip7708_eth_transfer_logs`](https://github.com/ethereum/execution-specs/tree/155c3e136d81dcd5c61086c9d832595b7641db4a/tests/amsterdam/eip7708_eth_transfer_logs). ## Security Considerations 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 Copyright and related rights waived via [CC0](../LICENSE.md).