Update EIP-7708: Move to Draft

EIPS/eip-7708.md

@@ -2,9 +2,9 @@
 eip: 7708
 title: ETH transfers emit a log
 description: All ETH transfers emit a log
-author: Vitalik Buterin (@vbuterin), Peter Davies (@petertdavies)
+author: Vitalik Buterin (@vbuterin), Peter Davies (@petertdavies), Etan Kissling (@etan-status), Gajinder Singh (@g11tech), Carson (@carsons-eels)
 discussions-to: https://ethereum-magicians.org/t/eip-7708-eth-transfers-emit-a-log/20034
-status: Stagnant
+status: Draft
 type: Standards Track
 category: Core
 created: 2024-05-17
@@ -20,24 +20,46 @@ Logs are often used to track when balance changes of assets on Ethereum. Logs wo
 
 ## Specification
 
-### Parameters
+### ETH transfer logs
 
-* `MAGIC`: `TBD`
+A log, identical to a LOG3, is issued for:
 
-### Functionality
+- Any nonzero-value-transferring transaction, before any other logs created by EVM execution
+- Any nonzero-value-transferring `CALL`, 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
 
-Whenever (i) a nonzero-value `CALL`, (ii) a nonzero-value-transferring `SELFDESTRUCT`, or (iii) a nonzero-value-transferring transaction takes place, issue a log, identical to a LOG3, with three topics: (i) `MAGIC`, (ii) the sender address, (iii) the recipient address. The log data is a big-endian 32-byte encoding of the transfer value.
+| 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) |
 
-The `LOG` of a value-transferring transaction should be placed before any logs created by EVM execution. The other two `LOG`s are placed at the time that the value transfer executes.
+This matches the [ERC-20](./eip-20.md) Transfer event definition.
+
+### Selfdestruct processing
+
+A log, identical to a LOG2, is issued for:
+
+- Any nonzero-value-transferring `SELFDESTRUCT` to the same account, at the time that the value removal executes
+
+| Field | Value |
+| - | - |
+| `address` emitting log | `0xfffffffffffffffffffffffffffffffffffffffe` ([`SYSTEM_ADDRESS`](./eip-4788.md)) |
+| `topics[0]` | `0x4bfaba3443c1a1836cd362418edc679fc96cae8449cbefccb6457cdf2c943083` (`keccak256('Selfdestruct(address,uint256)')`) |
+| `topics[1]` | `from` address (zero prefixed to fill uint256) |
+| `data` | `amount` in Wei (big endian uint256)
 
 ## 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.
 
 ### Open questions
 
-1. Should withdrawals also trigger a log? If so, what should the sender address be specified as?
+1. Magic value used for `address`? For address: (a) `0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` (same as `eth_simulateV1`), (b) `0xfffffffffffffffffffffffffffffffffffffffe` ([`SYSTEM_ADDRESS`](./eip-4788.md)), (c) zero address
 2. Should fee payments trigger a log? It would ensure "completeness", in the sense that you can compute the exact current balance table by watching logs, but it would greatly increase the number of logs, perhaps to an unacceptably high amount.
+3. Should withdrawals also trigger a log? They are not associated with transactions.
 
 ## Backwards Compatibility