Token Standards Watch / Developer Tools

Two related proposals submitted to the official BSV Blockchain BRC repository introduce a model for tokenized assets with miner-enforced creator payments and a method for delivering those assets to newcomers through pre-funded claim links.

The first submission, provisionally numbered BRC-146, proposes a class of self-replicating covenant tokens built with OP_PUSH_TX. Under the proposed design, every valid transaction must recreate the asset for its next holder while also producing the creator, publisher, or other payment outputs defined by the token’s original rules. (GitHub)

Because the conditions are contained in Bitcoin Script, a transfer that omits a required payment, redirects it to another destination, changes its ordering, or pays less than the prescribed amount would fail the covenant’s validation rules. The proposal therefore describes these terms as traveling with the token rather than depending on a marketplace or application operator to enforce them.

BRC-146 presents two profiles. A single-payee version applies publisher and current-holder payments during a permissionless acquisition. A multi-payee version can require several creator outputs, potentially supporting shared authorship, component licensing, or predefined payment splits. The submission says the single-payee profile has been deployed and validated on BSV Blockchain mainnet, while the multi-payee profile has been tested using the BSV TypeScript SDK’s Script interpreter. (GitHub)

The proposal also uses a genesis-linked verification model. Rather than carrying an expanding chain of ancestor transactions with every transfer, the asset is intended to bind its identity to a genesis transaction and support verification through a Merkle proof, following principles referenced from the existing Merkle Proof Token specification.

An accompanying open-source implementation appears in PharLap, an experimental browser-based wallet and tokenized-content project. PharLap’s documentation describes working mainnet flows for minting, permissionless replication, ownership transfers, refundable token bonds, and creator-payment covenants. The repository states that the core system operates on mainnet, but it has not published a formal software release and continues to identify the project as experimental. (GitHub)

A second submission, provisionally numbered BRC-147, addresses the onboarding problem that a new user normally needs both a wallet and sufficient funds before receiving or acquiring an on-chain asset.

The proposed method allows a publisher to create pre-funded voucher outputs and distribute them as claim links. When a recipient uses a link, the voucher funds the acquisition and transaction costs, while a newly generated recipient key becomes the owner of the resulting asset. Under this model, the person paying for the transaction does not have to be the person who ultimately owns the asset. (GitHub)

Voucher keys are derived deterministically from the publisher’s key. The proposal says this would allow the publisher to rediscover outstanding vouchers and reclaim funds from links that were never used, without maintaining a separate local database of every voucher.

BRC-147 is designed to work with the permissionless acquisition branch proposed in BRC-146, although the general payer-and-owner separation could inform other onboarding systems. Its intended use is to let an organization, creator, or application cover the initial costs of bringing a new participant on-chain rather than asking that participant to obtain BSV tokens before the first interaction.

Both proposals remain open pull requests. At the time of this report, neither has received a formal review, assignee, label, project assignment, or milestone. Their provisional BRC numbers do not indicate acceptance, and the submissions may be revised, renumbered, or declined during review. (GitHub)

Review the proposed BRC-146 specification

Review the proposed BRC-147 specification

Explore the experimental PharLap implementation

BSV TIMES read:
These proposals connect two practical application problems. The first asks whether creator or publisher payments can be embedded in an asset’s continuing transaction rules rather than enforced by a marketplace database. The second asks how a new user can receive that asset without first navigating token acquisition and transaction funding. Neither proposal is an accepted standard, but the accompanying implementation gives the discussion more substance than a conceptual document alone. Their longer-term importance will depend on technical review, interoperability with wallets and indexing tools, and whether other builders adopt the same transaction patterns.

Posted on July 20, 2026