Every standard Kadena account is protected by an Ed25519 key. A large enough quantum computer could break that key from public information alone. The community has already written the replacement: hash-based SLH-DSA signatures and a new q: account type. This page shows how it works, what it costs, and how close it is to mainnet.
A k: account is literally the letter k followed by your 64-character Ed25519 public key. That key is visible to everyone from the moment the account exists. Shor's algorithm, run on a cryptographically relevant quantum computer, can derive the private key from it. Switch the view to see what changes with a post-quantum account.
Example keys are illustrative. Format rules come from Pact 5's Guards.hs and Principal.hs: a post-quantum key is the letter q followed by 64, 96 or 128 lowercase hex characters.
| Prefix | Guard | Signature | Quantum-safe |
|---|---|---|---|
| k: | One key, keys-all | Ed25519 | No |
| w: | Multisig keyset (hash of keys + predicate) | Ed25519 / WebAuthn | No |
| q: | One SLH-DSA key, keys-all | SLH-DSA (FIPS 205) | Yes |
| x: | Multisig where every key is SLH-DSA | SLH-DSA (FIPS 205) | Yes |
A mixed multisig that holds any Ed25519 key stays a w: account. Only an all-post-quantum keyset earns the x: prefix, because one classical key would reopen the door.
The wallet creates an SLH-DSA key. Three strengths are supported: SHA2-128s, 192s and 256s (32, 48 or 64-byte public keys).
The public key in hex, prefixed with q, becomes the q: account. Anyone can send KDA to it with transfer-create.
As today, the transaction is hashed with Blake2b. The signature covers that hash, not the raw payload.
The wallet signs the hash in FIPS 205 pre-hash mode with the fixed context string CHAINWEB, so a signature made for Kadena cannot be replayed on another system.
The signature travels base64url-encoded, tagged with a scheme such as SLH-DSA-SHA2-128s instead of ED25519.
The node checks the signature and charges gas for its size and for the verification work. Security now rests only on hash functions, which quantum computers can weaken but not break.
SLH-DSA signatures are large. The bars below are drawn to the same scale: an Ed25519 signature is 64 bytes, while the smallest SLH-DSA option is 7,856 bytes, about 123 times bigger.
Chainweb 3.2 introduced an initial gas model that charges for transaction size before Pact runs. This estimator applies that model's published formula. It covers only the up-front initial gas, not the gas for executing your Pact code.
Formula from InitialGasModel.hs: 0.01 gas per payload byte, plus 0.01 gas per signature byte, plus a size penalty of (size cost ÷ 512)7, plus a verification charge per signer. Ed25519 is 21 gas (live since 3.2). SLH-DSA charges of 816, 1,584 and 3,992 gas are early benchmark figures (2.04, 3.96 and 9.98 ms) from the draft Chainweb 3.3 gas model in PR #44. They are not final and will likely change before release. Signature bytes assume the {"sig":"…"} JSON encoding: 128 hex characters for Ed25519, unpadded base64url for SLH-DSA. Example payload and gas price are illustrative inputs.
Full production means anyone can create a q: account, receive and spend KDA from it with a normal wallet, on mainnet, after miners activate the upgrade. The score below weighs nine milestones by how much of the remaining work each one represents, then credits each one by what the GitHub record shows: merged and released code counts fully, open or draft pull requests count partly, and plans count little. Each milestone is also tied to concrete GitHub events (a pull request merged, a release tagged, a TODO removed from a file); a job on the Kadena Nexus server checks for them hourly and moves the bar up automatically when they happen.
| Milestone | Weight | Evidence on GitHub | Done |
|---|
GitHub facts as of Oct 9, 2026 (static snapshot)
Not an official roadmap. The weights are fixed; the scores move only when the linked GitHub or mainnet event happens, and never move down. The final milestone is read from the live fork number on a Kadena mainnet node.