BRC-176 Defines Offline Validity Proofs for BSV-21 Tokens

Token Verification Watch / Network & Protocol

In Brief

BRC-176 introduces an offline-verifiable proof format for BSV-21 token outputs, allowing a recipient to verify a token’s identity, amount and transaction lineage back to a valid deployment without relying on a global token indexer. The specification packages the required transaction evidence using BEEF and accounts for BSV-21 histories in which tokens can be split and merged across multiple transactions. It does not establish whether an output remains unspent or prove the token’s global circulating supply. (Beersy)

A recently published Bitcoin Request for Comments defines a portable method for proving that a BSV-21 token output is valid using the transaction evidence carried with the token itself.

News Report

BRC-176, “BSV-21 — Validity Proofs,” was published August 28 by Open Protocol Labs and David Case and revised September 1. It defines an offline-verifiable packet for outputs created under the BRC-161 and BRC-162 BSV-21 fungible-token specifications. (Beersy)

The problem it addresses is different from simply finding a token balance.

An indexer can maintain a database describing which BSV-21 outputs belong to an address, their transaction histories and whether those outputs appear to have been spent. But if the recipient must trust that database to determine whether the token itself was validly created and transferred, the indexer becomes part of the token’s trust model.

BRC-176 instead defines what transaction evidence must accompany a claimed token output so that its validity can be checked independently.

The basic package consists of a BRC-62 BEEF bundle plus a defined scope identifying the outputs being proved. Depending on the situation, the proof can travel as BRC-95 Atomic BEEF for outputs from one transaction, BRC-158 Outpoint BEEF for an individual output, or a bare BEEF package with the subject outputs identified separately. (Beersy)

The verifier begins with the token output being received and works backward through its BSV-21 ancestry.

For each relevant transaction, it checks the token ID and amount, determines which inputs belong to that same token, and verifies that those inputs are themselves valid. That process continues recursively until every required branch reaches the token’s original deployment transaction.

For ordinary transfers, the specification applies a conservation rule: the amount of valid same-token inputs must be sufficient to support the token amounts moved by the transaction. Where the token uses an authority-based minting model, the verifier instead has to establish a valid authority lineage back to the corresponding deployment. (Beersy)

This becomes more complicated than provenance for a single indivisible satoshi because BSV-21 tokens can split and merge.

A token amount of 10,000 units might be divided into outputs of 6,000 and 4,000 and later combined again. The history is therefore not necessarily one straight path from the current output to an origin. It can form a directed acyclic graph, or DAG, containing multiple branches that must all be accounted for.

BRC-176 explicitly distinguishes this from the 1Sat provenance model described by BRC-159 and BRC-150. A 1Sat Ordinal can be followed from its current tip toward its satoshi origin, while BSV-21 validity depends on token-ID-specific conservation and authority rules across potentially branching transaction history. (Beersy)

That difference also changes how BEEF must be packaged.

Ordinary Atomic BEEF is designed to be SPV-minimal. Once a mined ancestor can be represented by sufficient Merkle evidence, its complete transaction body may no longer need to accompany the subject transaction.

For BSV-21 verification, however, an ancestor’s transaction body can itself contain information required to determine whether the token was validly conserved or minted.

BRC-176 therefore reuses the Atomic BEEF framing where appropriate but explicitly does not apply the normal rule that unnecessary ancestor transaction bodies should be stripped. Every required same-token source transaction must remain available until the verifier can trace the necessary lineage back to deployment. (Beersy)

Missing evidence causes the proof to fail closed.

If a required token-parent transaction is absent, the verifier cannot simply assume that the missing input was valid. The corresponding contribution is not counted, which can cause a legitimate token to remain unproven, but cannot manufacture additional valid input value from missing information under the specified verification algorithm. Resource limits such as maximum packet size or recursion depth must likewise result in an unproven result rather than an assumption of validity. (Beersy)

Before any BSV-21 rules are considered, the BEEF evidence itself must also pass its underlying transaction checks. Transaction IDs must correspond to the supplied transaction bodies, included Merkle paths must verify against trusted block-header information, and unmined descendants must connect to proven ancestors.

A self-consistent collection of fabricated transactions is therefore not sufficient merely because its internal token arithmetic adds up. (Beersy)

BRC-176 is equally explicit about what a successful proof does not establish.

It does not prove that the subject output is currently unspent. That still requires the same UTXO-status checks required when receiving other BSV payments or assets.

It also does not prove global circulating supply or establish that an issuer has never produced other valid tokens through an authorized minting path. Nor does it define wallet basket metadata and display information, which remain the responsibility of BRC-163. (Beersy)

What it does establish is narrower: for the specifically named output being presented, the verifier can establish its BSV-21 token ID and amount and validate the required conservation or authority lineage back to a recognized deployment.

The specification lists 1sat-stack and 1sat-sdk as implementations. The current 1Sat SDK provides BSV-21 token functionality alongside its BRC-100 wallet tooling, transaction-building components and 1Sat infrastructure, although BRC-176 should not be taken to mean that every wallet or BSV-21 application already exchanges these proof packets. (Beersy)

BSV TIMES Read

The important architectural idea in BRC-176 is that finding information and proving information do not have to be the same job.

An indexer can still be extremely useful. It can locate token outputs, organize histories and help a wallet discover what it owns. But BRC-176 attempts to remove the indexer from the final question of whether a particular BSV-21 token history is internally valid.

Instead, the evidence can travel with the asset.

That is closely aligned with the broader SPV direction of BSV Blockchain: a recipient should be able to receive the transaction evidence required to verify what matters rather than querying one authoritative database and accepting its answer.

BSV-21 makes this harder than following a single satoshi because fungible units can divide and recombine. BRC-176 turns that branching history into a defined proof package and verification procedure rather than leaving every wallet or token service to invent its own method.

The limitations matter just as much. A validity proof is not a live UTXO check, and it is not a global supply audit. Those are separate questions requiring separate evidence.

But that separation is useful infrastructure design. If wallets and applications can independently verify the validity of the particular token outputs they receive while using other services only for discovery and current-state information, BSV-21 becomes less dependent on any one token database remaining available and trustworthy.