Research-driven builders and investors in the cybernetic economy

We contributed to Lido DAO, P2P.org, =nil; Foundation, DRPC, Neutron and invested into 150+ projects

Deconstructing Account Abstraction

Artem Kotelskiy

Jan 11, 2024

Summary:

Problem: currently, most users access their accounts on Ethereum by their private key. This requires sophisticated key management and paying gas fees, which prevents consumer adoption.

Solution: account abstraction, aka decoupling user’s address and user’s private key. This is achieved by making smart contract wallets default accounts for Ethereum users. Such wallets enable arbitrary transaction verification and gas fee sponsorship, leading to superior UX.

On a technical level: the Ethereum ecosystem has converged on a particular standard ERC-4337, which achieves the desired properties of account abstraction, does not compromise on Ethereum values, and does not require any changes on the protocol level.

In practice: there are various technological aspects of smart contract wallets, and we explore some of them in three case studies — security models in Argent, modular contract architecture in Safe, and network abstraction in Avocado.

Acronyms used:

AA = Account Abstraction EOA = Externally Owned Wallet SCW = Smart Contract Wallet tx = transaction

Disclosures:

cyber•Fund is investor in Argent, Instadapp, Safe and Web3Auth.

1. Introduction

To understand AA we start by describing the issues with the current state of Ethereum wallets.

1.1 Externally Owned Accounts and their problems

The most common type of wallet on Ethereum today is an account controlled by a private key, aka Externally Owned Account (EOA). To be included in Ethereum, tx are signed and validated:

Notice how the private key and user’s address are linked, since they are produced from one key-generation function. This is by design, as the signature validation process is fixed on the protocol layer: validator checks whether the signature has originated from the private key associated to user’s address. This means that users need to (1) not lose their private key; and (2) not expose their private key. To satisfy both requires a serious effort, and this turns out to be a major UX issue preventing crypto adoption.

Concepts that alleviate this UX barrier are multi-key security (where tx needs to be signed by “k out of N” private keys) and social recovery (where a lost wallet can be recovered by “k out of N” previously specified wallets). Cleverly splitting up the private key is one way to implement multi-key security, and this is the direction taken by multi-party computation (MPC) wallets such as ZenGo. However, this approach does not provide good recovery experience, since there revoking access is not possible.

A better approach is offered by signature abstraction: the idea of completely decoupling user’s address (asset ownership) from user’s private key (signing capability).

1.2 Account Abstraction

More broadly, AA is the idea of making all of the validity conditions of a tx — signature verification, gas payment, nonce increase, chain compatibility — programmable, by moving them out of the core protocol level into the EVM smart contract level. AA consists of:

  • Signature abstraction — allowing accounts to use any verification logic. Enables other signature schemes, multi-sigs, social recovery, time-locks, withdrawal limits, etc.

  • Fee abstraction — allowing different models of payment for tx fees. Enables sponsorship of fees and taking fees in ERC20 tokens.

  • Nonce abstraction — allowing different replay protections apart from a single nonce. Enables sending multiple txs in parallel.

  • Network abstraction — allowing interaction with other chains via message bridges. Enables users to not worry about “does my friend use the same chain as me”. (This is the holy grail of crypto UX: not achievable right now, but is something many researchers and developers are thinking towards.)

We dive into AA below, from the perspective of how it evolved on the technical level.

2. The evolution of Account Abstraction

Here is the outline of this section:

2.1 SCWs enable signature abstraction ↓ 2.2 Relays enable fee abstraction ↓ 2.3 ERC-4337 decentralizes relays ↓ 2.4 Native account abstraction

2.1 SCWs enable signature abstraction

SCWs enable arbitrary tx validation logic. In the SCW paradigm, a user has two addresses on Ethereum: one is their EOA to sign and pay for Ethereum txs, and the other is user’s SCW where they store their assets:

User still sends Ethereum tx via their EOA, still with a signature that is checked by a validator. But now the tx is a function call for user’s SCW: the code of SCW then, prior to executing tx instructions, validates credentials of the user. This is where the arbitrary tx validation happens, enabling multi-key security and other desirable features. (User’s instructions and credentials are often created according to the EIP-712 — a common standard for data hashing and signing.)

We see that the asset ownership (in user’s SCW) is decoupled from the account authorization for moving those assets (user’s credentials). In other words, the signature in the initial EOA model is abstracted away into more general credentials.

2.2 Relays enable fee abstraction

Non-expert users cannot be expected to have an additional EOA with ETH to send calls to their SCWs, hence the need for the fee abstraction. It is achieved by introducing another party called relay:

User only needs to specify their credentials and tx instructions, while relay packages those into Ethereum tx and submits to the Ethereum network. The fees are either subsidized by the relay, or reimbursed to relay by user’s SCW or potentially a different “sponsor” account. As before, user’s credentials (signatures, certificates, etc) are validated with arbitrary custom logic by the SCW code. This preserves self-custody: only the user can initiate a tx.

2.3 ERC-4337 decentralizes relays

In the above design 2.2, user’s tx has to be wrapped into Ethereum tx that calls the SCW, implying that: (a) each relay’s tx has 21000 gas overhead; (b) there is no explicit standard and free market for how relay is compensated; (c) centralized relay services (which wallets tend to provide) pose censorship and single-point of failure risks.

Enter ERC-4337:

Recently, the Ethereum ecosystem has converged on a particular architecture for AA: ERC-4337 standard [spec, reference implementation]. Compared to design 2.2, relay service is decentralized into the network of bundlers.

ERC-4337 key components are:

  1. UserOperation (UserOp) consists of instructions, user’s credentials (signature in the specification) and fee parameters for inclusion into Ethereum block and future bundler refund.

  2. 4337-mempool is a new mempool for UserOps; there could be several such mempools, some private and some public; there will one canonical public mempool however.

  3. Bundler is a new type of node that takes multiple UserOps from the 4337-mempool, bundles these UserOps together into Ethereum tx, and sends it to the Entry point smart contract. The incentives to do so are similar to validators’ incentives in Ethereum: inclusion fees & MEV.

  4. Entry point smart contract is a single special smart contract that exists to abstract away some of the complexity involved, so that developers can build secure SCWs more easily.

Importantly, this architecture can be implemented without a single hardfork level change to Ethereum protocol, which are getting harder and harder to reach social/developer consensus on. This also helps developer adoption, as anyone can spin up the infrastructure for ERC-4337 on any EVM-compatible chain.

The table below provides an overview of benefits that come with ERC-4337, compared to EOAs and SCWs with centralized relays.

Apart from decentralizing relay and making AA developer friendly, one of the key aspects of ERC-4337 is the successful convergence of the community on a common standard. ERC-4337 was specifically designed to be a neutral open standard, making it into a Schelling point for developers — this is why it was able to capture much of the bear market narrative and attention.

We study ERC-4337 in more detail below, but before that we finish covering the evolution with the idea of native AA.

2.4 Native Account Abstraction

Initially, it was thought that AA would be implemented on the protocol layer of Ethereum; see EIP-86, EIP-2938 and EIP-3074 and Vitalik’s overview of those. However, the complexity of the change together with reluctance to commit to a particular design pushed the community towards a more lightweight solution, namely the 4337 standard, that can be implemented without any protocol changes. The resulting current direction for the ecosystem is to use 4337 SCWs more and more, and use EOAs less and less.

In the future, however, ERC-4337 will likely still be enshrined in Ethereum, since it offers gas efficiency, flexible bug recovery through hardforks, and censorship resistance improvements — this was clearly argued in the recent article by Vitalik. Another reason is that block builders will end up running the vast majority of bundlers anyway, introducing side-code risks in the Ethereum protocol just like MEV-boost does right now, pre ePBS. The high level steps involved in the 4337 enshrinement will be introducing upgradability from EAOs into SCWs (see EIP-7377), and enshrining UserOps as the native tx type on Ethereum.

In the meantime, rollups offer a perfect ground for implementing native AA. Recall that in the design 2.1 user calls a smart contract function, but needs to package this call into a tx from an EOA. The main idea for native AA is to allow users to call SCWs directly:

A Rollup Improvement Proposal (RIP-7560) for native AA on rollups was published recently, and the general design there is very much influenced by the 4337 architecture. Moreover, two zk-rollups — zkSync Era and StarkNet — have implemented native AA long ago. In StarkNet, every single account is a SCW, and the way txs are signed is specified by each SCW; fee abstraction is to be implemented. In zkSync Era, the design is very similar except they also support EOAs (to include the current users of EOA wallets), and both EOA and SCW accounts support fee sponsorship.

3. Deeper dive into ERC-4337

3.1 Validation and execution of UserOperations

Below we describe the step-by-step process happening on-chain after the Entry point smart contract receives a bundle of UserOps. The main idea is to first validate all UserOps from the bundle and take the fees from users’ SCWs, and only after that execute UserOps’ instructions. Apostrophes indicate optional steps that are interactions with paymaster contract that sponsors the fees, and aggregator contract that simplifies the validation process for multiple txs. The latter signature aggregation is important for L2’s, since it allows rollups to post much less signatures to L1. Note that nonce abstraction is also implemented in the ERC-4337, by allowing multiple sequences of nonces.

The use of CREATE2 opcode in Create2Factory implies that the address of not-yet-deployed user’s SCW can be predicted and generated locally by wallet software. This allows user to accept payments before creating their SCW.

Thanks to the Entry point smart contract design, developers of SCWs need to do fairly minimal work to support AA through 4337. Namely, each SCW needs to have two functions:

  • Validation function, which takes in UserOp: it is supposed to verify credentials and nonce on the UserOp, pay the fee, increment the nonce if verification succeeds, and throw an exception if verification fails.

  • Execution function, which takes in UserOp’s instructions: usually it either sends ETH or makes one or several calls to other smart contracts (for sending ERC20 tokens or something else).

3.2 Censorship resistance requires DoS protection

In the 4337 design, censorship resistance is achieved by introducing a separate permissionless mempool for UserOps. But it comes with a cost: any party could spam the mempool with fake UserOps and potentially clog the system. Thus bundlers need an effective method to pre-validate UserOps before sending them on-chain. Bundlers also need to make sure that each UserOp will refund the fees associated with its inclusion.

For the above reasons bundlers simulate the validation of each UserOp before sending the bundle on-chain. Furthermore, in order to ensure that simulation and the actual on-chain behavior in the future coincide, certain opcodes and access to other smart contracts’ storage are prohibited during the UserOp validation stage.

Further complication is in the fact that paymasters may use oracles, and the oracle prices may change between simulation and execution, thus representing a DoS attack vector on bundlers. In addition to paymasters, other global entities like aggregators and factories can also potentially access storage that changes. To mitigate this, reputation system is in place which allows to punish global entities. Furthermore, these entities need to provide a certain stake within the entry point: it is never slashed and can be withdrawn with a delay, but provides a good enough protection against sybil-attacks – deployment of too many malicious global entities. (Alternatively, global entities may limit their use of storage.)

There could be usecases where it is useful to relax some of the above rules for paymasters and aggregators. In this case, bundlers may whitelist trusted paymasters and signature aggregators, and UserOps that use these whitelisted entities are sent to a separate alternate mempool.

3.3 Extrapolations on rollup tx supply chain

Let’s envision that most users will express their intents via UserOp parameters inside the 4337 standard. Inspired by Matt Cutler’s thread that explores the mainnet UserOp/tx supply chain, we present a possible scenario for how UserOp/tx supply chain will shape up on a rollup.

From the tx supply chain viewpoint, the main difference between L1 Ethereum and L2 rollups is that rollup mempools are private. And, to maintain the current good UX, mempools will likely stay private in the future. This is possible even with an MEV capturing mechanism introduced, as was shown in Ed Felten’s recent proposal that involves a sealed bid auction (and decentralizing the sequencer via threshold encryption).

Another stark difference is that there are no block-builders in rollups — sequencer has the monopoly over block production. It may also seem that there are no searchers as well — how would they submit a bundle of txs? In reality, however, searchers will be able (1) submit bundles of UserOps; (2) possibly submit bundles of rollup txs as well, depending on the future auction design (see slide 19).

The resulting 4337-enhanced supply chain on rollups looks as follows; we remark that many of the rollup searchers will run their own bundlers.

If a rollup introduces public mempool, they will likely introduce some form of PBS as well, and then the supply chain will look very similar to the one on mainnet. With the exception that rollups will probably not need the doubly-trusted relays, because there will likely be either one or a few sequencers permissioned by the rollup DAO, and so the resulting accountability makes the risk of sequencer rearranging txs very low.

We conclude with a simplified version of the rollup supply chain, in case the native rollup AA is implemented:

3.4 ERC-4337 adoption

The ecosystem-wide rollout of AA powered by ERC-4337 is underway in full swing. For a glimpse into the current state, we recommend two data reports [1, 2] by Sixdegree and 0xKofi, as well as a comprehensive wallet infrastructure guide by Nichanan Kesonpat from 1kx; below we provide a brief snapshot.

On the 4337 infrastructure side, all the AA components are mostly ready to go: Entry point smart contract is audited and deployed, private mempools / bundlers / paymasters are offered by Pimlico, Stackup, Alchemy and other companies, and L2s are making supporting 4337 standard easier. Pimlico’s vendor-agnostic library permissionless.js makes it easy for developers to deploy 4337 SCWs and interact with bundlers and paymasters. Importantly, the canonical public UserOp mempool is not yet in production and is expected to go live soon.

On the SCWs side, existing personal wallet providers are in the process of implementing AA and supporting ERC-4337, while new wallets launch with immediate 4337 support: Candide, Patch, Clave, Daimo, Soul, etc. Most 4337 SCWs, however, are created by dapps using “embedded” or “sdk” 4337 wallets: Zerodev, Biconomy, Fun, etc. (Under the hood of those embedded wallets is the “signer” or “key-management” infrastructure layer, which already existed before for EOA wallets – see this article by Rui Shang from SevenX ventures for an in-depth overview of present and future solutions.)

In the SCW modules space (which we cover in Section 5.2), Rhinestone is offering a “Module-Store-as-a-Service” product, where they provide wallets with an “App store”-type of functionality for module management.

On the dapp side, lack of support of multicalls and EIP-1271 (or its backwards compatible successor ERC-6492 proposed by Ambire wallet) has been a problem for SCW adoption, and the ecosystem is in the process of resolving this hurdle.

Having covered lots of low-level blockchain infrastructure, we now showcase how SCWs work in three case studies on our portfolio companies.

4. Case study: Argent

Argent is the first consumer-oriented open-source mobile SCW that implemented social recovery on Ethereum L1, back in 2018.

4.1 Argent before 2021

Towards 2021, Argent converged on the following security model:

User’s SCW is protected by guardians – other Ethereum addresses:

  • Any guardian can lock SCW for 5 days;

  • Majority of guardians can recover SCW (change its owner);

  • Majority of guardians+owner can authorize txs to untrusted addresses and contracts — either one-time interaction or for a fixed-time trusted session.

User can add/remove guardians and trusted addresses, but with a 36h delay that protects from a theft scenario: guardians are able to lock SCW within that 36h delay. Additionally, there is an off-chain recovery scheme, as well as a set of trusted smart contracts and wallet-connects that is managed by Argent multi-sig.

We remark that ZK-Email technology allows emails to be guardians as well, as is explored by Clave recently.

4.2 Argent after 2021

Despite the well-thought out design, in the 2021 bull market Argent faced the following three critical problems: A. L1 gas fees were too high; B. Most dapps were incompatible with SCW (no EIP 1271 support, no multicall support); C. SCWs in general did not have significant advantage over EOA wallets.

Problem A is a major one, and to solve it Argent made the obvious decision to move to L2s.

Problem B may seem insignificant, but one has to consider incentives: a long-tail dapp cannot and does not have to support SCWs, since most users use EOAs, through Metamask and other wallets. Whereas Argent users do want to be able to interact with long-tail dapps. The end result for Argent was to focus on those rollups which help promote SCW as first class citizens: zkSync and StarkNet. Both of these rollups implemented native AA, and both of these ecosystems push their dapps to support SCWs from day one.

Problem C is partly caused by Problems A & B, but also largely has to do with the evolution of wallets: EOAs were the first, were able to capture the reputation & security network effects, and thus currently dominate the EVM-chains market. This informed Argent’s strategic decision to focus on StarkNet, the only prominent rollup that is non-EVM and has no EOAs: all StarkNet’s accounts are SCWs by default. As a result, currently Argent controls 80% of the wallet market on StarkNet, and thus will grow synchronously with StarkNet’s adoption.

Argent’s SCW design has also evolved since 2021. They developed various StarkNet wallets: Argent X chrome extension (where recovery is controlled by a seed phrase + email 2FA), Web Wallet (where users enjoy the familiar Web2 email+password experience), a mobile StarkNet wallet, and a multi-sig. At the core of all these products is Argent’s StarkNet SCW written in Cairo, with the following security model:

The SCW is protected by one guardian — Argent’s backend — access to which is secured through 2FA. We consider various scenarios:

  • Normal operations: all the regular operations need signatures of both user and Argent: this allows Argent to detect and prevent fraud.

  • Argent censors txs: user has the ability to change the guardian (for example to their other wallet, effectively removing Argent from the equation), albeit with a 7 day delay. The spec also describes a model where user has private key 3 as a third co-signer, and signature requirement is changed from 2/2 to 2/3 — in this case user will not have to wait 7 days to push out Argent’s co-signer.

  • Private key 1 is stolen: the thief cannot do anything immediately because of 2FA. They have to wait for 7 days to do the recovery, and so the user has ample time to use [2FA + private key 1] to change private key 1.

  • Private key 1 is lost: using 2FA user initiates the 7 day recovery; delay is in place to prevent malicious recovery requests — user can override this recovery with private key 1.

  • Private key 1 is lost AND stolen: this is the only case which is not covered — the thief will initiate the 7 day recovery and the user will not be able to do anything. However, user will always be pushed to securely backup their private key 1 (e.g. via automatic cloud backup on the phone). This does not introduce any new attack vectors because private key 1 alone does not enable anything (need either 2FA or 7 day delay), so user can freely backup their private key 1 without additional worries.

Even though the above security model involves a centralized party, it does not introduce any new trust assumptions. The idea of a time-locked recovery backup key can be implemented in a different way too, see Clave’s model for example. Compared to the classical social recovery, this approach seems more practical.

We do not cover Argent’s smart contract architecture: they follow a nowadays standard modular approach, which we cover in the next case study.

5. Case study: Safe

Formerly known as Gnosis multisig, Safe{Wallet} is by far the most battle tested and used solution for an EOA multi-signature SCW, securing over $75 billions in total. Safe{Wallet} is targeted towards DAOs and other organizations needing multi-party capital/access management, as well as crypto savvy users that are comfortable with using their EOAs but would like to distribute access to their cold storage.

5.1 Safe{Wallet} architecture

Below in blue we highlight the main functions of the contracts; the less important functions are omitted.

Deploying Safe account: user calls SafeProxyFactory contract to deploy its Safe account, which is a SafeProxy SCW that delegates functionality to the Safe Singleton implementation contract. This means that, when user interacts with their Safe account, delegateCall opcode executes code from the Singleton, but uses and changes the storage of the calling SafeProxy contract.

After deployment, the user calls the setup function to configure their Safe account by setting the number of required signatures and the list of owners, which are saved in the SafeProxy SCW.

Executing tx: user generates a Safe tx hash using the EIP-712 data hashing scheme. The required amount of parties sign it either with a private key, on-chain approval or a SCW. Then the user submits the tx to the Safe account on-chain. The gas fees are eventually refunded from Safe account to a chosen entity (tx initiator by default).

Optional functionality: plugins are separate smart contracts that are whitelisted by the Safe account to implement additional functionality. Also, to add extra blocking conditions for tx execution, one may use hook (aka guard) contracts performing specific checks before and after Safe txs — more on this below.

5.2 Modular approach

An important realization of the Ethereum ecosystem was that SCWs allow for a modular architecture — additional functionality can be added and removed in the form of modules. This unlocks easy customization, risk isolation, and adaptability (as the space evolves, there is no need to overhaul the entire SCW design).

Two main design standards have been put forward: ERC-6900 standard in the context of ERC-4337, and also Safe’s standard. Modules in ERC-6900 are called plugins, and they can contain validation/execution/hook functions; Safe’s modules have two types: plugins (for execution) and hooks (for pre/post-execution checks that can change storage and revert calls). Diagram below clarifies how the two designs compare:

The call flows in ERC-6900 and Safe are in many ways similar. The main idea is to not use delegateCall (as in ERC-2535), since this will undermine SCW’s security from the storage perspective [1, 2] — instead plugins should have their own storage, and call SCWs with specified “executeFromPlugin” type of function. In case of Safe, the call flow looks approximately as follows, from left to right:

One difference in the ERC-6900 case is that the tx is initiated from User’s 4337 SCW, and then the plugin is executed via callback; see the two diagrams in the spec.

Let us mention that this design does not require that each SCW will have to deploy their own plugins. For instance, in case of ERC-6900 where plugins are executed via callbacks, the same plugin can be installed for different SCWs, as long as: - there is no way to cause the plugin to self-destruct; - the plugin only accesses storage associated with msg.sender; - the plugin only calls back to msg.sender – never to a user-provided address.

We end with highlighting a recent development in the modular SCW space – Rhinestone's new ERC-7579 proposal. It is a minimal standard for modular SCWs, which, in the interest of vendor flexibility and innovation, strips away the extra complexity and opinionated security measures of ERC-6900.

5.3 Safe{Core} Protocol: interoperobility standard for modular SCWs

While the technical standards behind modular SCWs appear to be in the final stages, the actual transition to SCWs with plugins will require a strong coordination effort. To this end Safe has recently published a whitepaper that outlines a high-level transition plan, in a secure fashion with no fragmentation.

Problem: while it is clear that the right architecture for SCWs is modular, if each different vendor develops their own modules, then the ecosystem as a whole loses:

  • Composability: there is no standard for interactions with SCWs;

  • Vibrant competition: vendors that develop better modules will accrue network effects;

  • Security: each new module implementation will need its own security audit, and will have less usage and testing.

Solution: to set a standard under which various vendors will co-develop and use the same modules. For managing the relationships between SCWs (vendor agnostic) and modules, a special Manager contract will be in place, as is illustrated in the diagram below from the whitepaper.

Manager contract maintains internal database in the form of Registries: this is where the critical curation services and additional security are provided. According to the recent talk by Richard Meissner, one can view the proposal as bridging ERC-4337 SCWs on the left and ERC-6900 plugins on the right. Let us also remark that the Rhinestone team was one of the first to develop the idea of registries.

The resulting Safe tx execution, involving both plugins and hooks, is best described by another whitepaper diagram:

5.4 Safe{Core} AA SDK: for building on top of Safe{Wallet}

Even though Safe{Wallet} in its raw form only implements signature abstraction, its modular architecture & bulletproof security make it a perfect candidate for evolving into a feature-rich consumer friendly SCW. Realizing this, Safe has been developing an extensive AA/SCW infrastructure, under the name Safe{Core} AA SDK. It enables developers to efficiently leverage Safe{Wallet} to build consumer friendly wallets, such as Candide Wallet and others. The SDK offers several solutions for developers:

  • A decentralized but permissioned Gelato relay service. Another relay service will be offered via 4337 UserOp mempool, through the 4337-support plugin. There is also an integration with Pimlico’s permissionless.js library that allows to conveniently create Safe accounts with 4337 support. With the current momentum behind 4337, this will likely be the most common way to implement AA on top of Safe{Wallet}.

  • A social login solution SafeAuth: an integration of Web3Auth into Safe that enables MPC-based address generation based on socials. Importantly, the address generation is deterministic, allowing users to port their accounts between various dapps and Safe{Wallet} interface using social logins, solving the vendor lock-in issue.

  • An onramp solution enabled by Stripe and Monerium.

We conclude with a remark that Safe is a true Web3 project: all their products are open-source, and they do have a token (which is currently non-transferrable).

6. Case study: Avocado

Released by the Instadapp team, Avocado’s core product is a SCW controlled by an EOA, enhanced by cross-chain gas abstraction and powerful custom features. They have also released their multisig product, whose functionality is similar to Safe{Wallet}. In terms of interfaces, there is Avocado web wallet targeting crypto power users, and there is an upcoming mobile app that will be more consumer friendly.

6.1 Overview

Off-chain interactions: after connecting their EOA, users generate and sign their tx (using EIP-712, similar to Safe) in the Avocado app, and then send it to a special Avocado RPC — this effectively creates a multi-chain environment for users of Metamask and other EOA wallets. Next, the tx is picked up by the broadcasters — Avocado’s own whitelisted relay service. The destination chain id is specified in the domain salt of tx, which allows Avocado’s broadcasters to wrap the EIP-712 tx into a chain tx, and send it to the right EVM chain.

On-chain interactions: the chain tx first lands into the Forwarder contract, which is similar to the Entry point contract in the 4337 design — it is to manage whitelisted broadcasters, and in general to track all activities of Avocado SCWs.

Forwarder contract sends the tx to the SCW, whose architecture is similar to the one of Safe: Avocado SCW is a proxy contract that delegates functionality to the singleton implementation. A factory contract to create SCWs is also in place.

Remark: to preserve censorship resistance and self-custody, users can also submit txs directly to their Avocado SCW, sidestepping broadcasters and paying the gas fees themselves.

Features: optimizing for power users, Avocado has developed several useful features, including: - non-custodial 2FA options; - building a multicall tx in their tx builder; - saving any kind of txs as a shortcut; - automatic approval revokes after a swap.

Business model: Avocado has chosen to monetize from the start, charging 20% of gas fees from the user. In the case of a dapp interaction, half of the 20% goes to the dapp, under the condition that the dapp is integrated natively into the Avocado app interface.

6.2 Gas and Network abstractions

The main differentiators of Avocado are cross-chain gas abstraction and the overall focus on network abstraction.

Gas abstraction: Avocado’s back-end server upkeeps the gas balances in USDC. As illustrated above, gas topups happen when user sends USDC to a particular EOA, while gas spendings happen when broadcasters submit txs to chains. Gas withdrawals are not yet enabled, due to security considerations. Important properties of this design are: - users do need to trust Avocado with their gas balances; - this does not undermine the self-custody of assets in the SCW; - users can top up their gas on any chain.

Network abstraction: since Ethereum has chosen to scale horizontally by sharding its execution between various rollups, cross-chain interactions become increasingly more important. The goal of network abstraction is simple: for the user to not worry about what chain they are on, and seamlessly interact cross-chain. Currently, Avocado implemented the basic cross-chain token sends via batching two txs: bridge and send. This is the first instance of network abstraction being implemented in practice.

More generally, the decision to prioritize network abstraction informed many of Avocado’s otherwise unconventional past choices: - creating their own separate RPC; - not using the ERC-4337 standard for AA; - abstracting gas and relaying txs in a centralized fashion.

In the future, Avocado team plans to progressively improve cross-chain UX, and set up a proper decentralized paymaster & relay. Importantly, the latter may involve a separate Avocado rollup or blockchain.

What’s next for Account Abstraction?

On the adoption front, consumer friendly SCWs on L2s are getting ready to meet the demand of the next wave of users.

On the research and development front, the next step is clearly the aforementioned network abstraction. Even though ERC-4337 does not directly address it, the ecosystem is starting to seriously discuss potential designs in this direction. We remark that intents will likely play an important role in effectively implementing network abstraction — this is explained well in the Uma Roy’s talk on AA, intents and bridging, and is also evident from the UniswapX design.

Acknowledgements: We are grateful to Clement Bihorel, Matt Cutler, Dan Coombs, Sol Irvine, Michael Jordan, Thrilok Kumar, Itamar Lesuisse, John Rising, Rui Shang, Yoav Weiss and Steven Zapata for helpful feedback and discussions.

Resources: