Hi @soispoke, @nerolation, lightclient and @vbuterin, thanks for putting this together. The privacy-protocols-as-shared-senders bottleneck is a real problem, and decoupling replay protection from a single linear sequence is the right shape of fix, we solved it at EVVM on the SC virtualization layer and works great.
In the following post I explain in more detail our experience with this concept, which we call asynchronous nonces, and, based on 3 years of iterations, we have some functionalities that could be interesting to consider in the design of the Keyed Nonces.
1. Non-authoritative reservation as a deliberate choice.
EVVM ships one reservation primitive on top of the keyed nonce, and only one: non-authoritative.
Any actor (the user, an app, middleware) can publish “I intend to use nonce X” onchain at gas cost. The registry does not block anyone else from using the same nonce; it just makes intent visible and indexable. We deliberately did not ship authoritative locks because authoritative locks introduce their own failure modes: lock-grabbing as a DoS vector, bad-UI lockups holding keys hostage, and the same heterogeneous-RNG concern shifted onto a different primitive without solving it. An advisory layer adds information without adding new ways to deny service.
This is the point worth flagging for EIP-8250 specifically. The spec correctly notes that applications “deriving nonce_key from a per-use identifier SHOULD domain-separate the input and reject derived keys equal to 0.” But there is no protocol-level visibility into what keys are intended to be used, only what has already been used. In the edge case where two independent wallets generate the same nonce_key for different purposes (the 2**256 space makes it cosmically unlikely with strong RNG, but real-world UI code is not always strong RNG), an advisory registry surfaces the conflict before consumption. Cheap signal, voluntary, gas-priced, and the 2**64 nonce_seq space leaves room to reissue under a fresh derivation if a collision is detected.
Whether this belongs in EIP-8250 itself or in companion infrastructure is a separate question. It is worth at least anticipating in the Rationale or Security Considerations, since downstream wallets and middleware will face the heterogeneous-RNG question regardless of where the keyed-nonce state lives.
In case the Keyed Nonces are decided to be unique for just once general usage, not account linked, it will also work for the account purposes. Because a general “used” state is still different than “I want to reserve this for my own transaction future usage” state.
2. Pairing keyed nonces with tx.origin and msg.sender checks in the same validation step.
The EIP solves replay-domain separation; it doesn’t address “who is authorized to submit or relay this transaction”. By validating signature + nonce + (origin, sender) executor permits in one atomic call, two primitives become useful in practice, which we would like to be considered, or can be part of a new EIP propossal, but are directly linked to the keyed nonces usage:
-
tx.originlets you restrict, at the validation step, which EOA is allowed to land a given keyed transaction. For relay markets and Fisher-style networks (check EVVM for reference), this is the difference between “any submitter can extract this signed payload and replay it through a competing pathway” and “only the originator’s intended relayer is honored”. A lot of infra-level implementations open up if the validation cooperates with this hint. -
msg.senderlets contracts queue, store, and conditionally trigger user-signed transactions onchain, without needing staking or token-permission systems to trust the relayer. Trust comes from auditable contract code rather than economic security. Concrete pattern: a Storage contract that holds signed user transactions until a condition is met (timelock, oracle output, multisig vote), then becomes themsg.senderexecuting them. Code-level trust replaces slashing economics for an important class of intent-based and time-locked flows. This would be a major upgrade in general for the network, and requieres Keyed Nonces to work.
3. On necessity at protocol level
Not to argue against the EIP, just to give the discussion a data point: a lot of what EIP-8250 unlocks at the application layer is already accessible at the contract level today, with no fork. Async nonces in a mapping have served real privacy, shared-sender, and parallel-intent flows in production for us. The state-growth tax that motivates KEYED_NONCE_FIRST_USE_GAS = 20000 is real but, on contract-level implementations, has not yet approached a ceiling that would justify lifting the model into protocol. Smart-contract iteration speed on this surface has been a meaningful advantage while the use cases mature.
4. Design risk
Finally, there is a very big consequence that we in EVVM have seen happen constantly, and that is that by having Async Nonces available, for convenience, absolutely all devs have stopped using Sync Nonces (normal nonces of current EVM), leading these standard nonces to obsolescence.
Thanks again for the work on this.
Best,
German Abal (@ariutokintumi)
Co-founder of EVVM.org, ETH Cinco de Mayo, IAldea.org
Speaker at ECH Institute EIP Summit 2025 (talk).