Introducing Account Abstraction on Aptos

by Aaron Gao

We are excited to introduce Account Abstraction (AA) on the Aptos blockchain, a feature that allows any account to be authenticated via Move code, in addition to the existing native authentication schemes. This feature, outlined in AIP-104, empowers users to implement complex, customizable authentication mechanisms while maintaining security.

What is Account Abstraction?

Account Abstraction enables accounts to be authenticated using Move-based logic within the Aptos Virtual Machine (AptosVM), rather than relying on native Rust authentication methods. This allows users to define their own authentication logic, extending the potential of the Aptos blockchain beyond traditional cryptographic schemes.

Why is AA Important?

Without Account Abstraction (AA), Aptos relies on native Rust-based authentication, which is limited to predefined cryptographic schemes. This causes several issues:

1. Limited Authentication Options: Native methods are restricted to basic cryptographic schemes, making it difficult to support advanced authentication mechanisms like multisig or custom logic.
2. Lack of Flexibility: Developers can’t easily define complex or application-specific authentication logic, such as multiple signatures or dynamic checks.
3. Delegation Challenges: Granting third parties partial access to accounts is difficult, requiring users to sign every transaction, which is inefficient.

AA solves these problems by enabling customizable, flexible authentication functions that provide greater control and scalability.

How Does Account Abstraction Work?

At its core, Account Abstraction introduces a new authenticator: the AbstractionAuthenticator. This new authenticator delegates the responsibility of authentication to a Move function stored in a resource at the account address. Here’s how the process unfolds:

1. Storing the Authentication Function: A Move function responsible for the authentication check is stored in a new resource at the account’s address.
2. Dynamic Auth Call: When a transaction involves an account configured with an AbstractionAuthenticator, the AptosVM dynamically calls the authentication check to the Move function registered for that account before the prologue.
3. Authentication Flow: The transaction execution proceeds only if the authentication function successfully returns a valid signer. If any authentication fails, the entire transaction is aborted.

The AA authentication flow

How to adopt Account Abstraction?

1. Call the entry function aptos_framework::account_abstraction::add_dispatchable_authentication_function to add your customized move function as the abstracted authentication function, where this function to add must match function signature fun (account: signer, auth_data: AbstractionAuthData): signer;

The passed-in signer is a master signer while the returned signer can be a permissioned signer.

1. When submit a transaction, use the new native Authenticator that represents the authentication scheme specified by the current transaction is AA. AccountAuthenticator::Abstraction { function_info: FunctionInfo, auth_data: AbstractionAuthData }

where the function_info is the the function specified in the previous step and the auth data containing two fields:

enum AbstractionAuthData has copy, drop {
    V1 { digest: vector<u8>, authenticator: vector<u8> },
}

where digest is the sha3_256() digest of the transaction signing message and authenticator is the “signature” of AA which can be verified by the authentication move function.

After the account is configured to use AA and the account authenticator associated with this account is set to AccountAuthenticator::Abstraction , AptosVM will check the validity of the auth_data with the specified move function. If everything goes well, the returned signer of the specified move function will be used as the signer of this account for this transaction payload.

AA move authentication function’s gas limit is set to a new gas parameter, max_aa_gas, set to 60 gas unit initially.

Key Advantages of This Approach

• Scalable and Flexible: AA decouples authentication from rigid, native cryptographic checks. This allows for greater flexibility in authentication logic, making it easier to scale and implement complex logic.
• Security and Auditability: By using the existing dispatchable function mechanism, which has been widely audited, AA ensures secure and traceable authentication. Additionally, the use of a gas-limited function helps mitigate the risk of DoS (Denial of Service) attacks.
• Enhanced Transaction Context: The ability to leverage transaction context during authentication increases the flexibility and richness of the authentication process. Developers can use additional information from the transaction to tailor authentication.

What Are the Use Cases?

AA unlocks a variety of powerful use cases for developers and users:

• Multisig Accounts: Enable accounts that require multiple signers to authorize transactions, improving security without the complexity of traditional multisig solutions.
• Sandbox Accounts: Create temporary accounts that isolate assets and reduce exposure to risks.
• Delegated Asset Management: Allow a trusted third party to manage assets under strict permissions, providing a semi-custodial model without sacrificing control over the assets.
• Dynamic Permissioned delegation for Applications: Grant trusted applications restricted access to users’ assets when combining AA with permissioned signer feature , removing the need for users to sign every transaction.

Why Not Ethereum’s ERC-4337?

Aptos’ Account Abstraction (AA) differs significantly from Ethereum’s ERC-4337, which relies on complex solutions such as user operation pools and contract wallets. Implementing these solutions on Aptos would introduce considerable complexity by bundling signatures and transactions, making the development and interaction processes more challenging. In contrast, AA on Aptos provides a simpler, more scalable solution while preserving high security and flexibility.

Aptos’ Account Abstraction is streamlined: you submit a transaction with a different authenticator. In comparison, ERC-4337 typically requires the user to interact with a bundler (an SDK or wallet that prepares the UserOperation), which then wraps it into a transaction.

Future Evolution

Initially, this feature is launched with permission_delegation, an official AA module that enables permissioned delegation. Based on feedback from users and developers, we plan to expand this collection by adding more commonly used Move-based authentication modules. This will help facilitate the adoption of Account Abstraction and prevent the need to reinvent the wheel.

Get Started

Ready to explore Account Abstraction? Check out our documentation to learn how to implement customizable authentication for your transactions. We look forward to your feedback and seeing the innovative solutions you build.

Stay tuned for future updates as we continue to enhance the flexibility and scalability of Aptos.

Happy building!