BIP 122 Blockchain URI Explained for Blocks and Transactions

BIP 122 Blockchain URI Scheme: This guide explains BIP 122 URI scheme for Blockchain references / exploration in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

General URI shape

The proposal uses blockchain:[//chain]/type/value. Type is tx, block or address. Transactions use a 64-hex identifier; blocks may use a 64-hex hash or decimal height; addresses use the relevant chain's address encoding. Omitting the chain identifies Bitcoin mainnet under the draft's convention.

Chain ID and forks

For a base chain, the chain ID is its genesis block hash including leading zeroes. For a forked chain, the draft uses the first block after the fork. The explicit identifier reduces name ambiguity, but software still needs a trusted registry or user confirmation before selecting a network and data source.

Transactions, blocks and addresses

A transaction reference identifies data, not confirmation or finality. A block height can name a different hash after a reorganisation. An address reference does not prove ownership, payment intent or network safety. The handler should display type, chain and resolved result without silently turning a reference into a spend action.

Parser and dispatch risks

Custom URI handlers receive input from web pages, documents and QR codes. Enforce length, grammar and hexadecimal rules before dispatch. Reject control characters, extra path segments and unsupported schemes. Escape every displayed value, and never construct a shell command or unrestricted web redirect from a raw URI.

Explorer trust boundary

A public explorer can omit, delay or mislabel chain data and learns which objects the user requests. A local validating node provides stronger consensus evidence but may not index every address. Applications should distinguish convenient lookup from local validation and communicate the privacy cost of remote resolution.

Draft status and interoperability

BIP 122 has not become a universally registered Bitcoin application convention. Two handlers may interpret chain omission, address formats or fork identifiers differently. New products should feature-detect support, offer copyable raw identifiers and avoid replacing normal HTTPS links unless the user retains a clear fallback.

Safe fixture suite

Test mainnet, testnet, regtest and a synthetic fork chain with transaction, block-hash, block-height and address references. Add truncated hashes, mixed case, leading-zero loss, huge heights, encoded separators and unknown chains. Confirm that lookup cannot trigger payment, remote code execution or a silent network switch.

Conclusion

BIP 122 offers a clean idea for portable blockchain references, but its draft status and custom-handler boundary require cautious parsing, explicit chain identity and a clear distinction between lookup and validation.