BLOCK-20

    Bitcoin · inscription-carried token protocol

    BLOCK-20: token operations anchored to Bitcoin blocks

    BLOCK-20 writes compact JSON into Bitcoin inscriptions. Deploy defines a ticker, transfer moves a balance, and every mint carries the hash of a Bitcoin block. A reader credits that mint only when the named block is genuinely on the active chain, mined after the deployment, before the mint's own reveal, and recent enough. Minting is not open. It is proved.

    Read the specification Verify a mint anchor

    767430

    First Bitcoin mainnet height a BLOCK-20 reader scans

    Protocol marker
    block-20
    Chain
    Bitcoin (mainnet in production, testnet configurable)
    Carrier
    Ordinals inscription envelope, taproot script-path reveal
    Operations
    deploy, mint, transfer
    Decimals
    0 (whole units only)
    Reader profile
    bitcoin-universe-block20-v1
    Lifecycle
    Experimental

    The idea

    The mint anchor

    Most inscription token protocols let anyone mint at any time until supply runs out. BLOCK-20 keeps that shape but adds one field to every mint: hash, a 64 character lowercase Bitcoin block ID. That single field is what a reader checks before crediting anything.

    How a BLOCK-20 mint derives validity from block data Four Bitcoin blocks in a chain. The first is the deploy block. The second, highlighted in amber, is the anchor block whose hash the mint payload carries. A gap of intermediate blocks follows. The last block is the block that reveals the mint inscription. The anchor must sit at or after the deploy block, strictly before the reveal block, and no more than 144 blocks before the reveal block. deploy block height D ticker becomes live anchor block height A its hash is the mint's . . . intervening blocks reveal block height R mint inscription appears D ≤ A < R and R - A ≤ 144 and the block at height A on the active chain must hash to the value in the payload otherwise the mint credits nothing at all
    A mint payload names a block. The reader resolves that hash to a height on the active chain and checks three distances. Fail any one and the mint is rejected outright, not partially credited.

    Chain membership

    The block has to be real

    A reader resolves the hash through a Bitcoin node. If the header is unknown, or its height now belongs to a different block, the mint is rejected. A hash from an orphaned block does not count.

    Ordering

    After deploy, before reveal

    The anchor height must be at or above the deploy height and strictly below the block that reveals the mint. You cannot anchor to a block that has not been mined yet, and you cannot anchor before the ticker existed.

    Freshness

    No older than the window

    The reader rejects an anchor more than 144 blocks before the reveal, roughly one day of Bitcoin. Mints cannot be prepared far in advance and dumped later.

    Who this is for

    Three readers, three entry points

    People inscribing tokens

    You want to know what will be written to Bitcoin, what it costs, and how to tell whether your mint counted.

    Start with the guide

    Application developers

    You are building against a BLOCK-20 reader and need the payload grammar, the state model, and the confirmation and reorganization behavior.

    Read the reference

    Protocol implementers

    You are writing an indexer and need numbered rules, exact rejection conditions, and vectors to test against.

    Read the specification, then the vectors

    Support

    What Bitcoin Universe products actually do with BLOCK-20

    Claims below are limited to what is wired in the organization's own capability registry. Anything not listed is not currently supported.

    BLOCK-20 surface support recorded in the Bitcoin Universe capability registry.
    SurfaceSupported actionsState
    Coreview, discover, view collection, view activity, view transactionDiscovery only
    Walletview, send, receiveSupported
    Inscribedeploy, mint, transferWriter
    MarketplacenoneNo trade path

    BLOCK-20 is indexed but not tradeable inside Bitcoin Universe. The capability registry records no marketplace entry for this protocol at all, which means no Universe product implements listing, buying, offers, or settlement for BLOCK-20. Balances can be viewed, sent, and received. They cannot be bought or sold through a Universe surface. Do not read the explorer and the wallet as evidence that a market exists.

    Two halves

    A writer that emits, a reader that decides

    BLOCK-20 is deliberately split. The writer places bytes on Bitcoin. It does not compute balances, order operations, or settle transfers. Everything about who owns what is decided by a reader applying the rules on this site.

    The writer

    Bitcoin Universe Inscribe builds the JSON payload, funds a commit output, and broadcasts a reveal. It selects the mint anchor by reading the current chain tip while the order is being created. It performs no supply or ticker validation of its own.

    Follow an order end to end

    The reader

    A reader replays inscriptions in block order, applies the payload grammar strictly, checks the mint anchor against a Bitcoin node, tracks reservations for transfer inscriptions, and reverses everything cleanly on a reorganization.

    See indexer semantics

    Emitting a payload is not the same as it being accepted. The writer will happily inscribe a mint whose amount exceeds the ticker limit, or a ticker that was never deployed. The reader rejects it and no balance changes. Always verify after the reveal.

    Attribution

    Where the shape came from

    BLOCK-20 uses the compact field conventions established by inscription-carried token standards that originated outside Bitcoin Universe, notably BRC-20: a p protocol marker, an op operation, a short tick, and string-encoded amounts. The parts specific to BLOCK-20 are the mint anchor in the hash field and the reader rules that make it binding.

    The writer described here is the Bitcoin Universe Inscribe implementation. The reader rules described here are the bitcoin-universe-block20-v1 profile operated by Bitcoin Universe. Both are implementations. Neither is a Bitcoin consensus rule, and another reader may reach a different conclusion about the same inscription unless it applies the same profile.

    There is no version field inside a BLOCK-20 payload. A change to field names, defaults, serialization, or the anchor rule is compatibility sensitive by construction. Version changes are recorded in the changelog.

    Entry points

    Specification

    Numbered normative rules: envelope, payload grammar, the anchor derivation, operation semantics, and every rejection condition.

    Guide

    Plain-language walkthrough with worked deploy, mint, and transfer examples.

    Reference

    Terminology, indexer semantics, fees and size, limitations, security considerations, implementation checklist.

    Lifecycle

    Commit and reveal stages, order statuses, and payment safety.

    Mint anchor verifier

    Client-side tool that parses a payload and walks the anchor derivation step by step.

    Test vectors

    Valid and invalid cases with expected reader outcomes.

    External: source repository, docs.bitcoinuniverse.io, security reporting, Universe Inscribe writer.