Title: EIP_7708__ETH_transfers_emit_a_log
Category: EIPs

Author: vbuterin
Date: 2024-05-17T12:08:19.962Z

https://github.com/ethereum/EIPs/pull/8575
Abstract
All ETH-transferring calls emit a log.
Motivation
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.
EIP number TBD.

Author: wjmelements
Date: 2024-05-18T00:27:12.736Z

It should be backfilled too. Internal transactions have been a major challenge for blockchain accounting. This feature is more useful if it is available for all of the history.

Author: wjmelements
Date: 2024-05-18T00:37:55.704Z

I have some suggestions.

The log’s address field should be nil. It is important that nobody can forge this log. The easiest way to do that is to have a special value for address, since other events would have to be emitted from a source account. nil should be used for all “system logs” therefore.
The magic should not collide with any solidity-style event hash. A magic of 0000000000000000000000000000000000000000000000000000000000000000 will not have collisions. While the magic topics[0] can probably be removed altogether if the log address is unique, keeping it allows other types of “system log” in the future. Other values will not compress as easily as all-zeros.

Author: wjmelements
Date: 2024-05-18T00:42:47.206Z

Should withdrawals also trigger a log? If so, what should the sender address be specified as?

Yes, from the zero-address, which is the common behavior for erc20 mints.

Should fee payments trigger a log?

I am in favor of this even when the gas price is 0. While it isn’t necessary for accounting because transaction fees are specified by gasPrice * gasUsed, including them would allow eth balances to be completely tracked by querying logs. It would no-longer be necessary to query individual transactions, and it would be easier to locate all transactions sent from an account.

Author: z0r0z
Date: 2024-05-18T04:48:15.941Z

While I appreciate ETH resembling ERC20 for offchain accounting purposes by introducing logs, I wonder if this might be best accomplished on the paymaster-side, if the goal is to make things easier for smart accounts. Personally, I would prefer the approach we have seen so far – introducing features to ETH progressively through wrappers, like wETH. After all, if someone had “new great idea that makes logs not useful” we would then be kind of stuck with bloat.

Author: radek
Date: 2024-05-18T21:34:10.521Z

What would be the impact on storage needs?
Are there any numbers for at least the backfilling case?

Author: metony
Date: 2024-05-19T15:38:08.960Z

Working with Smart accounts this is the #1 pain for us when it comes to track ETH transfer. We ended up debug_ tracing calls on multiple chains, with big $$ in infra costs. And this is also a big blocker in decentralizing portion of what we’re doing (stealth addresses with smart accounts). This would be a huge benefit imho.
Of course we need to limit the logs to transfers with amount> 0.

Author: eyalc
Date: 2024-05-19T19:02:04.473Z

Hmm. operations cost on ethereum try to reflect the cost (of storage, cpu) in term of “gas”.
Emitting a “Transfer” event costs roughly 1700 gas.
Who should pay this cost?

Author: metony
Date: 2024-05-19T22:43:21.290Z

Who should pay this cost?

Fair point. To support this, I created this dune dashboard (on L1) to get the feeling of the amount of values.
https://dune.com/70nyit/ethereum-call-with-value-greater-0
On avg we have around 1M logs emitted. Considering gas 1700, it will be a total of 1.6B gas per day. Currently the avg usage of gas is around 100B per day. This means there’s a 1.6% avg cost increase in gas spending.

Author: wjmelements
Date: 2024-05-20T21:14:06.648Z

eyalc:

Who should pay this cost?


ETH transfers via CALL already cost 6700 gas and basic transfer transactions have an even higher base of 21000.

Author: eyalc
Date: 2024-05-21T07:59:38.923Z

wjmelements:

ETH transfers via CALL already cost 6700 gas and basic transfer transactions have an even higher base of 21000.


The above costs come to cover for nonce change, balance change, and calldata cost.
the extra 6700 extra for transfer is for covering the balance change from both sender and reipient. compare the above cost to performing them using “native” assembly: nonce increment is sload+sstore which is ~5100 gas
So you either think that the current cost is over-paid, and its OK to add another 1500, or that we need to adjust and add this extra gas to the "call"cost.

Author: wjmelements
Date: 2024-05-22T20:02:05.010Z

eyalc:

The above costs come to cover for nonce change


Only for the 21000. CALL does not increment nonce.



 eyalc:

balance change


Correct.



 eyalc:

and calldata cost.


Calldata is billed separately for transactions and is free for CALL.

Author: Tobi
Date: 2024-05-25T12:50:20.588Z

wjmelements:

It should be backfilled too. Internal transactions have been a major challenge for blockchain accounting. This feature is more useful if it is available for all of the history.


No it shouldn’t. Things shouldn’t be over-complicated. In a world of inifinite engineering capacity… yeah good idea. But we need to prioritize features and there’s a limited amount of engineering capacity.

Author: wjmelements
Date: 2024-05-25T13:50:29.274Z

Tobi:

Things shouldn’t be over-complicated.


It’s not hard to backfill logs, but it is hard to do blockchain accounting for ether, and that should be fixed.

Author: MicahZoltu
Date: 2024-05-30T16:22:39.402Z

We have this implemented in eth_simulateV1 (add `eth_simulateV1` by KillariDev · Pull Request #484 · ethereum/execution-apis · GitHub) by replicating an ERC20 Transfer(address from, address to, uint256 value) with the logging contract address set to 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE.
Rationale:

0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE is a defacto standard value that many contracts use when they support both tokens and ETH and they want to include ETH in a mapping and they need a lookup key.  Unlike 0x0, there isn’t risk of accidentally checking for it by leaving value uninitialized.
Following ERC20 Transfer log makes it so anything that parses ERC20 transfer logs can also parse ETH logs without any additional work.  The ERC20 transfer logs contain all of the information desired, (“token”, from, to, amount) so the fit the desired purpose well.

Author: MicahZoltu
Date: 2024-05-30T16:23:02.085Z

wjmelements:

It’s not hard to backfill logs, but it is hard to do blockchain accounting for ether, and that should be fixed.


Receipts contain logs, and they are part of history, so they cannot be backfilled without rewriting history.

Author: wjmelements
Date: 2024-05-30T20:53:54.645Z

I don’t think rewriting all of the blocks is the easiest way to backfill. Instead, generate replacement receipts for all of the transactions (and blooms for all of the blocks) before the activation block and start serving them instead once they become available. I don’t even think the nodes have to compute these themselves; their operators could trust an import. I was thinking there could be a contest to see who can generate the update first, and ways other competitors could disprove prior submissions if there was a mistake. Similar to re-genesis, it isn’t necessary for all of the nodes to do all of the work, so-long as there is enough incentive to disprove a false submission.
The aforementioned import is only really necessary for already-running nodes. When doing a full block sync, the node would produce two sets of receipts: the one expected to match the block’s receipt hash, and the one that will be served in eth_getLogs and eth_getTransactionReceipt. There could be a parameter for those methods to fetch the legacy logs.

Author: metony
Date: 2024-05-31T08:35:26.688Z

Backfill is a very cool nice-to-have, if we can find a nice way to have it without delaying the consensus on this EIP, while being able to emit logs for ETH transfers is a must have.

Author: 0xInuarashi
Date: 2024-05-31T11:00:04.385Z

I would support this if we could somehow tackle the questions:

How do we do this without increasing the gas of Transfers that do not wish to include logs ?
How do we do this without adding as much gas as a normal event emission? (native opcode/protocol level stuff → export it to blob?)

Ideally I think the optional Transfer log would be cool, while users can opt out of it for slightly cheaper gas costs. 1700 is obscene when considering 21k is the transfer cost, that’s almost 10%.
I would think that such things should cost XX or XXX gas costs max, increasing with log size, and if not needed to store as permanent data, some expiry or onto blobs could save a lot of “gas” maybe.

Author: wjmelements
Date: 2024-05-31T18:52:07.066Z

0xInuarashi:

I would support this if we could somehow tackle the questions:


You seem to have some confusion about the spec. Do you understand that the proposal is for every ether transfer to be documented by a log, but the current gas costs are not increased?

Author: etan-status
Date: 2024-05-31T19:13:27.979Z

Strong support for this from the perspective of trust-minimized light clients. Together with EIP-6493: SSZ Transaction Signature Scheme this unlocks straight-forward implementations of IVC for scalable trust-free Ethereum logs - HackMD
Regarding the open questions, I think that they don’t necessarily have to be combined with this EIP. Both withdrawals and fee payments are easier to track than plain ETH transfers.


For fee payments: When monitoring logs in a trust-minimized world (EIP-6466: SSZ Receipts Root), they are already cross-checked against the receipts_root. The full ETH fees are also part of the same receipt that is already being proven, so full information is extractable in a straight-forward way. Especially in a EIP-7706 multidimensional fee world, some users may want separate logs per fee type, while others may only be interested in the total. I think that it’s fine to expect that a trust-minimized wallet / accounting software can process the full receipt relevant to its own transactions.


Withdrawals: This point should be extended with the ‘fee_recipient’ payment (formerly ‘coinbase’) as well. Both withdrawals and fee_recipient payments only affect users that solo stake, and larger staking operators that already have access to trusted monitoring; notably, liquid staking users or members of decentralized staking pools don’t benefit as they interact through a smart contract and never directly receive the withdrawals / fee payments. Furthermore, processing is already comparably simple because there is no concept of failures, and the withdrawals tree / block header are tiny compared to the full transactions/receipts logic. I think that it’s fine to have no logs for withdrawals and the fee_recipient payment.

Author: fergmolina
Date: 2024-05-31T22:05:05.486Z

If the motivation behind this EIP is to track balances changes, we would need that all ETH transactions emit a log including payments fees and withdrawals. Backfilling is a must also.
The main issue here is that we are going to almost duplicate the amount of logs per day. I did an extension of @metony Dune dashboard to analyze this point: https://dune.com/fergmolina/eip-7708-eth-transfers-emit-a-log

Author: metony
Date: 2024-05-31T22:43:15.161Z

while users can opt out of it for slightly cheaper gas costs

If this EIP is implemented, it must be for all the logs (no opt-in options). We’re proposing this to simplify tracking of ETH within smart accounts, so it should work for every transfer.
Good point @fergmolina on not just viewing this from a “gas increase” perspective, but also from a “log size” increase perspective.

Author: 0xInuarashi
Date: 2024-06-01T10:55:11.153Z

i mustve missed the part where there is no additional gas cost for logs, I read some comment about the comparison with a 1.7k event cost
if there’s no gas cost increase, then seems useful

Author: MicahZoltu
Date: 2024-06-01T11:12:41.060Z

This should increase the cost of any operation that moves ETH.  If it is believed that CALL is overpriced, then we should separately analyze and lower the price of CALL as a separate EIP.  The cost of writing a log is meant to capture the storage space required (receipts) as well as the increase in block body size over the network, plus perhaps some minor costs associated with generating the log.

Author: 0xInuarashi
Date: 2024-06-01T20:28:29.862Z

I feel like it would be very hard to argue the usefulness tradeoff of such logs if it places additional financial tax on every user who may or may not care them

Author: MicahZoltu
Date: 2024-06-01T22:54:10.559Z

Every token seems to be willing enough to pay the price, though part of that could be driven mostly by the fact that it is required in the ERC20 standard.

Author: mattstam
Date: 2024-08-09T01:05:22.636Z

Agree backfill would be best. Though if this is not technically possible (due to changing receipt history), what might also work is emitting the entire balance of the from and/or to accounts after the transfer instead of the amount transferred. Then overtime, indexers would be able to fill out the balance of all active accounts just by looking at these logs.
Accounts that don’t send / receive any ETH won’t get indexed, but presumably this wouldn’t matter much because most of the reason you do this is to display an active user’s balance on a frontend.

Author: wjmelements
Date: 2024-08-09T11:23:54.534Z

mattstam:

most of the reason you do this is to display an active user’s balance on a frontend.


No you can achieve that with existing functionality such as eth_getBalance.
One improved use case is tax accounting: calculating unrealized and realized loss, determining when to carry over a cost basis.

Author: wjmelements
Date: 2024-08-15T21:54:22.266Z

wjmelements:

No you can achieve that with existing functionality such as eth_getBalance.


Actually, not everybody has the advanced tooling I have so they rely on event subscriptions to detect changes. So this EIP would actually make it easier for others to update a user’s balance in a frontend.

Author: metony
Date: 2024-08-18T15:49:02.624Z

I think the attached screenshot sums up perfectly why we need it. This is a message sent by the #1 hackathon. I’ve highlighted the part that matters to this thread.
My position is that we don’t necessary need to make it retroactively compatible, I don’t see a huge advantage into that. But definitively emitting events when ETH is transferred is a critical one, so that wallets can easily show when a native token is sent to a user.
This is a UX-critical EIP.
ETHBrussels_Internal_transfer_issue719×978 80 KB

Author: metony
Date: 2024-09-22T21:02:33.083Z

Nice post by Daimo, showing how a full archive node is inevitable for them to trace smart wallet ETH transfers - Less Terrible Ethereum Indexing

Author: lassejaco
Date: 2024-10-11T11:50:51.771Z

Just signaling my support for this! We ran into this problem when adding smart contract wallet support for the Devcon ticketing system. Have seen others struggling with this in the wild too.
It’s shockingly difficult to verify ETH payments stemming from smart contract wallets.

Author: wminshew
Date: 2024-10-22T16:50:59.983Z

Strongly support this as well!

Author: etan-status
Date: 2024-11-13T16:35:55.258Z

It can be combined with a drop of the logs bloom, the two extra logs per tx consume about the same space as the per-receipt logs bloom.

Author: MicahZoltu
Date: 2024-11-13T17:14:28.997Z

I’m not a fan of horse trading.  If dropping the bloom makes sense, then we should drop the bloom.  If it further makes sense to reduce the gas cost of logs or transactions due to the removal of the bloom then we should do that.
Separately, if we generate new logs automatically, we should increase the cost of affected transactions as appropriate.
I dislike the idea that we should ship the two things at the same time and “call it even”.  If the math works out to be even that would be neat, but I doubt it it would (things in the real world are never that clean).

Author: dror
Date: 2024-11-16T04:12:07.852Z

Is there a standardized way to calculate the expected gas cost of a feature?

Author: MicahZoltu
Date: 2024-11-16T07:16:52.240Z

The various core dev teams essentially try to estimate the load a given operation puts on the node.  This could be CPU load, storage capacity load, disk read/write load, or network load.  They then compare that to other operations (e.g., ADD, SSTORE, LOG, etc.) and try to align them all so a given amount of gas puts the same load on the system no matter how you use it.
It is definitely more of an art than a science, particularly since network, storage, I/O, and CPU aren’t directly comparable.  I believe they may have some benchmarking tools that helps them complete this task, but I’m not personally familiar with them.

Author: etan-status
Date: 2025-03-26T07:35:11.458Z

Addon to propose some of the missing values:

Update EIP-7708: Provide more details and add fee payments by etan-status · Pull Request #9003 · ethereum/EIPs · GitHub

Author: metony
Date: 2025-03-26T15:04:19.570Z

Great @etan-status !

Author: metony
Date: 2025-04-14T22:43:05.995Z

With chains moving to even lower block times ( see https://x.com/jessepollak/status/1911858196836483540 ) I think this EIP becomes even more important, if we don’t want to trace-debug 5 blocks per seconds to undertsand when ETH has been sent out of a Smart Wallet

Author: andrewcheng
Date: 2025-04-17T03:44:00.446Z

This would be much easier to filter ETH transfers.

Author: u59149403
Date: 2025-04-17T23:12:55.461Z

I think source address should be set to 0xeee…eee instead of 0xfffffffffffffffffffffffffffffffffffffffe . This is what ERC-7528: ETH (Native Asset) Address Convention recommends. Or to 0x000…000 for better compressibility

Author: wjmelements
Date: 2025-04-18T17:57:20.129Z

ERC-7528 doesn’t have consensus. Plenty of protocols (such as UniswapV4) use the zero address for native assets. I prefer zero or null for compression, but also because it can become a precompile in the future.

Author: etan-status
Date: 2025-04-19T05:57:52.280Z

The rationale of 0xffff…e is that it is already used in finalized EIP-4788. I don’t really see the point of having multiple system addresses, but they seem to be used for validator operations as well (with arbitrary deployed contracts designated to be system relevant), so one could also use 0xeee.ee specifically for ETH transfers as well. There’s also the EIP-7799 interaction for getting a complete picture of the ETH balance history; one could also use the 0xeee.ee address for these. Or zero.