Addresses and locks: key-locked and script-locked outputs

What protects your funds? Every Kaspa address is a lock on UTXOs, and Kaspa has two kinds of lock.

A Kaspa address is not an account, it doesn't hold funds. An address's mission is to spell out the lock an output will carry. Kaspa has two kinds of these locks:

1. 1A key lock: starts with q, the address is a public key in disguise. kaspa:qpc6655zfnql67…kzy9jz8q is the 32 bytes of a key, dressed with a checksum so a typo is caught. The lock says: this key must sign. Whoever holds the matching private key can spend, and that is what your wallet does for you.
2. 2A script lock: starts with p, kaspa:pzzgtjkyzsgxp24…c62fn0pl is the fingerprint of a script, 32 bytes of hash. To spend it, you have to show the script itself. The node takes the script, checks that its fingerprint matches the address, and then runs it. Only when the script is satisfied does the UTXO move. Every covenant since Toccata is a script, so all of them live behind p addresses.

From a p address alone you cannot read the script, only its fingerprint, until someone spends it or publishes it. Your wallet shows both kinds as UTXOs. The lock decides what the spend must show.

X-ray an address

q vs p: tell them apart

Look at it on chain

Two transactions:

1. 60a2f205…3f145914 created:
   • a p output, 0.3 KAS to kaspa:pzzgtjkyzsgxp24…c62fn0pl.
   • a q output, the change to kaspa:qpc6655zfnql67…kzy9jz8q.
   One transaction created both locks.
2. The script revealed. 2436d2fc…f7501f3d spent the p output.
   Read the full case

   Transaction 60a2f205… made two outputs: 0.3 KAS behind a p address, and the user's change behind a q address. A p address is the fingerprint (the hash) of a script. At that moment nobody on the network could see the script itself, only its fingerprint.

   Then 2436d2fc… spent that 0.3 KAS. To spend a p output you must put two things in the input: the script itself, and whatever that script demands. So the input carries the script (187 bytes) and a signature (65 bytes).

   The node did two things. First it hashed the script it was handed and compared the result to the 32 bytes inside the p address. They matched, so this is the script the address was made from and not a substitute. Only then did it run the script. The script says one thing: key K must sign. The signature was K's, so the script said yes and the 0.3 KAS moved.

   Two extra facts make the example interesting. The script also carries a dead branch (OP_FALSE OP_IF … OP_ENDIF) that the node never executes, because it's a place to stash a text note that off-chain KRC-20 software reads. That is why this p address is not a Toccata covenant, it's the older trick of hiding data inside a script. And key K is the very same public key the q address is built from. One owner, one key, two locks: the q output is locked by the key directly, the p output is locked by a script that demands the key. That is "Same key, two locks."

Sources

An address is a prefix, a version byte and a payload, with an 8-character checksum, in rusty-kaspa v2.0.1 crypto/addresses/src/lib.rs (versions 0 PubKey, 32 bytes, 1 PubKeyECDSA, 33 bytes, 8 ScriptHash, 32 bytes) and bech32.rs (the charset and the checksum). The lock each address stands for is built in crypto/txscript/src/standard.rs: OpData32 <key> OpCheckSig, OpData33 <key> OpCheckSigECDSA, OpBlake2b OpData32 <hash> OpEqual, the hash being blake2b-256 of the script. Opcode values are in opcodes/mod.rs. The decoder on this page is a line-by-line port of bech32.rs, checked against the node's own test vectors. The two transactions were read from api.kaspa.org on 6 September 2026. The revealed script was hashed with blake2b-256 and matched to the p address.