Recently, the crypto community has been waking up to the harsh reality that expecting most people to control their accounts with a single (unchangeable) seed phrase isn’t going to fly – and it’s a huge drag on the adoption of web3 and DeFi.

A proposal called ERC-4337 is intended to be Ethereum’s solution. It describes a system called “account abstraction” that enables the possibility of decentralized multi-factor account control and recovery – no magical single seed phrase required. Followers of Radix have noticed that this sounds, on the surface, a lot like Radix’s “Smart Accounts” that were introduced and discussed at RadFi.

So does ERC-4337 obsolete Radix’s Smart Accounts? Not at all – and the reasons why highlight the important advantages of the deeply different architecture of the Radix Network.

Implementation Matters

First, Smart Accounts will go live on the Radix Network with the Babylon upgrade, expected within months – and use of the full capabilities of Smart Accounts in the new Radix Wallet will be close behind. It remains to be seen how long implementation and adoption of account abstraction will take on Ethereum, as a practical implementation of the proposal needs to be completed and rolled out. Once that’s done, wallets and other integrations will take additional time to get the feature in the hands of users.

But much more importantly, Ethereum’s account abstraction and Radix’s Smart Accounts implement the no-single-seed-phrase “feature” in vastly different ways, and that difference has a number of big implications for both users and developers.

In short, ERC-4337 layers a new and highly complex system onto Ethereum to achieve account abstraction. This complexity was unavoidable in order to circumvent some fundamental aspects of the design of the Ethereum network that would be too disruptive to modify. But the resulting add-on system approach brings numerous new risks of fragility, inefficiency, and incompatibility.

On Radix, the implementation of Smart Accounts fits directly into the general model for asset management, transactions, and authorization that are used universally on the network. It's not a whole new system layered on top - it's just the natural way that accounts behave on Radix. In fact, all accounts on Radix are Smart Accounts.

Let’s look at the differences and results in more detail.

What is Account Abstraction?

The best place to start is the summary from the ERC-4337 specification:

"Instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a UserOperation. Users send UserOperation objects into a separate mempool. A special class of actor called bundlers (either block builders, or users that can send transactions to block builders through a bundle marketplace) package up a set of these objects into a transaction making a handleOps call to a special contract, and that transaction then gets included in a block."

That first bit in bold is important. The defining requirement of ERC-4337 is that the system must work without disrupting how accounts and transactions already work. This requirement is understandable. Rearchitecting these low-level primitives would be a dramatic undertaking, especially for a live network, impacting deep assumptions made in consensus, virtual machine, and more. Maybe worse, doing so would immediately break Ethereum’s ecosystem of live applications, assets, and client software.

Working from that requirement, there’s a lot going on in the system described even at a summary level. This isn’t just tech jargon for developers; the concept being described there is indeed quite complex.

If the solution isn’t allowed to change how current accounts and transactions work, then the only available approach is to add a whole new system on top, and that’s what ERC-4337 proposes: creating a sort of parallel account and transaction processing system without the benefit of the lower-level platform features originally intended for them.

To get a feel for the scope of complexity of this new system, let’s take a practical example and break down what it means to “submit a transaction from your account” using account abstraction. Here’s how it would work, in simplified form, with the ERC-4337 model:

1. The wallet receives a proposed transaction, but doesn’t actually sign it directly. Instead it constructs and signs a pseudo-transaction called a "UserOperation". This contains the same stuff that a normal transaction would, plus extra data needed to make the account abstraction system work. That signed pseudo-transaction is submitted to a new special mempool just for account abstraction (i.e. it isn’t immediately included in a block like a regular transaction).
2. New “bundler” nodes watching the special mempool are expected to bundle up a bunch of these pseudo-transactions into a single real transaction that in turn calls a special "EntryPoint" smart contract. That bundled real transaction is submitted to the regular mempool and included in a block. A new add-on staking and reputation scoring system, specifically for the account abstraction system (read the spec for full details), is required for the bundler system to try to throttle spam attacks with many colliding pseudo-transactions.
3. The EntryPoint smart contract then breaks up the bundle of pseudo-transactions and makes individual calls to individual user smart contracts that act as our new “abstracted” accounts, telling those smart contracts what each user wanted to do with its respective account. If a given account smart contract doesn't exist yet, the EntryPoint is also responsible for calling a special factory smart contract to generate one.
4. Those respective abstracted account contracts then verify signatures on their pseudo-transactions, according to the user's configuration (here’s where we get our no-single-seed-phrase feature), and make the desired calls to other smart contracts on the user’s behalf. The account smart contracts are responsible for implementing a bunch of additional logic for checking the EntryPoint, conducting fee payment, and some safety checks to make sure nothing goes wrong with this relayed set of transaction instructions.

If you didn’t fully get that, it’s not your fault. In order to get the feature we want, that’s a huge amount of new “machinery” both on- and off-ledger: new pseudo-transactions, new smart contracts, a new mempool, new fee payment mechanisms, new anti-spam mechanisms – with new error checking to make sure it’s functioning properly. It’s a technically impressive solution that works without changing the bottom-level protocol and transaction primitives, but it’s impressive in a way that’s a bit like a Wallace and Gromit contraption.

Why does that matter? With all of those new moving parts, it becomes tremendously more difficult to implement all of these parts and be certain that there are no unanticipated consequences for users or dApps and to be sure that there are no exploitable edge cases that could cause harm.

If account abstraction is intended to be the solution for eliminating the single seed phrase for users, then all of those risks will apply to the majority of user transactions on Ethereum. This should be a huge concern for Ethereum users and developers.

This complexity also means it will take time to get support in wallets and dApps. They will need to be updated to understand how this new system works and give it what it needs, while continuing to support everything that doesn’t use this completely different account model.

Creating Smart Accounts with Radix Network Features

The design of the Radix Network itself started with a very different set of assumptions from Ethereum and other L-1s, driven first and foremost by the needs of mainstream adoption. This meant architecting from scratch Radix’s consensus, virtual machine, smart contract language, transactions, and wallet UX to make the common features of web3.0 and DeFi – assets and dApps, accounts and identities – not just possible but native features of the network that work intuitively and predictably.

That philosophy made “no single seed phrase” Smart Accounts not only a necessary part of the solution for great user experience, but natural and simple to implement. In fact, Smart Accounts nearly emerged on their own from features of the network design. Here’s how.

One of the defining features of the Radix Network design is this:

• Native assets – making intuitive asset behavior universal, not implemented in separate smart contracts.

‍

This is crucial to being able to solve the problems with smart contract safety and development difficulty, and it drove the creation of an asset-oriented virtual machine that makes assets native network objects.

If the network is to manage assets as native objects, it needs to have “places” where those assets can actually be – and that means that Radix accounts can never be just a keypair. Accounts have to be real “components” – Radix’s form of smart contracts that can interact with native assets and hold them in containers called “vaults”.

With all accounts defined to be components, that frees Radix to include useful logic with those components. Creating logic to control accounts with multi-factor signing and recovery means using another feature of the Radix Network:

• Native authentication – making controlled access to accounts and components universal, with the network ensuring that the right signatures or “badge” tokens are present.

‍

Rather than tie all authentication to the single signing key of the account submitting the transaction, as on other L-1s, Radix’s auth system lets components define clear and powerful access rules that determine who is able to do what.

Bringing these features together makes the design of the Smart Account system for users and the Radix Wallet possible. With Smart Accounts, the Radix Wallet can define a wide variety of “signing factors” (like the user’s phone, a Yubikey, a hardware wallet, or even a set of security questions) that can be combined to control Smart Accounts and the assets they hold, and help users recover access if they lose access to a factor. No magical seed phrase needed, and it’s all built using the core capabilities of the network, rather than an add-on system.

Smart Accounts in Usage

But how do users and dApps interact with those Smart Accounts in transactions? One more important Radix Network feature comes into play:

• Composable, asset-oriented transactions – called “transaction manifests”

Rather than define a transaction as a message to one smart contract from one signer, all Radix transactions directly specify how assets should move between an arbitrary set of accounts and other components being called. 

This is great for enabling unlimited atomic composability between different dApps (without smart contract code), and for allowing the Radix Wallet to show users exactly what will happen in transactions. But it also makes using Smart Accounts in transactions elegantly simple.

Comparing to the transaction steps above to use ERC-4337’s abstracted account system, here’s how “submit a transaction from your account” will work on Radix with Smart Accounts:

1. The Radix Wallet receives a transaction, perhaps including a withdrawal of assets from the user’s account(s) plus other desired component interactions. The wallet signs the transaction with the appropriate signing factors for the relevant account(s) and submits it to the network.
2. Because withdrawing assets from an account requires authentication, the Radix Network ensures that the right combination of signatures or badges, as configured by the user, are indeed present in this transaction.

That’s it! This is incredibly simple, and it’s how all user transactions work on the Radix Babylon network and beyond. No unanticipated consequences or exploitable edge cases, and it works naturally with Radix’s intended sharding design for massive parallelism.

The difference between account abstraction and Smart Accounts is similar to the difference between how “tokens” work on Ethereum vs. Radix. While both check the feature box for “users can create tokens”, the Ethereum way is complex, risky, and unintuitive whereas the Radix platform makes assets a first-class feature of the platform.

The simplicity of this system is also its power. It means that smart accounts can include more than just the basics. For example, “social recovery” is just a matter of providing badge tokens to trusted third parties that authorize them to begin a recovery process on your account. Delegated fee payment is inherent; any component in the transaction can pay the fee because there is no “caller” account that must do so. 

Because the Radix network makes the necessary fundamental building blocks intuitive, simple, and safe, none of these features require adding new layers of complexity to the system. But on Ethereum and other L-1 not designed from scratch to have those building blocks, these sorts of features will always require clever but worrisomely convoluted approaches like ERC-4337.