Hello everyone, I’m Nic, a blockchain developer at imToken Labs. Today, I’ll share how to build a safer and more user-friendly AA (Account Abstraction) wallet using Validation-Centric Design.
Today's talk will be divided into three parts:
- How are AA wallets built today
- Validation-Centric Design
- Technical Challenges and Solutions
1. How Are AA Wallets Built Today
AA wallet, a smart contract wallet implemented through Account Abstraction technology, features core functionalities including:
- You can use Multi-Sig, Passkey or Email to authorize your transactions
- You can pay gas fee with USDC/USDT, credit card or even get sponsored
- You can recover your wallet if key lost or stolen
- You can authorize third party to perform actions on your behalf
However, most AA wallets today follow an Account-Centric Design, characterized by:
- Account holds the user’s assets
- Account contains the validation logic, payment logic, recovery logic etc.
- Account is upgradeable
- (optional) Account is modular (ERC-6900, ERC-7579, etc.)
This approach creates friction for users switching between AA wallets. Unlike EOA wallets, where users seamlessly switch wallets via private keys or seed phrases, AA wallets require users to create new accounts and manually migrate tokens between wallets.
This process is cumbersome, risks asset loss, and degrades user experience. Moreover, while contract upgradability facilitates feature enhancements and updates, it also introduces potential risks. Take the 2024 Ronin Bridge hack as an example—this incident highlighted the security vulnerabilities that upgradable contracts may pose.
At the time, the Ronin Bridge contract defined two initialization functions for v3 and v4. However, only the v4 initialization function was executed, while v3 was overlooked, leading to a contract vulnerability that resulted in a loss of approximately $12 million.
Such mistakes often stem from the complex challenges faced during the version iterations of upgradable contracts. Imagine a scenario where the latest version of a wallet has been upgraded to v2.0.0, but a user, Bob, is still using an outdated version, v0.1.0. How can his wallet be securely upgraded to the latest version?
This requires ensuring that every parameter initialization during the step-by-step upgrade process—from the old version to the final v2.0.0—must be executed accurately. For developers, this presents a significant challenge, as any misstep could lead to severe security vulnerabilities.
This also explains why, even for projects like Ronin Bridge, which are maintained by large teams of professional developers, it remains difficult to completely avoid errors caused by the complexity of upgradable contracts.
2. Validation-Centric Design
The core idea of an AA wallet built with Validation Centric Design is to separate complex functionalities—such as verification logic, payment logic, and upgradability—from the account contract, leaving only the most fundamental functions: asset holding and DApp interaction.
By doing so, the account contract is significantly simplified, reducing its complexity and maintenance burden. The other complex functionalities are integrated into AccountEntry, which serves as the "entry point" for the account contract, handling all advanced logic.
Developers can focus on designing the AccountEntry contract, while users remain unaware of its existence and can seamlessly switch between different wallets without transferring assets.
This design offers several key advantages:
- Secure iteration: Developers can deploy new contracts at any time (e.g., upgrading from simple signature verification to multi-signature + biometric authentication) without requiring users to migrate their accounts.
- Agile development: It supports rapid adaptation to new standards or frameworks, preventing legacy technical debt from hindering progress.
- Seamless user experience: Users can enjoy new features through the wallet interface without being aware of changes in the underlying contract.
However, if the AccountEntry contract is designed to be upgradable and contains vulnerabilities, AA wallets built with Validation-Centric Design may still be vulnerable to attacks.
Beyond these advantages, Validation Centric Design also introduces additional features that further enhance both user experience and development flexibility.
Multi-Account Management
With Validation Centric Design, users can easily manage multiple accounts. Due to the simplicity of account contracts, users can create multiple accounts, switch between them flexibly, and even control multiple accounts within a single transaction.
3. Technical Challenges and Solutions
1. How to pay the gas fee?
Since AccountEntry initiates transactions but holds no user funds, paying gas fees requires creative solutions:
- Option 1: Store user funds in the AccountEntry Contract.
- Drawback: Users must manually fund the contract.
- Option 2: Transfer funds from the Account Contract to the AccountEntry Contract during transactions.
- Drawback: Violates ERC-4337 rules and some bundlers don’t support
- Option 3 (imToken’s Approach): Use Paymaster to prepay gas fees and later deduct costs from the user’s account.
- Advantage: Bypasses rule limitations.
- Challenge: Requires additional contract management and security audits.
2. Not easy to view on explorer
The Account is not the userOp.sender—the AccountEntry is. This makes it difficult for users to see which of their accounts executed a transaction.
The same issue applies to Meta Transactions, contract wallets like Safe, and child/sub-accounts.
Current workarounds rely on custom wallet parsing to display user-centric transaction details.
Thank you for your listening!