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
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.
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 for details.
Choosing a 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: How gas sponsorship works alongside validation
System Contracts: How validation schemes are implemented at the protocol level
ML-DSA44 Deep Dive: Full specification for the MLDSA algorithm
PQC Overview: Background on post-quantum cryptography on Armchain
Last updated