# BRC-100 An inscription-borne tick ledger with a two-step transfer; its only mirror died, so BTI was ruled its indexer on 2026-08-11. URL: https://blockspace.wiki/protocols/brc-100/ BRC-100 is a fungible tick ledger written in inscriptions. In [BTI](https://blockspace.wiki/glossary/bti/)'s token table its tokens are BRC-100 ticks, each identified as `brc100:`, case-folded. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own brc100 decoder. ## How BRC-100 writes to Bitcoin BRC-100 operations are JSON bodies in ord [inscriptions](https://blockspace.wiki/glossary/inscription/). Each operation therefore has two claimants: the tick, and the sat that carries the inscription. The ruleset records the protocol's facts as BTI reads them: - `p` is case-insensitive, and uppercase is 54 % of the population; - a tick of 4 bytes is reserved (the protocol voids its own first deploys, `ordi` and `sats`); ticks of 3 or 5 to 100 bytes are legal; - a deploy sets `max`, `lim`, `mma` and `dec` (at most 18, default 18), and mints count against `mma`; - a transfer has two steps. The transfer-inscribe has no ledger consequence: it arms a note on the inscription's destination output and locks the amount. The send is any spend of that output, and the output that covers the note's sat position receives the units. BTI's BRC-100 study (2026-08-05) measured 200,065,278 bytes in 2,601 blocks, 4.55 % of every byte Bitcoin confirmed while it ran. In block 822,364 it took 6,384 of 6,511 transactions and 97.21 % of the block. One tick, `bos`, is 98.5 % of it. The study found that an earlier, lowercase-only count had seen only 46 % of the payloads. ## How BTI attributes its bytes BTI first meant to adapt inBRC's keyed mirror, the only source that ever existed. It never answered: probed on 2026-08-05 and again on 2026-08-11, it timed out on every route. A source that does not answer would stall the whole roster, so BRC-100 was ruled natively indexed on 2026-08-11. BTI's decode is the record (B32), and no adapter exists or is planned. The decoder claims for the tick only; the sat's claim is the ord adapter's. The transfer-inscribe writes no tick claim, a lesson the ruleset credits to an off-by-one found in BRC-20. The send claims. The tick's Book C is 0 by the ruleset, because the JSON body is the sat's content (B14); the envelope span is shared with the sat's claim and divided by the books. Mint2, mint3, burns, `cop` and all application state are typed [residue](https://blockspace.wiki/glossary/residue/): seven occurrences in 621,485 payloads. The transferability gate passed on 2026-08-11 and was re-verified on BTI's own node: a transfer-inscribe of 36,000 `bos` at block 820,820, and a send six blocks later that landed the units on the buyer's dust output while the seller was paid 716,400 sats. ## Findings of the August review The BTI protocol review of 2026-08-29 found three things. - **Book C is not zero.** BRC-100 carried 20.1 MB of Book C where the ruleset says 0, traced to a 2026-08-16 schema ruling that span-covering claims own content atoms, which had not entered the ruleset text. - **It had not ended.** Its apparent end at block 955,000 was only the books' horizon; a `bos` claim stood at block 964,137. - **Tick length is counted in bytes.** A single CJK character is 3 bytes and so a legal tick, while a single emoji, at 4 bytes, is rejected as reserved. The review calls this a documented convention, not an error. ## Live figures BRC-100 holds 0.14 GB in Book A, 0.02 % of the chain's bytes and 0.11 % of all Book A, with 0.02 GB in Book C. The books count 560 ticks across 715,589 operations, from block 805913 to 972145 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space protocols API ยท https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20