Part 1: Modular Account Abstraction for Everyone Else

What is modular account abstraction and why should I care?

Account abstraction is a difficult concept to understand if you’re a non-technical builder in web3. Throw in the word “modular” and it feels like the concept has evolved before you even had a chance to learn the basics.

Given the purpose of account abstraction is to 10x web3 UX and make web3 useable, it’s important that product managers, marketers and other folks building at the app layer understand what account abstraction unlocks — especially modular account abstraction.

At its core, modular account abstraction allows developers to build self-contained components that extend the functionality of the user’s account. We believe this will establish smart accounts as a new platform for product innovation, disrupting the wallet space in the same way iPhone disrupted the mobile phone industry.

This blog post covers modular account abstraction for non-technicals and highlights the potential product implications it will have at the app layer.

What are the basics?

On Ethereum there are two types of accounts; externally owned accounts (EOAs) and contract accounts. EOAs are “active” in that they can initiate transactions and pay gas for execution. Contract accounts are “passive” — they can be triggered by an EOA, which pays the gas for execution. However, the upside of contract accounts is that they are programmable and can execute arbitrary logic stored in the code of the account (i.e. smart contracts).

With an EOA the account and the signer are tightly paired together. If you lose your key you lose your crypto because every transaction from the account must be signed by that private key. EOAs are the primary account used for wallets today — including Metamask, Rainbow and Coinbase Wallet.

Account abstraction refers to the transition of contract accounts from being passive to becoming active, allowing a smart contract to become the user account and initiate transactions without reliance on an EOA for triggering the transaction or paying the gas for execution. Given smart contracts are code, this opens up programmable execution (do X then Y) and programmable validity (authorise X to do Y) within the user’s account. It’s the combination of programmable execution and validity that makes account abstraction so powerful. Examples of wallets that utilise this include Safe, Argent, Fluvi, Pier Wallet and Soul Wallet. Common features include:

• Multi-sig: The ability to only approve transactions when m of n signers approve, creating added layers of security.
• Account recovery: The ability to switch out the owner of the account if the signing mechanism becomes compromised.
• Transaction batching / multi-call: Approve and execute a set of transactions under the same transaction to reduce gas fees. This can also be used to string together an arbitrary set of transactions into single-click solutions.
• Gas abstraction: Subsidise gas fees according to pre-determined rules or allow users to pay gas in any ERC20 token, removing the need for users to have the native token to operate (run Arbitrum operations using USDC).

Herein, we’ll refer to contract accounts, and the embodiment of account abstraction, as “smart accounts”.

Sounds awesome! What’s the catch?

There are still some significant shortcomings to account abstraction today. The shortcomings largely stem from a lack of user and developer customisation, leading to vendor lock-in and user fragmentation.

Lack of customisation

Smart accounts today are static, monolithic contracts with opinionated feature sets. In order to offer a new account feature the developer must either a) fork an existing implementation and add the additional feature or b) start from a base implementation and rebuild several standard components (such as recovery) along with the new feature set. Under both these circumstances the developer must have the whole account audited and redeployed. This creates a poor developer experience and limits the potential for smart accounts to become a true platform for innovation at the app layer, and creates immediate externalities in the form of vendor lock-in and user fragmentation.

Vendor lock-in

EOAs allow users to easily migrate their account to any other EOA-based wallet (via seed phrase recovery). This gives the user the ability to choose their wallet vendor, and therefore, their wallet features — even though these features are largely cosmetic and frontend related (e.g. different portfolio overview and tracking features).

Unlike EOAs, smart accounts are not easily transferable between wallet vendors and there are no interoperability standards to ensure feature transferability. The result is that users must adopt multiple accounts if different wallet vendors have the features they desire — a subpar experience that leads to user fragmentation.

User fragmentation

To give this problem a concrete example. Assume a user, Sally, already has a smart account built by Vendor A but is looking to play a web3 game supported by Vendor B. Let’s also assume that the developer of the game utilises a specific implementation of batching or multi-call to power an improved UX. Sally either settles for a subpar gaming UX or creates a new account with Vendor B. This fragments her assets, which is bad for her (increased wallet management overhead) and the game developer (reduced access to onchain data about their users), not to mention the incremental gas required to deploy the extra account.

Developer experience and security

Forking and rebuilding accounts to add new features creates duplicate work and makes the integration between dapps and wallets more complex. It also increases security debt. Although code is being reused, the alternations for new features can not be siloed and independently assessed, increasing the potential for account vulnerabilities.

Enter modular account abstraction.

What is modular account abstraction?

My co-founder, Konrad, has an amazing post on the technicals and I implore you to read it. For the purpose of this blog post, you should think of modular account abstraction as breaking the smart account into composable Lego pieces. Each module is a smart contract that can extend the onchain functionality of the core account.

This solves the core problem of account customisation, allowing developers to focus on building the new account feature rather than a whole new account. ERC-6900 was launched back in April and aims to standardise modules and how they are integrated into smart accounts. The EIP specifies three types of module behaviour;

• Validation: The ability to customise what / who is authorised to perform what actions on the account. For example, I can add a Passkey that is stored in the Secure Enclave of my device and allow this key to become the default way I create transactions.
• Execution: The ability to set a pre-determined chain of transactions that can be automatically executed based on a pre-determined trigger. For example, swap token A for token B and stake on X protocol if this button is pressed.
• Hooks: Code that runs pre- or post-execution of a transaction to enforce a specified rule. For example, run a check against a blacklist of smart contracts before every transaction and revert if blacklisted.

How does this help solve existing smart account problems?

With developers building smart account features (via modules), rather than entirely new account implementations, the standardisation of core accounts can be streamlined — allowing for greater interoperability between wallet vendors. With a standardised approach to modules, we can also ensure that any new smart account feature can be easily adopted by any account.

In the example above, the game developer only needs to offer Sally the specific module for installation on her existing account to enable the full gaming experience. The beauty of this is that she doesn’t even need to know that this is required. It can all be bundled into a simple onboarding UX.

Duplicate work is reduced and security can be tighter because new smart account features are contained within smart contract modules, avoiding augmentation of pre-existing core account implementation. This increases the reusability of existing smart contracts, rather than re-writing the same code.

App layer innovation

Modular account abstraction presents a new platform for open and permissionless innovation within the account. Enabling advanced features for the wallet itself and driving an improved UX for dapps. What’s unique is that any application builder will have access to programmable execution and validity within the user’s smart account. By building a module, developers can create novel onchain functionality that can be paired with offchain features to deliver powerful web3 products with web2 equivalent UX.

Advanced wallet features

Virtual cold storage

Most users today are paranoid that they’ll sign a malicious transaction that drains their wallet. Due to this, dapps like delegate.cash and warm.xyz have emerged to give users heightened security when claiming NFT utility. An alternative to this could be a smart account module (in the form of a hook) that prevents the transfer of elected assets in the user’s wallet — i.e. virtual cold storage. The user chooses the digital assets to freeze (maybe a certain monkey pic) and with every transaction, this hook will run and throw an error if the transaction will cause the asset to leave the wallet.

Automated trading strategies

Setting up an automated DeFi trade today requires the user to engage with a dapp, express their trading strategy (buy X when Y occurs) and then custody some form of collateral to make those trades with an external smart contract. Instead, a module could be built to perform DeFi trading strategies directly in the account without the user having to custody assets to an external contract. This could be a simple dollar cost averaging module or a more complex strategy with triggered buy and sell actions.

Improved dapp UX

Session keys

A session key is a key that can only be used to approve a pre-defined set, or type, of transactions. Because the key is scoped, it can then safely be given to external parties in order for them to execute actions bound by user-defined parameters. These parameters are, in theory, limitless (and in fact need to be standardised for user security) but the simplest include time, transaction origin, transaction value and gas limit. A great example where session keys enhance an external dapp is web3 gaming where continuous interactions with the blockchain are required, but signing every time is tedious and distracting from the core experience.

Conclusion

Modular account abstraction is a growing niche within the wider smart account movement that has the power to truly next-level the web3 application layer. Today, smart accounts provide enhanced security and other quality-of-life improvements for users (social recovery, email login, etc). Tomorrow, modular account abstraction will turn smart accounts into a platform where any developer can build unique product experiences for users, either experienced right inside the wallet application or within an external dapp.

This is part 1 in explaining the app layer implications of modular smart accounts. Part 2 will explore more opinionated versions of how product builders can disrupt the wallet and dapp ecosystem with this tech stack.

If you’re a web3 product builder check out our module wishlist and get in touch to start building.

Acknowledgements

Thanks, Lukas, Ahmed and Marc for your feedback and input! Thanks, Konrad and Zeroknots, as always.