Content Licensing Watch / Data Infrastructure
In Brief
BRC-170 has been merged into the BSV Blockchain BRC repository, introducing the Locked Content Header, or LCH, a common container and licensing protocol for encrypted digital content. LCH combines encrypted files with signed usage offers, BSV payment mechanisms, buyer-specific licenses and controlled key delivery, supporting models ranging from one-time purchases and rentals to metered access, derivative works and AI training.
News Report
A newly merged Bitcoin Request for Comments defines a common framework for publishing encrypted digital content together with machine-readable licensing terms, payment requirements and the evidence needed to establish what a buyer is permitted to do with the material.
BRC-170, “Locked Content Header (LCH) — Licensed, Micropayment-Enabled Content,” has been merged into the BSV Blockchain BRC repository following Pull Request #236.
The specification, authored by Ty Everett, is designed to address a problem that becomes increasingly important as digital content is sold in smaller units and increasingly accessed by software rather than only by people.
Individual applications can already encrypt a song, document, dataset or other file and release a decryption key after payment. But without a shared format, each service has to decide independently how to represent the content, authenticate the seller, describe usage rights, collect payment, deliver keys and preserve evidence of what the buyer acquired.
BRC-170 brings those pieces together into an extensible format called the Locked Content Header.
An LCH package identifies the encrypted content, its media type, integrity information, relevant rights holders and one or more ways in which the content can be licensed. A compatible application can inspect the header, select an acquisition method it supports, make the required BSV payment and receive a signed buyer-specific license together with the decryption capability granted under that license.
The protocol is independent of the underlying media type.
A protected asset could be audio, video, software, a font, a document, a dataset or another digital format. An .lch file can contain the ciphertext directly or point to the exact encrypted bytes through supported locators including HTTPS, UHRP or CHIRP.
That creates a separation between storage and licensing.
UHRP can identify and locate content, while BRC-167 CHIRP can divide large material into independently verifiable chunks for distributed or partial retrieval. LCH sits above those mechanisms and describes what the encrypted content represents, who controls relevant rights and what a recipient must do to obtain authorized use.
BRC-170 adopts the W3C Open Digital Rights Language, ODRL 2.2, as its normative rights-expression framework rather than defining an entirely new license language.
An offer and a license are deliberately treated as different objects. An ODRL Offer describes proposed terms, while payment and acceptance result in a signed ODRL Agreement tied to the buyer.
The initial LCH profiles cover several forms of use:
- fixed-price rendering or access;
- quantity- or range-metered use;
- event-metered access such as an individual page or play;
- time-limited rental;
- incorporation into a derivative work; and
- use of content as AI or machine-learning training input.
This allows the commercial model to follow the actual use of the content rather than requiring every asset to be sold as an unrestricted whole-file purchase.
For example, a document service could license individual pages, a media application could provide time-bounded access, and a dataset publisher could state whether machine-learning use is permitted and under what conditions.
LCH also defines segmented encryption for cases where an application should not receive the decryption key to an entire asset.
A client can acquire selected ranges or segments while the protocol identifies exactly which encrypted portions and keys are being released. That is particularly relevant to large media, metered consumption and other uses where revealing the whole file after the first small payment would defeat the licensing model.
Payment is likewise integrated into the specification rather than left entirely to each application.
BSV payment is the normative payment scope, with BRC-105 providing the mandatory single-payee HTTP payment mechanism for a full core implementation. BRC-121 and other explicitly identified mechanisms can be used by acquisition profiles that support them.
The specification goes further for material involving multiple rights holders.
A single licensed work can represent several interests — for example, a recording, composition, performance or incorporated source material — each controlled by a different party. LCH can construct one BSV transaction containing the required outputs for multiple payees while retaining evidence connecting each payment to the corresponding demand.
The design avoids requiring those recipients simply to scan the blockchain looking for payments that might belong to them. Each payee participates through authenticated payment-delivery and receipt mechanisms, with the protocol defining recovery and idempotency requirements for interrupted settlement.
BRC-170 also addresses derivative works.
It uses C2PA provenance information to identify source material incorporated into a derivative asset, while LCH composition records preserve the relationship between the new work and the licenses governing its ingredients.
That can allow downstream obligations to remain attached as content is combined rather than disappearing when a new file is exported.
This is potentially relevant not only to traditional media production but also to AI-generated and AI-assisted material, where datasets, media fragments and other source works can pass through several processing stages before appearing in a final output.
The protocol nevertheless makes an important limitation explicit.
LCH does not claim that digital-rights controls can prevent every unauthorized copy after plaintext has been legitimately decrypted or rendered.
Its purpose is narrower and more infrastructural: standardize confidentiality before acquisition, machine-readable offers and agreements, seller authority, payment evidence, key delivery, provenance and the expected behavior of conforming applications.
BRC-170 also relies on several existing BRC components rather than creating a parallel stack. These include BRC-78 for buyer-bound encrypted key delivery, BRC-95 for Atomic BEEF transaction transport, BRC-100 for the wallet/application boundary, BRC-103 and BRC-104 for authenticated communication, and existing BSV payment specifications.
The result is less a new content marketplace than a proposed interoperability layer beneath many possible marketplaces, players, wallets and content applications.
BSV TIMES Read
Digital content licensing usually lives inside applications.
A streaming service knows what a subscription permits because the service owns the account system, payment system, content database and access rules. Move the same content outside that application and much of that meaning disappears.
BRC-170 explores a different architecture.
The encrypted asset can carry enough standardized information for another compatible application to identify what it is, verify who is authorized to offer it, understand the available terms, obtain the appropriate license, make the payment and receive the necessary decryption capability.
That makes the license more portable than the storefront.
The micropayment aspect becomes particularly interesting when the asset does not have to be purchased as one indivisible object. Pages, ranges, plays, rental periods or machine-learning rights can become independently priced forms of access, while a derivative work can preserve its relationship to licensed source material and potentially settle obligations to multiple contributors.
It is still a specification rather than evidence that a broad interoperable content economy already exists. Applications, wallets, publishers and rights holders would have to implement it before that becomes meaningful at scale.
But the direction is important for public data infrastructure. If content, identity, payments, rights and provenance can use common interoperable formats, a creator or publisher does not necessarily have to rebuild the entire commercial relationship inside every application that carries the work.
Source Links
BRC-170 — Locked Content Header specification
BRC repository merge activity — PR #236 / BRC-170
Posted on September 2, 2026
Leave a comment