Build Account Abstraction wallets with AWS and Alchemy

This post is co-authored with Alchemy. Alchemy builds APIs, SDKs, and tools that help developers build blockchain applications. Alchemy is actively involved in the Account Abstraction community and recently released Account Abstraction infrastructure APIs and SDKs.

Ethereum wallets are used to manage access to Ethereum accounts and to the assets that are held by those accounts. Any activity a user performs on Ethereum, such as sending payment, or buying an NFT, is done through a wallet.

Ethereum wallets, also known as Externally Owned Accounts (EOAs), are based on public key cryptography. The public key is akin to an email address, which can be shared publicly, whereas the private key is akin to a password, which should never be shared. Anyone with the public key can encrypt a message which can only be decrypted by the corresponding private key. Similarly, the private key can be used to sign a message, and anyone with the public key can verify this signature.

Applying this to blockchain, a public key is used in deriving a wallet address. When a user issues a transaction from their wallet, such as sending a payment to another wallet, they sign their intent using their private key and send that transaction to the blockchain network. Anyone on the network can easily verify that the transaction was signed by the private key associated with the wallet’s address, as the wallet address is derived from the public key corresponding to the private key.

The use of well-established cryptographic primitives like creating digital signatures on well-known elliptic curves, such as secp256k1 in the case of Ethereum, comes with the benefit that no known attack or exploit exists up to now.

However, wallets also come with significant user experience (UX) challenges, which in extreme cases can lead to complete loss or theft of funds, and require users to become comfortable with new security concepts like managing private keys and seed phrases. Some other challenges include needing to maintain a balance to pay for transaction fees, and not offering users a way to recover or rotate private keys.

In Part 1 of this two-part series, we explore these challenges in more depth and look at how Ethereum’s Account Abstraction (AA) wallets, which launched in early 2023, address these challenges while enabling new features like payment subscriptions and account recovery. In Part 2, we discuss how you can build AA wallets on AWS using Amazon Cognito and AWS Key Management Service (AWS KMS) with Alchemy’s AA APIs and SDK.

Challenges with Ethereum wallets

What is an Ethereum wallet?

A helpful analogy for an Ethereum wallet is a digital safe whose key is permanently fixed and may never be changed. The safe can’t be opened in any other way than by using the key or a copy of it. Therefore, it’s imperative this key be safeguarded because anyone with the key can retrieve the contents of the safe for themselves. If the key is exposed to a third party, it can be used to extract all the contents of the safe. If the key is lost and no copies exist, the key can’t be retrieved, leaving the contents of the safe locked forever. While these properties ensure the contents of the safe can’t be extracted without the key, they also pose a poor user experience.

Challenges with private key management

Private key management is a hard problem. Corporations are building entire processes around private key management, defining who is allowed to access the keys and where they are stored, and using recovery options such as printed versions stored in safes or external storage devices. Still, there have been numerous incidents where even experienced users lost their private keys or had their private keys exposed to an unauthorized party via social engineering attacks.

Paying for transactions

For a wallet to send a transaction on the Ethereum network, the wallet must pay the transaction fee (also known as the gas fee). This must be paid in the network’s native currency, ether (ETH). This also poses a user experience challenge because every wallet must first be bootstrapped with ETH before it can transact on the network.

EOAs present several UX challenges, including that private keys are fixed and cannot be updated, and that a balance is required to pay for Ethereum transactions.

Summary of wallet challenges

Let’s summarize the user experience challenges of EOAs:

• No built-in key recovery; if you lose the private key, it’s lost forever
• No fine-grained authorization management. Anyone with access to the associated private key has full control over the wallet
• No key rotation; you can’t update the private key associated with a wallet
• Wallets must maintain a sufficient balance of ETH in order to transact on the network

For completeness on key recovery, it’s worth mentioning that wallets created as part of a hierarchical deterministic (HD) wallet can have their keys recovered via the HD wallet’s seed phrase. The seed phrase is a mnemonic representation of a root private key, often comprised of 12 or 24 words, and it can be used to derive the private keys in an HD wallet. Although a seed phrase may be easier to maintain (human-readable words compared to a 256-bit string of characters), it maintains the same properties as a private key, notably that if it’s lost, it can’t be recovered, and if compromised, the assets in the wallet are immediately at risk. A seed phrase also can’t be rotated. To summarize, a seed phrase should be managed as if it is the private key itself.

Hardware wallets, which provide an extra layer of security by preserving the private key within a secure element on the device without connectivity to the internet, and native smartphone wallets have helped mitigate some of the user experience challenges like secure private key storage. However, these devices are still geared towards users who are already familiar with how blockchain wallets work, and still require the user to manage some aspect of the wallet security, such as safeguarding a seed phrase.

Ethereum Improvement Proposal 4337 (EIP-4337)

What is EIP-4337?

In September 2021, a group of authors proposed EIP-4337: Account Abstraction Using Alt Mempool to address the challenges we’ve discussed. Account Abstraction introduces a new transaction flow that enables the use of programmable smart contract wallets (AA wallets) to address many of these challenges, while continuing to support EOA wallets.

AA wallets are smart contracts that are deployed on-chain, that enable a user to perform the same transactions they would typically perform with an EOA. Ownership of an AA wallet is determined by the code contained within the smart contract, whereas with an EOA this is done within the Ethereum Virtual Machine (EVM). As the AA wallet contains code, this enables a range of features not possible with EOAs such as role-based permissions, supporting multiple owners, transferring ownership, and payment subscriptions.

Support for alternative cryptographic signature schemes

Compared to EOAs, ownership verification is abstracted away from the underlying EVM, and is managed by the user’s smart contract. Ethereum has a hard dependency on the secp256k1 elliptic curve, and the EVM provides a native precompile (called ecrecover) for verifying signatures using this elliptic curve. This is how EOA transactions are authenticated.

With AA wallets, a private key is still required in order to sign a transaction, for example, to initiate a transfer. However, the difference now is that many different cryptographic signatures schemes can be supported in the smart contract to validate the signature, such as quantum proof Lamport signatures. This enables the wallets to support organizations who must comply with NIST standards (FIPS 102) and require support for secp256r1 or other curves, or for compatibility with other chains who support different elliptic curves.

Improved private key management

Validating the transactions within the smart contract enables functionality that isn’t possible with EOAs. If a user loses their private key or their mobile device containing their private key, social recovery can be implemented within the smart contract to enable a new private key to be associated with the wallet instead. Furthermore, multiple keys can be associated with a single smart contract wallet. Users can define the keys of trusted account guardians, whether they be people or hardware devices, with a rule specifying that if the majority of the guardians agree to a key update, meaning they collectively provide a valid signature, then the primary owner of a smart contract account can be updated.

Using multiple keys, a family wallet can be implemented, with a key for every member of the family. The logic of the wallet could enforce spending limits on children, and could require two parent signatures for any transaction above a certain amount. Threat detection services can be integrated into the wallet by requiring a signature from a trusted third party’s threat detection service to ensure the counter party of a user’s transaction is not a malicious actor. Subscriptions can be configured within a wallet, for example, to automatically authorize a once-a-month utility payment, provided it’s within a certain threshold.

Support for sponsored transactions

Another benefit of AA wallets is they remove the requirement that every user must maintain a balance of ETH within their wallet for paying network transaction fees. Although every transaction still requires ETH, another entity, known as a Paymaster, can pay these fees on behalf of the user. The Paymaster may require the user to pay them in USD, or an ERC20 token, or not pay them back at all, for example during a promotion or during user onboarding.

You can access Alchemy’s implementation of Paymaster called Gas Manager here. We will dive into more technical details of the Paymaster in Part 2.

With AA wallets, account ownership is verified in code, and a balance of ETH is not required to pay for Ethereum transactions.

Summary of benefits of Account Abstraction wallets

To summarize, and continuing on our analogy from earlier, we are decoupling the key that opens the safe. We now have a much bigger design space on how to create and manage the key, and the choices for the underlying cryptographic algorithm of the key, and can introduce logic handling into the wallet.

AA Wallet Security

Replacing EOA wallets with AA wallets introduces new security considerations. Just like any software application, smart contracts are susceptible to bugs, which for a smart contract wallet could result in loss of funds. Another risk is vulnerability due to a bug within the EVM. Any smart contract wallets that will be deployed to production should be audited to help reduce these risks. Some third party AA wallet providers, including some open-source wallet implementations, have been audited and may be used as a starting point. Any customizations to the smart contract would require the wallet be audited prior to deploying to production.

Use cases enabled by AA wallets

Account Abstraction went into production in Q1 2023 on Ethereum mainnet and the initial applications that incorporate it are still being developed. AA wallets are well-suited for applications that need to, at scale, onboard users and provide them with wallets. They are well-suited for this because users’ AA wallet addresses are known ahead of time, even before the user ever interacts with it, which enables lazy instantiation of the wallets.

Typically, when an Ethereum smart contract (including a smart contract wallet) is deployed to the network, its address is determined by the deployer’s address, and the deployer’s ‘nonce’ which is a counter of the number of transactions the deployer has sent.

In 2018 an alternate method was introduced, called CREATE2, which calculates the smart contract address using:

• the deployer’s address
• a salt value the deployer specifies
• a bytecode representation of the smart contract code
• the constructor arguments to the smart contract which could include a user’s social media username

This feature, also known as a counterfactual address, can be used to pre-fill a wallet with Non-Fungible Tokens (NFTs), loyalty points, or other assets before the user ever uses it. The smart contract wallet is created the first time the user wants to send a transaction from their wallet.

The AA Paymaster feature also helps with onboarding because it removes the requirement that users must maintain a balance of ETH for transaction fee payment. We will dive more into Paymasters in Part 2. This feature enables some novel use cases.

NFT marketing campaigns

Marketing campaigns that want to airdrop NFTs to a large cohort of users can do this fairly easily with AA wallets. Because all the recipients’ wallet addresses are known ahead of time, the campaign can issue an NFT to each address. Users can immediately view their NFTs after the airdrop, without needing to take any steps to create their wallet or submit any on-chain transaction. Refer to this guide from Alchemy for more details on implementing a solution like this.

Financial service institutions

Financial service institutions can create on-chain wallets for their users that are secured by the same authentication systems they already have in place. The wallets can be seamlessly integrated into an existing Identity Provider (IdP) authentication flow. Additional security measures like MFA or JWT tokens can be validated within the smart contract.

Existing applications using IdP authentication can continue to use the same authentication mechanisms with AA wallets. This is possible because of the smart contract underlying the wallet. Service providers define the authentication and business logic within the smart contract. They can also enable the user to transfer ownership of the wallet to a private key of the user’s choosing by enabling a key update within the smart contract. This enables users to still claim ownership of their AA wallet when they need to switch to working with a different financial institution.

Gaming

Games incorporating NFTs for ownable in-game assets can provide AA wallets out of the box to game players. A benefit of AA wallets over traditional wallets within games is that when a user purchases an in-game asset, this typically requires the user to pause from game play in order to approve the transaction. For gameplay that requires acquiring several in-game assets, this can impede the user’s experience because they must frequently pause the game when approving transactions.

With AA wallets, a user can approve a one-time transaction that sets a duration and spending limit for the game, and then during that period of time, all transactions are automatically approved, and gameplay is not interrupted when in-game assets are purchased. This can be configured with safety guards such as limiting the price of each individual item that is purchased, or to require the user to manually approve a transaction when the purchase price exceeds a certain threshold.

Conclusion

Account Abstraction is available on many Ethereum Virtual Machine (EVM) chains, including Ethereum mainnet, all of its test networks, and many of the Ethereum Layer 2 networks. Another benefit of AA wallets is that since the wallet addresses are derived deterministically, users can have the same wallet address on different EVM networks, providing a solution to the current fragmentation of wallets across the EVM ecosystem.

To create an AA wallet, you can start from an open-source implementation, such as a wallet for just a single account, or a wallet that supports multiple accounts. The eth-infinitism team has several samples in the following GitHub repository. You can use these as a starting point, with your application-specific logic embedded within them. Refer to this guide from Alchemy on getting started with building smart contract wallets.

If you would like to explore this further, please reach out to us.

In Part 2, we walk through a sample architecture of building an AA wallet with Amazon Cognito and AWS KMS for the authentication and key management aspects of the wallet, and using Alchemy’s AA infrastructure APIs and SDK.

About the authors

Emile Baizel is a Senior Blockchain Architect at AWS. He has been working with blockchain technology since 2018 when he participated in his first Ethereum hackathon. He didn’t win but he got hooked. He specializes in blockchain node infrastructure, digital custody and wallets, and smart contract security.

David-Paul Dornseifer is a Blockchain Architect with the AWS Worldwide Specialist Solutions Architect organization. He focuses on helping customers design, deploy, and scale end-to-end blockchain solutions.