10-05-2026 
|
Getting your Trinity Audio player ready...
|
The views expressed in this article are those of the author and do not necessarily reflect the position of CoinGeek.
TL;DR: BRC-162 upgrades BSV fungible tokens with a compact binary format that allows Bitcoin Script to read token data directly while potentially reducing script size by around 60%. The upgrade preserves existing BSV-21 tokens, requiring no migration, and unifies BSV-21 and BRC-92 into one standard. Wallet and indexer support is still pending, while the official name—Mandala Tokens—could eventually give way to the proposed 1Color Tokens.
Key Takeaways:
- BRC-162 streamlines BSV token transactions by making token data easier for Bitcoin Script to process
- Existing BSV-21 tokens need no migration, but wallets and indexers must support BRC-162 for users to access the new format.
- BRC-162 unites BSV-21’s token model and BRC-92’s encoding into one standard, eliminating the need to support two separate formats.
- BRC-162 adopts the Mandala Tokens name, while 1Color Tokens remains under consideration as an alternative inspired by Bitcoin’s colored-coins concept.
In the small hours of October 2, 2026, at 02:34 UTC to be exact, a pull request merged in the BSV BRC repository, and BSV‘s fungible tokens got an upgrade that breaks nothing. It is called BRC-162, and it gives us more useful, more powerful token tools on 1Sat Ordinals without a single breaking change to the BSV-21 tokens that already exist. If you hold those tokens and you do nothing, nothing changes. If they are transferred to the new format, they remain the same tokens with the same ID.
That kind of promise almost never comes attached to an upgrade in this industry, so I am thrilled about this one!
So what actually changed?
BSV-21 is the fungible token standard on 1Sat Ordinals. Until now, every BSV-21 token output has carried its data as a JSON inscription, which is a little text document riding along on each output. BRC-162 keeps the exact same token model and only changes how it gets written down. The spec says: “Token id, supply models, and balance/authority economics are the same; only the on-output encoding differs.”
The new encoding is binary, and the whole format fits on one line of script:
`<token id> <amount> OP_2DROP <any locking script>`
Push the token ID, push the amount, drop them both, and whatever locking script you like does its normal job. It doesn’t even carry a label: “There is no tag: the layout itself is the protocol marker.”
The big win is that Bitcoin script can finally read the thing. The spec’s own motivation reads: “Wallets and contracts can build and check token outputs in script without assembling an inscription or parsing JSON.” So a covenant, a marketplace lock, or an automated market maker can read and enforce token amounts with ordinary opcodes. JSON is lovely for humans and miserable for Bitcoin script, so now the script doesn’t have to touch it.
Whether those tokens are genuine is still settled by indexers and overlays, which is the design I defended this August, so nobody needs to send me an “actually, Kurt” on X.
It’s smaller, too. By my napkin math, a plain pay-to-address transfer drops from about 172 bytes of locking script as a JSON inscription to 62 bytes under BRC-162, which is roughly 60% smaller! There is no published benchmark yet, so please check my math.
The ID gets tidier as well: “Every token has exactly one wire form, so scripts that compare id bytes agree on token identity.” And there is room for an optional metadata payload that never gets validated, so “its presence, absence, or contents never make an output invalid and never affect balance or authority admission.”
Metadata that cannot brick your token… what a concept!
Everything else carries over from BSV-21: a token is still identified by the output that deployed it, supply is still either fixed at deploy or minted later by an issuer’s authority output (which suits things like stablecoins), any locking script can follow the prefix, offline validity proofs still work under BRC-176, and wallets can keep the same basket.
Great, another token standard. What do I have to do?
Nothing.
Existing BSV-21 tokens keep their ID: “The token id is fixed for the life of the token.” The old BSV-21 document still “remains normative for existing BSV-21 tokens,” and only new tokens get nudged toward the new format. Even that nudge is polite, since “New fungible tokens SHOULD be issued under this document” stops well short of a MUST.
The validity-proof spec, BRC-176, treats the old and new encodings as a single token: “Either encoding is an output of the same token model.” So, a balance held in the old JSON form can be spent into a BRC-162 output, and it is the same token with the same ID. For a holder, there is no swap, no snapshot, and no “send your tokens to this address by Friday.”
The work belongs to wallets and indexers. They have to ship BRC-162 support before you see any of this in an app. The spec’s list of implementations still reads “None yet.” Two draft implementations are already open, though, one from each author: David Case has a template up in the 1Sat SDK, and Deggen opened one in the BSV TypeScript stack on October 2.
So the design is finished, and the code is arriving right behind it.
2 specs, 1 handshake
This standard exists because two builders, who had each solved the same problem their own way, decided that one spec beats two and merged a few good ideas together.
David “shruggr” Case of Open Protocol Labs, who also wrote the BRC-176 proof spec, brought BSV-21, which is the token model. Darren “Deggen” Kellenschwiler of the BSV Association published BRC-92, the Mandala Token Protocol, in September 2024, and it introduced the push-and-drop prefix: push the token data, drop it, and let any locking script follow. That left BSV with two good ideas in two different formats, and every wallet, overlay, and contract was stuck supporting both. The new spec takes one piece from each: “Mandala tokens use the BSV-21 token model with the push-and-drop prefix that BRC-92 introduced.”
Case opened the first pull request, covering BSV-21 in both JSON and binary, in August 2026. The slimmer format that he and Deggen agreed on was merged on September 28. Then, on October 2, Deggen withdrew his own BRC-92 in favor of the single spec. From the pull request: “Its author, Deggen (also an author of BRC-162), agreed: rather than keep two specs, the fungible token designs converge on one.”
Do you know how rare that is in this industry? Competing standards usually end in a fork, a feud, and a decade of podcasts, but Deggen approved the final merge with a review comment that reads, in its entirety:
“Cool alright”
Peak diplomacy!
Full disclosure: I am one of the contributors named on the spec, alongside Luke Rohenaz, Michael Boyd, and Dan Wagner, and I am a founder of Open Protocol Labs, whose name is at the top of it. So, weigh my cheerleading accordingly… but the spec and the pull request are both public, so you don’t have to take my word for any of it.
So what do we call them?
Naming has been the hardest part by a mile. “1Sat Tokens” was tried on September 26 and reverted the next day because, per the pull request, it “is too easily confused with 1Sat Ordinals NFTs.” On October 1, the draft was titled “1Color Tokens” for about 13 hours (the commit is public), and that evening it became “Mandala Tokens,” taking the name from Deggen’s BRC-92 with his agreement.
The official title today is “BRC-162: Mandala Tokens,” and I have no quarrel with it. Mandala is a perfectly good name, but it is also a very busy word in BSV. It already names the network architecture I wrote about on August 17, the BSV Association’s stablecoin platform, and the older token protocol. We love that word so much, we keep giving it new jobs…
So we are kicking around another one: 1Color Tokens.
It is a callback to one of the oldest tokenization ideas in Bitcoin, called colored coins. In March of 2012, Yoni Assia posted “bitcoin 2.X (aka Colored Bitcoin),” and that December, Meni Rosenfeld’s “Overview of Colored Coins” put it this way: “by carefully tracking the origin of a given bitcoin, it is possible to color a set of coins to distinguish it from the rest.”
Where the 2012 designs made you trace a coin’s history to learn its color, BRC-162 writes the color (the token ID and the amount) right on the output, and by convention, each token output holds a single satoshi.
One sat, one color.
Fourteen years later, the color is printed right on the coin, and I think the name should say so. To be clear, “Mandala Tokens” is the official title, and 1Color is only under consideration, which is why I want to hear from you. Tell me on X whether 1Color sings or whether Mandala should keep the job. And builders, please go read the spec, poke at it, and tell David and Deggen what you find!
If it holds up, feel free to borrow Deggen’s review.
“Cool alright.”
FAQs:
What is BRC-162?
BRC-162 is a BSV token specification that introduces a binary encoding for fungible tokens on 1Sat Ordinals. It preserves the existing BSV-21 token model while allowing Bitcoin Script to read token IDs and amounts directly, without parsing JSON inscriptions.
Does BRC-162 change existing BSV-21 tokens?
No. Existing BSV-21 tokens retain their original IDs, supply models, and balance and authority rules. They can be transferred into the new encoding without becoming different tokens, and holders are not required to swap or migrate their assets.
How does BRC-162 improve token transactions?
BRC-162 uses a compact push-and-drop script prefix to encode token IDs and amounts. This allows contracts and other on-chain applications to inspect token information using ordinary Bitcoin Script opcodes.
Is BRC-162 supported by wallets and indexers, and could its name change to 1Color Tokens?
At the time of writing, BRC-162 had no completed implementations, although draft versions were underway for the 1Sat SDK and BSV TypeScript stack. Wallets and indexers must still add support for the new standard. Meanwhile, Mandala Tokens remains its official name, with 1Color Tokens still under consideration as an alternative.
This opinion piece is published to encourage discussion. The author’s views are their own and do not constitute legal, procurement, or policy advice, nor do they represent the positions of CoinGeek or its partners.
Watch | Tokenization on public blockchain: Transforming RWAs and finance
