TL;DR

• Userops (ERC-4337) are slow, complex, and high-cost.
• Intents are fast, simple, and low-cost.
• Intents can be chain agnostic (ERC-7683). Ethereum’s horizontal scaling strategy almost guarantees that intents will eat userops.

Introduction

Account abstraction is the end game for the mainstream adoption of Ethereum-compatible blockchains. In 2023, ERC-4337 was introduced as the transaction infrastructure to enable smart accounts in a permissionless and decentralized manner. We believe this infrastructure will remain foundational to Ethereum’s account model remaining trustless and censorship resistant. However, this infrastructure’s complexity, cost, and latency limit the widespread adoption of smart accounts. Furthermore, Ethereum’s liquidity fragmentation across many L2s necessitates a transaction infrastructure that is dynamic, lightweight, and chain agnostic.

Intents and standards like ERC-7683 are eating userops. They present a number of advantages: cost efficiency, speed, developer simplicity, and the ability to be easily extended to support cross-chain transactions. In our 2025 predictions, we wrote that ERC-4337 would be met with new competition. The competition is intents, and the adoption is already taking off, with many account abstraction players making the switch.

It’s important to highlight that intents and userops are not mutually exclusive. They are complementary. The complexity and overhead of ERC-4337 come from its open and permissionless properties. We believe ERC-4337 is foundational to ensuring that Ethereum’s account model remains trustless. But for speed and best-in-class UX, intents are taking over.

What Are Userops?

ERC-4337 introduces infrastructure at the application layer of Ethereum to enable account abstraction. That is, enabling smart contract accounts (herein “Smart Accounts”) to transact without relying on an Externally Owned Account (EOA). The introduction of Smart Accounts makes the user account programmable and unlocks many new quality-of-life features for end users (e.g., gas abstraction and batching).

ERC-4337 infrastructure enables Smart Accounts by introducing User Operations (userops), which are pseudo-transactions that contain transaction details to be executed on behalf of the user. Userops are sent to a dedicated mempool, bundled by specialized actors called bundlers, and submitted to the blockchain via a global entrypoint contract.

Key Features of Userops:

• Batching Transactions: Users can perform multiple actions (e.g., token approvals and swaps) in one transaction.
• Flexible Gas Payments: Gas fees can be paid in ERC-20 tokens or by third parties (i.e., paymasters).
• Isolated Validation Phase: The separation or userop validation and execution, and the introduction of opcode restrictions in the validation phase, allows for an open mempool that is DOS resistant.

The scope of userops is focused on single-chain interactions, enhancing functionality and user experience within a specific blockchain like Ethereum. Systems that extend userops to multiple chains, such as Biconomy’s MEE, do so by bundling userops and sequentially executing them through traditional bridging routes. These routes are packed into a single signature envelope signed by the user.

What Are Intents?

Intents are user-defined goals like swapping tokens between two chains or staking assets across networks. A network of fillers (or solvers) competes to execute these intents efficiently across multiple blockchains.

ERC-7683 standardizes cross-chain intents, allowing users to specify desired outcomes across blockchains without worrying about the underlying execution routing. Intents abstract away the complexities of the underlying chain or protocol delivering the required transactions to achieve the desired outcome.

Key Features of Intents:

• Cross-Chain Interoperability: Intents enable seamless actions across different blockchains, eliminating the need for users to manage multiple wallets or bridges.
• Simplified User Experience: Users specify what they want (e.g., “Swap Token A on Chain X for Token B on Chain Y”), and fillers handle how to achieve it.
• Standardized Execution: ERC-7683 provides a unified framework for expressing and fulfilling intents, making it easier for developers and fillers to participate.

The scope of intents is, by definition, broad. It includes same- and cross-chain interactions, addressing the challenges of operating in a fragmented, multi-chain ecosystem.

Why Intents Are Eating Userops

Account abstraction is a key transition for Ethereum as we move from a niche technology into mainstream adoption. It introduces many quality-of-life improvements that are necessary for the vast majority of the population to engage with blockchain-based and self-sovereign systems.

ERC-4337 brought the first wave of early adopters and a significant increase in the tooling and services available to developers building on smart accounts. However, it did not bring about a sizable rise in Smart Account users. One driver for this was the friction in migrating from an existing EOA to a Smart Account — EIP-7702 resolves this and will be included in Pectra. The second is the complexity and overhead ERC-4337 introduces, creating friction for developer adoption and increasing the cost of transacting (gas).

The core drivers for intents eating userops:

1. Enhanced cross-chain liquidity and efficiency
2. Faster execution
3. Cheaper gas costs
4. Simplified developer and user experience

Enhanced Cross-Chain Liquidity and Efficiency

The proliferation of layer 2s, especially appchains, means users increasingly need to interact across chains. Intents provide a unified way to handle these interactions, reducing friction and improving accessibility. Userops, while powerful, are limited to single-chain environments and do not address cross-chain needs without adding extra layers of complexity. Furthermore, paymasters restrict locked funds to a specific gas operation on a single chain, limiting inventory utilization.

Intents, however, provide solutions that enable a shared network of solvers who can compete to fulfill user requests and absorb the added complexity. This competition can lead to better pricing for complex cross-chain routes (e.g., those that include swaps) and faster execution across chains, resulting in a more efficient use of liquidity across the ecosystem. The flexibility in solver actions also guarantees a much higher utilization rate of stored inventory.

Faster Execution

The ERC-4337 process has multiple stages, especially those involving paymasters, introducing significant RPC latency. A sponsored userop has multiple round trips between the ERC-4337 infrastructure and the wallet, resulting in meaningful RPC latency. On the other hand, intents utilize a network of fillers who compete to execute the user’s request as quickly and efficiently as possible. Since much of the work (e.g., finding the best execution path or liquidity source) happens off-chain, intents avoid the bottlenecks of onchain processing that userops require. Fillers can respond to real-time conditions — such as selecting the fastest DEX or intent-bridge — ensuring quicker execution than the rigid userops pipeline.

Cheaper Gas Costs

Intents are significantly cheaper regarding gas fees because they avoid the expensive infrastructure required by ERC-4337. ERC-4337 relies on a multi-layered system to process user operations: paymasters, bundlers, and a global entrypoint contract. Each component adds overhead that increases gas costs. The entrypoint contract is a coordination hub where every userop is validated, gas payments are handled, and execution occurs. This multi-step process requires additional onchain computations, driving up fees. Paymasters, while useful for gas abstraction, introduce extra onchain operations to sponsor or manage gas payments. Bundlers aggregate userops and submit them to the entry point, but this aggregation and submission process also consumes gas, especially as each userop is processed individually.

Intents streamline the process by offloading much of the execution logic to fillers (solvers) who compete off-chain to fulfill the user’s request. This reduces the number of onchain interactions. A user simply signs an intent specifying their desired outcome (e.g., purchase an NFT on Polygon using ETH on Base), and fillers handle the execution, often optimizing paths or batching multiple intents into a single transaction. By minimizing onchain steps and leveraging off-chain competition, intents significantly lower gas costs compared to the heavy infrastructure of userops.

Simplified Developer and User Experience

Intents allow developers and users to focus on outcomes rather than processes. For example, a user can express an intent to swap tokens across chains without understanding bridges or gas fees on different networks. This can be translated to a significant improvement in the developer experience. For example, when a developer uses Omni Account, the only input required from the developer is the destination chain and the desired outcome (e.g., an output token or DeFi action); our path algorithm and solver network do the rest.

Developers can build applications that leverage intents to offer seamless cross-chain functionality without integrating with multiple bridges or protocols individually. This reduces development overhead and fosters innovation, as developers can focus on building user-centric features rather than handling cross-chain complexities. Userops, while useful for single-chain applications, do not provide the same level of flexibility for multi-chain development. They also require a bunch of complex tooling — bundlers for gas estimation, complex simulations, etc — while intents are standard transactions without the need for these extra bells and whistles.

Complementary Nature of Userops and Intents

Userops and intents are not mutually exclusive and can complement each other. For Example, Omni Account is compatible with both intents and userops.

ERC-4337 provides a trustless and censorship-resistant method for Smart Accounts to transact. Although intents provide more than features parity with ERC-4337 bundlers and paymasters (as explained above), it is incredibly difficult to replicate the fully decentralized nature of ERC-4337’s open mempool. By supporting this infrastructure, developers can ensure that in all cases, their users are resistant to censorship, allowing for true self-sovereign autonomy on the blockchain.

In summary, intents provide the performance, efficient, and abstracted transaction rails for Smart Accounts, whilst the ERC-4337 infra provides a trustless vital fallback mechanism.

Conclusion

Conceptually, intents and userops are very similar. However, the flexibility of intents and the relaxation of the constraint to provide censorship resistance enables a drastic simplification of intent-based infrastructure, unlocking speed, flexibility, cost-effectiveness, and a chain abstracted substitute to userops.

In many cases, applications interface with private bundlers, negating the trustless properties of ERC-4337 whilst adopting all the complexity. Intents will eat this order flow and ERC-4337 will fall back to its foundations — censorship-resistant transaction rails for smart accounts.

Intents Are Eating ERC-4337 was originally published in Rhinestone on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Irrevocable signatures are one of the most important elements to chain abstraction. It’s often overlooked and bucketed into the resource lock problem. This article aims to highlight the intricacies of irrevocable signatures for EOAs and Smart Accounts, and the design impacts for chain abstracting both these account types.
• Irrevocable signatures for EOAs is a given, but compromised under EIP-7702. This needs to be carefully navigated to ensure chain abstract Smart EOAs are not able to attack solvers with double spend attacks.
• Smart Accounts enable key rotation, which is a great security feature, but compromises irrevocable signatures. Systems that chain abstract these smart accounts need to also enable irrevocable signatures.
• Omni Account addresses both these concerns ensuring that both smart accounts and smart EOAs can be chain abstracted under one common system.

Introduction

One underappreciated feature of EOAs is their ability to give irrevocable signatures. This means that once an EOA has signed over a blob of data and propagated the resulting signature, that will always be valid, meaning that it will always recover to that same EOA. While it is possible to allow signatures to be single use for a specific protocol, such as by making the signed data unique and then invalidating it when it has been verified once, the holder of the EOA private key has no recourse of revoking their signature unless this is specifically built into the protocol that recovers the signature.

Given that one of the core feature propositions of smart accounts is key rotation, it is easy to see how this paradigm does not necessarily apply to smart accounts. By definition, key rotation is about making signatures, whether already signed or yet to be signed, unusable in case the signing key gets compromised. However, smart accounts generally can achieve irrevocable signatures depending on the tradeoffs that the developer is willing to make. Before going into the specifics of this and how this paradigm applies to “smart EOAs”, by which we mean EOAs (momentarily) transformed into smart accounts through EIP-7702, it feels useful to first elaborate on what the use cases are that require irrevocable signatures.

The importance of irrevocable signatures

Generally speaking, having irrevocable signatures is useful whenever a signature is validated with some delay after being signed. One clear and recent example of this is in the intents and chain abstraction space. For use cases in this space, it is common to have the user sign a payload that is propagated to solvers and only verified onchain at a later time. In chain abstraction, it might even be common to verify a signature at a much later time, after an intent has been filled on a target chain and solvers are reclaiming their funds on the source chain. In fact, this is how our chain abstraction solution, Omni Account, works. Omni Account allows a user to instantly spend funds on a target chain that are dispersed across many origin chains in a single signature. Being trustless on the user side means that solvers also reclaim their funds on the origin chains using the same user signature as authorization. One attack vector here is to revoke a signature on an origin chain before the solver can come back to claim your funds, essentially double-spending.

Smart accounts

As mentioned above, smart accounts are generally able to key rotate without restriction in order to give users a way to mitigate key loss or compromise. However, smart accounts (and especially modular smart accounts) being programmable means that it is feasible to restrict key rotations in different ways depending on the tradeoffs. For example, one could timelock key rotation so that a user would need to wait for a certain amount of time in order to be able to actually rotate their key. This could solve the problem mentioned above with ensuring that signatures will be valid for at least a certain amount of time.

Smart EOAs (EIP-7702)

The problem gets tricker for smart EOAs. The reason for this is that while the account is programmable, it is not fully programmable meaning that some logic sits outside of the account itself so that the code deployed at the account has no visibility over it. This logic is the re- or un-delegation of the account. Full smart accounts deployed as a proxy do not have this issue because even the upgrade of the proxy is an action that goes through the account so can be restricted in certain ways. Because of this, there can be logic that monitors and enforces checks on any actions that could lead to the revocation of a signature and there is a guarantee that this logic will always run. Because this is not the case in smart EOAs, this presents a challenge to any system that depends on such a guarantee.

One solution is to fall back on the signature of the EOA which will continue to be valid even when the account is delegated. The main caveat is that it is common for contracts and libraries, such as solady, to first check if an account has code and then try using ERC-1271 before even trying to use ecrecover. If this is the case in the protocol that one intends to use then it seems like there’s no way to achieve irrevocable signatures using smart EOAs. However, if the signature logic is controlled by the protocol, then the developer can choose to try ecrecover before even checking if the account has code deployed. This is, for example, what Uniswaps TheCompact does.

Conclusion

Irrevocable signatures are a useful construct especially in the context of multiple execution environments, namely rollups, and the desire to verify a signature across multiple environments with a potential time delay. For example, this is how Omni Account allows users to instantly and trustlessly spend their funds across chains with a single signature. However, while EOAs and smart accounts can give the guarantee of irrevocable signatures, smart EOAs cannot, limiting their usefulness or at least reducing their user experience.

Unlocking chain abstracted EOAs with EIP-7702 and irrevocable signatures was originally published in Rhinestone on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Omni Account is a system that chain-abstracts any ERC-7579 Smart Account and Smart EOAs (EIP-7702), unifying cross-chain balances for any intent.
• Central to this system is the Resource Lock Hook, an ERC-7579 module that enables Smart Accounts to make irrevocable onchain commitments, and the Orchestrator, an offchain system for coordinating resource locks and intents with solver networks.
• We’ve partnered with Across as the preferred settlement layer, which, together with our unique onchain architecture, enables instant cross-chain intents that are entirely trustless for the end users.
• The system was developed closely with Magic in preparation for the upcoming Newton launch. We’re excited to support the growth of the Magic ecosystem, which already serves industry success stories such as Polymarket, Immutable, WalletConnect, and Helium.
• We’ve collaborated with Circle to make USDC the preferred token denominator for all gasless cross-chain stablecoin intents. Enabling USDC to flow between networks instantly.
• At launch, Omni Account will be compatible with Safe, Biconomy’s Nexus, and Magic’s upcoming Newton Smart Account, with more implementations on the way!
• Omni Account will also level up EOAs with a resource locking mode that is EIP-7702 ready.
• We’re in prod and ready for integration 🚀

Introducing Omni Account

Rhinestone Protocol 1.0 is the first interoperability protocol for Modular Smart Accounts. It enables any developer to build self-contained components called Modules that securely extend the feature set of any Smart Account, making Modules the Smart Account equivalent of smartphone apps. The next frontier for the Rhinestone Protocol is to make Smart Accounts truly chain abstracted, from balance and address unification to module state synchronization.

Today, we announce Omni Account, an intent-powered system that employs ERC-7579 Modules to transform ERC-7579 accounts and Smart EOAs (EIP-7702) into chain abstracted accounts. Omni Account has two core components: 1) the Resource Lock Hook to enable irrevocable onchain guarantees to offchain entities through a single signature, and 2) the Orchestrator, an offchain entity that sequences transactions and ensures users cannot break their onchain guarantees.

The Orchestrator is currently a single server-side system, but importantly, it is trustless for the user. The initial use case of instant and atomic cross-chain intents is built on Across, allowing the Orchestrator to inherit a robust optimistic proof system. Due to the onchain design of Omni Account, a malicious act from the Orchestrator can only lead to a deposit to the Across Spokepool which will simply return the funds to the user.

The vision for Omni Account goes far beyond solving Ethereum’s fragmented liquidity. Omni Account allows users to express any intent to a specialized execution layer without the strict requirement of atomized settlement. From debit card integrations to offchain order books, Omni Account’s architecture is designed to make resource locks fully open and composable to any developer. One single balance with infinite possibilities — everything everywhere all at once.

To unlock the limitless use cases of resource locks, Omni Account will utilize the full potential of modular Smart Accounts and extend the philosophy behind ERC-7579 (permissionless and open innovation) to the Orchestration layer — more on this below.

Omni Account is already in production, and partner integrations have begun. Check out our demo to see what this new system can do today!

Disclaimer: The demo wallet runs on unaudited contracts. These contracts are for testing and demonstration only.

Partnering with Magic

We’re excited to work with Magic, a leading player in the wallet space, to bring Omni Account to market. Omni Account is built to be consumed by any application looking to instantly access cross-chain liquidity. However, when directly integrated into the wallet, the system reaches its maximum potential. Magic has been a key design partner for the Omni Account SDK, informing core features and infrastructure decisions.

Magic services some of the most significant crypto projects, including Polymarket, Immutable, WalletConnect, and Helium. They are fully integrated into Ethereum’s horizontal scaling strategy, with the Newton chain providing a core piece of the puzzle for the ecosystem’s fragmented UX. Rhinestone is excited to partner with Magic as a key distribution and GTM partner.

Omni Account Architecture

Omni Account consists of the following components:

• ERC-7579 Smart Account: Initially supporting Safe and Biconomy’s Nexus.
• Resource Lock Hook: An ERC-7579 module that enforces resource locks.
• Settlement Executor: An ERC-7579 module that sets verifiable execution pathways for the Orchestrator to the integrated Settlement Layers for claim requests on the origin network.
• Orchestrator: An offchain entity that tracks ongoing intents to ensure those funds cannot be double spent.
• Settlement Layer: An execution layer with sophisticated actors performing executions on the user’s behalf.

Resource Lock Hook

Omni Account employs the Resource Lock Hook, an ERC-7579 module that hooks into every execution and checks a simple invariant: will the execution and any approvals made during execution reduce the account balance below the resource-locked amount? If false, the Resource Lock Hook allows the transaction to pass. If true, the transaction will only pass with a signature from the Orchestrator to ensure that those funds aren’t already being spent elsewhere.

This novel approach has many favorable traits when compared to the existing escrow and co-signer models by combining the best from both approaches:

• A flexible trust model: Like the escrow model, only locked funds require a signature from the Orchestrator to be spent. The user decides whether to lock their assets perpetually, partially, or just in time.
• No separation of assets: Like the co-signer approach, assets need not be separated into a new contract to be locked. This quality-of-life feature ensures user balances are easier to track and index with existing tools.
• Composable and interoperable: The Resource Lock Hook is built to be minimal and nonintrusive to Smart Accounts’ regular functionality. Orchestrator signatures are only required for locked assets; therefore, no functionality, feature, or new product innovation is blocked during the account’s regular operation. ERC-7579 accounts remain extensible, portable, and secure — an open platform for innovation.

One Signature. Any intent.

The Resource Lock Hook employs an ERC-712 signature envelope to encode complex cross-chain intents into a single signature. This signature contains the cross-chain routes and arbitrary call data to be executed on the destination chain, allowing any intent to atomically execute with the cross-chain transfers once funds hit the destination chain Omni Account. From the user’s perspective, this is one signature for any instant intent.

Omni Account provides M-to-1 origin chains to a destination chain and M-toN input tokens to output tokens. Solver-based swapping allows users to combine any supported token from any supported chain to execute any intent with one signature.

If Ethereum’s horizontal scaling strategy plays out as expected, the first time a user interacts with an onchain app will likely be their first interaction with a new chain. Therefore, a scalable Chain Abstraction system must enable instant cross-chain intents even if the user does not have an account on the destination chain. Omni Account provides this functionality with a just-in-time deployment flow. With one simple action, the user authorizes the intent and the deployment of the Omni Account.

Finally, the Omni Account system guarantees a deterministic output token (i.e., no slippage) and destination chain atomicity. Solver routing issues caused no partial fills or failed executions. This is all guaranteed without requiring a single solver to fill the entire intent.

EIP-7702 Compatibility

The obvious counterpoint to the Resource Lock Hook is that it is incompatible with EIP-7702. The private key of an EOA delegated to an Omni Account can always subvert the lock. For this reason, the Resource Lock Hook module has been built to support the Compact, an open-source escrow specifically designed for cross-chain intents.

The Resource Lock Hook signature payload is structured to match the Compact. Therefore, to support EOAs, the developer activates an EIP-7702 flow that points the Resource Lock Hook to the Compact for balance unlocks. All other components and integration points are unchanged!

Chain Abstracted USDC

We’ve collaborated with Circle to make USDC the underlying token for any cross-chain intent. Hold USDC and instantly perform any cross-chain action: swap, LP, lend, borrow, or buy an NFT. Whatever the intent, the Omni Account system can transform the initial USDC position into a series of destination chain executions and cross-chain routes that lead to one atomic experience for the end user. A key ingredient to enabling this without wrapping USDC is the Resource Lock Hook. The hook has a pre-validation function that prevents the permit function on the USDC contract from bypassing the lock.

The Orchestrator

The Orchestrator acts as a trusted entity to enforce resource locks. It listens to user intents, propagates them to a solver network, creates resource lock allocations for counterparties (e.g., the Across Relayers), and facilitates the claim process via the chosen settlement layer (e.g., Across).

Orchestrator Trustlessness

The Orchestrator is trustless from the end user’s perspective. This is achieved through Omni Account’s onchain architecture. The Orchestrator can only interact with the Smart Account via the Resource Lock Hook and the Settlement Executors, providing onchain verifiable transaction rails. The current Settlement Executors utilize the Across Protocol as the sole settlement layer. Even if the Orchestrator managed to transact without the user’s approval, the transaction could only be sent to the Across Spokepool, leading to a refund via Across’ optimistic proof system.

The Orchestrator also does not present any liveness and censorship risk to users. This is achieved via an onchain escape hatch that can be activated through an onchain call without dependency on Rhinestone or the Orchestrator.

At launch, sophisticated solvers are the only party that needs to trust the Orchestrator. They must trust that the accounting and security checks are performed correctly, preventing users from doublespending the system. However, solvers do not depend on the Orchestrator for claim requests. This process is permissionless and trustless.

Furthering Decentralization

The Orchestrator only co-signs transactions involving locked funds (unlike a co-signer approach that requires signing every Smart Account interaction), making the system significantly more straightforward to operate and maintain. This reduced complexity creates a more efficient path toward solving the second challenge of verifiably correct sequencing and security checks. The Orchestrator has been built in Rust, and zkVM is being explored to provide a verifiable and trusted computing environment. Our mission is to make the Orchestration layer open and permissionless, and we’ll be publishing research and diving into this with early partners building on resource locks.

Multi-Modal Orchestration Layer

Our vision is for the Orchestration layer to exhibit properties similar to those of ERC-7579, allowing developers to spin up an application-specific Orchestrator node that can provision allocations and claims on a single locked balance per user. The core component is a shared and verifiable intent queue. We’re in the early ideation phase of architecting this multi-modal orchestration layer and are open to collaboration. If you’re developing a product that can benefit from account-native resource locks, please reach out!

Conclusion

Omni Account significantly levels Ethereum’s UX and interop, unifying account implementations and chains. Starting with Safe, Nexus, and Magic’s Newton, Omni Account unifies balances across all EVM-compatible chains and enables users to express any intent to a specialized execution layer without the strict requirement of atomized settlement. For the user, these actions are instant and atomic, completely removing the concept of a “network” from the web3 application UX.

Omni Account is in production under a private beta. Please reach out for an API key to get started!

Omni Account: A new paradigm for cross-chain interop was originally published in Rhinestone on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the last few weeks, EIP-3074 has been seriously and widely debated in the account abstraction ecosystem. The EIP was flagged for inclusion in Pectra, starting development for devnets, dev tooling support, prototyping and debates around the standard. One core debate focused on its impact on the account abstraction roadmap and on existing account abstraction designs, most notably ERC-4337.

Yesterday, Vitalik proposed EIP-7702 which aims at a similar goal as EIP-3074 but has a different implementation. Notably, it seems more aligned with the account abstraction roadmap, existing infrastructure as well as proposals, including RIP-7560.

Overview of the EIP

EIP-7702 takes inspiration from EIP-5806 and proposes a new transaction type, during which the contract of a list of EOAs can be set with the provided code relevant to each EOA. In practical terms, it means that on top of the existing fields of a tx, an array is provided, which includes a contract code and signature per element. When executing this tx type, a client would loop over this array, recover the EOA address for each signature, and set the code of this EOA to the provided contract code. At the end of this transaction, the code of all of the EOAs provided is removed. The proposal does not require any of the EOAs provided to be the transaction origin, making it compatible with relayers, including ERC-4337 bundlers.

How does it differ from EIP-3074

EIP-3074 introduces two new opcodes, AUTH and AUTHCALL. On a high level, AUTH recovers the signature of an EOA and, if successful, sets a context variable that allows for AUTHCALLs to happen. AUTHCALL executes a call that is, in most respects, similar to the normal CALL opcode but uses the recovered EOA address as the message sender. This means that an EOA can give a so-called invoker contract permission to execute calls that originate from that EOA.

Both proposals have the same goal: to give EOAs the ability to execute code. EIP-3074 achieves this by allowing a contract to execute calls with the EOA address as the message sender. EIP-7702 achieves this by setting the code of the EOA for the context of a transaction. Thus, the latter is almost completely compatible with existing smart accounts since a user can just sign over their code using their EOA and have that code live under the EOA address for the scope of a transaction. By contrast, EIP-3074 requires rebuilding existing smart accounts to use the proposed opcodes (as discussed in a prior blog post).

Why it is more aligned with the account abstraction roadmap

Currently, the account abstraction roadmap on Ethereum depends on ERC-4337 and (in the future) RIP-7560. The core focus of both of these proposals is censorship resistance and decentralized relaying. One key factor in this pursuit is the separation of validation from execution. However, with EIP-3074, validation (using AUTH) is tightly coupled with execution (using AUTHCALL), making it harder, but not impossible, to decouple these from each other. By contrast, EIP-7702 does not have such a restriction and is entirely un-opinionated towards the design of the smart accounts.

Longer term, the goal of the account abstraction roadmap is to move all users onto smart accounts, some of which will need to happen through permanent migration from EOAs to smart accounts. The way this would likely occur in an EIP-3074 world is with EIP-5003. This extension adds another opcode, AUTHUSURP, which allows contract code to be permanently deployed to an EOA address without code. In EIP-7702, migration could be implemented much simpler, potentially making it as easy as adding a flag to the signed data.

A clear path to permissionless innovation

In our prior blog post, we discussed invoker whitelisting by wallet vendors as the most restrictive element to the design space around EIP-3074. In short, if a dapp wishes to build new product features that require a novel invoker contract, they must have the contract whitelisted by all relevant wallet vendors.

Our proposed solution to this problem was a modular invoker that borrows from the research and development around ERC-7579 and/or ERC-6900. This would allow for one or a few highly secure and trusted modular invoker implementations that are universally whitelisted and extended by any developer via a module. A permissioning and security system borrowed from the modular account abstraction space would then allow for the permissionless development of invoker features.

EIP-7702 creates a simple means of directly adopting the existing modular account abstraction solution to unlock permissionless UX innovation with EOAs. It ensures backward compatibility with existing modular smart account implementations and all the tooling and infra being built around modular smart account standards.

One further upside of EIP-7702 is that it makes it far easier to build an application that uses smart account features like batching, sponsorship, session keys, and more for both EOA and smart account users. While this is to some extent also true for EIP-3074, an application would likely have to go through more effort to become compatible with both. In the worst case, this means that dapp developers might choose to only support one or the other, creating fragmentation for users, essentially forcing them to have both an EOA and a smart account that needs to be used depending on the application.

Open questions

In-protocol revocation

EIP-3074 initially did not include a way to revoke AUTH signatures in the protocol. Having this in the protocol means that even when an invoker becomes malicious or has some sort of bugs, it would be possible to revoke the signature. After input from the community, the proposal was amended so that the EOA nonce and chainid would also be signed over. Nonetheless, this change still sparked a lot of debates.

EIP-7702 currently includes no in-protocol revocation mechanism, but there are some suggestions to include it. However, one downside of this is the need to pick a specific mechanism for this, for example, the account nonce, a maximum nonce, a nonce manager, or another mechanism. One problem with this is that it essentially requires picking and sticking with one of these proposals rather than allowing account developers to choose how this is done. Because of this, we believe that the proposal should remain un-opinionated and retain flexibility.

Storage

EIP-5806 prohibits the usage of the SSTORE opcode in the context of the EOA address. One reason for this is that if an EOA can eventually be upgraded, there might be already-set storage which could lead to unexpected behavior. Because of this, we believe that a similar restriction would make sense for EIP-7702. This would entail that smart accounts would need to be re-written so that their storage lives in an external contract. However, this would not be majorly complex and we have already prototyped an example for this.

Permanent upgrade

One further idea suggested by Vitalik is to add a flag to the transaction data to permanently upgrade an EOA to a smart account. Practically, a client could just check if this flag is set and not remove the code at the end of the transaction if it is set. One further idea is that even if this flag is not included in the Pectra hard fork, the fact that it would be minimal effort to include in a client could mean that rollup clients might experiment with this feature and add it before it is added on Ethereum.

Conclusion

EIP-7702 is more aligned with the account abstraction roadmap and is less likely to cause tech debt for Ethereum clients and protocols built on top. As a result, we see it is a strictly better version of EIP-3074, given that it achieves the same aims in a more elegant and future-proof way. There remain some open questions on the standard so it makes sense to keep exploring its implications but it seems likely that it would remain a better way forward for EOA UX that is also aligned with the smart account ecosystem. This entails that EIP-7702 is also more likely to lead us to a future where permissionless innovation is possible for both EOAs and smart accounts and not just the latter.

Exploring EIP-7702 was originally published in Rhinestone on Medium, where people are continuing the conversation by highlighting and responding to this story.

Smart accounts are gaining adoption with many new implementations being built in a modular fashion. These modular smart accounts (hereafter just smart accounts) move functionality to external contracts called modules to increase the speed of feature development, future-proof themselves, and allow for customization by developers and users. However, these smart accounts are built in vastly different ways, creating vendor lock-in and ecosystem fragmentation.

In collaboration with ZeroDev, Biconomy and OKX and with valuable feedback from many individuals deeply involved in the space, we propose ERC-7579, which outlines the minimally required interfaces and behavior for modular smart accounts and modules to ensure interoperability across different account implementations. The goal of ERC-7579 is to achieve smart account interoperability with minimal impact on the implementation logic of the account so that smart account vendors can innovate and compete, while also allowing for a flourishing, multi-account-compatible module ecosystem.

The need for standardization

There are several reasons why standardizing smart accounts is extremely beneficial to the ecosystem. The most important of these are:

• Interoperability for modules to be used across different smart accounts
• Interoperability for smart accounts to be used across different wallet applications and SDKs
• Preventing vendor lock-in for smart account users and application developers

The current landscape

Currently there are 6 different modular accounts being used in production, with more being built. However, these accounts follow quite different architectures and interfaces and have very different requirements for how modules are used. This means that currently, there is no practical way of building modules for all accounts that does not involve a significant technical lift, such as by extending accounts with additional “manager” components.

To solve this problem, ERC-6900 was released in April 2023 to standardize smart account and module interfaces. While the authors of ERC-7579 support the objective of ERC-6900 to standardize modular accounts, we believe it goes beyond the minimum requirements for modular smart account interoperability. Specifically, ERC-6900 wraps significant complexity into the account standard, adding opinionated security measures. However, this complexity and large scope with specific design choices inhibits account vendor flexibility and innovation.

ERC-7579, on the other hand, is minimally prescriptive to allow account and module interoperability without compromising innovation and experimentation for account and module developers. This approach allows developers to make their own trade-offs around complexity and security and for accounts to compete on various angles such as cost, security and complexity to build on top of.

Nonetheless, we think that many components of ERC-6900 should not go to waste, such as the permissions system through a manifest. These concepts will continue to push the ecosystem forward and we believe standardization around them can happen in the form of an extension to ERC-7579 (see below).

Our approach

While smart accounts have developed rapidly through the course of this year, we do not think that they have reached their final state yet and probably aren’t even close. The need to allow builders to keep innovating on smart account architectures is fundamentally at odds with the idea of standardizing accounts for the much-needed interoperability. Therefore, we believe that a standard should be as un-opinionated and minimal as possible, standardizing just enough to alleviate some of the problems we are faced with today but allowing the space to be pushed forward by smart account innovators.

As a result, our approach to this proposal has been twofold:

1. Take learnings from existing smart accounts that have been used in production and from building interoperability layers between them
2. Ensure that the interfaces are as minimal and open to alternative architectures as possible

Extensions

As hinted above, it is very likely that standardization will need to continue to happen for smart accounts and modules. This standardization might also happen for a subset of smart accounts or modules, such as, for example, further standardizing security safeguards around module usage. To encompass this, we suggest using a rough extension schema that allows for future ERCs to extend the behavior of ERC-7579. There are already some examples of this for other ERCs, such as ERC-2612. This schema is very loose and ultimately it is up to the community and individual builders to decide whether or how to adhere to future standards but our proposal is the following:

Future standards that are meant to be extensions to ERC-7579 should be launched and labeled as such. For example, an ERC might use the title “[FEATURE] Extension for ERC-7579”. Further, future standards should adhere to the incremental module type IDs introduced in this standard, by using the next unused module type ID. While it could make sense to define this extension system more rigorously in the future, we believe that it is anyways up to the community to accept or reject future standardizations, so defining rigid rules is likely not needed.

In an attempt to provide an example of such an extension and how it can be structured, we have modified the title and wording of the previously released ERC-7484 to now be an extension to ERC-7579.

Conclusion

After careful consideration and feedback from the community, we have decided to launch ERC-7579, a minimal standard for smart accounts that allows account builders to continue to innovate on many fronts, while also making it easier to build on top of and across these accounts. We are very excited for the further development that this unlocks for the modular smart account ecosystem and are looking forward to further input from the community. To join the discussion and contribute, check out the Ethereum Magicians Thread and join the Modular Contract Account Standards telegram group.

We would also like to, in no particular order, thank Filipp, Taek, Vectorized, Greg, Felix, Eric, Elim, Sachin, Ankur, Ross, Kristof, Jayden, Wilson and the rest of the OKX team for their support and feedback.

Introducing: ERC-7579 was originally published in Rhinestone on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re super excited to have the support of the EF for the development of the Module Registry. A public good that will serve as the foundational layer to the Rhinestone Protocol and the greater module ecosystem.

As we’ve said many times before, modular account abstraction transforms the wallet into an open and permissionless platform for innovation. In order to achieve this, we require a secure trust delegation layer where trusted entities can make attestations that assert statements about the security of smart account modules. Smart account vendors will tap into this registry to build their own opinionated “module marketplace” and wallets will plug in to offer an unlimited feature set to their users.

For more on the Module Registry check out our docs. If you’re interested in building your own module, reach out to kurt@rhinestone.wtf and check out the ModuleKit.

Ethereum Foundation 🫶 Rhinestone was originally published in Rhinestone on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re already in the know and want to join the movement, check out rhinestone or join our developer waitlist.

Ecosystem components

The following section will outline and discuss the different components of the modular AA ecosystem. These components are the account, modules, registry, UIs and developer tooling. These components may not be the only parts required to make this ecosystem function in the long term, but at least for now adequately encompass the different areas that teams are focusing their research and development efforts on.

Modular accounts

Modular accounts are smart accounts that are easily and securely extensible by a user, as opposed to “static” accounts that can only be modified by a developer and need to be redeployed. This allows the user to switch out, add or remove functionality in their smart account on the fly.

Implementation approaches

There are currently two different approaches to modular smart accounts, those created or inspired by the Safe architecture and those inspired by the Multi-Facet Proxy (aka Diamond) Standard (ERC-2535). These two approaches have evolved differently and can be contrasted along multiple axes.

The Safe account has evolved over time from the original multisig built by Gnosis and predates ERC-4337. The team places a strong emphasis on security and extensibility, whereas ERC-4337 support is at this point in time only possible through a module. However, there are talks about implementing native support in a future version. An example of a team building a modular account inspired by the Safe architecture is Biconomy. Their recently released (and fully audited) account changes the Safe account in several ways, namely by adding native ERC-4337 support and making all accounts 1/1 multi-sigs.

The other approach is inspired by ERC-2535 and has been discussed and pursued extensively by different teams over the last several months. This standard aims to make smart contracts extensible by standardising a way of storing a reference to modules (called facets) and executing these using the delegatecall opcode. While discussion around this opportunity has been ongoing for a while, the (to our knowledge) first working implementation was built by us at ETHDenver. Since then, several other teams have released implementations at various stages, such as the ZeroDev Kernel, which is a minimal and extensible smart account that has taken some inspiration from ERC-2535. Further, the Alchemy team has written up a draft stage EIP (ERC-6900), aiming to standardise modular smart accounts with inspiration taken from ERC-2535. Soul Wallet has also experimented with an ERC-2535 account in the past, although they have since shelved these attempts (we were unable to link to any code of these attempts).

As stated above, these two different approaches can be contrasted along different axes. One of these is the usage of delegatecall to execute modules as opposed to using an external call. Using delegatecall allows the execution of external code from within the context of the calling contract, which entails that the external code can modify the storage of the calling contract and make external calls that emanate from the calling account rather than the module. This does not allow for a separation of concerns, meaning that a module can overwrite any storage slot on the account, which gives rise to a major attack vector. While the Safe account currently does allow a module to be called using delegatecall, this might change in the future, either by being removed entirely or by creating different permission levels for modules. One upside of using delegatecall to execute modules is that modules can be singletons, drastically reducing the gas cost associated with adding a module.

Another difference between these approaches is the way that modules are stored and transactions are routed. ERC-2535 uses a mapping from function selector to module address, which entails that no two active modules can share the same function name (the selector being the hash of the name and arguments). The transaction flow using this router is to look up a function signature in this mapping and call the corresponding contract address with this signature and arguments using delegatecall. The Safe account, on the other hand, only stores a reference to the module address, thus making it possible for multiple modules to use the same function selector. Further, the transaction flow can either be triggered by the Safe account or the module, which can then call into the Safe account to execute a transaction from there.

The third major difference is the way that these implementations handle storage. Because of the way that ERC-2535 calls modules, storage cannot be handled like it would in a normal smart contract. Instead, developers usually choose to use structured or “diamond” storage, which stores data to storage slots that are the hash of a unique, module-specific identifier. This means that different modules don’t overwrite each other’s stored data and cause the contract to behave in unexpected ways. While Safe modules can be called using delegatecall, they are not required to be called in that way and can therefore handle their own storage. This means that storage is not required to be structured in the aforementioned way but can be used in the regular (sequential) way that Solidity storage positioning is usually implemented or any other desired way of handling storage.

These are some of the biggest differences between the approaches, but for another evaluation on the different approaches see this article written by the Safe team.

Modules

Modules, sometimes called plugins or facets, are smart contracts that aim to extend the functionality of smart accounts. For example, a module might allow the owner to use a different signature scheme to control their wallet or to trigger a certain action every time a token is transferred to another account. Related to the different implementations of modular accounts that exist so far and have been discussed above, there are different ways of building and executing modules. Hence, the modules that exist today are either built for the Safe architecture, like these or these, or for a diamond-inspired architecture, such as for ZeroDev’s Kernel or some demo modules built by us at ETHDenver.

As explained in more detail above, how a module is structured depends on the account implementation that it is meant to be used for. One main difference is that a module built for the Safe infrastructure needs to (unless called via delegatecall) call back into the Safe account to initialize a function call from within the context of the account. By contrast, a module built for a diamond-inspired account does not need to do this since it’s code is executed from within the smart account itself. On top of this, there also exists a standard that modules built on top of the Safe architecture can use, called the Zodiac standard. The standard aims to separate different components of a modular account, termed avatars, guards and modules and thus aims to create a generalised framework for building smart account modules. Some examples of modules that use this standard can be found here.

One example of a team that is building a module for smart accounts in public is Permissive. Their focus has, so far, been to build an authorization framework for smart accounts, mostly focusing on allowing more granular access control whereby a user can give different entities concrete permissions over specific actions that are executed by the account. They have released a module for the Safe account and are working on porting this over to different modular implementations.

Registry

Many of the modular implementations of both smart contracts generally and smart accounts more specifically have so far been built with a strong trust assumption between the user and module developer. This is how ERC-2535 is almost exclusively used today, allowing developer teams to manage large and complicated codebases. However, the greater vision for the smart account ecosystem is to remove this trust assumption, allowing for 3rd party developers to build modules that non-technical users can securely add into their wallet. While the trust assumption cannot be completely removed (someone, after all, needs to attest to the security of a module), we can bundle all the trust assumptions made between individual users and module developers into a single entity, the module registry. This means that a user now only needs to trust this single entity rather than needing to trust every single developer of a module that they want to use.

While this line of thought leads to the conclusion of a centralized registry, this is far from the vision that we (rhinestone) are pursuing. Instead, we are currently prototyping a registry that is akin to a hyperstructure, meaning that it is open, unstoppable and, most importantly, permissionless. This means that different parties with different security assumptions can sit on top of this registry and it is up to the user to choose which party to trust under which circumstances. Currently, we are prototyping different implementations with helpful input and collaboration from different teams, such as Safe and members of the 4337 team at EF. Once we have more concrete details on the upsides of different implementations and incentive designs, we will start sharing these more publicly and open-sourcing the underlying code.

User Interfaces

As previously noted by Yoav, one of the lesser-explored aspects of modular AA is a similarly modular frontend design. This is necessary because UI components need to be specifically built to trigger certain on-chain functionality by knowing function selectors, argument encodings and (potentially) what frontend or backend logic to execute. So far, we are not aware of any team making significant progress on this problem, although we are slowly starting to explore this for the reference implementation built on top of the registry discussed above. From our initial research, a secure design of a modular frontend allowing for external module developers is non-trivial.

Developer tooling

While there exists developer tooling for dapp or wallet developers to integrate modular AA into their applications, there is very little guidelines or tooling to help developers build modules. Safe has a guide here and ZeroDev has one here but apart from these we are unaware of anything more substantial that allows developers to easily understand how to build a module. As the space matures, we imagine that more guides and actual tools will emerge, lowering the barriers to entry for module developers substantially.

Conclusion

Modular AA is a subset of the broader AA movement which aims to modularize smart accounts in order to make them customizable for a user and allow developers to easily build self-contained smart account features rather than needing to build an entire account. The aim of the above article is to give an extensive overview of the current state of this space as well as highlighting where progress is being made. We have also tried to include as many relevant links to progress that we are aware of, but if we left anything out, please do contact us so that we can include them. Finally, there is a Telegram group in which many of the ongoing discussions in this space are happening. Feel free to join it if you are interested in staying up to date and/or contributing. If you have any questions feel free to contact me or check out what we’re building at rhinestone.

Acknowledgements

Thanks to Kurt, ZeroKnots, Lukas and Derek for helping me with valuable feedback.

Originally posted at https://mirror.xyz/konradkopp.eth/7Q3TrMFgx2VbZRKa7UEaisIMjimpMABiqGYo00T9egA

WTF is Modular Account Abstraction was originally published in Rhinestone on Medium, where people are continuing the conversation by highlighting and responding to this story.