THE WALLET PROBLEM

Cryptocurrency wallets are the backbone of the blockchain ecosystem, enabling users to hold, manage, and transfer their digital assets without intermediaries. This empowers individuals to act as their banks, transacting freely with anyone with a crypto wallet.

However, while self-custody grants unprecedented financial control, it also brings significant risk. It is estimated that around 20% of all Bitcoin has already been lost due to seed phrase mismanagement—a sobering statistic that underscores the risks associated with self-custody. Although similar analyses have not been conducted on other blockchains, an understated estimate suggests that about 1% of the ETH supply has also been irretrievably lost due to key mismanagement. 

Managing funds on a self-custody wallet, without an entity to rely on for recovery can be daunting. Users often risk disastrous consequences such as approving malicious smart contracts, succumbing to phishing attacks, or losing their funds entirely due to user error. Additionally, the complexity of securely storing a seed phrase creates another significant barrier. This challenge, compounded by other unfamiliar hurdles in the crypto space, like gas fees, priority fees, maximal extractable value (MEV) attacks, and multi-chain transactions, makes the process of entering the crypto world far from optimal.

Despite these challenges, the crypto space is evolving rapidly. The industry is working to resolve these issues through new technological developments and creating a more secure, user-friendly experience. This report will explore how new solutions are reshaping the wallet experience, making cryptocurrency management more accessible and efficient for users at every level.

CURRENT WALLET CHALLENGES

Managing cryptocurrency through wallets offers users complete control over their assets, but this autonomy also comes with significant difficulties. The design of these wallets, particularly Externally Owned Accounts (EOAs), presents several challenges that can lead to poor user experience, financial loss, and inefficiencies. Below, we explore some key issues and how they impact user experience.

SEED PHRASE VULNERABILITY AND USER RESPONSIBILITY

Cryptocurrency wallets are designed to give users freedom over their assets without relying on intermediaries. However, this independence comes at a cost—the burden of responsibility falls entirely on the user. In traditional finance, much of this responsibility is handled by teams or systems; in crypto, it's on the individual.

EOAs, the most common type of cryptocurrency wallets, are controlled by a public-private key pair. While this grants users complete control, it comes with several limitations, such as reliance on a single seed phrase for access and needing to manually approve every transaction step. This presents several critical challenges that hinder user experience and security. One of the most significant issues is the vulnerability of seed phrases. As the single point of failure, losing a seed phrase inevitably means losing access to the wallet and its funds.

THE COMPLEXITY OF MANAGING CRYPTO TRANSACTIONS

Beyond the challenge of securing seed phrases, users face additional complexities when interacting with blockchains. The freedom to control your funds is one of the core benefits of self-custody. This autonomy is particularly attractive in the growing world of decentralized finance (DeFi), where users can access financial instruments similar to traditional finance. For example, users can deposit digital assets like ETH or stablecoins and borrow other assets while retaining exposure to their original holdings.

However, interacting with DeFi protocols using EOAs introduces layers of complexity. For each transaction, users must go through multi-step processes such as:

• managing gas fees

• handling token approvals

• ensuring that their transactions are confirmed on-chain. 

This process is far more cumbersome compared to its traditional finance services, where such operations are generally streamlined or handled by intermediaries. 

As DeFi continues to grow in popularity, the limitations of EOAs become more evident. Managing multi-step transactions, navigating complex interfaces, and safeguarding against phishing attacks and malicious contracts are just a few of the pain points that hinder broader adoption. The fragmented user experience is further complicated by the rise of multi-chain ecosystems. Users interacting across different blockchain architectures, such as Solana (SVM), Ethereum (EVM), and Cosmos, face increased friction due to the complexity of managing cross-chain transactions.

These challenges underscore the need for solutions that simplify the crypto experience and make self-custody more secure and user-friendly. As the demand for decentralized finance grows, addressing these issues is crucial to improving the user experience and encouraging broader adoption.

ACCOUNT ABSTRACTION: FROM EOAS TO SMART WALLETS

To address the challenges posed by EOAs, account abstraction has emerged as a crucial innovation. It is a method of setting up a blockchain network in which the user’s assets are stored in smart contracts rather than EOAs, the goal of this setup is to abstract away the complexity for the end user, allowing for a smooth and intuitive user experience whilst retaining self custody and sovereignty. It does this by decoupling the wallet logic from private keys to smart contracts. One standard that pushes account abstraction forward is ERC-4337, which introduces essential elements of account abstraction. While ERC-4337 plays a prominent role in account abstraction, other Ethereum Improvement Proposals (EIPs), such as EIP-7702 and various custom wallet solutions, also improve the user experience. Together, these solutions represent a broader movement toward more flexible and secure wallet technology.

HOW ACCOUNT ABSTRACTION TRANSFORMS WALLET USABILITY AND SECURITY

As previously mentioned, EOAs are controlled by a public-private key pair, meaning that each transaction or interaction has to be signed with the associated key. Account abstraction, however, transforms this process by introducing smart wallets, also known as smart contract accounts. Smart wallets differ from EOAs because they are blockchain accounts controlled by smart contracts instead of a private key. This decoupling of control allows smart wallets to be much more flexible and more secure.

USABILITY

One of the key benefits of smart wallets is that they can be created in multiple ways, not just from a single seed phrase. For instance, smart wallets can utilize social logins (e.g., email, Google, Twitter, or Discord accounts) or hardware security models (e.g., iPhones, Android devices, hardware wallets). This innovation makes onboarding new users much easier, as they are no longer required to manage complex seed phrases. 

Additionally, smart wallets enable the use of Paymasters, which are smart contracts that verify and/or sponsor user transactions. With Paymasters, users no longer need to hold native gas tokens to pay for transaction fees on every network they interact with, reducing the complexity of using multiple blockchains. For example, if a smart wallet receives an airdrop, the user can pay gas fees using any ERC-20 tokens instead of acquiring native tokens like ETH first. A real-life example for the future can be that merchants can allow users to pay with their crypto wallets on their phones, only holding USDC, where the paymaster sponsors the transactions.

Another improvement is batching transactions. For instance, when a user wants to swap tokens using an EOA, they must first approve the token on the decentralized exchange (DEX) and then initiate the swap. Instead, smart wallets streamline this process by allowing users to approve and swap in a single step which abstracts away token approvals completely - most smart wallets offer this feature in their built-in swaps, but for batching to work with dApps, the dApps themselves need to support transaction batching. In addition, users can take advantage of transaction batching when revoking multiple approvals in one go, transferring tokens, or a combination of different actions. 

SECURITY

Smart wallets offer significant security enhancements over EOAs, mainly through features like social recovery. If users lose access to their seed phrase or private key, social recovery allows them to regain access through trusted contacts or other pre-defined recovery methods. Some wallets even enable users to regenerate new keys without compromising the security of the entire wallet.

Furthermore, smart wallets provide more granular control over assets. Users can set spending limits for certain tokens or dollar amounts within a specific time frame. Multiple signers can be required to approve the transaction for high-value transactions, adding another layer of protection. This could be analogous to having budgeting options per store on your bank account or having a specific spending budget on certain items. Or having your partner sign off on big check items. 

In addition, smart wallets allow users to whitelist trusted addresses or blacklist known malicious addresses. This reduces the risk of interacting with phishing contracts or inadvertently approving dangerous transactions. In the worst-case scenario, if a signer is compromised, the compromised signer can be removed, and a new signer can be added—ensuring that the wallet remains secure without needing to migrate funds to a new wallet.

In the next section, we will delve deeper into how these features are made possible through the ERC-4337 standard.

A CLOSER LOOK INTO ERC-4337 AND ACCOUNT ABSTRACTION

ERC-4337, also known as the account abstraction proposal, was co-authored by Vitalik Buterin, Yoav Weiss, Kristof Gazso, Dror Tirosh, Shahaf Nacson, and Tjaden Hess. It was introduced without any modifications to the underlying Ethereum blockchain. It achieves this by replicating the functionalities of a transaction mempool. The core difference between ERC-4337 transactions and regular transactions is that ERC-4337 transactions are application level transactions, rather than protocol-level transactions. This means they're defined in Solidity code above the EVM layer. This new type of transaction is called userOperation, which represents bundled actions a user wishes to execute on the blockchain. These actions are sent to a specialized mempool for further processing. A key limitation of Ethereum is that only EOAs can initiate transactions. Smart contracts cannot start interactions on their own. This is where bundlers come in, as intermediaries that sign and submit transactions on behalf of smart wallets.

To better understand the ERC-4337 framework, it's essential to highlight the five key roles involved:

• The User: The user's main responsibility is to authenticate their identity and create userOperations—the specific actions they want to carry out on-chain.

• Bundlers: Bundlers are nodes that monitor the specialized ERC-4337 mempool for incoming userOperations. Because smart wallets cannot initiate transactions directly, bundlers—acting as EOAs—pick up multiple userOperations from the mempool, verify them, and sign the actual on-chain transaction. The bundler then submits it to the EntryPoint contract for execution.

• EntryPoint Contract: The EntryPoint contract is the core smart contract in the ERC-4337 framework. It is responsible for validating and executing the bundled userOperations received from the bundler. This smart contract interacts with smart wallets, bundlers, and paymasters to ensure smooth transaction execution.

• Paymasters: Paymasters are smart contracts that sponsor gas fees for users based on predefined rules. They enhance the user experience by covering gas costs and reducing the need for users to hold native gas tokens for each network they interact with.

• Smart Wallets: These are blockchain accounts controlled by smart contracts instead of private keys. Smart wallets handle the final execution of userOperations after validation, ensuring that transactions occur securely and efficiently.

To better visualize the role of each participant, here’s an example of how a typical ERC-4337 smart wallet transaction unfolds:

1. Action Creation: A user initiates an on-chain action, such as a token swap, structured as a userOperation.

2. Mempool Submission: The userOperation is submitted to the specialized ERC-4337 mempool, awaiting processing.

3. Bundling Process: A bundler picks up multiple userOperations from the mempool, verifies their validity, and signs the transaction. The bundler then sends it to the EntryPoint contract.

4. Gas Check: The EntryPoint contract validates the userOperations, checking if the smart wallet has sufficient gas to execute the transaction. If not, the contract assesses whether a paymaster can cover the gas costs.

5. Transaction Execution: Once validated, the EntryPoint contract calls the smart wallet to execute the userOperations. After successful execution, the bundler is compensated through gas paid by the wallet or the paymaster.

To the observant reader, some alarm bells might have gone off, mainly regarding EntryPoint. 

• EntryPoint is the single point of failure for ERC-4337, as all the transactions are being processed and validated by EntryPoint. While it has been audited rigorously and formally verified, it will remain susceptible to security risk and reliability issues.

• It decouples account ownership and control to EntryPoint, which can introduce the risk of unauthorized transactions. 

• It increases the flexibility of the end-user, however, it creates complexity in the backend. 

Therefore, while ERC-4337 can do tremendous leg work for user adoption, it isn’t the end all yet for account abstraction. 

ERC-4337 OVERVIEW AND STATS

https://dune.com/sixdegree/account-abstraction-overview

ERC-4337 has seen impressive adoption since its deployment in March 2023. 

• Approximately 88% of userOperations are funded via paymasters, indicating widespread usage of gas sponsorship features by dApps. 

• Over 19.5 million account abstraction wallets have been created, facilitating a total of 102 million user operations. 

• Generated over $4.2 million in sponsored gas fees, with bundlers earning over $750,000 in revenue. 

Interestingly enough, currently around 80% of the userOps are still unbundled. The second section sits at 6.6% with userOps bundled with more than 5 transactions.  

Most of these operations occur on Base (53%) and Polygon (35%), underscoring the popularity of these networks for account abstraction. 

However, when looking at users per chain, the image shifts. Of the nearly 20 million users, nearly 80% (16.3 million) are on Polygon, and only 12.6% are on Base.

While there is explosive growth on the wallet creation and userOps side, data might suggest that retention is not there yet. Since its inception, only 0.3% of the first wallets remain active. Of course, this does not have to mean that these users have left. Due to the nature of how smart wallets can work, it could mean that they have retired their original wallets to remain private on-chain. 

The wide adoption of ERC-4337 is evident in its usage across several prominent projects. Below are examples that saw significant activity from smart wallets.

• EARN’M Piggy Box Collection (Polygon): A DePIN project transforming smartphones into “earnphones” with over 10 million smart wallet interactions.

• Anichess (Polygon): An on-chain chess game that introduces unique gameplay with a twist.

• ZTX (Arbitrum): A multiplayer digital world where users can create, trade, and manage digital assets.

• Blocklords (Base): A strategic multiplayer game where players manage resources, and farms and engage in battles

SPECIFIC EXAMPLES OF ACCOUNT ABSTRACTION THAT IMPROVE UX

Several smart wallets have successfully implemented account abstraction, enhancing the user experience with key features such as social recovery, transaction batching, gas sponsorship, and advanced security controls. These features combine to make the interaction with dapps far more streamlined and secure than traditional EOAs. Below, we mention a few wallets that have implemented these features. However, it is important to note that we are not listing all the features of the wallets.

For example, Argent uses guardians to add additional layers of security. If a user loses access to their keys, a majority of guardians (3 out of 5) can authorize recovery, enabling the user to regain control of their wallet. This social recovery mechanism is a major improvement over EOAs, where losing access to a private key often results in permanent loss of funds.

Another example is Safe, the most widely used multisig wallet on Ethereum. Safe allows for a similar recovery process, offering self-appointed guardians and trusted entities like Sygnum and Coincover to act as guardians, further enhancing the security of wallet recovery.

Meanwhile, Ambire supports a hybrid account abstraction approach enabling the use of EOAs and smart accounts across all EVM chains. It’s the first extension to let you derive smart accounts on existing seeds and hardware wallets with the same address on all EVM chains. Each smart account has a single signer key, with recovery options planned for later.

It is important to note that while these projects implement account abstraction, they do not all utilize the ERC-4337 standard. Nevertheless, they show how different approaches to account abstraction can improve both security and user experience. Projects like Soul Wallet, Candide, UniPass, Castle, and Openfort are examples of smart wallets that employ the ERC-4337 standard.

In the next section, we will compare how each wallet type stacks up against each other, what the pros and cons are, and which is suitable for which user.

EOAS vs CUSTODIAL WALLETS vs SMART WALLETS

EXTERNALLY OWNED ACCOUNTS (EOAs)

Pros:

• Simplicity: EOAs are straightforward to use. They rely on a single seed phrase and private key for management, making the setup process simple.

• Low Transaction Costs: Since EOAs directly initiate transactions without needing intermediary smart contracts, gas fees are often lower than for smart wallets.

• Widespread Support: EOAs are universally supported across all blockchains, making them compatible with almost every dApp or DeFi platform.

Cons:

• No Recovery Mechanism: If users lose their private key or seed phrase, the assets are permanently lost, as there are no fallback mechanisms.

• Limited Features: EOAs don’t support advanced features like social recovery, multisig, or transaction batching. Each transaction must be signed manually, often creating inefficiencies for users engaging in complex DeFi interactions.

• Security Risks: EOAs are more vulnerable to phishing attacks, as users often need to approve and sign transactions manually for each interaction, increasing the risk of falling victim to malicious contracts.

Ideal users:

• Casual users with blockchain experience who only need basic functionalities, such as sending and receiving cryptocurrency or interacting with simple dApps.

• Experienced crypto users who are comfortable managing their private keys and prefer the lower gas fees and simplicity of EOAs.

• Cost-conscious users looking to reduce transaction costs prefer the minimalistic direct wallet control approach.

CUSTODIAL WALLETS

Pros:

• Ease of Use: Custodial wallets are extremely user-friendly and require little setup. Users typically log in with a username and password, and the provider handles all technical details, including key management.

• Account Recovery: If a user loses access, the custodial wallet provider typically offers account recovery options, making it easy to restore access to funds.

• No Technical Knowledge Required: Because the service provider manages everything, there’s no need for the user to worry about private key storage, gas fees, or managing complex transactions.

Cons:

• Lack of Control: Users do not hold their private keys, which means they trust a third party with their assets. This undermines one of the core principles of decentralization.

• Security Risks: Custodial wallets are prone to centralized security breaches. If the provider is hacked or experiences internal fraud, users’ assets could be compromised.

• Less Compatibility: Custodial wallets might not support advanced dApps or DeFi protocols, as they tend to offer limited interaction with the wider crypto ecosystem.

Ideal users:

• Beginner users just entering the crypto space don’t want to deal with the complexities of key management or gas fees.

• Users seeking convenience, especially those uncomfortable managing private keys or interacting with complex DeFi applications.

• Users who require additional support from a trusted entity.

SMART WALLETS

Pros:

• Enhanced security: Smart wallets leverage account abstraction to add features like social recovery (allowing trusted parties to help recover accounts) and multi-signature approval (requiring multiple signers to approve high-value transactions).

• Customizable Rules: Users can set spending limits, whitelist trusted addresses, or blacklist known malicious ones. They can also automate processes, which is difficult with EOAs.

• Simplified User Experience: Smart wallets offer streamlined experiences by supporting features like transaction batching (combining multiple operations into one) and gas sponsorship (allowing gas fees to be paid in ERC-20 tokens or even covered by dApps).

• Greater Flexibility: Smart wallets can interact across multiple chains and manage assets more efficiently by leveraging smart contract functionality, offering more tailored controls than EOAs.

Cons:

• Higher Complexity: Smart wallets are contracts, and as such they are inherently more complex than just an EOA.

• Depending on third parties: Smart wallets are created by a company. They most likely will require updates and upgrades or vulnerability patches if they are found. 

• Smart Contract Risk: Since smart wallets rely on smart contracts, they are exposed to smart contract vulnerabilities, which, if exploited, could lead to loss of funds.

• Gas Costs: Using smart contracts can result in higher gas fees compared to EOAs, particularly on congested networks like Ethereum.

• Possibly worse integration: Depending on which smart wallet you use, they might not necessarily be integrated with certain dapps.

Ideal users:

• Beginner users without experience with crypto, managing seed phrases that just want to do something with a dapp or want a more intuitive experience with features like social recovery and gas sponsoring so that they don’t need to onramp first.

• Advanced users or those handling large amounts of assets who require more security controls and flexibility.

• Users who frequently interact with decentralized finance (DeFi), multi-sig transactions, or complex dApps.

EMBEDDED WALLETS

Besides the distinction between Externally Owned Accounts (EOAs), custodial wallets, and smart wallets, a new category—embedded wallets—has started gaining traction. Embedded wallets are integrated directly into applications, offering a seamless user experience. While they often leverage smart wallet infrastructure, embedded wallets are typically confined to the scope of a specific application. Despite this limitation, they bring significant advantages, particularly by incorporating account abstraction features.

These wallets allow users to interact with applications without signing every transaction, making them particularly beneficial for use cases like on-chain games, decentralized social networks, and trading platforms. One of the leading providers of embedded wallets is Privy.io, which has onboarded over 20 million users across numerous projects, including well-known platforms such as friend.tech (nearly 1 million users), Pirate Nation, Hyperliquid (205,000 users), and OpenSea.

ENHANCING USER EXPERIENCE

Embedded wallets are integral to onboarding users into Web3 projects. They simplify the user experience by abstracting away complexities often associated with wallet creation and blockchain interactions. Key benefits include

Frictionless Onboarding

• Users can sign in with familiar social accounts such as Google, Twitter, Discord, or email. This eliminates the need for users to manage a seed phrase or private key directly.

• Wallet generation happens seamlessly within the application, removing the need for separate wallet software.

Streamlined Interactions

• Blockchain transactions, such as token approvals and gas fee management, are abstracted away. This provides users with a Web2-like experience while ensuring operations remain fully on-chain.

• Users can engage with on-chain activities without requiring prior blockchain knowledge.

Some case studies where embedded wallets have been applied

Gaming: In Pirate Nation, players can log in using their Google account. If they don’t have a wallet, one is automatically created. Actions like crafting, battling, and questing occur entirely on-chain without requiring users to sign each transaction.

DeFi: On Hyperliquid, users can sign in with their email and receive a one-time password (OTP) to log in. A wallet is created for them, allowing them to deposit USDC and start trading. Transactions, such as opening and closing positions, are one-click actions similar to centralized exchanges.

Social Platforms: On decentralized social networks like Farcaster, the user experience mimics Web2 platforms like Twitter or Facebook. However, a critical difference is that users on Farcaster retain ownership of their data and digital identity.

These innovations significantly lower the barrier to entry for Web3 adoption by providing a seamless experience while maintaining the decentralized ethos of blockchain technology.

LIMITATIONS AND RISKS

While embedded wallets bring convenience, they are not without drawbacks. Their design and scope introduce several limitations. Embedded wallets are isolated within the application they are integrated into. For instance, if a user creates an account on Hyperliquid and another on Pirate Nation, they will end up with two separate wallets, even if they used the same email address for both. Unlike global wallets, embedded wallets cannot easily interact with external dApps or services. This limits their utility for users who want a unified experience across multiple applications. Chain fragmentation is already a big challenge, and embedded wallets introduce another dimension to this which is app-specific fragmentation of your funds. A practical example of inhibited composability is the inability to stake your ETH in Lido and use your stETH on Aave to get a loan. 

Embedded wallets also face several security risks, particularly due to their reliance on application-specific integration. These risks include:

• Vulnerabilities in Configuration: Poorly configured security settings or misconfigurations can expose wallets to unauthorized access.

• Insufficient Isolation: If the wallet iframe or component is not properly isolated, malicious actors could exploit vulnerabilities to access sensitive wallet data or transactions.

• Man-in-the-Middle (MitM) Attacks: Communication between the embedded wallet and the host application can be intercepted, allowing attackers to alter or steal data.

• Dependency on Application Security: The security of the embedded wallet is often tied to the application's overall security infrastructure. If the host app is compromised, the wallet may also be at risk.

For example, a report from Dfns detailed a scenario where a protocol neglected proper security measures in its embedded wallet. This oversight allowed Dfns to extract the wallet’s private key, demonstrating the potential risks of rushing to implement such wallets without rigorous security checks.

RISKS OF SMART WALLETS

Smart wallets introduce advanced features that enhance security for user interactions, but the underlying smart contract vulnerabilities may present risks outside the user’s control. These risks are primarily technical. 

Operational risks

These involve flaws in access control, authorization, and privilege management, which can be exploited if the logic is insufficient or flawed. Some theoretical examples include escalation of owner privileges, bypassing signers/approvers, and the ability to change configurations arbitrarily. 

Implementation risk

These are errors that can result in unintended smart wallet behavior. Examples include: unauthorized transactions, bypassing limitations on transactions, connecting to dapps without required permissions, and signing malicious transactions even with safeguards.

Design risk

The wallet's design may introduce vulnerabilities, and some features might be exploited to alter the wallet's intended behavior. Some examples include functions that can trigger that aren’t defined in the code, asynchronous transaction processing, replay functions, return statements, and callback functions. 

Private key risk

Even though some smart wallets explicitly state that users do not need to manage their private keys or seed phrases, it should be noted that the wallet’s private keys are stored somewhere, either in the smart contract or on a ‘secure’ server somewhere. A real-world example of a smart wallet breach occurred with Loopring's smart wallet, in which a compromised “guardian”. Specifically, the official Loopring guardian (which was a single point of failure for some wallets) was hacked, allowing attackers to exploit wallets that only had one guardian—against best practice. This hack resulted in the theft of $5,000,000 worth of assets.

Attack vectors

Smart wallets, while equipped with enhanced features, remain susceptible to various forms of attack, including:

• Malicious Modules: Modules within the smart contract, which govern its functionality, can be manipulated to act as backdoors, allowing attackers to control the wallet’s funds. These modules could be maliciously inserted by third parties or introduced through decentralized marketplaces.

•  Wallet Control Outside of the Owner: Some wallets are deployed by third parties, potentially giving them backdoor access to wallet functionality. Additionally, transactions may be executed without explicit owner approval in certain cases, broadening the potential for attacks.

• Dapp integrations: integrations with dapps can be flawed and have unintended consequences, making the wallet susceptible to malicious transactions from the dapps.

• Phishing Attacks: Phishing remains a significant threat. Attackers may collect multi-signature data or gain unauthorized access to signers, enabling them to change contract data and move funds without legitimate approval.

Smart wallets offer many advantages over EOAs and custodial wallets, but they also come with unique risks due to their reliance on smart contract code. While users enjoy enhanced features, they must also remain aware of the technical risks, including smart contract vulnerabilities, private key exposure, and the potential for attacks through integrations or modules. Proper wallet maintenance, such as keeping the contract updated and ensuring security best practices, is crucial for mitigating these risks. 

Mitigating factors

To mitigate the risks associated with smart wallets, users should adopt specific practices to significantly reduce vulnerabilities while still benefiting from the advanced features smart wallets offer. 

Choosing well-audited wallets and contracts

Ensure that smart wallets are battle-tested and undergone rigorous independent audits by reputable firms. Audits aren’t the silver bullets against exploits, but they can identify vulnerabilities and exploits before they occur. 

Tips: Before using a smart wallet, research the audit history, and look for wallets that provide public audit reports from reputable firms like Trail of Bits, Spearbit, OpenZeppelin, Consensys Diligence, CodeArena, and Sherlock, to name a few. Be sure that when new updates are made to the wallet, they are audited before going public.

Best practice for social recovery

When using tools like social recovery, be cognizant of the fact that it is only secure when it is used properly. Improper use might lead to a false sense of security.

Tips: Ensure that there are enough guardians(signers) when creating the social recovery setup, and don’t rely on just one guardian (i.e., Loopring). Have 3 or more guardians that aren’t linked to each other with diverse clients, meaning desktops, mobiles (Android or iOS), hardware wallets, or trusted third parties.

Strong (uncompromised) credentials and Two-Factor authentication

For wallets that support social logins, use strong passwords and credentials that aren’t compromised, and enable two-factor authentication where possible.

Tips: use secure password managers to create and store long and complex passwords. Regularly check whether your credentials aren’t compromised.

Only interact with trusted dapps and verified smart contracts

When interacting with dApps or integrating with external smart contracts, ensure they are trusted and verified. Malicious dApps or contracts can inject harmful code or steal assets.

Tips: Always verify that the dapp you are using has been audited and is widely recognized in the industry.

Encrypt and backup private keys

Even though many smart wallets advertise not needing to manage private keys, ensure that if your private key is stored on-chain, it is encrypted and securely backed up. Never rely solely on the smart wallet's automated features.

Tips: If possible, import the seed phrase or private key into a hardware wallet for backup purposes.

Be Aware of Phishing and Social Engineering Attacks

Phishing remains a common attack vector. Be wary of unsolicited requests to share multisig data, login credentials, or recovery information.

Tips: Double-check URLs before connecting to dapps and avoid clicking on links from unknown sources. Never rush to do a transaction, always verify.

FUTURE OF WALLETS

While significant strides have been made with account abstraction, this report only discussed one ERC, ERC-4337, and its capabilities and limitations. However, there are other Ethereum Improvement Proposals to further improve account abstraction. One such proposal is EIP-3074, which introduces new Ethereum operations (opcodes) that could bring EOAs closer to smart contract functionality.

EIP-3074 allows EOAs to delegate transaction authorization to a smart contract, known as an invoker contract, for a single transaction. This would enable EOAs to mimic features of smart wallets temporarily. However, the invoker contract introduces potential vulnerabilities. Since the invoker contract gains control over the EOA during execution, any bugs or malicious code within the contract could result in stolen funds or unauthorized transactions.

Building upon this, EIP-5003 takes the concept further by providing a mechanism to permanently transition an EOA into a smart contract account, revoking access from the original private key. This is achieved by deploying smart contract code to the EIP-3074 authorized address. However, the permanence of such a migration raises concerns, as users may be hesitant to adopt this approach without fully understanding the long-term implications.

EIP-7702

EIP-7702, co-authored by Vitalik Buterin, Sam Wilson, and Ansgar Dietrichs, has been proposed to address these concerns. This EIP can be seen as the spiritual successor of EIP-3074 and 5003 as it builds on the concepts but takes a more conservative approach. It avoids introducing new opcodes and instead makes the upgrade temporary. With EIP-7702, EOAs can now store a delegation designator—an address that points to a smart contract. When a transaction is initiated by the EOA, it can execute the code at the designated address, allowing the EOA to function as a smart wallet temporarily. This brings features like sponsored transactions, batched transactions, social logins, and social recovery to EOAs, previously only available to smart contract wallets. However, this is an entirely new transaction type, and current wallet providers will be required to support this type of transaction. 

But EIP-7702 does still have limitations. The fundamental issue remains that EOAs are still controlled by a private key, which serves as a backdoor. This means that while a smart wallet created with an EOA may have multisig protections, the private key owner retains full control and can authorize transactions independently of the other signers. Additionally, account recovery remains a challenge. If the private key is lost or compromised, the only solution is to replace it, which can be challenging and does not offer a straightforward recovery mechanism. There is also the case of the gas cost being inherently higher than EOAs, this and the added smart contract risk might scare off on-chain natives that require minimal hand-holding.

Despite these limitations, EIP-7702 represents a significant step forward in account abstraction and is expected to be included in Ethereum’s Pectra update in February 2025.

FULL/NATIVE ACCOUNT ABSTRACTION

The ultimate goal for Ethereum's account abstraction, as envisioned by the developer community, is to transition every Ethereum account into a smart account. This shift promises significant benefits, many of which have been discussed previously. Additional potential improvements include:

• More signature schemes: Current EOAs only support ECDSA signatures, which are computationally intensive compared to newer cryptographic algorithms and lack quantum resistance. Enabling a broader range of signature schemes would allow for native support of smartphone-based signing.

• Default recovery options: By incorporating built-in recovery mechanisms during wallet creation, users could reduce the risk of permanently losing access to their accounts.

• Native sponsored transactions: Moving away from reliance on a centralized contract, such as EntryPoint, would allow each smart account to independently support sponsored transactions. This shift would simplify the user experience by removing concerns about gas fees and cross-chain management.

• Transaction batching and session keys: Full account abstraction would enable a seamless Web2-like experience, allowing users to log in to dApps using their wallets and perform multiple transactions in a single session.

These advancements present a vision where blockchain interactions are as intuitive and flexible as mainstream digital platforms. However, realizing these benefits requires substantial changes and careful coordination across Ethereum's infrastructure and its Layer 2 (L2) ecosystems.

STEPS TO NATIVE ACCOUNT ABSTRACTION

To transform this vision into reality, Ethereum and its ecosystem need to undertake significant developments.

• Full EVM integration: Account abstraction needs to be enshrined into the EVM to ensure consistent support across all L2s – L1 at a later stage. While some L2 solutions have already developed their own versions of account abstraction, a standardized approach, such as the Rollup Improvement Proposal-7560 (RIP-7560 or RollCall), is needed to prevent fragmentation. This proposal can be seen as a native extension of ERC-4337 tailored for L2s.

• Phasing out EOAs: New users should no longer create EOAs. Instead, all new accounts should be smart accounts, benefiting from the added security and functionality they offer. While proposals like EIP-7702 continue to facilitate the creation of EOAs to bridge user experiences, the goal is to create uniformity that aligns with advanced account abstraction capabilities.

• Migration of Existing EOAs: Existing EOAs need to transition to smart accounts to ensure uniform adoption. EIP-3607 addresses this by proposing the rejection of transactions from any sender with deployed code. This move would effectively disable traditional EOA transactions that share the same address as a smart contract, pushing the shift toward smart account usage.

Although account abstraction has been a focus for Ethereum developers for years, and significant strides have been made, achieving native account abstraction for all users remains an ambitious goal and will take time.

HOW DAPPS CAN SUPPORT SMART ACCOUNTS

While significant strides have been made in developing advanced account abstraction proposals like EIP-3074, EIP-7702, and Ethereum’s broader AA roadmap, some tools are already live and can be implemented immediately to improve compatibility with smart accounts. By adopting EIP-6492 and EIP-5792, dapps can enhance the user experience and support smart account functionalities.

EIP-6492: SIGNATURE VALIDATION FOR PRE-DEPLOYED CONTRACTS

This EIP is especially useful for onboarding users into dApps that use smart wallets like those built on ERC-4337. For example, a DeFi protocol could allow users to authorize transactions or perform actions like staking or swapping tokens without needing to wait for the smart account deployment to finalize.

EIP-5792: TRANSACTION BATCHING

A dApp like a decentralized exchange (DEX) can enable users to approve tokens and execute trades in one step, reducing gas costs and simplifying the user experience.

Integrating standards like EIP-6492 and EIP-5792 demonstrates how dapps can actively participate in the transition toward account abstraction. These EIPs not only bridge the gap between today’s infrastructure and the full realization of native account abstraction but also improve accessibility and efficiency for users right now. 

Big wallets like Safe, Coinbase Smart Wallet, WalletConnect embedded wallets, and thirdweb already support EIP-5792.

CONCLUSION

As we’ve explored in this report, cryptocurrency wallets are at the core of the blockchain ecosystem, granting users the ability to self-custody their digital assets. However, with that freedom comes significant responsibility, and EOAs have long been hindered by challenges such as seed phrase mismanagement, transaction complexity, and heightened security risks. This has created a barrier to mass adoption, especially for newcomers to the crypto space.

The rise of account abstraction, particularly through innovations like ERC-4337, represents a significant leap forward. Smart wallets are transforming the way users interact with on-chain by simplifying complex transactions, enabling features such as social recovery, and allowing for more flexible, secure wallet management and gas abstraction, effectively lowering the barrier to entering this ecosystem, bringing crypto interactions closer to what users expect from web2 systems.

However, as with any new technology, smart wallets come with their own risks, particularly in smart contract vulnerabilities. Operational, implementation, and design flaws could open the door to potential exploits. Therefore, users and developers alike must prioritize security best practices, ensuring that smart wallet systems are rigorously audited and that social recovery features are implemented properly.

Further improvements, such as EIP-7702, will likely bridge the gap between EOAs and smart wallets, making advanced wallet functionalities more accessible to a broader range of users. This evolution is necessary for continued growth and adoption, particularly as more individuals and institutions begin to explore the possibilities of decentralized finance and digital assets.

In conclusion, while the road ahead presents opportunities and challenges, the continued development of smart wallets and account abstraction will play a pivotal role in making cryptocurrency more secure, user-friendly, and scalable. As we move toward this future, users and developers must remain informed, cautious, and prepared to adapt to the evolving landscape of wallet technology.