Skip to main content

CryptoSwitchboard and crypto-agility

Existing chains are locked to one cryptographic scheme. If that scheme breaks, there's no fallback — only a contentious hard fork and years of social coordination. Quantum's answer is pre-baked algorithms plus state-driven routing: multiple signature algorithms compiled into every node binary at build time, with an on-chain switchboard controlling which are active.

CryptoSwitchboard precompile​

Read-only runtime algorithm governance, deployed at 0x1002. Genesis-initialized.

CallReturns
getApprovedPrimary()The list of scheme bytes currently accepted as primary in new KeyEntries
getHedgingMode()The current consensus hedging mode (normal, dual-sign, …)
isApprovedPrimary(uint8)bool — convenience predicate for KeyVault

The switchboard is initialized at genesis with [ML-DSA-44] as the approved primary and normal hedging mode. Read by the KeyVault precompile at addKey time and by the consensus multiplexer at each block.

How it works​

  1. Fat validator keychain. When validators register, they submit keys for every algorithm baked into the binary. The network is always pre-positioned for a switch.
  2. On-chain switchboard. The CryptoSwitchboard precompile (0x1002) holds the active configuration. The consensus side reads which algorithms are active for validator signing (e.g., [Falcon] normal, [Falcon, SLH-DSA] emergency dual-sign). The userland side reads the approved-primary list for KeyVault entries (e.g., [ML-DSA-44]). KeyVault enforces this list at addKey time — you cannot register a key whose primary scheme isn't on the list.
  3. Consensus multiplexer. At each block, the consensus layer reads the switchboard state and routes signing and verification through the required algorithms.
  4. Mempool routing. The node monitors the switchboard. If an algorithm is deactivated for new key registrations, pending transactions using only that algorithm remain valid during the grace period. Once the algorithm is fully deactivated for signing, pending transactions are invalidated.

Rotating among pre-baked algorithms is a governance transaction, not a code deployment. Adding a net-new algorithm family (a future NIST standard not already in the binary) requires a coordinated client update — but once the binary ships, activation is atomic and fork-free.

Staged deprecation​

Algorithm deprecation is a two-phase process to prevent bricking accounts with keys in cold storage:

  • Phase A — Registration freeze. The algorithm is removed from the allowed_for_new_keys list. No new KeyEntry can use it as a primary. Existing accounts can still sign normally and have a long grace period (months) to rotate keys.
  • Phase B — Signing deactivation. After the grace period, the algorithm is removed from the allowed_for_signing list. Accounts that have not rotated can no longer transact.

This staged approach gives cold-storage holders and institutions time to rotate.

Emergency mode​

For true emergencies — when an algorithm is actively broken and forgeable — governance can skip the grace period. During emergency, accounts without pre-positioned cold-vault keys (ML-DSA primary + SLH-DSA cosigner) are at risk. This is why the protocol encourages the cold-vault profile for high-value custody — it provides a covered escape hatch even if the lattice family breaks.

Consensus hedging (research, post-mainnet)​

Hash-based dual-signing at the consensus layer — e.g., validators SLH-sign periodic checkpoints — is under evaluation as a mechanism for producing long-horizon finality proofs that remain verifiable even if lattice confidence collapses. This is relevant for bridges, auditors, and cross-chain verification.

SLH-DSA signatures are 7,856 bytes per validator. Any practical checkpoint-hedging design would need to be low-frequency (daily / weekly, not per-epoch), committee-based (small subset of validators), or off-chain-published (gossiped and archived, with only the checkpoint hash anchored on-chain). This remains a research item and is not part of v1.

Design rationale​

Two reasons for this architecture over a hardcoded scheme. First, the systems-engineering argument: separating algorithm choice from binary release means the chain can rotate without a hard fork. Second, the operational argument: PQ standards are young — ML-DSA was finalized in August 2024, Falcon is in draft. The probability that one of these will need to be deprecated in the next decade is non-trivial. A chain that can rotate by governance transaction has options; a chain that can't, doesn't.