Every standard Kaspa address shows its owner's public key to anyone who looks. Ori Newman, who maintains the main Kaspa node software, has published a draft called KIP-22 that would change that for anyone whose wallet adopts it. The key would stay hidden behind a short fingerprint until the owner spends (KIP-22 draft).
The reason is quantum computers. None exists today that can break the signatures Kaspa uses, but a large enough one could work out a private key from a public key. The plan needs no network upgrade. Kaspa already accepts the kind of address it uses, and every wallet can already send to it.
Why a visible public key matters
A Kaspa wallet holds a private key, which it uses to sign payments, and a public key, which lets everyone else check those signatures. Working backwards from the public key to the private key is practically impossible for today's computers. A powerful quantum computer running Shor's algorithm could do it, and then it could sign payments as if it were the owner.
That makes timing important. A standard Kaspa address, the kind that starts with kaspa:q, is the public key itself, written in a different format. The key is out in the open from the moment the address first receives coins, and it stays that way for as long as the coins sit there. Solana addresses work the same way, and so do Bitcoin's newer Taproot addresses.
Older Bitcoin addresses took a different route. They hold only a hash of the public key, a short fingerprint that can't be turned back into the key. The key itself appears only when the owner spends. Ethereum accounts are similar, because the key appears with the first payment an account sends. KIP-22 gives Kaspa users the same kind of address.
A familiar trick with existing tools
Kaspa has no address type that holds a hashed public key. It does have pay-to-script-hash, or P2SH, which locks coins to the fingerprint of a short program called a script. Whoever spends the coins has to show the script, and the script has to approve the payment.
KIP-22 uses the simplest possible script. It contains the public key and one instruction that checks the signature against it. Until the coins are spent, the only thing the network sees is the fingerprint of that script, so the key stays hidden.
You can see the difference in the address itself. The first letter after kaspa: shows what kind of address it is. A normal address, the kind almost everyone uses today, starts with kaspa:q, and the rest of it is the owner's public key, readable by anyone. A KIP-22 address starts with kaspa:p, the letter Kaspa uses for script addresses, and the rest of it is only the fingerprint of the script. Anyone can send coins to either kind. The difference is that a kaspa:q address shows the public key from the first day, while a kaspa:p address keeps it hidden until the coins are spent.
The draft also fixes how wallets create these addresses from a recovery phrase. It uses a separate branch, m/22'/111111'/..., next to the usual one, so a wallet can keep these accounts apart from ordinary ones and find them again after a restore. The cost is a few dozen extra bytes when spending, because the transaction has to include the script. That adds only a tiny amount to the fee.
What it protects and what it doesn't
The protection holds only while the key stays secret. Spending reveals it, so an address that has been spent from should never receive coins again. The draft tells wallets to avoid reusing addresses. Anyone who receives everything to one address would have to change that habit.
The draft also warns about extended public keys. These are single codes that let a watch-only wallet or portfolio tracker see every address in an account. Sharing one gives away every public key the account will ever use, which defeats the purpose.
There's a short gap the draft can't close. Once a payment is broadcast, its public key is visible while the transaction waits to be confirmed. In theory, a fast enough quantum attacker could use that window to send a competing payment. On Kaspa that wait is usually a few seconds.
Coins in today's addresses get no protection until their owners move them to the new kind of address. That will take one ordinary payment, but only once the owner's wallet supports KIP-22. Restoring a recovery phrase in a wallet without that support won't show coins kept this way, even though they are still there.
A first step, not the whole migration
The full answer to quantum computers is new signature schemes that they can't break. kaspa.news has covered experiments with those on testnet, including post-quantum vault spends using existing Kaspa script. Hidden keys make that change smoother when it comes. Funds whose keys were never published can be moved to the new schemes without an attacker getting a head start.
Ori points to Bitcoin's BIP-361 as an example of where this could lead (BIP-361). That draft plans a staged retirement of today's signatures, with a rescue route for coins left in old addresses. KIP-22 says a similar plan could be written for Kaspa separately. For now, nobody has proposed one.
Who has to act
Because the network already understands these addresses, the work falls on wallets. Replying to the announcement, IzioDev quoted the line "No consensus changes are required" and added that this means it can be done today. A wallet has to adopt the convention before its users can receive coins this way.
The proposal is still a draft and may change. In the Kaspa R&D chat, IzioDev suggested it might fit better as a KCC, the format for shared conventions that don't touch the network's rules, and Ori agreed it could become one (discussion). Comments are open on the pull request and the research forum.
Telegram sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
