> For the complete documentation index, see [llms.txt](https://docs.armchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.armchain.org/account-abstraction/overview.md).

# Overview

Armchain ships with **native Account Abstraction (AA)** integrated directly into the protocol. This means smart contract accounts are fully supported at the consensus and client level, not bolted on as an application-layer standard. Users can control their accounts using a range of cryptographic schemes, and third parties can sponsor transaction fees through paymasters, all enforced at the network layer.

## What Native AA Means

Most blockchains use Externally Owned Accounts (EOAs): accounts controlled by a single private key. Account abstraction replaces that fixed signing requirement with arbitrary validation logic expressed in a smart contract. The account itself decides what constitutes a valid transaction.

On Armchain, this is native: the client nodes understand AA transactions directly, route them through a dedicated mempool, and apply validation via protocol-level system contracts before execution. There is no bundler, no separate entry point contract to fund, and no off-chain relay required.

| Feature           | Application-Layer AA (e.g. ERC-4337) | Armchain Native AA                            |
| ----------------- | ------------------------------------ | --------------------------------------------- |
| Validation layer  | Smart contract (EntryPoint)          | Protocol / system contract                    |
| Mempool           | Bundler-managed, off-chain           | Separate AA mempool in the client             |
| Gossip            | Standard P2P                         | Dedicated AA gossip layer                     |
| Gas sponsorship   | Paymaster contract                   | Paymaster contract (Foundation + third-party) |
| Custom validation | Solidity wallet contract             | System contract (Yul) or custom extension     |

## What It Enables

* **Multiple signing schemes**: Accounts can validate transactions using post-quantum signatures, WebAuthn passkeys, MPC-managed ECDSA keys, or any custom scheme.
* **Gasless onboarding**: The Foundation Paymaster sponsors contract deployments for new users, funded with ARM tokens. Users can get started without holding ARM first.
* **Third-party gas sponsorship**: Any entity can operate a paymaster to cover fees for their users.
* **Modular account logic**: Developers can implement custom account validation by extending the system contract framework.

## Architecture

```
┌─────────────────────────────────────────────────────────┐
│                       User / dApp                        │
│   Constructs AA transaction with chosen signing scheme   │
└──────────────────────────┬──────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│                  AA Mempool + Gossip Layer               │
│   Separate from the standard transaction mempool         │
│   Validates: paymaster deposit, basic format checks      │
│   Propagates AA transactions between nodes               │
└──────────────────────────┬──────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│               AA System Contracts (Genesis)              │
│   Factory Registry   ← account deployment               │
│   Validation Schemes ← MLDSA, Passkey, SLH-DSA, MPC    │
│   Foundation Paymaster ← gas sponsorship                │
└──────────────────────────┬──────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│                   EVM Execution                          │
│   Account validation → paymaster validation → execution  │
└─────────────────────────────────────────────────────────┘
```

## AA Transaction Flow

1. **Construction**: The user (or dApp) builds an AA transaction specifying the account contract address, call data, chosen validation scheme, and an optional paymaster.
2. **AA Mempool ingress**: The node receives the transaction on the AA gossip layer. It checks the paymaster has a sufficient deposit and that the transaction is well-formed.
3. **Gossip**: The AA transaction is propagated to peers via a dedicated AA gossip protocol, separate from the standard event gossip used by regular transactions.
4. **Account validation**: At inclusion time, the account's system contract validation function is called. The signature is checked against the chosen scheme (MLDSA, Passkey, SLH-DSA, or MPC).
5. **Paymaster validation**: If a paymaster is specified, the paymaster contract confirms it is willing to cover the gas cost for this transaction.
6. **Execution**: The account's call is executed through the EVM. Gas is deducted from the paymaster deposit (if sponsored) or from the account balance.
7. **Finality**: Like all Armchain transactions, the result is final the moment the block is sealed. No confirmation waiting is needed.

## Separation of Concerns

The AA mempool and gossip layer operate independently from the standard PQC (Type 3) transaction pipeline. Regular Type 3 transactions and AA transactions each have dedicated:

* Ingest paths in the client
* Mempool data structures
* Gossip message types
* Validation rules

This separation ensures that AA-specific spam or load cannot degrade the standard transaction pipeline, and vice versa.

## Current Status

The baseline implementation is complete and tested:

* All validation scheme system contracts are deployed at genesis
* The Foundation Paymaster is operational
* AA mempool and gossip layer are integrated into both the geth and opera (Armchain) clients
* Unit, integration, and end-to-end tests cover the full AA pipeline

The following areas are in active development:

| Area                                      | Status                             |
| ----------------------------------------- | ---------------------------------- |
| Ethers SDK support for AA transactions    | Planned                            |
| Wallet UI for validation scheme selection | Planned                            |
| Block explorer AA transaction indexing    | Planned                            |
| Gas policy review for AA transactions     | Under review                       |
| Falcon validation scheme                  | Pending reliable Go implementation |
| Social login via MPC                      | Under consideration                |

## Further Reading

* [Validation Schemes](/account-abstraction/validation-schemes.md): Supported signing algorithms and how to choose between them
* [Paymaster](/account-abstraction/paymaster.md): How gas sponsorship works and the staking-based economic policy
* [System Contracts](/account-abstraction/system-contracts.md): Protocol-level contracts, Yul implementation, and developer guidance
* [EVM Integration](/architecture/evm.md): EVM opcodes and changes supporting native AA


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.armchain.org/account-abstraction/overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.