Request/Discuss: Multi-Dimensional Nonces

[kamescg]

One of my favorite parts of the ERC-4337 specification is the flexibility of nonces.

As we all know EOA wallets are required to use a single nonce and increment that nonce every time a transaction is submitted. And generally speaking smart accounts (i.e. Safe) have adopted that approach for smart contract wallets, even though technically it's not required.

But the ERC-4337 specifically points out that trend does not to be followed.

In Ethereum protocol, the sequential transaction nonce value is used as a replay protection method as well as to determine the valid order of transaction being included in blocks.

It also contributes to the transaction hash uniqueness, as a transaction by the same sender with the same nonce may not be included in the chain twice.

However, requiring a single sequential nonce value is limiting the senders’ ability to define their custom logic with regard to transaction ordering and replay protection.

Instead of sequential nonce we implement a nonce mechanism that uses a single uint256 nonce value in the UserOperation, but treats it as two values:

• 192-bit “key”
• 64-bit “sequence”

https://eips.ethereum.org/EIPS/eip-4337#semi-abstracted-nonce-support

Given the trend towards "intents" and having the need to potentially execute transactions out of order and based on different constraints, I wanted to surface the conversation of potentially supporting multiple nonce types in the Coinbase Smart Wallet.

As an example I'm including a link to a "smart transaction" prototype that lets a users choose from multiple nonce types while still using a single packed 32 byte word.

• Standard Nonce
• Multi-Dimensional Nonce
• Time Nonce

https://github.com/district-labs/smart-transactions-v0/blob/main/contracts/intentify/src/nonce/NonceManager.sol

tl;dr

Not being required to use a sequential nonce could open up some interesting opportunities for the blockchain user experience. So mainly starting this conversation, while the Coinbase smart wallet is still in active development.

• How can the UX being improved by using a non-standard nonce?
• Is supporting multiple nonce types in the Coinbase smart wallet worth it?
• Could these nonce features be added as a module?

[wilsoncusack]

Thanks! We already do support the ERC-4337 nonces, and use a specific nonce key for repayable transactions. Do you have something more in mind?

[kamescg]

Reviewed the code. And I might also be misunderstanding the ERC-4337 but I interpreted it as being able to enable different type nonce styles i.e. having multiple "queues" that each have a stand-alone nonce or something that includes a timestamp for when a transaction can be executed. This wasn't in that exact line I've seen it in in the past in video/docs explaining some low-level erc-4337 stuff.

Kind of a far fetched idea, but might be useful for things like intents and being able to pre-sign more long-running transaction authorizations

After reading both your comments though, probably makes the most sense to think about trying these types of experimental ideas as modules that can extend the core smart wallet capabilities and be more self-contained.