> 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/validation-schemes.md).

# Validation Schemes

Armchain's native AA framework allows accounts to validate transactions using different cryptographic schemes. Each scheme is implemented as a system contract deployed at genesis. The architecture is modular: developers can add new validation logic by following the same contract interface.

## Supported Schemes

| Scheme      | Algorithm                     | Use Case                                                           | Status    |
| ----------- | ----------------------------- | ------------------------------------------------------------------ | --------- |
| **MLDSA**   | ML-DSA44 (FIPS 204)           | Post-quantum signing, same as standard Armchain transactions       | Available |
| **Passkey** | P-256 (ECDSA over secp256r1)  | WebAuthn, biometric devices (Touch ID, Face ID, hardware keys)     | Available |
| **SLH-DSA** | SLH-DSA / SPHINCS+ (FIPS 205) | Hash-based post-quantum, different security assumptions from MLDSA | Available |
| **MPC**     | ECDSA (secp256k1) via MPC     | Multi-party computation, Guardian accounts, social recovery        | Available |
| **Falcon**  | Falcon (NIST PQC)             | Lattice-based post-quantum, compact signatures                     | Pending   |
| **Custom**  | Developer-defined             | Any validation logic following the AA system contract interface    | Available |

***

## MLDSA

**ML-DSA44** (Module-Lattice Digital Signature Algorithm, FIPS 204) is Armchain's native signing algorithm for standard transactions. It is also available as a validation scheme for AA accounts.

An MLDSA AA account is controlled by an ML-DSA44 key pair. This is appropriate when the owner wants post-quantum security and is already using the Armchain tooling, or when migrating from a standard EOA to a smart account while keeping the same signing key type.

* **Security**: Post-quantum (\~128-bit security, NIST Category 2)
* **Key size**: 1,312-byte public key, 2,560-byte private key
* **Signature size**: 2,420 bytes

> For the full ML-DSA44 specification used by Armchain, see [ML-DSA44 Deep Dive](/pqc/mldsa44.md).

***

## Passkey (P-256 / WebAuthn)

The **Passkey** validation scheme uses **P-256** (ECDSA over secp256r1 / NIST P-256), the cryptographic algorithm underlying the WebAuthn standard. WebAuthn is supported natively by modern browsers (Chrome, Safari, Firefox) and operating systems.

This enables users to control a blockchain account using:

* **Biometric authentication**: Touch ID on MacBook, Face ID on iPhone, fingerprint readers on Android
* **Hardware security keys**: YubiKey and similar FIDO2 devices
* **Platform authenticators**: Windows Hello, iCloud Keychain

The passkey flow is familiar to users from web authentication: no seed phrase to manage, no separate private key to store. The signing key is generated and stored by the device's secure enclave or hardware authenticator.

> **Note**: P-256 is not quantum-resistant. The Passkey scheme trades off post-quantum security for maximum user-friendliness and hardware compatibility. For accounts where long-term quantum resistance matters, use MLDSA or SLH-DSA instead.

* **Standard**: WebAuthn / FIDO2 (W3C), NIST P-256 curve
* **Use case**: Consumer-facing dApps, biometric login, zero-seed-phrase onboarding
* **Browser support**: Chrome, Safari, Edge, Firefox (all modern versions)

***

## SLH-DSA (SPHINCS+)

**SLH-DSA** (Stateless Hash-Based Digital Signature Algorithm, FIPS 205), formerly known as SPHINCS+, is a post-quantum signature scheme standardized by NIST alongside ML-DSA.

Where MLDSA is based on the hardness of the Module Learning With Errors (MLWE) problem (a lattice assumption), SLH-DSA is based entirely on the security of hash functions. This gives it a different security profile: it does not depend on any lattice hardness assumption, making it a useful hedge for scenarios where the underlying assumption of MLDSA is ever questioned.

* **Security**: Post-quantum, hash-based (no lattice assumptions)
* **NIST Standard**: FIPS 205
* **Trade-off**: Larger signatures than MLDSA; slower signing; simpler security analysis

SLH-DSA is appropriate for high-assurance accounts where diverse cryptographic assumptions are a priority, such as long-lived treasury or governance accounts.

***

## MPC for ECDSA (Guardian Accounts)

The **MPC** scheme enables AA accounts controlled through **Multi-Party Computation over ECDSA (secp256k1)**. The on-chain validation logic verifies ECDSA signatures in the standard secp256k1 format, while the signing keys are managed off-chain through an MPC protocol that splits the private key across multiple parties.

No single party ever holds the complete private key. This enables:

* **Social recovery**: Account access can be recovered through a trusted set of guardians without any single guardian knowing the full key
* **Threshold signing**: M-of-N approval schemes for organizational wallets
* **Institutional custody**: Enterprise-grade key management with separation of duties

These accounts are referred to internally as **Guardian accounts**. The Guardian contract handles deployment, counterfactual address prediction, and execution of validated calls.

> **Note on social logins**: Social login (using OAuth providers like Google or Apple as account recovery) is architecturally possible via MPC but requires operating MPC infrastructure. This is under consideration as a future Armchain feature and is not currently available.

***

## Falcon (Pending)

**Falcon** is a lattice-based post-quantum signature scheme selected by NIST during the PQC standardization process. It produces smaller signatures than both MLDSA and SLH-DSA, which is advantageous for bandwidth-constrained environments.

Falcon support is not yet available on Armchain. A reliable, production-ready Go implementation has not been identified at this time. This scheme will be added once a suitable implementation is available.

***

## Custom Validation Schemes

The AA validation framework is intentionally modular. Developers can implement their own account validation logic by conforming to the system contract interface. Examples of what custom schemes can express:

* Multi-signature with an arbitrary threshold
* Time-locked transactions
* Allowlists of approved callers
* Hybrid schemes combining multiple signing algorithms

> **Important**: Custom validation contracts must currently be written in **Yul** (the EVM intermediate representation language). The AA system contracts introduce new EVM opcodes that the standard Solidity compiler (`solc`) does not yet recognize. Any contract that uses these opcodes for account validation or paymaster logic must be written at the Yul level until compiler support is added. See [System Contracts](/account-abstraction/system-contracts.md) for details.

***

## Choosing a Scheme

| Priority                                | Recommended Scheme                          |
| --------------------------------------- | ------------------------------------------- |
| Maximum quantum resistance              | MLDSA or SLH-DSA                            |
| Diverse post-quantum assumptions        | SLH-DSA (hash-based, no lattice dependency) |
| Consumer UX, biometric login            | Passkey (P-256 / WebAuthn)                  |
| Organizational custody, social recovery | MPC (Guardian account)                      |
| Compact signatures (future)             | Falcon (pending)                            |
| Custom logic                            | Custom (Yul contract)                       |

For most users, **MLDSA** offers the best combination of post-quantum security, tooling support, and performance. **Passkey** is the best choice for consumer products targeting mainstream users who should not need to manage seed phrases.

## Further Reading

* [Paymaster](/account-abstraction/paymaster.md): How gas sponsorship works alongside validation
* [System Contracts](/account-abstraction/system-contracts.md): How validation schemes are implemented at the protocol level
* [ML-DSA44 Deep Dive](/pqc/mldsa44.md): Full specification for the MLDSA algorithm
* [PQC Overview](/pqc/overview.md): Background on post-quantum cryptography on Armchain


---

# 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/validation-schemes.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.