Bitcoin mainnet · Fungible tokens · Bitcoin Stamps sub-protocol

Tokens printed into the ledger, not pasted onto it

SRC-20 is a fungible token protocol on Bitcoin. Its DEPLOY, MINT and TRANSFER operations are plain JSON documents carried in transaction output scripts. Output scripts are what a node needs to validate future spends, so every full node keeps them, whether it wants to or not.

Read the specification Validate a payload Start with the guide

At a glance

What it actually is, in plain language

A token on SRC-20 is a shared spreadsheet that nobody hosts. Somebody publishes a DEPLOY saying "there will be at most 21 million of a thing called PLATE, and each mint can take at most 1000". After that, anyone can publish a MINT to claim some, until the supply runs out, and anyone holding a balance can publish a TRANSFER to send it on.

Each of those is a short JSON document written into a Bitcoin transaction. Bitcoin does not know or care what the document says. It confirms the transaction, and then indexers, which are programs that read the whole chain in order, all apply the same rules and arrive at the same balances. The protocol is the agreement between those indexers.

The consequence people miss

A confirmed Bitcoin transaction is not the same thing as a successful token operation. Your transaction can confirm perfectly and your mint still be worth nothing, because the supply ran out three blocks earlier. Always check the result in an explorer after confirmation, not just the transaction status. The validity rules spell out every case.

Who this is for

If you hold or trade tokens

Start with the guide. It walks through what each operation costs, what "clamped" means when your mint comes back smaller than you asked for, and how to read a result.

If you are building a wallet or app

Read the specification end to end, then check your parser against the test vectors. The validator is useful while you are hand-writing payloads.

If you are writing an indexer

The activation heights and the indexer semantics are where implementations diverge. Reproduce them exactly or your ledger will not match anyone else's.

If you came from BRC-20

The field names are the same and the rules are not. Go straight to the difference table before you write a payload.

The argument for output scripts

This is the protocol's whole reason to exist, so it deserves an honest statement rather than a slogan.

Payload locationOutput scriptnot input witness
Retained byEvery full nodeas part of the UTXO set
Cost of thatFull weightno witness discount, permanent UTXO growth

An SRC-20 payload sits inside the scriptPubKey of outputs that can never be spent. Because a node must be able to validate a future spend of any unspent output, it must keep those scripts. The bytes are therefore held by every node running a full unspent-output set, permanently, as a side effect of how Bitcoin works rather than as a favour.

Inscription-based protocols put their payload in the witness of an input instead. That is committed by the block header just as firmly, and archival nodes keep it, but a validating node is permitted to discard it. The difference is not whether the data can be forged, because neither can. The difference is who is obliged to keep a copy.

The bill for this arrives as permanently larger UTXO sets for everyone running Bitcoin, and as higher fees for the person publishing, since output data pays full transaction weight with no witness discount. Both protocols are making a defensible trade. SRC-20 chose durability.

Rules U-1 to U-4 state this formally, with the diagram.

Where it came from

SRC-20 originated in the Bitcoin Stamps community in 2023, not in Bitcoin Universe. Bitcoin Universe indexes it, builds products on it, and maintains this documentation; it does not own or govern the protocol.

Origin and the record it left in the chain
Block	What happened
`779652`	First valid Bitcoin Stamp, carried as a Counterparty asset.
`788041`	First SRC-20 activity. Operations ride inside Counterparty issuances.
`793068`	First SRC-20 carried directly on Bitcoin, with no Counterparty encoding.
`796000`	Counterparty-encoded SRC-20 stops counting. The protocol becomes direct-to-Bitcoin.
`865000`	OLGA P2WSH encoding becomes available, replacing bare multisig for new transactions.

On the Counterparty question

SRC-20 is often described as being "built on Counterparty". That was accurate for about 8000 blocks and has not been accurate since block 796000, after which Counterparty-encoded SRC-20 is ignored outright. An indexer built today still needs Counterparty to replay history below that height and to index classic Stamps, but SRC-20 state from 796000 onward comes from Bitcoin alone. The full account is in section 12.

Its relatives

Bitcoin Stamps: The parent protocol. It stores images in the same unprunable output carrier. SRC-20 reuses that carrier and the stamp: prefix, and is told apart only by the p field of its JSON.
SRC-101: The naming protocol in the same family: namespaces, unique names, renewals and records. It shares the carrier and shares this ecosystem, but has its own operations and lifecycle. First seen at block 870652.
SRC-721: The non-fungible sibling, also carried by the same prefix and distinguished by p.

Support in Bitcoin Universe products

Only capabilities that are wired up in the Bitcoin Universe ecosystem registry are listed here. Anything absent is absent on purpose.

Declared SRC-20 actions per surface, from the ecosystem capability registry
Surface	Actions
Core	view, discover, view-collection, view-activity, view-transaction
Wallet	view, send, receive
Inscribe	deploy, mint, transfer
StampDEX	view, discover, view-collection, view-activity, view-transaction, list, unlist, buy, cancel-offer, settle

Marketplace activity for SRC-20 is owned by StampDEX and runs in external-execution mode: StampDEX holds the order book and the settlement authority, and Bitcoin Universe proxies to it rather than executing trades itself. The guide has the complete matrix, including each unsupported action and the recorded reason for it.

The rest of this site

01 / Normative
Specification

Numbered rules for the carrier, both encodings, activation heights, ticker and numeric rules, the three operations, and every validity and invalidity condition.
02 / Practical
Guide

Worked DEPLOY, MINT and TRANSFER examples end to end, what a transaction costs, and the verified product support matrix.
03 / Operator
Reference

Terminology, confirmation and reorg behaviour, the Counterparty dependency stated honestly, limits, security considerations and an implementation checklist.
04 / Proof
Test vectors

Valid and invalid payloads with the outcome an indexer must produce, each one traced to the rule that decides it.
05 / Tool
Payload validator

Paste a JSON operation and see every check explained, plus the BRC-20 differences. Runs entirely in your browser.
06 / History
Changelog

Version history for this document, and the protocol-level changes it records.

Entry points and links

Protocol sources

btc_stamps, the Bitcoin Stamps indexer and the reference implementation for these rules
Stampchain, the public explorer and API

Bitcoin Universe

Staying safe

Never share a seed phrase or private key, and never blind-sign. Before signing, check the network, the recipient, the amount, the outputs and the fee. Ticker symbols can look alike, so verify a token by its deploy transaction rather than by a familiar word or logo. A confirmed transaction does not by itself guarantee the token result you expected: follow it in an explorer afterwards.