Native precompiles
Quantum deploys native protocol precompiles at fixed addresses. Standard precompile gas costs apply when called by smart contracts.
Signature verifiers
Callable by any smart contract for on-chain signature verification.
| Precompile | Address | Purpose |
|---|---|---|
ecrecover | 0x01 | Standard Ethereum ECDSA (secp256k1) recovery. Retained for smart-contract compatibility. |
| P256 Verifier (EIP-7951) | 0x0100 | secp256r1 signature verification for passkey cosigning. EIP-7951 compliant (canonical L1 address). |
| ML-DSA-44 Verifier | 0x1003 | FIPS 204 ML-DSA-44 signature verification. Enables on-chain PQ sig verification for smart contracts, governance, and cross-chain proofs. |
| Falcon-512 Verifier | 0x1004 | Falcon signature verification. Enables smart contracts to verify consensus certificates and validator attestations. |
Protocol precompiles
Account abstraction infrastructure, callable via standard ABI-encoded CALLs.
| Precompile | Address | Purpose |
|---|---|---|
| KeyVault | 0x1000 | Key management: bootstrapKey, addKey, removeKey, updateKeyAuth, getKeys. Enforces approved-primary invariant, lockout protection, and lifecycle-intent binding. |
| NonceManager | 0x1001 | 2D nonce tracking: ValidateAndIncrement(nonce_key, nonce). Per-account, per-queue sequential counters. |
| CryptoSwitchboard | 0x1002 | Read-only runtime algorithm governance: getApprovedPrimary(), getHedgingMode(), isApprovedPrimary(uint8). Genesis-initialized with [ML-DSA-44] as approved primary and normal hedging mode. |
Note: PQ verification in pure EVM costs millions of gas. Implementing verifiers as native precompiles brings the cost to standard precompile-gas territory and makes them composable with normal Solidity tooling. The protocol precompiles are at known addresses read by the node's pre-EVM validation pipeline, which rules out implementing them as upgradeable contracts (circular trust dependency).
0x1000 — KeyVault
The KeyVault precompile is described in detail in KeyVault and key management. Operations:
bootstrapKey()— one-timekey_id = 0creation for accounts with no existing keys. Primary-only.addKey(uint32 keyId, bytes primaryPubkey, uint8 primaryScheme, bytes cosignerPubkey, uint8 cosignerScheme, uint8 permission, bytes scopedData)— requires FullAccess auth + lifecycle intent.removeKey(uint32 keyId)— requires FullAccess auth + lifecycle intent. Enforces min 1 FullAccess key.updateKeyAuth(uint32 keyId, bytes primaryPubkey, uint8 primaryScheme, bytes cosignerPubkey, uint8 cosignerScheme)— self-scoped (auth_key_id == target_key_id).getKeys(address account)— read-only, no auth.
Pre-EVM validation writes auth context (key_id, permission) into a transient storage slot on the precompile. During EVM execution, the precompile reads that slot — not msg.sender — to determine the outer transaction's authorization. This prevents confused-deputy attacks where a malicious contract called by a Scoped key tries to escalate privileges via an internal CALL to KeyVault.
0x1001 — NonceManager
Tracks 2D nonces. When a transaction has nonce_key > 0, pre-EVM validation calls the NonceManager:
ValidateAndIncrement(nonce_key, nonce)— verifies that the suppliednoncematches the precompile's stored counter for(sender, nonce_key), then increments.
When nonce_key == 0, the standard sequential account nonce applies — NonceManager is not consulted. This preserves backward compatibility for simple flows.
The protocol enforces a hard cap on active queues per account and replacement-by-fee rules within each queue to prevent state bloat.
0x1002 — CryptoSwitchboard
Read-only at runtime. Genesis-initialized. See CryptoSwitchboard and crypto-agility for the full semantics including staged deprecation and emergency mode.
Read by:
- The KeyVault precompile at
addKeytime to enforce that the primary scheme is on the approved-primary list. - The consensus multiplexer at each block to route validator signing and verification.
- The mempool validator to determine whether to accept new transactions referencing a particular scheme.
0x1003 — ML-DSA-44 Verifier
FIPS 204 verification, callable from smart contracts. Standard precompile gas cost applies. Useful for:
- On-chain governance with PQ-signed votes.
- Cross-chain proofs where the proof carries an ML-DSA signature.
- Application-layer signatures verified by Solidity contracts.
0x1004 — Falcon-512 Verifier
Falcon verification, callable from smart contracts. Enables contracts to verify consensus certificates and validator attestations (e.g., for light-client style verification within a contract).
Related
- KeyVault and key management — the full operation list and safety invariants
- CryptoSwitchboard and crypto-agility — runtime algorithm governance
- Transaction and block lifecycle — where each precompile is invoked along the path