BBQr is a publicly documented transport format from Coinkite. Each QR begins with the B$ prefix and a short header containing the encoding, file type, total part count, and index; it is followed by a data segment written as HEX, Base32, or fixed Zlib plus Base32.
BBQr addresses cases where a PSBT, signed transaction, or another file will not fit in one reasonably readable QR code. The sender splits the data into a series of frames and the receiver reassembles them, so the file can cross an air gap without a cable, card, or network connection. The format itself signs nothing, broadcasts nothing to the Bitcoin network, and is not part of consensus. [1]
Each frame starts with an eight-character header. The B$ prefix identifies BBQr, the next character selects the encoding, the next the content type, two base36 positions give the total frame count, and the last two give the current frame index. The example B$HP0301 means HEX, PSBT, 3 frames in total, and part with index 1. Every frame in one series must state the same encoding, type, and count. [1]
The QR uses alphanumeric mode with a restricted uppercase character set. Code H writes HEX, code 2 uses Base32 without the = character, and code Z first compresses the whole file with Zlib using wbits=10 and no file header, then uses Base32. Compression can shrink a PSBT, but may help little with hashes, UTXOs, and other high-entropy data; the encoder should then choose the smaller uncompressed option. [1]
Frames can be read in any order because the header carries their index. This is not a fountain code, however: the receiver must obtain all N parts, and a missing frame cannot be reconstructed from the others. The QR layer already has its own error detection and correction, so the specification adds no separate series checksum; the design discussion explicitly considered the trade-off among simplicity, overhead, and recovery of skipped frames. [4]
Project documentation calls BBQr widely deployed and, as of 27 July 2026, verified released public code in several signers, mobile wallets, and coordinators, including COLDCARD Q, Sparrow Wallet, Nunchuk Desktop, BTCPay Server, Krux, and BlueWallet. Support is not automatically bidirectional: for example, SeedSigner was listed for version 0.8.7 as decode-only. [2]
Two base36 positions allow at most 1295 parts, or ZZ. For QR version 40, the specification states 4296 alphanumeric characters and a theoretical uncompressed ceiling of 2 776 480 bytes for HEX or 3 470 600 bytes for Base32. A real implementation may impose a stricter limit: COLDCARD Q documentation accepts files up to 2 MiB and otherwise presents progress according to the part count. [6]
Type character P denotes a PSBT and T a finished Bitcoin transaction; J, C, U, B, and X cover JSON, CBOR, UTF-8 text, generic binary data, and executable data. The type helps a receiver choose a parser, but proves neither correctness nor safety of the content. A wallet must reject a type it does not expect at that step, and a signer must independently display outputs, amounts, and the fee before signing. [5]
An implementation should be checked with a round-trip test against the published repository and test data: encode the same file, shuffle the frames, read them again, and compare the result byte for byte. Missing and damaged frames, H, 2, and Z, the single-frame case, and device memory boundaries need separate tests. A real PSBT or other sensitive data must never be put into a public web generator. [3]
For the clearest picture, read this entry together with PSBT, Transaction, Hardware Wallet, Air-gapped Wallet, Multisig, Output Descriptor.
01Is BBQr the same as SeedQR?+
No. SeedQR represents a BIP39 wallet recovery secret and must be handled like a private key. BBQr is a general transport envelope for split data, often a PSBT or signed transaction. BBQr may carry sensitive content, but the format name alone does not mean the payload is a seed, and it does not encrypt the data.
02Does air-gapped transfer over BBQr make a transaction safe?+
No. Optical transfer removes one network or cable path, but a malicious coordinator can still prepare a PSBT with an attacker output, an unsuitable fee, or unexpected inputs. The user must verify addresses, amounts, the fee, and wallet policy on a trusted signing device; after signing, the coordinator should broadcast exactly the reviewed transaction.