KIP-22, Ori Newman's proposal for addresses that keep the public key hidden until you spend, moved from idea to mainnet in days. Users are already sending coins to the new address type on Kaspa mainnet — and the rulebook that tells any wallet how to recover those coins from a recovery phrase is still being written. For self-custody users, that gap between adoption and specification is the story.
What KIP-22 changes
A normal Kaspa address shows its public key to anyone who looks. A sufficiently powerful quantum computer could, in principle, work backwards from that public key to the private key. The new address type shows only a fingerprint of the key until the moment you spend. The relevant external pressure is not hypothetical: Europol, the EU's police agency, warned in a recent report that "once a public key is exposed, it remains permanently vulnerable to future quantum decryption".
The addresses are easy to tell apart — they start with kaspa:p rather than the usual kaspa:q.
A hidden-key address (P2PKH) publishes a hash of the public key instead of the key itself. The public key is revealed only in the spending transaction, which shortens the window in which it can be targeted. A normal Kaspa address (P2PK) shows the key from the start.
From network proposal to wallet rulebook
Ori first published the idea as KIP-22 — Kaspa Improvement Proposals being the usual track for changes to the network itself. But KIP-22 needs no network change at all. Because it is a convention about how wallets and apps handle keys, IzioDev suggested moving it to the KCC track instead, a shared rulebook for wallets and apps, and Ori agreed.
Gaurav Rana, known as BitcoinsSG, had suggested a similar idea earlier — without the part about key paths — and joined as co-author. Ori's stated motivation was practical rather than promotional: "I saw many ppl like you searching and implementing solutions, and I wanted to write a canonical solution for it". In other words, the proposal exists to stop a dozen incompatible implementations from quietly diverging.
Why hidden-key accounts get their own path
One recovery phrase can generate an endless number of addresses. A wallet finds yours by following a derivation path — effectively a street address for keys. The draft gives hidden-key accounts a path of their own, separate from normal accounts, and that separation is not cosmetic.
Ori explained that without it, a normal wallet "might expose the public keys" of the hidden-key account. Aglovale added a sharper version: if you have already shared the extended public key of a normal account, every key under it is already exposed, so a hidden-key address on that same branch would be exposed before it was ever spent. Ori agreed.
From the wallet side, IzioDev wanted the same separation to prevent mistakes in the opposite direction: "I don't want to mistakenly use my p2pkh account and emit p2pk changes for example." A wallet that mixes the two modes would spend from a hidden-key account and leak a key it was supposed to keep quiet.
The number is not settled
This is the part early users need to read twice. The first draft put hidden-key accounts under 22'. When the proposal moved to the KCC track, that number became a placeholder — XXXX' — with a note to change it once the KCC number is decided. It still is not decided.
Ori initially assigned the proposal KCC-3. KCC-3 has since become a wider plan for how wallets organise keys, written by IzioDev with Ori. It adds a level for the type of signature, but only for new kinds of accounts: the paths wallets use today, 44' and 45', stay as they are. The hidden-key rulebook is meant to follow on top of that as its own KCC.
The two worked it out in the open. When Ori first suggested separating signature types on the existing paths, IzioDev pushed back: "I'm not a fan of introducing yet another legacy wallet path. People are already lost and we only made one breaking change." After discussion, IzioDev agreed the signature type should be part of the path itself — "I'm aligned with you" — but only for new account types. Ori's review on GitHub then asked for a tidy-up: keep 44' and 45' out of it, and move the multisig parts into a follow-up KCC. IzioDev replied that it "sounds good". A wallet developer has separately documented how today's Rusty Kaspa multisig wallets order their keys, and offered to write it up so the follow-up can point to it for recovery.
The early-adopter trap
Wallets that moved early use the first draft's 22' path. If the final rulebook gives hidden-key accounts a different number, a wallet that only follows the final version will not look under 22'. Restore your recovery phrase in such a wallet and the balance can show zero.
Your coins are not lost in that case. They are still there under 22', and any wallet that supports that path can find them again. It is an unpleasant surprise, not a loss event — but for a self-custody user, a zero balance after a restore is exactly the kind of shock that causes panicked, irreversible decisions.
Practical rules while the rulebook is open:
- Stay with the wallet that generated the hidden-key address until the KCC is final.
- Keep your recovery phrase safe, and keep the wallet's own backup if it has one.
- After you spend from a hidden-key address, do not use it again — spending reveals the key, so it is not hidden anymore.
- Do not share your account's extended public key, the master key some apps request in order to watch a balance. It gives away every public key in the account.
The habits above are ordinary self-custody hygiene, and they are the same ones we design for: Kaspa Safe is a non-custodial on-chain vault where the contract, not a service, holds your KAS, the owner chooses the withdrawal delay, and an alarm key can cancel a theft in flight. Whatever wallet holds your hidden-key address, keep its backup and your recovery phrase together until the rulebook lands — details in how the vault works.
How much does it actually help?
Honest scepticism is part of the discussion. Hans Moog, who works on vprogs, personally doubts quantum computers will ever break public-key cryptography at realistic key sizes. Even so, Moog called KIP-22 "a really simple and inexpensive way to significantly reduce the quantum threat to Kaspa users", while adding that it "isn't a 'complete' post-quantum solution".
The weak moment is the spend. Your key is visible while the transaction confirms, so an attacker would need a quantum computer fast enough to crack it inside that window. "On Kaspa, that means just a few seconds," Moog wrote. That is a structural advantage of Kaspa's block times, and it is worth stating plainly: the same property that makes confirmation fast also shrinks the exposure window, but it does not shrink it to zero.
Ori believes Kaspa will eventually add native support for post-quantum signatures, and calls this convention "only the first step". Hidden-key addressing is a mitigation that any wallet can adopt today without a fork — not a finished answer to the question.
What it means for KAS holders
For holders, KIP-22 is a low-cost upgrade in hygiene: if you do not publish your public key, long-term exposure is reduced for addresses you have not spent from. For miners and operators who have shared extended public keys for accounting, watch-only setups or multisig coordination, the trade-off is sharper — those keys expose everything beneath them, so a hidden-key address placed on an already-shared branch gains you nothing.
The open question is exactly the one in the headline: recovery-phrase discovery. An address convention is only as good as the wallet ecosystem's ability to find it again five years from now, and the derivation number is still a placeholder. Until the KCC is fixed, the safest behaviour is boring — same wallet, good backups, no address reuse, no extended public key sharing.
If you keep your own keys, that boring part is the whole job. Tools like Kaspa Safe and the rest of the Kaspa Forge architecture exist to make the boring part harder to get wrong, not to replace the discipline.
Continue exploring
Desk key and encrypted-profile model
Next useful step: open the encrypted Desk
FAQ
What is a KIP-22 hidden-key address?
It is a Kaspa address that shows only a fingerprint (a hash) of the public key instead of the public key itself. The key is revealed only when you spend. Such addresses start with kaspa:p instead of the usual kaspa:q.
Does KIP-22 require a network upgrade?
No. It needs no network change at all. It is a wallet convention, which is why it is being written as a KCC — a shared rulebook for wallets and apps — rather than as a network-level KIP.
Why could my balance show zero after restoring my recovery phrase?
Early wallets derive hidden-key accounts under the draft path 22'. If the final rulebook assigns a different number, a wallet that follows only the final version will not look under 22'. The coins are still there; any wallet that supports that path can find them again.
Is hidden-key addressing a complete post-quantum solution?
No. Hans Moog called it "a really simple and inexpensive way to significantly reduce the quantum threat to Kaspa users" while stressing it "isn't a 'complete' post-quantum solution". The key is exposed while a spend confirms — on Kaspa, a few seconds.
What should I do if I try these addresses now?
Stay with the wallet that generated the address until the rulebook is final, keep your recovery phrase and any wallet backup safe, never reuse a hidden-key address after spending from it, and never share your account's extended public key.
Put your KAS where theft can be cancelled
A covenant vault on Kaspa mainnet: your keys, your rules, our tooling. Free on-chain, forever.
Create a vault