Developer Tools

A wallet receiving a token needs more than a transaction saying that somebody sent it.

It needs a way to determine whether the sender actually held valid units of that token, whether those units can be traced back through valid transfers, and ultimately whether the history reaches the token’s original deployment.

Two new draft proposals from Brandon Cryderman (GenericCPU) explore how that verification could travel directly between wallets rather than being replaced by the judgment of a token indexer or overlay service.

Proposed BRC-251 — Peer-to-Peer Fungible Tokens (P2P-FT) defines a wallet profile for holding, sending and receiving tokens built on the BRC-162 format.

Proposed BRC-252 — Compact Lineage Evidence for P2P-FT addresses what happens after those tokens have moved repeatedly and their accompanying history begins to grow.

The two proposals share one central principle:

the recipient verifies the token history for itself.

An overlay may help locate transactions or provide data, but its statement that a token is valid is not meant to replace the recipient’s own verification. GitHub

BRC-251 Carries the Token’s History With the Transfer

BRC-251 builds on BRC-162 and several existing BRCs to define a peer-to-peer wallet profile for fungible tokens.

When a token is transferred, the recipient receives more than the newest transaction.

The proposed delivery format uses a BRC-169 envelope containing an Atomic BEEF together with the token lineage needed to evaluate the transfer. The recipient then follows that history backward using the BRC-176 lineage model, checking the relevant token inputs and ultimately reaching the original deployment. GitHub

An output that has not successfully passed that verification does not enter the wallet’s spendable token balance.

That distinction matters because receiving transaction data and accepting a token as valid are separate actions.

A wallet can be handed a transaction, but the proposal does not ask the wallet to accept its token claims merely because another service has indexed them or because the sender says the balance is legitimate.

The receiving wallet performs the lineage checks itself.

Previously Verified History Can Become a Checkpoint

Walking all the way back to deployment is straightforward when a token has only moved a few times.

Over time, however, a frequently transferred token could accumulate a longer history.

BRC-251 already allows one important shortcut: the wallet does not have to repeat work it has already done.

If the lineage reaches an output that the recipient previously verified, the verification walk can stop there. The wallet already has a trusted local result for the history behind that output.

That creates the foundation for BRC-252.

Rather than inventing a new authority that certifies the token’s past, the wallet can treat its own earlier verification as a checkpoint.

BRC-252 Tries to Keep the Evidence From Growing Indefinitely

BRC-252 focuses on reducing how much lineage data has to accompany later transfers.

Its first optimization is simple: do not resend history that the recipient has already verified.

Suppose a wallet previously received and verified a particular token output. If that wallet later receives tokens whose lineage passes through the same verified history, the sender does not need to include all of those earlier ancestor transactions again.

The recipient can stop at its known checkpoint.

If the recipient no longer possesses that earlier verified material, it cannot simply assume the omitted history is valid. The missing transaction has to be retrieved, or the newly received tokens remain unverified. GitHub

That keeps the optimization tied to evidence the recipient can actually check.

Input Selection Can Also Reduce the Remaining History

BRC-252 proposes a second optimization at the sending side.

A wallet may have several token inputs that could satisfy the same payment amount. Those inputs may carry different amounts of unresolved history for the particular recipient.

The proposal says the sender should prefer the set that leaves the shortest remaining lineage for that recipient.

That does not make older branches invalid.

A sender can still spend them.

The idea is that when several valid choices are available, wallet input selection can consider not only token amount but also how much additional verification evidence the recipient will need. GitHub

This turns token-history size partly into a wallet-selection problem rather than assuming every transfer must carry the largest possible ancestry package.

“Compact” Does Not Yet Mean a New Compressed Proof

The word compact needs an important qualification.

BRC-252 does not currently define or register a cryptographic compressed-proof system that replaces the lineage walk.

Its draft explicitly says that a shorter proof only counts if the recipient can independently verify it, and no such proof is registered by the proposal.

An overlay signature does not qualify.

If a purported shortcut cannot be checked by the receiving wallet, the wallet ignores it and falls back to walking the transaction history. GitHub

So the current proposal is mainly about omitting evidence already known to the recipient and choosing inputs intelligently, not turning an arbitrary token history into a tiny proof through a new cryptographic construction.

That boundary is important because otherwise “compact lineage” could sound much more complete than the present draft actually claims.

Verification Is Different From Blockchain Confirmation

There is another distinction worth preserving.

BRC-251 and BRC-252 are primarily concerned with whether a token’s lineage and token rules can be verified.

That is not the same question as whether the newest transfer has already been mined into a block.

Atomic BEEF can carry the transaction material and available proof information needed by wallets, but determining token validity and determining current blockchain confirmation are different checks.

A wallet therefore should not interpret successful lineage verification as automatically meaning that the latest transaction is already confirmed.

The proposals address portable token evidence; normal transaction-state and mining verification remain part of the wallet’s broader responsibilities.

The Overlay Helps With Data, Not Truth

This may be the most important architectural feature of the pair.

Token systems often rely on indexers because somebody has to organize large amounts of historical transaction data and make token balances practical to discover.

BRC-251 does not prohibit overlays or indexers from participating.

Instead, it limits what their role means.

A service can provide transaction bodies, locate history or help deliver the information the wallet needs, but its own conclusion that the token is valid is not the verification boundary.

BRC-252 reinforces the same principle. A shorter representation is useful only when the recipient has enough information to check it independently.

That creates a different relationship between wallet and service provider.

The service can help the wallet find evidence without becoming the authority that defines whether the evidence is true.

Implementation Exists, but the Standards Are Still Drafts

BRC-251’s current pull request states that the model has been implemented in HandCash Desktop and Mobile.

It also makes clear that current builds still file these holdings under the existing bsv21 name. The proposed p2pft filing name belongs to the draft profile and has not yet become the final deployed convention. GitHub

BRC-252 remains earlier in its implementation path.

The proposal establishes rules for omitting recipient-known history and preferring inputs that leave less remaining evidence, but it does not yet introduce the more advanced compressed-proof mechanism that its architecture could accommodate later. GitHub

Both PR #320 and PR #321 remain open drafts as of October 15, so names, filing conventions and other technical details may still change during review. GitHub

Portable Evidence Rather Than Portable Trust

The interesting part of BRC-251 and BRC-252 is therefore not simply another token format.

BRC-162 already provides the underlying token structure.

These proposals focus on what happens when tokens need to move between independently operated wallets.

The sender supplies the transaction history needed to justify the token.

The receiver verifies that history.

Previously verified outputs can become local checkpoints.

Later transfers can omit ancestry the same recipient already knows.

Wallets can select token inputs partly according to how much new evidence must travel with them.

And external services can assist with discovery without becoming the final authority over validity.

If that approach develops successfully, token portability becomes less dependent on every wallet trusting the same token server.

What moves between wallets is not merely a balance assertion, but enough evidence for the receiving wallet to reach its own conclusion.

That is the larger idea behind the two drafts: peer-to-peer token transfer should carry portable evidence, not require portable trust in somebody else’s indexer.

Developer context

Brandon Cryderman (GenericCPU) submitted both BRC-251 and BRC-252 on October 14.

Related recent work includes:

• BRC-248 — Offline BAP Issuer Identity Packages, another proposal centered on carrying verification evidence with an object rather than depending entirely on an online lookup service. GitHub
• handcash-mpp, an unofficial open-source implementation of HTTP 402 machine-payment flows using HandCash payment infrastructure. GitHub
• HandCash Desktop, the BRC-100 self-custodial desktop wallet whose public repository documents token and application-facing wallet infrastructure; BRC-251 names HandCash Desktop and Mobile among its current implementations. GitHub

The recurring theme across these projects is portable verification and wallet-side processing rather than assigning all application state or validity decisions to a single hosted service.

Source Links

BRC-251 — Peer-to-Peer Fungible Tokens, GitHub PR #320

BRC-252 — Compact Lineage Evidence for P2P-FT, GitHub PR #321

BSV TIMES – Under the Surface

Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Update — October 15, 2026