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; purchaseCommitment: 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 historical transaction, exact predecessor/successor, increment, receipt, genesis ancestry, the full BRC-197 purchase commitment and selected release evidence before marking the duty fulfilled. A seller signature alone cannot substitute for those checks. txid and successor identify the exact transaction for the original signed release; purchaseCommitment is the same full 32-byte authenticated preimage digest carried by BRC-196 POTATOES. Neither the License nor the settlement is silently rewritten if a different, independently valid txid for that commitment later becomes current on chain. Historical fulfillment and selected-chain currentness are separate checks: the License verifier must not require the historical successor outpoint to remain on the selected chain when an independently verified equivalent alias is current.

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 commitment and License Request can recover an equivalent License through the promised period. A verified txid alias does not create a second compensation duty, License, key grant or charge. For mined release, the settlement must name the actually mined alias before first issuance. If a weaker release policy delivered against an earlier alias, keep the original License, settlement and release evidence as historical authorization; assess a later mined alias separately by verifying its complete transaction and matching commitment. A later alias proves current economic settlement only through that independent chain assessment, never by changing the signed historical receipt. 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 BRC-197's mandatory permissionless payout and expiry retirement; a payout-less listing is not a valid v1 family member.

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, including reserve-stage activation, is a precondition to purchase. C requires the exact BRC-197 activation and active artifacts and all four active routes. Reproduce their 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 historical txid/outpoint, full purchase commitment and allowed fulfillment profile; substituting another profile, beneficiary or amount is invalid. If the selected chain contains an equivalent txid alias, verify that candidate's complete transaction, commitment and lineage before reporting the original License as currently paid. Do not substitute the alias into the signed settlement, infer equivalence from equal outputs alone or mint a second fulfillment. 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",
  "expiryHeight": uint,
  "initialRevenue": {
    "recipients": [1*8 {"identity": bstr .size 33, "weight": uint}]
  },
  "schedule": "immutable",
  "derivation": "brc29-anyone-fixed",
  "withdrawal": "permissionless-quanta",
  "remainders": "retain-until-payout",
  "retirement": "seller-child-or-expiry-height-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 when comparing with descriptor.initialRevenue. Compare every entry, family and expiryHeight exactly; a digest of a displayed schedule is insufficient. The Offer and descriptor disclose the expiry height and public fixed-child derivation risk before payment. 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 accepts one immutable schedule per lineage. Preparation discloses the actual consumed outpoint and schedule through domainEvidence, and rejects a listing already at or beyond expiryHeight under its current chain view. Purchase preserves the script and increments its value; split preserves the schedule on both branches. Anyone can initiate payout, which pays every committed BRC-29-derived child destination in whole integer quanta and retains the remainder. The protected seller child can retire early; after expiry anyone can retire with an exact externally funded top-up. A later expiry does not revoke a timely prepared purchase's BRC-196 delivery/recovery obligation. No seller-only payout bypass, merge or amendment exists.

The Offer remains reusable across valid purchases and splits until its cutoff or lineage retirement. An outstanding preparation remains bound to its exact old outpoint and cannot silently follow a competing purchase, split, payout or retirement. Siblings and previously issued Licenses are not rewritten. A changed recipient or share schedule requires a new Offer, descriptor and seller-authorized lineage. An Offer promising immediate separate payments is incompatible with this accumulation profile.

The issuer and buyer verify the same portable genesis/activation/transition package, schedule, purchase scripts, increment and receipt. A settlement signature is attributable evidence of that validated purchase, not a replacement for it. The covenant enables withdrawal by anyone and complete distribution after expiry, but it does not prove a recipient has spent the resulting output. All signers and recipients require fixed-child wallet support without exporting a private scalar.

Lineage and purchase validation follow BRC-197's ordinary Bitcoin finality rules. A valid settled transition is not excluded because it was previously non-final or uses locktime/sequences other than the recommended construction. A currently non-final purchase remains pending and cannot fulfill the compensation duty or release a License until the selected BRC-196 admission/release conditions are met. Recovery from a local rejection through an independently verified eligible alias follows BRC-196's state transitions under the same acquisition and purchase commitment; it does not create a new duty or alter an already signed settlement.

Only operation 1 and the exact prepared acquisition/request/recipient receipt can satisfy this profile's purchase duty or create a License. A copied Script, direct active output or unrelated funded contribution is not a lineage descendant and cannot be counted as a sale.

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.