BRC-251 and BRC-252 Enter Repository With Token Rules and Proof Experiments

BRC / Wallets & Identity

In Brief

BRC-251 and BRC-252 have been merged into the BRC repository, bringing expanded token definitions, wallet responsibilities and published proof experiments into the shared proposal collection.

The work has developed substantially since BSV TIMES covered the earlier drafts on October 15. Both documents remain labeled “Open,” and the experimental proofs still require further work before wallets can use them to replace part of a token’s transaction history.

News Report

GitHub records pull requests #320 and #321 as merged on October 25, 2026, at 19:20 UTC. Their current titles are “Bitcoin Native Tokens (BNT): Definition and Wallet Duties” and “Short Proofs for Bitcoin Native Tokens.”

The milestone places the revised documents and accompanying experimental material in the repository’s main branch. It records publication of the proposals and their supporting work; wallet deployment and interoperability remain separate questions.

A Broader Token Definition

The October 15 drafts focused on a peer-to-peer fungible-token profile using BRC-162 and ways to reduce repeated transmission of transaction history.

The merged BRC-251 now defines a broader classification. Bitcoin Native Tokens must satisfy six tests, including amounts recorded in locking scripts, validity checkable from transaction bodies, transfers controlled by the holder, rules fixed at deployment and evidence that travels with the payment.

It separately defines Issuer-Permissioned Tokens, which require an issuer’s countersignature until a published release removes that requirement. The document identifies assets such as tickets and stablecoins as potential uses for this issuer-dependent class.

Supporting BRC-255 and BRC-253 describe the respective formats. Wallets are required to distinguish the classes in labels, balances and storage, validate received outputs before crediting them, and prevent ordinary payment or consolidation routines from consuming asset outputs.

The term “native” has a specific meaning within this proposal. Miners validate the underlying transaction scripts, while the receiving wallet checks token amounts and supply rules through the asset’s history. A transaction being mined does not, by itself, establish that its token claims are valid.

Published Experiments Extend the Earlier Work

BRC-252 now describes a cryptographic step proof: evidence intended to let a recipient stop checking earlier transaction history at a verified checkpoint while still checking the transfer it receives.

The repository includes an experimental SP1 proof program, published proof files, source code, test data and reproduction instructions. These materials were added during development on October 20 and are now included in the merged proposal.

The documented mainnet experiment follows a test token through deployment, splitting and merging. Its proof of the merge checks the earlier split proof within it. Separate experiments use synthetic chains of 10 and 100 transfers, each processed as one batch.

The published compressed proof files are each 1,272,656 bytes, approximately 1.27 MB. The developer’s recorded runs took about 155 seconds for the split proof and 351 seconds for the merge proof. The synthetic 100-transfer batch took 483 seconds. These are experimental measurements, not demonstrated wallet throughput.

The Final Short-Proof Format Remains Unfinished

BRC-252 specifies a proof type called bnt-step-1, using an SP1 Groth16 proof. The published experiments currently produce SP1 compressed proofs, which have not yet been converted into that final format.

The proposal also requires a fixed verification key identifying the proof program. That key has not yet been pinned in the specification. Until it is, the document says these proofs cannot be used to skip the normal transaction-history checks.

The implementation notes distinguish earlier wallet optimizations—remembering validated history, retrieving missing ancestors and selecting inputs with less remaining history—from the unfinished step-proof mechanism. The experiment’s README states that wallets do not yet check the published proofs.

Repository inclusion therefore provides a concrete specification and research milestone while leaving the final proof format and wallet integration open.

BSV TIMES Read

The work addresses a practical question for assets issued on BSV Blockchain: how much evidence must accompany a transfer, and what must the receiving wallet verify itself?

The revised classification makes issuer dependence explicit, while the proof experiments explore whether growing transaction histories can be represented more efficiently. Their usefulness will depend on completing the specified proof format and demonstrating reliable verification in wallet implementations.

Developer Context

Brandon Cryderman, using the GitHub account GenericCPU, authored both proposals. The accompanying proof project publishes the Rust program, test fixtures, proof files and instructions for reproducing and checking the experiments.

Source Links

Posted on October 26, 2026 (UTC)