LCH Acquisition through Private Overlays and Listing Covenants

Abstract and status

This proposal binds BRC-170 Locked Content Header licensing to two private-overlay purchase paths: BRC-105-funded lookup and a BRC-197 listing purchase followed by BRC-196 POTATOES. It reuses LCH assets, offers, buyer requests, authority, policies, licenses, encryption and key grants. Any conforming content application can use these bindings without adopting another application's token format or user interface.

LCH's deterministic CBOR and signature preimages remain authoritative. BRC-192's JSON transport carries complete LCH bytes as base64 and MUST NOT rehash diagnostic JSON as if it were an LCH object. An unsupported critical mechanism makes the selected offer unusable before payment.

1. Common bindings

This BRC registers extension IRI https://bsv.brc.dev/apps/0198#overlay-acquisition-v1, abbreviated E below. In an LCH Offer's extensions[E], the value is the following deterministic CBOR map. The Offer's critical array MUST include E:

overlay-binding = {
  "version": 1,
  "mode": "paid-lookup" / "listing-covenant",
  "seller": bstr .size 33,
  "service": tstr,
  "endpoint": tstr,
  "chain": { "network": tstr, "genesisHash": bstr .size 32 },
  ? "lineageAnchor": { "txid": bstr .size 32, "outputIndex": uint },
  ? "releasePolicy": bstr
}

Seller MUST equal the Offer seller and be authorized for its roles. Endpoint is the selected concrete base from BRC-194; payment.endpoint names the appropriate acquisition route below. lineageAnchor and releasePolicy are present exactly for listing-covenant mode. Output index is at most 4294967295. releasePolicy is the UTF-8 JCS encoding of the BRC-196 ReleasePolicy selected by this Offer, without a JSON digest wrapper. Its interpretation is critical. The chain and seller are compared with authenticated capability and transaction evidence, not taken on trust from a locator.

The application submits a complete LCH signed License Request in the outer request bytes. Use a BRC-77 publicly verifiable buyer signature. requestId for BRC-195 or BRC-196 is the lowercase hexadecimal LCH License Request ID. That deterministic binding replaces the normally random retry ID; the LCH requestNonce provides freshness. Asset ID equals the LCH Asset ID. termsDigest is the LCH Offer ID, thereby binding the full signed offer body including policy, payment and key-delivery choices. The authenticated recipient equals the LCH buyer. An adapter MUST compare each binding before initiating payment.

Both modes return context/secret with schema E and deterministic CBOR bytes:

acquisition-context = {
  "version": 1,
  "license": signed-object,
  "evidence": [* {"type": tstr, "object": signed-object}],
  "settlement": bstr,
  ? "purchaseEvidence": bstr,
  ? "paymentEvidence": bstr
}

signed-object is BRC-170's encoding. Evidence contains explicitly typed objects under section 5. Settlement contains the complete UTF-8 JCS signed packet for the selected mode. PurchaseEvidence is present exactly for covenant mode and contains the complete UTF-8 JCS package defined in section 5. Key grants remain inside the License; this wrapper cannot expand permitted actions or release extra key periods.

2. Paid lookup binding

The binding selects mode paid-lookup. The Offer uses an existing supported LCH usage profile and payment protocol https://bsv.brc.dev/apps/0170#brc105-single-v1, with exactly one buyer-bound requirement and payment.endpoint equal to the absolute HTTPS URL formed by appending /overlay/v1/private/acquire to the selected canonical base. The requirement endpoint equals that same URL. E expressly selects the outer Acquire envelope instead of posting a bare LCH request; unaware LCH clients reject E rather than sending the wrong wire shape. The price and challenge match the single LCH compensation duty exactly. The selected seller is payee or has the required receivePayment authority.

After BRC-105 verification, the issuer returns the signed License and selected key grants in protected lookup context alongside the purchased output's BEEF. LCH authority, Offer validity, buyer consent, policy evaluation, ciphertext preflight and key-commitment checks still apply. The recovery deadline is at least the Offer's recoveryPeriodSeconds beyond payableUntil, as well as BRC-195's minimum. An expired catalogue output does not erase a funded License Request. Payment retry and License reissue preserve the same request and rights without another charge.

Existing ciphertext MUST NOT be labeled as LCH segmented AES-256-GCM unless actually encoded that way. A migration can retain an older decoder under an explicit application schema while newly published LCH assets use supported encryption. Reusing a container label does not change encryption bytes or historic buyer rights.

3. Covenant accumulation binding

This BRC registers payment mechanism and settlement profile https://bsv.brc.dev/apps/0198#listing-accumulation-v1, abbreviated C. An Offer using C MUST include C and E in its critical array, select listing-covenant mode, and use the critical standing-offer profile S defined in section 5 with exactly one fixed-price standing requirement. The Payee MUST be the authorized seller/collector and the amount MUST equal purchasePrice. payment.endpoint and the standing requirement endpoint equal the absolute HTTPS URL formed by appending /overlay/v1/purchases/prepare to the selected canonical base. A duty that requires immediate separate payments to several rights holders cannot be satisfied by this profile. Such an offer needs a distinct compatible settlement design or LCH's existing multilateral path.

To avoid a circular commitment, the LCH Offer commits to the already existing lineage anchor, not a listing ID or future genesis txid. The chain is already in the binding. The listing descriptor includes the resulting Offer ID; its signed genesis authorization is delivered during catalogue lookup/preparation. Clients compare the Offer anchor, descriptor anchor, seller, asset, price, chain and exact genesis proof. No self-reference is solved by substituting an arbitrary placeholder into signed bytes.

Preparation returns BRC-196 signed terms binding the outer request digest. The buyer constructs the BRC-197 permissionless purchase with the acquisition/request/recipient/Offer commitments, submits the complete transaction to the selected private topic and recovers through BRC-196. There is no additional BRC-105 payment. Accumulated value remains in the listing until a permitted payout; a purchase is not a BRC-29 payment directly delivered to every artist.

The seller issues a BRC-192 signed packet of type lch-covenant-settlement with this body:

type CovenantSettlement = {
  version: 1; seller: Identity; buyer: Identity;
  requestId: Hex32; offerId: Hex32; assetId: Hex32;
  dutyUid: string; acquisitionId: Hex32;
  listingId: Hex32; previous: Outpoint; successor: Outpoint;
  txid: Hex32; satoshis: U64;
  releasePolicy: ReleasePolicy; releaseEvidenceDigest: Hex32;
  issuedAt: U64; recoveryUntil: U64
}

Its ID is digest("lch-covenant-settlement", body). The signer equals the authorized seller/collector. The issuer MUST independently verify the transaction, exact predecessor/successor, increment, receipt, genesis ancestry and selected release evidence before marking the duty fulfilled. A seller signature alone cannot substitute for those checks.

The License includes a fulfillment {dutyUid, settlementProfile:C, receiptIds:[settlementIdBytes]}. E's critical extension in the License maps this particular ID to the complete covenant settlement packet in acquisition-context.settlement; it is expressly not an LCH Payment Receipt ID. No other BRC-170 fulfillment fields are used for C. The License's extensions[E] is a CBOR map containing version:1, mode:"listing-covenant" and settlementId as a 32-byte byte string; its critical array includes E and C, with extensions[C]={version:1} in the License (the Offer has the richer section 6 value). The buyer-bearing Request, License subject, key-grant recipient, POTATOES recipient and settlement buyer must all match. The standing Offer contains no preselected buyer; S defines the exact late binding. The LCH request ID and the outer BRC-196 request digest are different hashes with different domains; the adapter validates both, never equates them.

This registers one new interpretation of settlement evidence while retaining LCH's existing fulfillment shape and critical-extension discipline. It MUST NOT be relabeled receipt-complete or authorized-output settlement. Exactly one compensation duty is supported in either mode; an Offer with two such duties is unsupported even when both name the same collector. Its dutyUid matches the single requirement and fulfillment exactly; later payout outputs are constrained by the listing’s current revenue schedule under BRC-197; the purchase itself does not immediately pay the individual recipients.

4. Playback, recovery and conformance

POTATOES delivery occurs only when the License, settlement proof and key grants can be returned consistently with the selected release policy. Pending license issuance remains delivery-pending even if STEAK exists. The same accepted payment/purchase and License Request can recover an equivalent License through the promised period. Already granted offline use cannot acquire a new online dependency merely because the transport migrated.

Ciphertext/UHRP/CHIRP range retrieval and authenticated decryption are separate from catalogue event streaming. A live output feed neither supplies media bytes nor changes an Agreement. LCH's safeguards on unknown terms, plaintext release, composition, rights authority and raw-key revocation limits remain in force.

Conformance covers existing fixed-render acquisition through paid lookup; correct CBOR/JSON separation; request-ID binding; wrong Offer/asset/buyer; unknown critical extension; covenant purchase and License; delayed release; wrong increment or lineage; duplicate recovery; multi-payee duty rejection; legacy ciphertext distinction; and authenticated playback of the selected key periods. Claims must list the exact usage, payment, encryption and key-delivery mechanisms implemented; “LCH compatible” alone is insufficient.

5. Standing Offers, retry identity and verification closure

The critical extension https://bsv.brc.dev/apps/0198#standing-offer-v1 (S) has value {version:1} in Offer.extensions, and MUST be listed in Offer.critical for C. Only C uses S in this version. S explicitly replaces only C's fixed pricing requirement shape with:

standing-requirement = {
  "dutyUid": tstr,
  "payee": bstr .size 33,
  "endpoint": tstr,
  "satoshis": uint,
  ? "interest": tstr
}

Buyer is forbidden, not ignored or filled with an anyone key. BRC-170's ordinary buyer-bearing payment requirement remains unchanged for all Offers without S. A client lacking S rejects this Offer before payment. All other Offer/authority/policy/fixed-price rules remain. The standing policy must leave the individual assignee open at Offer time; the signed License Request supplies the authenticated buyer, consents to the complete Offer ID/policy/action/selection and late binding, and fixes that buyer in the Agreement/settlement/License. A successor listing continues committing to the same Offer ID. Thus buyers A and B can issue distinct consented Requests against one unchanged descriptor/Offer, each receiving a separately recipient-bound License; neither Request edits the standing Offer. The Offer uses C as payment protocol, E as transport binding, and S as requirement semantics, with all three critical and the exact extensions[C] value defined below. C requires administration=seller-v1; an intentionally payout-less listing cannot be offered as this collector settlement.

Outer retries are byte-stable. Before first Acquire/Prepare, persist the complete original signed deterministic-CBOR License Request, including its ordered signatures array. Re-signing the same body, reordering signatures or adding a signature changes outer request bytes and therefore conflicts under the same LCH request ID/acquisition ID, even when every signature is cryptographically valid. It is not a second purchase and must not generate a new payment. Recovery by acquisition ID remains available when the original request envelope is unavailable. Two valid BRC-77 signatures over one body have the same LCH body ID and different outer digests by design. This explicit rule applies to all nested signed request retries; no implementation-specific semantic normalization is allowed.

The selected capability has a non-critical-to-other-profiles extension keyed E, value {version:1,bindings:[{kind:"lookup"|"topic",service:string,mode:"paid-lookup"|"listing-covenant",mechanisms:string[]}]}. It is required by clients selecting this BRC. A paid binding names kind lookup, the exact BRC-195 service and E plus the selected BRC-170 payment/usage/encryption/key-delivery profiles. A covenant binding names kind topic, the exact BRC-196 topic and E/C/S plus those LCH mechanisms and the BRC-197 revenue-listing-v1 executable family. Entries are unique by kind/service/mode; mechanisms are unique sorted absolute IRIs. All required mechanisms must be installed locally and advertised before wallet construction. Generic steak-potatoes capability alone is insufficient. Offer.binding.service equals this exact entry and Acquire.service or Prepare.topic; Offer seller equals the selected manifest identity and authenticated seller. Offer.binding.endpoint is the canonical base, not a route suffix. With base https://seller.example/api, covenant payment.endpoint is https://seller.example/api/overlay/v1/purchases/prepare.

Before creating a preparation/quote require Offer.notBefore <= now < Offer.notAfter if present, and preserve its authority/terms/bytes. Freeze the cutoff in payableUntil/purchaseUntil no later than Offer.notAfter. Require recoveryUntil >= cutoff + max(86400, advertised recoverySeconds, Offer.payment.recoveryPeriodSeconds) in Challenge/Terms, settlement and POTATOES. Once prepared/quoted, later expiry or withdrawal stops new preparations but does not revoke timely first-delivery/recovery for that existing obligation. BRC-195/196 pinned-candidate and unfinished-delivery rules prevail. A License recovered after Offer expiry is evaluated against those frozen accepted terms, not misrepresented as a newly accepted expired Offer. Original rights periods cannot be expanded by reissue.

Typed acquisition evidence is a list of {type,object}. Permitted type strings are exactly the pinned BRC-170 signature domains offer, authority, quote, payment-demand, payment-receipt, payment-authorization, transaction-evidence, and payment-delivery-ack, when needed by the selected mechanism. A type is never guessed by trying signatures; its shape must be the corresponding BRC-170 body and signer roles must verify. Sort by ASCII type then raw 32-byte LCH ID. Duplicate (type,ID) entries, including signature variants, are forbidden; differing bodies under one ID are an integrity failure. Maximum 128 objects, authority depth 16, decoded CBOR context 2 MiB and 256 signature checks; apply smaller local bounds first. Unknown evidence types fail unsupported. Any necessary external authority resolution is bounded and explicitly configured; missing authority is unresolved before payment/issuance, not implicitly granted. The complete Offer and Asset must be available from the Header plus evidence, with their exact original bytes/IDs; neither a diagnostic JSON map nor a displayed name suffices.

Covenant purchaseEvidence is {version:1,lineage:LineagePackage,purchase:Evidence,terms:SignedPurchaseTerms,release:ReleaseEvidence}. The lineage target is the consumed listing, purchase selects the successor at index zero, and signed terms/domainEvidence carry the same lineage package semantics. The buyer and License issuer verify this package independently against the same installed family; the issuer does not merely accept a seller's claimed increment. Availability of all package bytes and bounded full ancestry is a precondition to purchase. C requires the exact BRC-197 revenue-listing-v1 artifact and all seller-v1 routes. Reproduce its Script and domain checks before advertising C; a passing arithmetic model is insufficient.

Both modes require exactly one compensation duty and no additional unmet prerequisite duties. The Offer's policy may carry separately stated downstream nonpayment duties, but this profile cannot pretend the one transfer discharged them. Buyer matches Request.buyer, authenticated caller, outer recipient, Agreement assignee, License.subject, settlement.buyer and recipient of each BRC-78 grant. Seller matches Offer seller, capability identity, Challenge/Terms seller, settlement signer and POTATOES signer. The requirement payee equals that seller or an explicit receivePayment grant authorizes it; C additionally requires descriptor.seller to equal that collector. License issuer equals Offer.licenseIssuer or has issueLicense authority; key releaser equals that issuer or has releaseKey authority. Asset/Offer/Request IDs match every repeated commitment; chain and lineageAnchor match E/descriptor/package; price matches the unique duty, requirement, Challenge or actual successor increment. ReleasePolicy matches E, signed Terms and ReleaseEvidence byte-for-byte under JCS. POTATOES.evidenceDigest and settlement releaseEvidenceDigest equal the actual release digest. Verify settlement ID, exact txid/outpoint and allowed fulfillment profile; substituting another profile, beneficiary or amount is invalid. A collector receipt does not claim direct distribution to several beneficiaries.

Paid lookup uses a new explicit settlement profile https://bsv.brc.dev/apps/0198#paid-lookup-settlement-v1 (P), declared in the Offer mechanisms and critical extensions with value {version:1}. It is compatible with the BRC-170 brc105-single payment transport as specialized by E, but does not fabricate a multilateral Payment Demand. Its signed BRC-192 packet type is lch-lookup-settlement, with body {version:1,seller:Identity,buyer:Identity,requestId:Hex32,offerId:Hex32,assetId:Hex32,dutyUid:string,acquisitionId:Hex32,funding:{chain:Chain,txid:Hex32,outputIndex:U32},satoshis:U64,acceptancePolicy:ReleasePolicy,releaseEvidenceDigest:Hex32,issuedAt:U64,recoveryUntil:U64}. The signer is the authorized payee/collector, and the amount/output/acceptance are independently verified against the frozen BRC-195 challenge. Its ID is digest(lch-lookup-settlement,body). Context additionally contains paymentEvidence (present exactly in paid mode), a byte string of UTF-8 JCS {version:1,challenge:Challenge,payment:Evidence,release:ReleaseEvidence,derivationSuffix:string}; payment selects the exact challenged funding output. License.fulfillments is exactly [{dutyUid,settlementProfile:P,receiptIds:[settlementIdBytes]}]; License.extensions[E] is {version:1,mode:"paid-lookup",settlementId:bstr32} and License.critical includes E/P, with License.extensions[P]={version:1}. This expressly maps the ID to context.settlement, not to an LCH Payment Receipt. For C the analogous C fulfillment remains as in section 3. Other fulfillment fields are forbidden in these single-duty bindings.

Equivalent License reissue retains exact Agreement bytes/digest, request, asset, accepted rights/selection/key periods/commitments and settlement ID. Signature randomness, BRC-78 nonce and non-rights issuedAt may change, never the historical settlement/release basis or original entitlement. Decrypt and authenticate each selected content segment before exposing plaintext, check keyId against the CEK commitment and encryption period, and reject overgrant/unknown critical mechanisms before playback. Complete cryptographic/byte fixtures and qualification status are enumerated in the packet guide; no claim of deployable covenant acquisition is permitted without the registered family’s Script/domain qualification and compatible wallet integration.

6. Script-enforced collector revenue

For C, Offer.extensions[C] is exactly the following CBOR map (and C remains critical):

collector-revenue = {
  "version": 1,
  "family": "https://bsv.brc.dev/tokens/0197#revenue-listing-v1",
  "initialRevenue": {
    "revision": 0,
    "recipients": [1*8 {"identity": bstr .size 33, "weight": uint}]
  },
  "amendment": "unanimous-current-recipients",
  "remainders": "retain-until-payout",
  "retirement": "externally-funded-exact-top-up"
}

Recipients are sorted/unique by raw key, valid secp256k1 identities, and weights/total obey BRC-197. Convert identity byte strings to lowercase hex and revision 0 to JSON U64 "0" when comparing with descriptor.initialRevenue. Compare every entry and family exactly; a digest of a displayed schedule is insufficient. These initial terms are known before the Offer ID, so including them does not reintroduce the Offer/descriptor hash cycle. Paid mode does not carry C or claim script-enforced distribution of its payment.

An issuer selecting C explicitly accepts this schedule evolution rule: a descendant can amend recipients or shares only with seller authority and all current recipients’ transaction signatures, as verified by BRC-197. Preparation discloses the actual consumed outpoint and its current schedule/revision through domainEvidence. Purchase preserves that exact state and increments its value. Split preserves the schedule on both branches; merge requires matching current scripts. Payout pays each committed P2PKH destination in whole integer quanta and retains the remainder. Retirement distributes the complete balance with the separately authorized external top-up. No seller-only administrative bypass is permitted.

The initial Offer remains reusable after a valid amendment because C expressly authorizes that evolution; an outstanding preparation remains bound to its exact old outpoint and cannot silently follow an amendment. Amendment races require ordinary exact-transaction recovery and a new authorized preparation where necessary. Siblings and previously issued Licenses are not rewritten. If an Offer’s policy instead promises an immutable set of payout recipients, or immediate separate payments, this C profile is incompatible; do not claim that unanimous future amendment discharges a different promised duty.

The issuer and buyer verify the same portable genesis/transition package, current revenue state, purchase input/output scripts, increment and receipt. A settlement signature is attributable evidence of that validated purchase, not a replacement for it. The covenant provides enforceable distribution when a payout or retirement occurs; it does not impose a payout deadline, force the seller to submit an administrative transaction, or prove that a recipient has collected an output. Recipient consent authorizes the new distribution including retained proceeds, never an expansion or cancellation of a buyer’s existing licensed rights.

An administrative merge cannot satisfy this profile’s purchase duty or create a License: the issuer requires operation 1 and the exact prepared acquisition/request/recipient receipt. BRC-197 distinguishes a same-genesis provenance failure from economic loss. A merge involving an actually funded copy may conserve and add real constrained value in Script while failing this profile’s lineage checks. Do not count that contribution as sales, infer a purchaser entitlement from a larger balance, or describe rejection for false history as proof that funds were stolen.

Clients use BRC-192 section 10 to reconcile actual input consumption and current listing state across sources. Domain rejection does not undo a Bitcoin spend or resurrect its input listing. A chain reorganization can invalidate a current settlement assessment while leaving the historical License, Agreement and release evidence retained. Neither source re-entry nor a new provisional selection grants additional rights or initiates payment.