Ori Newman's idea for keeping your public key hidden until you spend moved fast. Within days, people were already sending coins to the new addresses on mainnet (example). The rulebook behind them hasn't caught up yet. The part that tells a wallet where to find these coins from your recovery phrase is still being decided.
A quick reminder of why this matters. A normal Kaspa address shows its public key to anyone who looks. A powerful enough quantum computer could one day work backwards from that key to the private key. The new addresses show only a fingerprint of the key until you spend (our earlier report).
Europol, the EU's police agency, put the risk bluntly in a recent report. Its warning is that "once a public key is exposed, it remains permanently vulnerable to future quantum decryption" (Europol).
From network proposal to wallet rulebook
Ori first published the idea as KIP-22. KIPs are Kaspa Improvement Proposals, usually for changes to the network itself. This one needs no network change at all. Since it stays a wallet convention, IzioDev suggested making it a KCC instead, a shared rulebook for wallets and apps, and Ori agreed (R&D chat).
Gaurav Rana, known as BitcoinsSG, had suggested a similar idea earlier, without the part about key paths, and joined as co-author (R&D chat). Ori also explained the reason for writing it in the first place. "I saw many ppl like you searching and implementing solutions, and I wanted to write a canonical solution for it" (Ori Newman).
Why these accounts get their own path
Your recovery phrase can create an endless number of addresses. A wallet finds yours by following a path, a bit like a street address for keys. The draft gives hidden-key accounts a path of their own, separate from normal accounts.
That separation isn't cosmetic. Ori explained that without it, a normal wallet "might expose the public keys" of the hidden-key one (R&D chat). Aglovale added that if someone has 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 (R&D chat).
IzioDev, who is trying out a first version for the Rusty Kaspa wallet, wants the same thing from the other side. "I don't want to mistakenly use my p2pkh account and emit p2pk changes for example." P2PKH is the hidden-key kind, P2PK the normal kind (R&D chat).
The number isn't settled yet
The first draft put these accounts under 22'. When Ori moved the proposal to the KCC track, that number became a placeholder, XXXX', with a note to change it once the KCC number is decided (draft). It still isn't decided.
Ori first assigned the proposal KCC-3 (KCC chat). KCC-3 has since become a wider plan for how wallets organise keys, written by IzioDev with Ori (pull request). 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 (KCC chat). The hidden-key rulebook is meant to follow on top of it as its own KCC (KCC chat).
The two worked it out in the open. When Ori first suggested a way to separate 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 talking it through, IzioDev agreed that the signature type would best be part of the path itself. "I'm aligned with you," IzioDev wrote (KCC chat). They settled on adding it only for new account types.
IzioDev then wrote KCC-3 "as discussed with Ori", and Ori thanked IzioDev "for the writing and the fruitful discussion" (KCC chat). Ori's review on GitHub asks for a tidy-up, keeping 44' and 45' out of it and moving the multisig parts into a follow-up KCC. IzioDev replied that it "sounds good" (review, KCC chat). A wallet developer has also 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 (GitHub).
What this means if you already use one
Wallets that moved early use the first draft's 22' path (example). If the final rulebook gives hidden-key accounts a different number, a wallet that only follows the final version won't look under 22'. Restore your recovery phrase there, and the balance can show zero.
Your coins aren't lost in that case. They're still there under 22', and any wallet that supports that path can find them again. It's just an unpleasant surprise nobody needs.
So if you're trying these addresses now, keep it simple.
- Stay with the wallet that made the address until the rulebook 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, don't use it again. Spending reveals the key, so it isn't hidden anymore.
- Don't share your account's extended public key, the master key some apps ask for to watch a balance. It gives away every public key in the account (draft).
These addresses are easy to spot. They start with kaspa:p instead of the usual kaspa:q.
How much does it really help?
Hans Moog, who works on vprogs, personally doubts quantum computers will ever break public-key cryptography at realistic key sizes. Still, 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 when you spend. Your key is visible while the transaction confirms, so an attacker would need a quantum computer fast enough to crack it in that window. "On Kaspa, that means just a few seconds," Moog wrote.
Ori believes Kaspa will eventually add native support for post-quantum signatures, and calls this "only the first step" (Ori Newman).
Hidden-key addresses will probably become normal. Until the number is final, the safest choice is the boring one. Stay with the wallet that made the address.
Telegram sources link to public messages in the Kaspa Core R&D (public) channel and the KCC Synchronous Communication group.
