ERC-7521: Generalized Intents for Smart Contract Wallets

EIPs
, , ,
1

Discussion thread for ERC-7521: Generalized Intents for Smart Contract Wallets.

The purpose of this ERC is to provide a single common interface for intent-based projects in the Ethereum ecosystem, unlocking future-proof access to the evolving intent landscape for developers and securing composability in the longer-term.

5 Likes
2

A more detailed rationale is outlined in this blog post. Any discussion related to this ERC can be facilitated below.

3

It is complex, how is the gas cost?

4

It depends on how complex the intent is and gas usage is more efficient when lots of intents are included in the same solution. Weā€™re currently working on gas optimizations, but weā€™re aiming to make it not much more expensive than ERC-4337. We should also be able to take advantage of EIP-1153 once it goes live.

5

Thanks for your work on this! I just have a couple questions to clarify after reading through the proposal.

  1. How would you let solvers submit additional data like for example if a standard requires proof of some computation or proof that some conditionals had been met with private data? Or basically if a standard would want some extra data for validation on the intent solution, can the context be used for this (not sure)?
  2. Do you guys have any thoughts on proving an optimal solution was submitted?
  3. Any thoughts on intent privacy and how this standard would evolve for that?
  4. If the intent entry point needs to be upgraded is there an easier way to upgrade for all standards and AA wallets instead of manual updates?
  5. Is it possible for different solvers to cooperate on different segments of an intent? For example, if they are specialized in different things like bridging, swapping, resolving external data dependencies etc.
2 Likes
6

  1. Good question! This would be a design problem for the intent standard to develop. One possible solution could be to create two new intent standards, lets call them ā€œData Blob Standardā€ and a ā€œZK Proof Check Standardā€. The ā€œData Blob Standardā€ would simply be an arbitrary bytes dump that is intended to be placed just before another intent segment that would like to consume that data. the ā€œZK Proof Check Standardā€ could then check that the segment processed before it is of the standard ā€œData Blobā€ and use itsā€™ data as a provided ZK proof. Iā€™ve actually gone ahead and added an issue to the reference implementation for the EntryPoint to gracefully interpret an intent with no set standardId or sender as a data blob.

  2. Itā€™s difficult to do this on-chain, but we imagine dutch auction style flows to achieve similar results. For example, a basic trade intent that releases more and more ETH over time in order to get the DAI they want. Another controversial way to do it would be a private mempool, but could also be done decentralized using something like flashbots SUAVE.

  3. Havenā€™t thought too deep about privacy, but I imagine thatā€™s something that needs to be done on the mempool off-chain side of things. Again, projects like SUAVE could help.

  4. All the standards would have to be redeployed for the new EntryPoint contract, yes. The reason the registration process is so strict was to avoid any possible exploits from registering a contract as an ā€œIntent Standardā€ that really isnā€™t. I canā€™t actually think of any exploits right now, but early in the spec construction, there was some cause for concern with overlap in function names and an old requirement that the smart contract wallet had to give super permissions to calls coming from the EntryPoint (no longer the case). If we think this is being too cautious, we can remove it. Making the smart contract wallet store the EntryPoint in storage is really just a gas optimization thing. We could add EntryPoint to the signed intent itself, but it would add calldata and still require the setting and clearing of the EntryPoint in the wallets storage as it needs to persist for the rest of the transaction in future function calls on the wallet. Transient data (EIP-1153) could help here though.

  5. Havenā€™t thought too much into that. I think this is out of scope for the spec, but it might be possible on the mempool layer where partial solutions would be gossiped instead of individual intents. Of course, this would require a trusted relayer, or possibly use something like SUAVE for more decentralization.

1 Like
7

Hey,

Solid proposal and interesting adoption of EP idea to intents space.

  1. Instead of smart contract wallets having to constantly upgrade to provide support for new intent standards as they pop up

Is it still the case with Modular Smart Accounts? Installing a new module to support new intent standard would be easy process, much easier than upgrading a wallet

8

Modular Smart Accounts will be helpful for smaller things like adding signature schemes, but it would still be a burden to users to have to make sure their wallet has all appropriate modules installed (and the correct version of the modules) before every action. Consider the scenario where a user wants to sign two intents that require different versions of the same module. The user would potentially have to go back and forth uninstalling and installing different modules before each intent, and you couldnā€™t overlap intents that have incompatible requirements.

I would also say that there is slightly better security in electing code to run once via ERC-7521 rather than having it become a permanent part of your wallet. In ERC-7521, if a bug is identified later down the road, only wallets that have unsolved intent floating in the mempool would be effected.