This writeup will “pop the hood” of the Beam Wallet, and explain how Account Abstraction and ERC-4337 power the core payment flows and Web2-like user experiences in the Beam wallet.  We want to give crypto enthusiasts, Beam Users, and other teams developing in the space some insight into the technologies that power the wallet and our thinking about the future of Beam.

If you’re not familiar with Beam, it’s a new crypto-enabled wallet purpose built for global payments. Beam combines the censorship resistance, true ownership, and ethos of crypto with the ease-of-use and familiarity of Web2 products like Venmo and Cash App. If you’d like to learn more, I’d recommend you check out our last post – “Introducing Beam”.

Why do we need account abstraction?

The first thing most people think when they hear about Account Abstraction is “why do I need this? Why can’t I just use a normal wallet like Metamask?”

There are many reasons. Most of them have to do with the distinction between the two different types of accounts on Ethereum – an EOA (Externally Owned Account) which is controlled by a private key, and a contract account, which is controlled by the contract code.

In a nutshell, EOAs are “user accounts" from the perspective of Ethereum. They can store and transfer an Ethereum balance, initiate transactions by calling contract functions, and can create contracts. In contrast, contract accounts are responsible for storing contract code and state variables, but can’t initiate transactions themselves without a top level call from an EOA. Ethereum was designed with this distinction in mind, and until recently, virtually all consumer wallets that held assets were just EOAs behind the scenes.

There are a number of drawbacks and limitations associated with the use of EOAs for end user wallets.

• Clunky Gas Experience: In order to send a currency like USDC from an EOA wallet, you need ETH to pay for gas. For new users with little crypto experience, this is a confusing and off-putting experience. If crypto is supposed to be better, why does it make you manage two currencies? This is even a headache for experienced crypto users when they have to deal with the cognitive overhead of having to top up their Ethereum balance to pay for gas — especially with the proliferation of rollups.

• Private Key Management: All EOA accounts are controlled by a single keypair, which means they are one accident, virus, library vulnerability, or careless copy / paste away from catastrophic compromise or loss of funds. If a user leaks their private key, or loses it, their account cannot be recovered.

• Poor Asset Protection: EOA accounts are not able to programmatically constrain the types of actions that users can take. This means that the process for approving the spend of 1 dollar, or 1 million dollars, is identical. This makes every interaction with the blockchain potentially catastrophic – one accidental signature can sweep a user of all their assets. No additional functionality can be added to an EOA (like timelocks, spending limits, additional verification thresholds) to increase user security.

• Transaction Limitations: EOAs have a fixed transaction format – they can only call a single top level contract function at a time. This means that transactions that should normally be batched (an approval and swap for a Uniswap transaction) have to be submitted as independent transactions, which is clunky and unfamiliar to new users. This also means that certain types of payment schemes that consumers are used to in Web2 environments – like subscription payments, withdrawal allowances, and recurring payments – are not possible in a crypto environment.

In response to these limitations, the Ethereum community proposed a variety of standards that would enable “Account Abstraction.” Account Abstraction is a catch-all term to describe a paradigm where users are able to control “smart contract wallets,” which can overcome the limitations of EOA accounts by leveraging programmatic controls and functionality. After a lengthy process, ERC-4337 was chosen — at least as the first approach — to avoid consensus layer protocol changes.

In a way, EOA wallets are like “flip-phones” – limited to a few core features like calls and text. But smart contract wallets are like “smartphones” – they allow for applications to be built on them, with customizable logic and controls. Here are some significant benefits that smart contract wallets have compared to EOA accounts.

• Programmatic Asset Protection: Smart contract wallets allow for arbitrary verification logic and programmatic restrictions, allowing the use of different approval criteria for different transaction types. For example, a user could enforce additional verification requirements for transactions over a certain amount, in combination with a daily spending limit. This would create a ceiling on the possible economic damage a user would experience during an account compromise.

• Gasless Transactions: Smart contract wallets allow for the use of Paymasters, which sponsor gas for smart contract transactions, in exchange for ERC-20 payments. This means that users can pay transaction fees in the currencies they are sending, an experience very familiar to users of Web2 payment products.

• Recoverable Private Key Management: Smart contract wallets enable various forms of social recovery, 2FA, and social authentication to manage private keys. For example, a user could designate a few friends who have the ability to recover that user's account in the event of a catastrophic loss. These wallets can also use non-traditional verification logic, like biometric authentication, two factor authentication, OAuth, and other methods that allow for more intuitive account management.

• Extensible Transactions: Smart contract wallets remove the need for transactions to be individually submitted. Instead, end users submit an array of “User Operations” to be executed by the wallet in a single transaction. Each UserOp specifies a transaction or set of transactions for the wallet to perform, allowing for complex contract interactions to be submitted easily.

• Session Keys: Smart contract wallets also enable alternative payment flows that users are used to in Web2 environments through the issuance of Session Keys. Session Keys are ephemeral credentials, akin to JWTs, that restrict the scope of actions the credential can take. This means that giving Netflix the ability to pull $10 USDC from your wallet each month is as simple as providing Netflix a session key that can be revoked at any time. The session key could restrict the scope of actions that Netflix can take to a single withdrawal of USDC on a month-long timelock. Session keys could also be used to give a family member emergency access to your account – for example, the key would be programmed to authorize a one time transfer of 1000 USDC.

These are just some of the benefits of Account Abstraction over traditional EOA wallets. Because Smart Contract wallets are programmable, they enable an infinite number of configurations that suit the needs of end users. These configurations are not possible with traditional EOA wallets. For Beam to be the best, most intuitive, global payment product, we had to use smart contract wallets over EOAs.

How does Beam use smart contract wallets?

This section shows how Beam uses smart contract wallets by walking through a user flow from start to finish. For the example, we will walk through Alice sending USDC to Bob and registering a Beam Name with ECO, which will demonstrate a few core benefits of Account Abstraction.

Sending some USDC

When Alice wants to send 10 USDC to Bob, she looks up Bob’s address using ENS, and is displayed a transaction approval.

The transaction displays gas fees in USDC, by charging a flat fee of 0.50 USDC per transaction. This means that Alice doesn’t need ETH in her smart contract wallet at all – Account Abstraction allows her to pay all her transaction fees in USDC. The transaction still costs ETH to run on Optimism, but behind the scenes, Alice is actually making an agreement with a Paymaster contract, which fronts the ETH in exchange for the USDC fee.

In order to understand how this is all negotiated behind the scenes and executed on Optimism, let’s walk through the 10 USDC payment.

1. When Alice confirms the transaction and fee, Beam constructs a set of User Operations to pass to the smart contract wallet. Each User Operation defines a set of actions for the smart contract wallet to perform. In this instance, Alice is sending Bob 10 USDC and paying a 0.50 USDC fee, so the User Operation will specify two USDC transfers.

2. Alice’s wallet sends the User Operations to a server, which inspects the transaction to make sure it will be sponsored by the Beam Paymaster. It makes sure that the transaction is a transaction supported by Beam’s flat fee system, which serves two purposes:

   1. It prevents abuse of the flat fee system, which is intended for peer-to-peer transfers. Without the check, Alice could submit non-transfer transactions that would be much more expensive than the flat fee.

   2. It provides an extra layer of protection for Alice through transaction whitelisting! Beam only allows specific sets of User Operations to be processed from the Beam interface. This protects Alice from accidentally approving or signing transactions that she does not realize she is signing. In the future, as Beam integrates with dApps and other DeFi native services, this extra layer of protection should prevent users from getting scammed if front end services are compromised or spoofed.

3. The relayer server sends the User Operations to a Paymaster, which inspects the transaction, and approves it if the correct fee is sent. It sends the transaction back with a signature that is validated on chain, which indicates that the Paymaster will sponsor the transaction.

4. Beam now has the User Operations and a Paymaster Signature. It signs this data, fills in some gas variables, and submits the transaction to a bundler service. The bundler submits the transaction on chain for the user! Here is an example USDC transaction with decoded data (which you can view on Optimistic Etherscan if you’d like).

5. The transaction completes! The 10 USDC is sent to Bob, and Alice is charged a 0.5 USDC fee that is sent to the Paymaster’s vault. Account Abstraction made it possible for Alice to pay Bob without having to hold ETH, and in a single atomic transaction that paid Bob and the transaction fee.

Because the smart contract wallet is compatible with ERC-4337, users are not ultimately reliant on the Beam servers in order to execute transactions. They can submit UserOps to whatever bundler service they want using a different interface. This is a key way that Beam provides the user convenience expected of Web2 products, while maintaining permissionless opt out expected of Web3 systems.

Registering a Beam Name

Registering a Beam Name (an ENS subdomain of *.beam.eco) from the interface uses the exact same flow behind the scenes. In this instance, a UserOp is constructed to combine the approve and register transactions (which would normally be separate), into one transaction. This is a key differentiator of Account Abstraction wallets – they can take operations that would otherwise need to be performed separately, and logically batch them into a single, seamless transaction.

Registering a Beam Name uses a flat fee of 600 ECO, with the transaction fee fully sponsored by Beam. Essentially, the cost of the transaction fee is baked into the total cost of 600 ECO, which emulates payments in the Web2 world where transaction costs are typically just baked into prices, which is only possible with Account Abstraction.

The future of Account Abstraction in Beam

These types of Web2 payment flows would not be possible with existing EOA accounts, and highlight some of the advantages of using Account Abstraction in Beam. But even now, Beam is barely scratching the surface of what is possible with Account Abstraction. Below is a non-exhaustive list of some of the ways that we have thought about extending the functionality of Beam with Account Abstraction.

• Alternative Authentication Logic: Smart Contract wallets can swap out the underlying logic for signature authentication to any arbitrary scheme. In the future, Beam might allow users to use alternative signature schemes like Biometric Authentication or support multiple permissioned owners with unique restrictions for each owner.

• Session Keys: Session keys are ephemeral credentials, akin to JWT tokens, that can impose arbitrary restrictions on the actions of the session keys. Session keys can be used to enable Web2 payment flows like credit card authorizations. For example, a session key could be issued to a merchant that would allow them to withdraw 10 USDC a month to pay for a recurring subscription, or you could give your friend a session key to give them emergency access to 500 USDC of your funds. Session keys can also transform dApps to behave like normal Web2 Apps – by pre-authorizing and restricting the set of actions the dApp can take, the user doesn’t need to approve every single transaction. Session keys would provide an additional layer of security in this instance when Beam users are interacting with dApps, or white labeled dApp interfaces.

• BLS Signature Aggregation and other compression schemes: One downside to smart contract wallets is that they require posting a ton of calldata to the L1, which makes them significantly more expensive than compatible L2 transactions (around ~4-5x more expensive). We are already exploring the use of BLS signature aggregation to compress signature data, and various compression schemes to dramatically reduce the amount of calldata that a transaction requires, which should lower fees for Beam users.

• Social Recovery: Smart contract wallets allow users to set “guardians” for their wallet, which would allow them to be recovered in the case of the loss of the private key that owns the wallet. The recovery process would require signatures from N of M of the guardians, to allow the signer private key to be rebound. Other schemes would also allow the private key to be rebound in case of credential leakage.

• Threshold Based spending limits: Allow users to set withdrawal limits, and arbitrary restrictions based on spending threshold limits, and additional validation requirements for specific types of payments. These would mimic Web2 payment flows that Beam users are used to.

• Private Transactions: Smart contract wallets can be extended to support private transaction schemes like “stealth addresses”, which will fulfill the ultimate vision for Beam – the most “cash like” digital payments experience in crypto.

• Intents: Instead of users being required to specific exactly what they’d like to do, smart contract wallets enable “intent based” user actions. For example, in a modern blockchain environment, users might “swap 10 USDC for 10 UST on Uniswap”. In a future paradigm, users might submit something like “I will pay 10 USDC to the first person who will send me 10 USDT”, which would outsource the specifics of the fulfillment of the order to market makers or transaction solvers. This kind of system would dramatically reduce fees that individuals would pay for transactions.

• EIP-6900 Support (Modular Smart Contract Accounts and Plugins): This EIP proposes a way to support modular components for smart contract wallets that could be swapped in and out as plugins. Plugins allow for underlying logic in any part of the smart contract wallet (session keys, subscriptions, spending limits, and role-based access control for example) to be implemented by “installing” a smart contract that supports the correct interface.

We are barely beginning to scratch the surface of what's possible with Account Abstraction in Beam. We believe this technology is at the core of making Beam the most user friendly global payments platform, all powered by cryptocurrency.