Address

An address is a locking script written so that a person can copy it, read it aloud or put it in a QR code.

Under the text there are only two things: a witness version (which kind of lock) and 32 bytes of witness program (whose lock). Bech32m wraps them in a network prefix and a checksum. Paste an address into a wallet and the wallet unwraps it back into the locking script it puts in a transaction output.

Try it

This address received 2 PRL in block 130,825. Decode it, then change one character.

What are the parts of an address?

The human-readable part is the only part you can read. Everything after the separator uses a 32-character alphabet, qpzry9x8gf2tvdw0s3jn54khce6mua7l, where each character stands for a number from 0 to 31. It leaves out 1, b, i and o, which are easy to confuse.

Size

63 characters (mainnet), 64 (test networks)

Type

bech32m text

Format

prefix ‖ 1 ‖ version ‖ program ‖ checksum

Which prefixes does Pearl use?

The prefix says which network an address is for. Wallets refuse an address from the wrong network.

Look at the middle: the 52 program characters are identical on every row. Same key, same program. Only the prefix and the checksum change, because the checksum covers the prefix too.

Two test networks share tprl, and regtest shares rprl with simnet, so an address tells you “mainnet, test or regtest”, not which testnet. (Pearl’s code also reserves tprl for a signet, but no Pearl signet runs.)

Which versions are there?

The version character picks the kind of lock. Pearl accepts exactly two.

The program must also be exactly 32 bytes. Bech32m itself could carry 2 to 40, but Pearl’s decoder insists on 32 for both versions.

How does an address become a locking script?

Directly. Decode the version and the program, then write OP_n (0x50 + version), a push of 32 bytes (0x20) and the program:

Here is the real payment that sent 2 PRL to the address in the “Try it” box. Its second output’s locking script is 5120 followed by the 32 bytes behind vt5a5d5…:

That’s all a “payment to an address” is on chain: an output whose locking script is the address, unwrapped. A Taproot address holds the key itself, not a hash of it, so there is nothing to look up.

What does the decoder reject?

These are the results of feeding strings to Pearl’s own DecodeAddress on mainnet settings:

All-capital addresses are allowed because QR codes store capitals more compactly. Mixing cases is not.

Why exactly 63 characters?

Count the pieces: 3 (prl) + 1 (separator) + 1 (version) + 52 (program) + 6 (checksum) = 63.

The 52 comes from the 32 bytes: 256 bits, cut into 5-bit characters, needs 52 characters (260 bits), with 4 zero bits of padding at the end. Since every Pearl program is 32 bytes, no Pearl address is ever shorter or longer. Test addresses add one letter for the t or r: 64.

What do Pearl wallets hand out?

• Taproot, always. Oyster and the Pearl Desktop Wallet give out prl1p… addresses from the BIP-86 path, a fresh one each time you ask, so payments aren’t trivially linked.
• Never P2MR. P2MR outputs are valid and do appear on chain (rarely: 5 in 200 recent blocks, against 62,638 Taproot outputs), but a search of Pearl’s v1.5.2 code finds nothing outside tests that creates a P2MR address.
• Quantum-safe on request only. getnewaddress … pq=true gives a prl1p… address whose tweak commits to an XMSS script. It looks like any other Taproot address.

import { decodeAddress } from '~/lib/bech32m';

const a = decodeAddress('prl1pvt5a5d5z42egswfv7uscht7rv2rj3z4m8n3qp3w35592ydq88v4seuhn70');
a.network;  // 'mainnet'
a.version;  // 1
a.type;     // 'p2tr'
a.script;   // Uint8Array(34): 51 20 62e9da3682aab288392cf7218bafc36287288abb3ce200c5d1a50aa234073b2b