Skip to content

Update EIP-7708: Move to Draft #9003

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
eth-bot merged 12 commits into from
Jan 20, 2026
Merged

Update EIP-7708: Move to Draft #9003

Changes from 9 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
2d0af4a
Update EIP-7708: Provide more details and add fee payments
etan-status Oct 29, 2024
1939890
Fix lint
etan-status Oct 29, 2024
68deb0c
Update wording on open question
etan-status Jan 15, 2026
700face
Merge branch 'master' into fl-ethlogs
etan-status Jan 15, 2026
15abb8e
Drop logs that can be reconstructed from tx/receipt data
etan-status Jan 15, 2026
bb546d6
Cleanup
etan-status Jan 15, 2026
7b25326
Nonzero-value-transferring
etan-status Jan 15, 2026
f14d40a
Change system address to one that is used in JSON-RPC
etan-status Jan 16, 2026
370938e
Extend write-access list
etan-status Jan 16, 2026
4b19eb7
Change address to 0xfff..e
etan-status Jan 19, 2026
48758bc
Clarifying comments
etan-status Jan 20, 2026
5459529
Add Selfdestruct event
etan-status Jan 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 16 additions & 9 deletions EIPS/eip-7708.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -20,24 +20,31 @@ 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 `CALL`, at the time that the value transfer executes
- Any nonzero-value-transferring `SELFDESTRUCT`, at the time that the value transfer executes

@jwasinger jwasinger Jan 20, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some edge cases to think about here:

  1. a selfdestruct-to-self for a contract created in the same transaction will immediately burn that balance.
  2. a selfdestruct-to-self for a previously-existing contract will result in no net balance difference even if it is "nonzero-value-transferring"

For the sake of simplicity, I suggest we treat both cases as a transfer of value to self. There is not really a proper way to indicate that the balance is being burned in the case of 1.

@etan-status etan-status Jan 20, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible from solely the information in the logs (whatever is proposed to be emitted here), the transactions (amount, max prio fee), the receipts (gas used), the block header (base block fee, withdrawals), and the genesis balance (or, whatever the balance was at the time of the fork when this activates) to reconstruct the account balance accurately, in all cases?

Or do we need a second log for burning ETH in these situations?

@jwasinger jwasinger Jan 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we would need a special log to indicate burn in the case of 1.

@jwasinger jwasinger Jan 20, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for the case of 2. we can just mark this as a transfer of zero value to self. It's the only case where a value transfer log of this type would be allowed.

@etan-status etan-status Jan 20, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The special log could either be a LOG2 Burn(from, amount), or reuse the Transfer log (with a destination of system address). The Burn log would probably be cleaner, as it doesn't actually increase the balance of the system address. The Transfer log would be a bit more consistent with ERC20 (no need to combine the result from multiple log topics); but for ERC20 it actually gets credited to zero/burnaddress so it's not the same semantics.

@etan-status etan-status Jan 20, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, Selfdestruct(from, amount)? To indicate the special operation? Then, (1) and (2) would be the same?

@jwasinger jwasinger Jan 20, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I like that

Or, Selfdestruct(from, amount)? To indicate the special operation? Then, (1) and (2) would be the same?

This could work.

@etan-status etan-status Jan 20, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added Selfdestruct(from, amount).

@benaadams benaadams Jan 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is not really a proper way to indicate that the balance is being burned in the case of 1.

Isn't burn for ETH a transfer to 0x0? (to null) like emission is a transfer from 0x0

Symbolic burns transfer to 0xdEaD but that's not what we are talking about here

@etan-status etan-status Jan 20, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a Transfer, the value is actually credited to the destination.
This Selfdestruct doesn't credit anything. One couldn't reconstruct the actual value of the zero / 0xdead address if the special case isn't denoted as such.


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.

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.
| Field | Value |
| - | - |
| `address` | `0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` (same as `eth_simulateV1`) |
| `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) |
Comment thread
etan-status marked this conversation as resolved.

## 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` and `topics[0]`?
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

Expand Down