Detailed explanation of ERC-7521 draft: adding user intent to account abstract wallet

Original author: Stephen Monn

Original compilation: Deep Chao TechFlow

In the ever-evolving landscape of blockchain and decentralized applications, more and more attention is being drawn to the concept of user-defined intent rather than pure transactions. This frees users from having to worry about navigating the increasingly complex process of DeFi and unlocks a host of additional use cases that are only now being conceived.

With individual applications already using their own different and incompatible intent structures, it makes sense to create a common intent standard that can be shared and understood by all users, applications, wallet software, solvers, searchers, etc.

To aid composability and lower the barrier to entry, we propose ERC-7521, a standard that supports the common intent of smart contract wallets.

What is user intent?

Since this field is so new, the definition of intent is currently a bit fuzzy. From an overall concept, the term is generally used to refer to a user's expression of a desired on-chain outcome or end state. For the purposes of this specification, an intent is defined as a set of actions and expectations set by a user. These operations and expectations may be combined with those of other intents in an effort to meet the common and best interests of all parties involved.

A series of on-chain operations that satisfy all parties involved is called a solution. Specialized resolvers (similar to bundlers in ERC-4337) will compete to find the solution that provides the highest satisfaction to users. This can be achieved, for example, by finding the best/most efficient on-chain path, leveraging off-chain liquidity sources, combining the intentions of different users to exploit common needs, etc., even including their own intentions.

Add user intent to account abstraction

The key to enabling universal intent is to use smart contract-based abstract accounts. Similar to ERC-4337, intents are signed as messages and then verified on-chain via separate transactions. These signed messages are then propagated in their own memory pool.

The goal of this specification is not to create a framework for smart contract wallets to integrate and automatically support the broad range of possibilities defined by the signed intent itself. Therefore, the framework also needs to allow for a seamless and permissionless upgrade and code extension process as new intended use cases emerge.

Single entry and unlimited intent standards

To help facilitate this seamless and allowed upgrade and expansion process, the EntryPoint contract in ERC-4337 was modeled, but also split into two distinct parts. The first part, called the entry point, is the main entry point for submitting intent solutions and is responsible for validating intent signatures and running high-level intent processing logic.

The specific content of the intent processing logic is defined in a separate contract, called the intent standard, which is specified by the signed intent itself. Entry points call these contracts to handle an intent. It is the intent standard that defines how attached intent data and execution are handled, as well as basic off-chain rules related to denial of service attack vectors inherent to the intent, such as how messages are delivered to resolvers and protection mechanisms against DoS attack vectors inherent to the intent. .

These standards of intent should be established self-contained, independent of this specification. We expect that as the intent landscape becomes more mature, optimized niches and emerging use cases emerge, new intent standards with additional capabilities will emerge. Adoption and support of these standards will be driven by social consensus among wallet developers and intent solvers, as well as end-user demand.

To ensure that our proposed ERC has significant functionality in its early stages, we have developed an asset-based intent standard to support most current blockchain use cases. We will refine this standard (and this ERC) in a public environment to adapt to the needs of the ecosystem.

Vague but powerful intent structure

User intent contains primary data that can be broken down into two parts:

• Necessary verification data used by the Entry Point contract to verify messages with the sender before executing them.
• Intent Standard-specific additional data specified by the intent.

Intent standard data can be anything, but is always broken into separate parts called intent segments.

The Entry Point contract does not explicitly understand what the data is, but it does recognize the division into segments. The Entry Point contract calls the Intent Standard contract to process one segment at a time, and enforces that the intent's segments are always processed in the specified order. However, Entry Points allow other intents to be processed between execution segments.

These intent segments usually consist of actions the user wishes to handle or to check whether certain conditions are met. In addition, one Segment can pass data to the next Segment during processing. This data is called intent context data and is useful in validating changes that occurred between segments and avoiding the need to recalculate useful data. Again, making full use of this data is determined by the Intent Standard specification.

Combine intentions for maximum satisfaction

During intent processing, the intent is able to raise dissatisfaction with any type of condition, whether it's an unexpected low balance or any condition that the intent's criteria might be looking for to evaluate to false. When this happens, the entire transaction is rolled back, including processing of unrelated intents that may have occurred previously.

Only when a set of intentions are submitted and processed in an order that satisfies all parties are they considered spent and the resulting state allowed to be persisted on-chain. It is these combinations of intents that form the solution and are passed to the Entry Point contract for processing.

However, simply submitting a list of intents is not enough because segments for different intents can be arranged in different orders. Therefore, a solution also specifies how different intent fragments should be ordered during processing (how different intent fragments should be interleaved).

Part of the solving process typically involves the solver formulating an intent to help satisfy a set of other intents, allowing them to maximize user satisfaction while generating some profit.

Conclusion: Enhancing Intent-Driven Blockchain Interactions

The focus of the specification is to define a basic framework for smart contract wallets so that they can connect and unlock powerful expressions of intent for users, even as the landscape continues to evolve. Defining intents as a collection of smaller intent segments provides a great experience for the user and reduces the number of times the user needs to sign. Intent segmentation and shared background data also help unlock powerful capabilities without using large amounts of gas. Intents can trust that all their segments will be processed sequentially without manual inspection.

Universal user intent opens up a whole new world that is only now beginning to be explored. From simple gasless token swaps to more complex conditional intents that automate processes like transferring funds from cold to hot wallets or making daily coin purchases via a single signed message, the possibilities for intents are vast! Our specification of the asset-based intent standard is the first of many iterations that will enable the community to take advantage of this new framework.