It’s been two and a half months since we first released the ERC-7521: General Intents for Smart Contract Wallets spec. Since then we’ve been collecting feedback and improving on the design. We are now ready to publish the first revision to the spec which includes several changes aimed at widening the possibilities of generalized intents. Continue reading for a breakdown of what’s new.

Intent Standard per Intent Segment

Intents no longer have to belong to a single intent standard definition, meaning the individual segments that make up an intent can specify their own standard. This change makes intents more modular in their construction and should simplify intent standards themselves into easier to consume bite size concepts. Consequently, solvers should have an easier time understanding intents as all they have to know is a few core primitives that make up each intent and not many all-encompassing intent standards. This also allows concepts that were previously hardcoded into the Entry Point to be included optionally as an additional segment to the intent (more on this later).

Context Data Management

With intent segments now able to belong to different intent standards, the context data passed around from segment execution to segment execution now needs a more formal structure. To accomplish this, the context data now acts as a simple data stack. Segments of one standard can push data to the stack for another standard to pop and consume later. If a segment doesn’t use the context data, it simply leaves it unchanged and passes it forward for the next segment’s potential consumption. Also note that intent segments need to be ordered correctly to ensure context data is appropriately added and consumed.

Nonce Management

Nonce management has been removed as a responsibility of the Entry Point and is instead an intent standard to be included as one of the segments in an intent. This change allows multiple replay prevention strategies to be developed and utilized instead of just the nonce solution. It also opens the door for intents that want to be replayed!

Nonce Storage in the Entry Point

Multiple intent standards may want to read or write to the same storage values. To help accomplish this, the Entry Point contract now includes read and write functions for nonce values or any other sort of shared storage that might be useful between standards. For security reasons, these nonce values are only allowed to be written to by the currently executing intent standard and solely for the currently executing intent sender.

Signature Aggregation

Native Entry Point level signature aggregation support has been added. While this could technically be handled at either the wallet level or intent segment level, it’s most gas efficient if the Entry Point contract handles it directly and prevents each intent from having to verify intent validity redundantly. The aggregation technique closely follows the technique currently specified by ERC-4337, where the intent validation function can now return an address pointing to a signature aggregation contract if direct signature validation failed. Even though this design mirrors ERC-4337 very closely, it should be noted that the aggregation contracts cannot be reused and will need to be tweaked for ERC-7521 as some of their functions directly consume the UserOp or UserIntent objects for optional introspection.

Smaller Changes

Some additional smaller changes that were made include:

• Intent Standard Re-Use - Intent standards no longer need to explicitly point to a targeted Entry Point contract allowing them to be registered to newer Entry Point versions without redeployment.
• Removal of Timestamp on Intent Object - The timestamp field on the intent object has been removed and any sort of time based validity conditions are now applied to an intent as an added intent segment.
• Searcher Based Simulation - There is no longer a dedicated solution simulation function since solvers are expected to be sophisticated enough to dry run the actual solution themselves and be involved in the current proposer builder separation process.

Conclusion

The modifications introduced in Revision 1 of the ERC-7521 spec aim to make intent standards more accessible and flexible. We continue to welcome feedback and suggestions to further improve the specification. With more composable intents, refined context data management, versatile nonce management, and signature aggregation at the Entry Point level, ERC-7521 is leveling up and getting us one step closer to on-chain adoption of generalized intents. Be sure to follow along at ERC7521.com, if you'd like to contribute to ERC-7521 Development shoot us a message to be added into the developer group.