# SRC-20 and SRC-101 SRC-20 ticks written in the Stamps carriers, and SRC-101 names, both catalogued by the stamps adapter. URL: https://blockspace.wiki/protocols/src-20/ SRC-20 is a fungible tick ledger written in the same output-side carriers as [Stamps](https://blockspace.wiki/glossary/bitcoin-stamp/). SRC-101 is a name protocol from the same indexer. [BTI](https://blockspace.wiki/glossary/bti/) measures them as two families, `src20` and `src101_name`. ## How SRC-20 writes to Bitcoin The data-types reference gives the "direct" SRC-20 encoding, citing stampchain's specification. The payload is a 2-byte big-endian length, the lowercase prefix `stamp:`, then JSON. The whole is ARC4-encrypted with the first input's funding txid, byte-reversed, as the key. The ciphertext fills the first two key slots of each 1-of-3 [bare multisig](https://blockspace.wiki/glossary/bare-multisig/) output, 31 usable bytes per fake key and 62 per output. A decoder collects those slots in order, strips each key's first and last byte, decrypts, checks the prefix and takes `length` bytes. Stamps from before block 796,000 ride Counterparty issuances over the same carrier. From block 833,000 the Stamps family also writes [OLGA](https://blockspace.wiki/glossary/olga/) P2WSH chunks. Those outputs look exactly like real P2WSH, so BTI finds them from context: a Counterparty issuance in the transaction, or the SRC-20 direct pattern. The BVT document's roster calls Stamps and SRC-20 "deliberately un-prunable; the most expensive channel per byte". In the July 2026 measurement run, Stamps measured 1.008 bytes per vbyte, essentially no witness discount. ## How BTI attributes SRC-20 bytes The stamps [metaprotocol adapter](https://blockspace.wiki/glossary/metaprotocol-adapter/) adapts the stamps indexer, which decodes Counterparty's format itself and indexes stamp validity, numbering, SRC-20 ticks and SRC-101 names. Its trust is derived. Ruling B6 settles what the token is: a direct-era SRC-20 stamp number names an artifact, and the tick is the token, so demand stays queryable through the tick's operations. In the token table's words, "the tick ledger rides the stamp assets". The stamps rule for protocol outputs (B29(6)) is that they are the decoded message's destinations; a dust-value heuristic is kept as a counted fallback. A data carrier's span is the full output serialization (B30(2)/B23); in the case studies' words, the value and varint "carry the data as surely as the dust does". The indexer table records one caution for the stamps indexer: exit code 5 is a consensus failure, never force-restarted. Because every source gate fails closed, an unreachable stamps source stops the whole catalogue pass, not just its own unit. ## SRC-101 names An SRC-101 name is a token because the name itself changes hands: BTI proved 48 self-transfers on chain (B5), which is ruling U3's standing test. Each name's identity is `/`. A root is a collection, not a token, so a DEPLOY is typed non-token consumption: no claimant exists for it (U3, U5). A name expires as a supply-only burn at its mint height plus `dua` × 144 blocks, where `dua` counts days (B12). The token table puts SRC-101 in its own namespace, not under Counterparty (a taxonomy fix of 2026-08-03). ## Live figures SRC-20 ticks hold 0.56 GB in Book A, 0.07 % of the chain's bytes and 0.42 % of all Book A, with 0.08 GB in Book C. The books count 1,710 ticks across 1,433,793 operations, from block 788041 to 972298. SRC-101 names hold 1,948,985 bytes in Book A: 1,863 names across 1,961 operations, from block 871148 to 949910. Its Book C is 0 bytes (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - 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