-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request/Discuss: Multi-Dimensional Nonces #20
Comments
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? |
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. |
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.
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.
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.
The text was updated successfully, but these errors were encountered: