Using BLOCK-20 without guessing

Inscribing a BLOCK-20 payload does not create tokens. It publishes a claim. A reader replays every BLOCK-20 inscription in block order, applies the rules, and produces balances. The reader can reject your claim silently and your Bitcoin is still spent.

Suppose you want a ticker called BLK with 21 million maximum supply and a 1000 unit cap per mint.

{"p":"block-20","op":"deploy","tick":"BLK","max":"21000000","lim":"1000"}

With an optional description:

{"p":"block-20","op":"deploy","tick":"BLK","max":"21000000","lim":"1000","des":"Anchored supply experiment"}

What the reader does

1. Confirms the content type and size, then parses the strict grammar. All five required fields are present, all values are strings, nothing repeats.
2. Normalizes BLK to the identity blk. If blk, Blk, or BLK was already deployed, this inscription is ignored.
3. Checks that lim (1000) does not exceed max (21000000).
4. Records the deploy height as the block containing this inscription, and the deployer as the reveal owner.
5. Creates the ticker with total, circulating, minted, and burned supply all at zero.

Say BLK deployed at height 767430, nothing has been minted yet, and you want 1000 units. The writer reads the current tip while creating your order. In this example the tip is block 767430, whose ID is the value below.

{"p":"block-20","op":"mint","tick":"BLK","amt":"1000","hash":"000000000000000000029730547464f056f8b6e2e0a02eaf69c24389983a04f5"}

Your reveal is mined at height 767500.

What the reader does

1. Parses the payload and checks the exact field set for a mint: p, op, tick, amt, hash.
2. Finds an active deployment for blk.
3. Confirms amt (1000) does not exceed lim (1000). Equal is allowed.
4. Confirms the hash is 64 lowercase hex characters.
5. Asks a Bitcoin node for the height of that block ID and gets 767430, on the active chain.
6. Checks 767430 >= 767430 (deploy bound, satisfied at the boundary), 767430 < 767500 (before the reveal), and 767500 minus 767430 = 70, which is inside the 144 block window.
7. Remaining supply is 21000000, so the full 1000 is credited to your reveal address.

Run these exact numbers through the anchor verifier to see each step evaluated.

You hold 1000 BLK and want to send 250 to someone. This takes two chain events.

{"p":"block-20","op":"transfer","tick":"BLK","amt":"250"}

Revealing this inscription creates a reservation. Your balance still reads 1000. Your available balance drops to 750, because 250 is now committed to that inscription.

send the transfer inscription to the recipient's address

The first move settles the reservation. Three outcomes are possible:

Funding rules that are not optional

• Send one dedicated output at or above the displayed minimum. Several smaller outputs are not combined.
• Do not reuse a commit address for anything else, and do not pay an expired order's address.
• Do not pay twice because a status is slow to update. Check your wallet transaction first.
• Keep the order identity, payload preview, receiver, commit address, amount, expiry, and your wallet transaction ID until the reveal appears.

The lifecycle page explains each order status and what to do about it.

1. Open the reveal transaction in a Bitcoin explorer and read the inscription content.
2. Compare it byte for byte with the payload preview you saved.
3. For a mint, note the reveal block height, look up the anchor hash to get its height, and run both through the verifier.
4. Check the balance in a BLOCK-20 reader. Remember that a reader waits for confirmations and can revise recent history after a reorganization.