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: Supported signing algorithms and how to choose between them

• Paymaster: How gas sponsorship works and the staking-based economic policy

• System Contracts: Protocol-level contracts, Yul implementation, and developer guidance

• EVM Integration: EVM opcodes and changes supporting native AA