From a3c71bd98e74bcb2f7e6a4e3042fb8e410893154 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Fri, 17 May 2024 15:40:22 +0300 Subject: [PATCH] Update eip-9999.md --- EIPS/eip-9999.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/EIPS/eip-9999.md b/EIPS/eip-9999.md index 3cc4f9b452c86..8f4a5b2bf6f6a 100644 --- a/EIPS/eip-9999.md +++ b/EIPS/eip-9999.md @@ -34,6 +34,11 @@ The `LOG` of a value-transferring transaction should be placed before any logs c 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? +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. + ## Backwards Compatibility No backward compatibility issues found.