EIP-8077 Add sender and nonce to transaction announcements (eth/XX - announce transactions with nonce)
Hegota Considered for Inclusion · Networking & nodes · EIP status Draft · created 2025-11-07
Messages that nodes use to announce new transactions to each other also carry the address and nonce of the sending account. This is a mempool communication improvement that lets the receiving node choose more intelligently which transactions to fetch first.
Why it is needed
Ethereum nodes keep transactions that are not yet in a block in a waiting area called the mempool, and exchange them with each other. For small transactions, a node pushes the body directly to a few neighbors, but the remaining nodes, as well as large transactions and type 3 transactions that carry blobs, receive only an announcement that "this transaction exists." Today this announcement contains only the hash, type, and size. The receiving node has nothing to judge by except the order in which announcements arrived, so when it spreads requests across several neighbors, it easily ends up fetching transactions that cannot be included in a block because of gaps in the nonce (the per-account sequence number) of the same account. Even when it tries to fill a gap, it does not know whose transaction with which number is missing, so the only option is to request one more hash at a time. To filter out stale announcements for transactions already on chain, it has to keep the hashes of every transaction on chain in a cache. There is also no way to request only the transactions of a particular sender. As block throughput grows, nodes will increasingly be unable to fetch every transaction, so they need information that lets them pick what to fetch and fill gaps.
What changes
Today
- The announcement carries only the transaction hash, type, and size.
- The receiving node requests based only on announcement order, so nonce gaps are likely to form.
- To fill a gap, the only option is to request the missing hashes one at a time.
- To filter out stale announcements, the cache has to hold every transaction hash on chain.
After EIP-8077
- The announcement also carries the sending account's address and nonce.
- The receiving node can choose which transactions to fetch so that no gaps form in its own mempool.
- For ordinary transactions, the nonce can be compared against the current account state to filter out stale announcements immediately.
- Only the transactions of a particular sender can be requested.
Who is affected
- Client teams: Implement the new version of the eth protocol. The sending side only needs to add two lists to the message, and because announcements grow larger, it can revisit the threshold that decides whether to push the body directly or send only an announcement. The specification does not enforce the receiving side's selection logic.
- Node operators and validators: It is applied through a client update without a hard fork. Clients on older versions can keep using the previous protocol version, so the network does not split.
- L2 and wallet developers: The original text says the ability to request only transactions from a specific sender address matters for user experience and L2s. There is no way to do this today, but it becomes possible after this EIP.
- Ordinary users: The transaction format, fees, and EVM rules do not change. This is a change that makes communication between nodes more efficient, so there is nothing for you to do directly.
In depth
NewPooledTransactionHashes message format
Extends the NewPooledTransactionHashes (0x08) message of the devp2p eth protocol in the next version (eth/XX). The eth/69 format is [txtypes: B, [txsize₁: P, txsize₂: P, ...], [txhash₁: B_32, txhash₂: B_32, ...]] and carries three lists: type, size, and hash. The eth/XX format appends two more lists to this: [txsource₁: B_20, txsource₂: B_20, ...] and [txnonce₁: P, txnonce₂: P, ...]. txsource is a 20-byte address and txnonce is a variable-length integer. As the subscripts show, each list is arranged in the same transaction order. The change keeps the message number and existing fields as they are and only adds two lists at the end.
What txsource and txnonce refer to
txsource is the account whose nonce the transaction consumes, and txnonce is the nonce value it consumes. For transactions of type 0x00 through 0x04, the address recovered from the signature is txsource and the transaction's nonce field is txnonce. For EIP-8141 frame transactions, txsource is the sender field explicitly specified in the transaction rather than a signature-recovered address, and txnonce is the nonce field. When EIP-8250 applies, the nonce field is replaced by nonce_keys and nonce_seq, and in that case txnonce is nonce_seq. The sender of a frame transaction is not a value recovered from a signature, may not equal the address of any entry in the signatures list, and may be a contract account.
Handling on the sending and receiving sides
The change on the sending side is simple. Only the data being sent changes. However, because announcements grow larger, an implementation MAY revisit the condition (usually transaction size) that decides between eager push, which sends the body immediately, and an announcement. The receiving side can use the additional information to improve request scheduling, but the protocol does not enforce a particular approach and leaves it to implementations. The Rationale explains that hash, size, and type alone are not enough, and that adding the sender and nonce lets the receiving side make better fetch decisions.
The nonce of a frame transaction must not be treated as an account nonce
The announced nonce is not always the account nonce. Where EIP-8250 applies, a frame transaction can consume a keyed nonce sequence instead of the sender's account nonce, and in that case txnonce is that sequence value and is unrelated to state[txsource].nonce. A valid transaction can announce a value far lower or higher than the account nonce, and the announcement alone does not reveal which of the two is in use. Therefore the receiving side MUST NOT compare a frame transaction's txnonce with state[txsource].nonce to discard it as a stale announcement or to infer nonce gaps, and MUST NOT use <txsource, txnonce> as the identifier of a frame transaction. In EIP-8250, the identifier of a pending transaction is <sender, nonce_keys, nonce_seq>. The type carried in the announcement distinguishes frame transactions from those for which the account nonce check is valid.
The role of announcements in account abstraction transactions
EIP-8141 makes sender an explicit field rather than a value recovered from the signature, so the receiving side has no way to know the sender before fetching the body. Its public mempool accepts at most one pending frame transaction per sender, requires its nonce to equal the sender's current nonce, and identifies pending transactions by <sender, nonce>. So there is no nonce gap to fill for this transaction, and the announcement instead tells whether the node already holds a candidate for that sender. Validating a frame transaction requires simulating the validation prefix, so fetching and then rejecting it costs execution as well as bandwidth, which makes the value of this answer high. EIP-8250 changes the nonce to <nonce_keys, nonce_seq>, but the announcement carries only nonce_seq. The key set can be up to 16 words, and even reducing it to a 32-byte canonical hash would make every announcement of every type pay that cost. Because the public mempool still accepts only one per sender, the sender address drives the scheduling decision and the nonce remains a hint.
Overhead and alternatives considered
This adds a B_20 address and a variable-length nonce to the existing B_32 hash, size and type, so announcements grow noticeably. The source expects an efficiency gain that justifies this, but leaves the detailed figures as TBD. Alternatives were also considered. Dropping small transactions from the extended announcement, since they mostly spread by eager push, and applying the change only to blob transactions were not chosen, because filling nonce gaps would still remain trial and error. The number of neighbors to announce to is not set by the protocol, and if bandwidth is tight, sending more metadata to fewer neighbors is considered better. Since announcements for one transaction arrive duplicated from about half of a node's neighbors on average, there is also a proposal to randomly mix simple and detailed announcements, but the gain is judged small compared to the added complexity. Identifying transactions by sender, nonce and RBF (replace-by-fee) version instead of by hash would require signing the version, which makes it a deeper change. Instead, carrying the already signed fee values in the announcement lets a node pick the new version as a stand-in for the RBF version. It can also anticipate the ordering result and avoid fetching transactions that would be discarded anyway, which cuts traffic further.
Compatibility and security
A new version of the eth protocol must be deployed, but supporting multiple versions side by side is standard practice, so old clients can keep using the previous version. EVM consensus rules do not change and no hard fork is needed. On security, the address and nonce in an announcement cannot be verified until the body is fetched or received by eager push, so they must not be treated as trusted information. An attacker can send announcements with arbitrary sender addresses at no cost, and a node that looks up state[txsource].nonce for every announcement ends up reading state once per announcement for an address the attacker chose. This is an announcement-level form of the sender state read amplification described in EIP-8141, and it is the reason cheap checks such as peer limits or rate limits should come before any state access based on announcement metadata. If the announced <txhash, type, size, address, nonce> tuple differs from the transaction actually received, it is treated as a protocol violation. Once the hash is checked, it becomes clear that the announcing node was either malicious or announced without verifying the contents.
Status and fork discussion
This EIP is in Draft status, so its format and details may still change. In particular, the overhead figures are still TBD in the source. On the core developer calls, it was accepted as a Hegota candidate (PFI) at 08.13 ACDE #243. It was introduced as a proposal to attach the sender and nonce to transaction hash announcements so the mempool can select more intelligently. At 10.08 ACDE #247, it was moved to Considered for Inclusion (CFI), on the condition of an in-depth analysis that includes frame transactions and fee fields. It is assessed as a networking improvement that helps the mempool hold up as the gas limit rises.