Discussion topic for EIP-8250: Keyed Nonces for Frame Transactions · Pull Request #11598 · ethereum/EIPs · GitHub
Abstract
Replaces the single sender nonce of an EIP-8141 frame transaction with a (nonce_key, nonce_seq) pair. nonce_key == 0 aliases the legacy account nonce; each non-zero key selects an independent protocol-managed nonce sequence stored in a NONCE_MANAGER system contract. Transactions on different non-zero keys are replay-independent.
Motivation
A frame transaction currently consumes one linear sender nonce, so a delayed transaction blocks every later frame transaction from the same sender. This is too restrictive for designs that intentionally share one sender across many independent users or actions.
The leading example is privacy protocols. To avoid binding onchain activity to a unique public sender, users transact through a single shared sender address. With one linear nonce, that shared sender becomes a throughput bottleneck: one user’s inclusion invalidates every other user’s pending withdrawal even when the spends are otherwise unrelated. Smart-wallet session keys and relayer-style senders face the same problem.
Keyed nonces let each spend pick its own nonce domain, for example one derived from a privacy nullifier. Transactions on different keys are replay-independent. This removes the protocol-level nonce obstacle to future keyed-aware mempools that admit concurrent transactions from the same sender. This EIP does not by itself change EIP-8141’s public-mempool guidance.
Tying nonce consumption to EIP-8141’s payment-approval step also gives single-use-key applications, such as nullifiers, an atomic spent-once guarantee: if validation requires the selected key to be unused, successful inclusion makes it used, regardless of whether later frames revert.