Native account abstraction

Quantum implements Native AA in the node's transaction parsing layer — not in EVM opcodes, and not in application-layer bundler infrastructure. Every account is a smart account by default, and every signature is verified at the protocol level before EVM execution.

Why not ERC-4337, EIP-7702, or EIP-8141?

Alternative	Why we didn't pick it
ERC-4337	UserOperations, off-chain bundlers, and gas-heavy proxy smart contracts. Useful for chains stuck with ECDSA; dead end for a new L1.
EIP-8141 (Frame Transactions)	Theoretical ideal but introduces unsolved mempool DoS vectors (arbitrary code execution in the validation frame). Too risky for production today.
EIP-7702	Still requires ECDSA at the outermost authorization layer. Fundamentally incompatible with PQ-by-default.

Quantum's approach: a custom EIP-2718 transaction type (0x7A) interpreted directly by the node.

The composite transaction envelope

Reference: The full precompile addresses and call shapes are in Native precompiles.

Transaction fields (EIP-2718 type 0x7A)

Field	Type	Notes
chain_id	u64	Chain identifier
sender	Address	Explicit sender — ML-DSA is non-recoverable, unlike ECDSA ecrecover
nonce_key	u256	2D nonce: queue ID (0 = legacy sequential)
nonce	u64	2D nonce: sequence within the queue
key_id	u32	References a KeyEntry in the sender's KeyVault
max_priority_fee_per_gas	u128	EIP-1559-style priority fee
max_fee_per_gas	u128	EIP-1559-style max fee
gas_limit	u64	Gas limit for EVM execution
calls	Vec<Call>	Batched calls, atomically executed
access_list	AccessList	EIP-2930 access list
fee_payer	Option<Address>	Gas sponsor (None = sender pays)
fee_payer_key_id	Option<u32>	Fee payer's key reference
fee_payer_signature	Option<CompositeSignature>	Fee payer's composite signature
init_primary_pubkey	Option<Bytes>	Raw pubkey for explicit bootstrap registration (bootstrapKey() only)
init_cosigner_pubkey	Option<Bytes>	Reserved — must be absent during bootstrap (primary-only)
primary_signature	SigningKeySignature	Mandatory primary signature
cosigner_signature	Option<SigningKeySignature>	Optional cosigner signature

Each call in the calls list has a to (Call or Create), value, and input.

Signature schemes

Scheme	Tag	Pubkey	Signature	Wire total
ML-DSA-44 (FIPS 204)	0x01	1,312 B	2,420 B	3,733 B
P256 (secp256r1)	0x02	64 B	64 B	129 B
ECDSA (secp256k1)	0x03	33 B	64 B	98 B
SLH-DSA	0x04	32 B	7,856 B	7,889 B

How composite signatures work

Every transaction references a key_id from the sender's on-chain KeyVault. The node looks up the corresponding KeyEntry, which defines which signatures are required:

• The primary_signature is always verified against KeyEntry.primary. The primary scheme must be on the switchboard's approved-primary list (today: [ML-DSA-44]).
• If KeyEntry.cosigner is Some, the node also verifies cosigner_signature against that public key. If the KeyEntry has no cosigner, cosigner_signature must be None.

Key principle. The primary signature is the lock. The cosigner is a convenience and compatibility layer — not a security dependency. If the cosigner is absent, the transaction is still fully PQ-secure. If it is present, users get both seamless UX and defense-in-depth. The naming is deliberately generic (primary / cosigner rather than pq / classical) because today's PQ scheme may become tomorrow's default.

Account profiles

• Profile A — Retail / Mobile. ML-DSA-44 primary + P256 (secp256r1) cosigner via the RIP-7212 precompile. Users authenticate with Apple or Android FaceID. No seed phrases, no browser extensions. The passkey handles the familiar UX; ML-DSA handles the security. Checkout feels identical to Apple Pay.
• Profile B — Institutions and hardware wallets. ML-DSA-44 primary + ECDSA (secp256k1) cosigner. Custodians like Fireblocks, Coinbase Prime, and Copper have spent years building ECDSA MPC networks; Quantum lets them plug their existing pipeline in as the cosigner and add an ML-DSA signer alongside. Integration drops from an estimated 18 months to a quarter because the legacy infrastructure stays intact.
• Profile C — PQ-only. ML-DSA-44 primary alone, no cosigner. For users and applications that don't need classical compatibility.

Why this isn't "hybrid security"

Other chains propose hybrid cryptography as a migration crutch — ECDSA stays required, PQ is optional. Quantum inverts this. The primary is required. The cosigner is optional. The cosigner exists because passkeys make great UX, because hardware wallets are how whales store funds, and because custodians have infrastructure they shouldn't have to throw away. It is convenience and compatibility, not a security dependency.

Protocol-level primitives

• Batched transactions. The calls: Vec<Call> field allows multiple EVM calls in a single transaction, executed atomically via checkpoint / revert. Only the first call may be a CREATE; subsequent calls must be CALL. Patterns like "approve + swap + revoke" complete in one transaction.
• Native gas sponsorship. A fee_payer field carries a sponsor's composite signature (primary + optional cosigner, same PQ-by-default invariant). Both sender and fee payer sign the canonical tx_intent_hash — a typed hash of all execution-affecting fields excluding all signature blobs — with different domain separators (QuantumSender vs QuantumFeePayer). The sponsor relay is a stateless signing proxy with a policy check, not an ERC-4337 bundler. No EntryPoint, no UserOperation, no bundler. The transaction is a real L1 transaction with normal receipts and tooling compatibility.
• Pre-EVM verification. Transaction-level composite signature verification happens at the protocol level before EVM execution. No EVM gas is charged for transaction authorization. This is distinct from verifier precompiles (ML-DSA-44, P256, Falcon-512), which are callable by smart contracts and charge standard precompile gas.
• Zero proxy deployment fees. Account abstraction is in the transaction envelope and key management is handled by native precompiles, so users do not pay EVM gas to deploy proxy smart contracts. A user's first interaction with the chain is a single atomically-secure composite transaction.
• Parallel mempool scaling (2D nonces). Following the RIP-7712 specification, Quantum implements (nonce_key, nonce) pairs. When nonce_key == 0, the standard account nonce applies; when nonce_key > 0, the NonceManager precompile tracks an independent sequential counter for that queue. Institutional custodians and native paymasters can process thousands of sponsored or threshold-signed transactions in parallel. A per-account cap on active queues plus replacement-by-fee rules keep state bloat in check.

Key rotation and crypto migration

Addresses on Quantum derive from the initial ML-DSA pubkey hash at account creation. The KeyVault decouples the address from the current signing keys: the protocol validates transactions by looking up the account's KeyVault in state, not by re-deriving the address from the signer's pubkey. Signature verification uses verify_detached() — load the stored public key by key_id and verify against the detached signature bytes.

Key rotation is AddKey(new) → verify it works → RemoveKey(old). Each operation is a separate transaction. The address, assets, token approvals, and all on-chain references stay the same.

This makes cryptographic migration trivial. If a new signature scheme replaces ML-DSA-44 on the switchboard's approved-primary list, users add a key with the new scheme and remove the old one. No address change, no asset migration, no broken contract ACLs. See KeyVault and key management for the full set of operations.

Cold vault profile (lattice hedge)

For high-value accounts wanting defense against a lattice-family break, a KeyEntry can have primary = ML-DSA-44 and cosigner = SLH-DSA (both required). No new policy machinery — this is a standard composite KeyEntry where the cosigner happens to be hash-based rather than classical. SLH-DSA signatures are 7,856 bytes, so this profile is designed for rare high-value operations, not everyday transactions. SLH-DSA verification ships in the node's native tx-auth path; an EVM precompile is deferred until a concrete smart-contract use case appears.

Related

• KeyVault and key management — every lifecycle operation and the permissions matrix
• Native precompiles — addresses, gas costs, and call shapes
• Transaction and block lifecycle — the full propose / verify / notarize / finalize flow