Applicant

The Bitcoin Corporation Ltd

Inventor

Richard Boase

Date of Preparation

12 March 2026

Title of Invention

Automated Rights Inheritance and Revenue Cascade for Derivative Digital Works Using UTXO-Based Parent-Child Token Lineage

Critical Distinction — Application-Layer Protocol vs. Base-Layer Blockchain

This patent describes an overlay/application-layer (Layer 2) protocol operating on top of BSV's UTXO settlement layer. It does NOT modify the base blockchain protocol. All mechanisms described herein — lineage registries, revenue cascades, derivation attestations, and spending conditions — operate at the application/overlay layer, leveraging BSV's UTXO model, Merkle proofs, and script capabilities without requiring any changes to the base protocol. Throughout this specification, "on-chain" refers to data inscribed in blockchain transactions; the logic interpreting that data is executed by overlay network participants (lookup services, topic managers, and client software), not by blockchain miners. Blockchain miners settle the transactions; overlay participants interpret them.

Field of the Invention

The present invention relates to systems and methods for automatically propagating intellectual property rights and revenue entitlements through chains of derivative digital works using blockchain-based token lineage. More particularly, the invention concerns a protocol whereby the tokenisation of a digital work (content, patent, domain name, software, dataset, or any other digital asset) on a UTXO-based blockchain creates a parent token, and when a derivative work is subsequently created from that parent work, child tokens are issued with on-chain lineage records linking them to the parent token, such that a configurable percentage of all revenue generated by the child token is automatically routed upstream to parent token holders — with this cascade extending across multiple generations (grandparent, parent, child, grandchild, and beyond) with geometric decay, enforced atomically via UTXO spending conditions, and requiring no centralised royalty enforcement mechanism, no trusted intermediary, and no voluntary compliance by downstream creators.

Background of the Invention

Problem Statement

Derivative Works Generate Value That Never Reaches Original Creators

The creative economy is built on derivation. A novel inspires a film; a film inspires a soundtrack; a soundtrack inspires a remix; a remix inspires a TikTok dance. A patent enables a product; the product enables a service; the service enables an ecosystem. A domain name anchors a brand; the brand anchors a franchise; the franchise anchors merchandise. At every step, the derivative work generates economic value that is partially attributable to the original work — yet in practice, the original creator receives nothing from second-generation and subsequent derivatives. Copyright law provides theoretical rights to authorise derivatives, but enforcement is expensive, slow, jurisdictionally limited, and practically impossible once a work has been remixed, translated, adapted, or forked across multiple generations. The result is a systematic undercompensation of original creators and a legal fiction that derivative rights are meaningfully enforceable.
Existing Royalty Mechanisms Are Single-Level and Easily Circumvented

The NFT ecosystem introduced the concept of on-chain royalties, most notably through Ethereum's ERC-2981 (NFT Royalty Standard, EIP-2981, adopted 2022). ERC-2981 defines a royaltyInfo() function that returns a royalty recipient and percentage for a given token sale. However, ERC-2981 is purely advisory — marketplaces are not obligated to call the function or honour its output. Major NFT marketplaces (Blur, LooksRare, X2Y2) have explicitly bypassed royalty enforcement to offer lower trading fees, resulting in royalty payments to creators declining by over 80% between 2022 and 2024. Furthermore, ERC-2981 is single-level: it pays royalties to the original minter of a specific token, not to upstream creators of works from which the token's content was derived. There is no concept of multi-generational cascade.
Account-Model Blockchains Cannot Enforce Atomic Revenue Splits

On account-model blockchains (Ethereum, Solana, etc.), a token transfer is a state mutation in a smart contract. There is no inherent mechanism to require that a transfer transaction includes additional payment outputs. Royalty enforcement requires either: (a) wrapping all transfers through a contract that intercepts and redirects funds (easily bypassed by transferring the entire wallet, using a wrapper contract, or selling off-chain with on-chain delivery), or (b) relying on marketplace cooperation (which, as demonstrated, is unreliable when competition incentivises fee minimisation). The UTXO model, by contrast, allows a transaction's outputs to be structurally validated — a UTXO can only be spent if the spending transaction includes specified outputs, making revenue cascade enforcement a property of the transaction structure rather than a voluntary application-layer behaviour.
No System Traces Multi-Generational Derivation On-Chain

Existing blockchain systems record ownership transfers (who holds a token) but not derivation relationships (this work was derived from that work). A remix token has no on-chain link to the original song token. A translated ebook token has no on-chain link to the original language edition token. A forked software project token has no on-chain link to the upstream repository token. Without on-chain lineage, there is no data from which to compute multi-generational revenue cascades, even if a mechanism to enforce them existed.
Centralised Content ID Systems Are Opaque and Dispute-Heavy

YouTube's Content ID system is the most widely deployed derivative work detection system. It uses audio and video fingerprinting to detect when uploaded content matches copyrighted works in its database, and can automatically monetise, block, or track the derivative content. However, Content ID is: (a) centralised — YouTube controls the database, the matching algorithm, and the dispute resolution process; (b) opaque — creators cannot inspect the matching criteria or challenge decisions through any mechanism other than YouTube's internal appeals process; (c) single-platform — it only operates within YouTube; content distributed on other platforms is unmonitored; (d) biased toward large rights holders — major labels and studios have preferential access and dispute resolution, while independent creators face asymmetric enforcement; and (e) limited to audio/video — it does not cover text, software, patents, domains, datasets, or other digital asset types.
The Applicant's Existing Patent Portfolio Addresses Adjacent Problems But Not Multi-Generational Cascade

The Applicant has previously filed patent applications addressing related but distinct aspects of tokenised digital works:
- Tokenised Patent Licensing (bCorp-PAT-008) — Enables licensing a patent through token acquisition via a bonding curve. However, it binds a single token to a single patent; there is no mechanism for derivative patents to inherit revenue obligations from parent patents.
- Signed Semantic Triples (bCorp-PAT-011) — Provides a general mechanism for expressing relationships between digital entities as cryptographically signed subject-predicate-object triples. While a triple could express "WorkB isDerivedFrom WorkA," the Signed Semantic Triples system does not automate revenue flow based on those relationships — it records meaning but does not enforce economics.
- Decentralized Dividend Distribution (bCorp-PAT-005) — Enables competitive application-layer miners to distribute dividends to token holders. It distributes revenue to holders of a specific token but does not trace cross-token lineage or cascade revenue between different tokens in a derivation chain.
- POI Overlay State Verification (bCorp-PAT-015) — Ensures the correctness of derived state computations in overlay networks. It provides the verification infrastructure but does not define the specific lineage and cascade state that the present invention requires.
- Bit Trust (bCorp-PAT-010) — Registers intellectual property on-chain with identity-bound provenance. It proves authorship and existence but does not track derivative works or enforce revenue flow from derivatives to originals.
The present invention bridges these existing capabilities: it uses Signed Semantic Triples to express derivation relationships, Decentralized Dividend Distribution to deliver cascade payments, POI Overlay State Verification to ensure lineage state integrity, $401 identity for creator verification, and Bit Trust for IP registration — adding the novel multi-generational lineage registry, geometric revenue cascade, and atomic UTXO enforcement that none of the prior applications provide individually.

Prior Art Limitations

ERC-2981 (NFT Royalty Standard, Ethereum, 2022) — Defines a royaltyInfo() function returning a recipient address and royalty percentage for a given NFT sale. The standard is advisory only; callers are not required to honour the returned values. It supports only single-level royalties (original minter to current seller), not multi-generational cascades. It operates on the account model, where enforcement requires marketplace cooperation. It does not record derivation relationships — every NFT is treated as an independent creation with no concept of parent-child lineage.

ERC-2981 Enforcement Attempts (OpenSea Operator Filter, 2022–2023) — OpenSea attempted to enforce royalties by maintaining a blocklist of contracts that did not honour royaltyInfo(). Creators could opt into the Operator Filter Registry, which blocked transfers to non-compliant marketplaces. This was abandoned under competitive pressure from zero-royalty marketplaces. The approach was centralised (OpenSea controlled the blocklist), circumventable (new contract addresses could be deployed faster than they could be blocked), and addressed only enforcement of single-level royalties — not multi-generational cascade.

Creative Commons Licensing (2001–present) — Creative Commons provides standardised licence terms including provisions for derivative works (CC BY-SA requires derivatives to carry the same licence). However, CC licences: (a) are legally enforced, not technologically enforced — compliance depends on the derivative creator voluntarily attributing and licensing appropriately; (b) do not include any revenue sharing mechanism — even CC licences requiring attribution do not entitle the original creator to a share of derivative revenue; (c) have no on-chain representation or machine-readable enforcement mechanism; and (d) do not track multi-generational derivation chains.

YouTube Content ID (Google, 2007–present) — As described above, Content ID detects derivative audio/video content and can monetise it on behalf of rights holders. It is centralised, opaque, single-platform, biased toward large rights holders, limited to audio/video, and does not provide a generalised multi-asset derivative tracking or revenue cascade mechanism.

Audius Protocol (2020–present) — Audius is a decentralised music streaming protocol that tracks music ownership on-chain. It supports royalty payments to artists but does not track derivation relationships between tracks (e.g., a remix's lineage to the original). Revenue distribution is based on stream counts, not on derivation hierarchies.

Zora Protocol (2021–present) — Zora provides on-chain NFT infrastructure with creator-first economics, including a "creator reward" mechanism on mints. However, Zora's rewards are single-level (rewarding the creator of the specific collection being minted) and do not cascade through derivation chains. There is no concept of a parent-child token relationship where child token revenue flows to parent token holders.

The Graph Protocol (2020–present) — The Graph indexes blockchain data and makes it queryable. While it could theoretically be used to index derivation relationships if such relationships existed on-chain, The Graph itself does not define derivation semantics, does not create lineage records, and does not automate revenue distribution based on indexed relationships.

Patent Citation Networks (academic, various) — Academic literature has studied patent citation networks as graphs of intellectual derivation. However, patent citations are: (a) informational only — citing a patent does not create an obligation to pay the cited patent holder; (b) recorded in patent office databases, not on-chain; and (c) not connected to any automated revenue distribution mechanism.

No existing system combines: on-chain registration of parent-child derivation relationships between tokenised digital works; automated multi-generational revenue cascade with geometric decay; atomic enforcement of cascade payments via UTXO spending conditions; identity-bound derivation attestation using verified on-chain identity; contestation mechanisms for fraudulent derivation claims; multi-parent fork handling with proportional revenue splitting; and dust threshold termination for cascade efficiency.

Summary of the Invention

The present invention provides a system and method for automated rights inheritance and revenue cascade in derivative digital works, comprising:

(a) A Lineage Registry operating at the overlay layer of a UTXO-based blockchain, wherein each entry records a parent-child relationship between two tokenised digital works, including: the child token identifier, the parent token identifier, the derivation type (adaptation, translation, remix, fork, excerpt, annotation, or other), the revenue share percentage flowing from child to parent, the derivative creator's verified identity, and a block-anchored timestamp — such that the complete derivation history of any tokenised work is reconstructable from on-chain data;

(b) A Revenue Cascade Engine that, when revenue is generated from any token in a lineage tree, traces the token's ancestry through the Lineage Registry, computes the revenue share owed at each generation using geometric decay (each generation receives a configured percentage of the revenue passing through it), allocates shares to parent token holders proportionally to their holdings, and terminates the cascade when the per-holder share falls below a configurable dust threshold — producing a complete revenue distribution plan spanning the entire ancestry of the revenue-generating token;

(c) A Derivation Attestation Protocol whereby a creator of a derivative work signs an on-chain attestation linking the new work's token to one or more parent tokens, the attestation being bound to the creator's verified $401 identity chain, including a content similarity reference (hash of the derived portions or a semantic triple expressing the derivation relationship), and subject to a contestation window during which parent token holders may challenge fraudulent derivation claims;

(d) An Atomic Cascade Enforcement Mechanism leveraging UTXO spending conditions to ensure that when a child token generates revenue (through sale, licence fee, streaming payment, or any other monetisation event), the spending transaction MUST include outputs paying the cascade allocation to parent token holders — making the revenue share structurally inseparable from the revenue-generating transaction, not a separate voluntary payment;

(e) A Multi-Parent Fork Handling mechanism for derivative works derived from multiple parent works (e.g., a remix incorporating elements from two songs, a software project forking two upstream repositories), whereby the cascade share flowing upstream is split proportionally among parent lineages according to weights specified in the derivation attestation;

(f) A Lineage Contestation Protocol enabling parent token holders to challenge derivation attestations they believe to be fraudulent (false claims of derivation, either to parasitically associate with a successful parent work or to wrongfully impose cascade obligations on an independent work), with resolution through evidence submission, community adjudication, or oracle verification within a configurable contestation window;

(g) A Cascade Decay and Dust Threshold Termination mechanism ensuring that revenue cascades do not propagate infinitely or generate economically meaningless micro-payments, by applying geometric decay at each generation and terminating cascade computation when the per-holder allocation falls below a defined minimum (the dust threshold).

Detailed Description of the Invention

1. System Architecture

The Rights Inheritance Cascade system operates as an overlay network on top of the BSV blockchain's UTXO settlement layer. The system comprises the following principal components, each operating at the application layer:

1.1 Overlay Network Foundation

The system builds upon the BSV overlay network architecture defined by BRC-24 (Overlay Lookup Services) and related standards. The overlay network consists of:

Topic Managers — Application-layer nodes that determine which transactions are relevant to the Rights Inheritance Cascade protocol. A Topic Manager for this protocol admits transactions containing lineage records, derivation attestations, cascade payment commitments, and contestation events. It rejects transactions that do not conform to the protocol's data format.
Lookup Services — Application-layer nodes that index admitted transactions and provide queryable state. For this protocol, Lookup Services maintain: (a) the Lineage Registry (a directed acyclic graph of parent-child token relationships); (b) the Cascade State (precomputed revenue distribution maps for each token in the lineage tree); (c) the Attestation Index (pending, finalised, and contested derivation attestations); and (d) the Revenue History (historical cascade payments for audit and verification).
Synchronisation via GASP — Overlay nodes synchronise lineage data using the Graph-Aware Sync Protocol (GASP), ensuring that all nodes in the network maintain a consistent view of the lineage graph. Each lineage record, attestation, and cascade payment is a UTXO admitted to the overlay, and GASP ensures these UTXOs are propagated across all participating nodes.
Settlement via BSV — All lineage records, attestations, and cascade payments are settled on the BSV blockchain as standard transactions. Blockchain miners validate transaction structure and settle UTXOs; they have no knowledge of lineage semantics. The overlay layer interprets the settled transactions.

1.2 Token Foundation

Every digital work in the system is represented by a token on the BSV blockchain (BSV-20 or BSV-21 standard). A token has:

A genesis transaction — the transaction in which the token was first minted, containing the work's metadata (title, description, content hash, creator identity).
A total supply — the number of token units in circulation (default: 100,000,000,000 — one hundred billion, per the Applicant's standard token architecture).
A holder set — the set of addresses holding token balances, queryable from on-chain state.
A revenue stream — any monetisation event generating satoshis attributable to the token (sales, licence fees, streaming payments, secondary market royalties, dividend distributions).

The present invention does not prescribe a specific token standard; it operates with any token representation where: (a) the token has an identifiable genesis reference, (b) the set of holders and their balances can be determined from on-chain state, and (c) the token can be the subject of revenue-generating transactions.

1.3 Lineage Registry

The Lineage Registry is the core data structure of the system. It is a directed acyclic graph (DAG) where:

Nodes represent tokenised digital works (identified by their token genesis transaction ID).
Edges represent derivation relationships (directed from child to parent, indicating "this child is derived from this parent").
Edge weights represent the revenue share percentage flowing from child to parent along that edge.

Each edge in the Lineage Registry is recorded on-chain as a UTXO containing a Lineage Record.

1.3.1 Lineage Record Data Format

A Lineage Record is inscribed as an OP_FALSE OP_RETURN output with the following byte layout:

OP_FALSE OP_RETURN <fields...>

Offset  Size     Field                        Encoding
──────  ───────  ───────────────────────────  ─────────────────────────
0       4        Protocol identifier          0x52 0x49 0x43 0x50 ("RICP")
4       1        Version byte                 0x01
5       1        Operation type               0x01 = lineage record
                                              0x02 = derivation attestation
                                              0x03 = cascade payment commitment
                                              0x04 = contestation event
                                              0x05 = contestation resolution
                                              0x06 = lineage amendment
6       32       Child token genesis TXID     SHA-256 hash (the derivative work)
38      32       Parent token genesis TXID    SHA-256 hash (the original work)
70      1        Derivation type code         0x01 = adaptation
                                              0x02 = translation
                                              0x03 = remix
                                              0x04 = fork (software)
                                              0x05 = excerpt
                                              0x06 = annotation
                                              0x07 = sequel
                                              0x08 = compilation
                                              0x09 = cover version
                                              0x0A = parody
                                              0x0B = port (platform)
                                              0x0C = training data derivative
                                              0xFF = other (described in metadata)
71      2        Revenue share percentage     uint16 little-endian, basis points
                                              (e.g., 1000 = 10.00%, max 10000 = 100%)
73      32       Creator $401 identity root   TXID of creator's $401 root inscription
105     32       Content similarity hash      SHA-256 hash of the derived portions
                                              of the child work, or 0x00×32 if not
                                              applicable
137     32       Attestation reference TXID   TXID of the derivation attestation
                                              transaction (0x00×32 if attestation
                                              and lineage record are in same tx)
169     4        Contestation window          uint32 little-endian, seconds
                                              (default: 2,592,000 = 30 days)
173     8        Timestamp                    uint64 little-endian, Unix epoch seconds
181     4        Block height reference       uint32 little-endian, block at which
                                              the record was created
185     var      Metadata payload             JSON (length-prefixed: 4-byte LE)
                                              containing: title, description,
                                              derivation rationale, content URLs,
                                              and any additional context

Each field is pushed as a separate data item in the OP_RETURN script. The Bitcoin script structure is:

OP_FALSE OP_RETURN
  <4 bytes: "RICP">
  <1 byte: version>
  <1 byte: op_type>
  <32 bytes: child_token_genesis_txid>
  <32 bytes: parent_token_genesis_txid>
  <1 byte: derivation_type>
  <2 bytes: revenue_share_bps>
  <32 bytes: creator_401_root_txid>
  <32 bytes: content_similarity_hash>
  <32 bytes: attestation_ref_txid>
  <4 bytes: contestation_window_seconds>
  <8 bytes: timestamp>
  <4 bytes: block_height>
  <M bytes: metadata_json>

For a derivative work with multiple parents (multi-parent fork), multiple Lineage Records are created in the same transaction — one per parent, each with its own revenue share percentage. The sum of revenue share percentages across all parent lineage records for a given child token MUST NOT exceed 10,000 basis points (100%).

1.3.2 Lineage Record Transaction Structure

A Lineage Record registration is a single Bitcoin transaction with the following structure:

TRANSACTION: Lineage Record Registration
═══════════════════════════════════════════════════════════════

INPUT 0:  Creator's UTXO
          scriptSig: <sig> <creator_pubkey>
          (funds the registration + miner fee)

OUTPUT 0: Lineage Record inscription (OP_RETURN)
          scriptPubKey: OP_FALSE OP_RETURN <RICP> <0x01> <0x01>
                        <child_token_txid:32> <parent_token_txid:32>
                        <derivation_type:1> <revenue_share_bps:2>
                        <creator_401_root:32> <similarity_hash:32>
                        <attestation_ref:32> <contest_window:4>
                        <timestamp:8> <block_height:4>
                        <metadata_json:var>
          value: 0

OUTPUT 1: Registration fee to Lineage Registry operator
          scriptPubKey: OP_DUP OP_HASH160 <registry_operator_pkh>
                        OP_EQUALVERIFY OP_CHECKSIG
          value: [configurable fee, e.g., 10,000 satoshis]

OUTPUT 2: Change
          scriptPubKey: OP_DUP OP_HASH160 <creator_pkh>
                        OP_EQUALVERIFY OP_CHECKSIG
          value: [input value - fee - miner fee]

For multi-parent registrations, additional OP_RETURN outputs (OUTPUT 1, 2, ..., N) are included, one per parent lineage record, followed by the fee output and change output.

1.4 Derivation Attestation Protocol

Before a Lineage Record is considered finalised, the creator of the derivative work must provide a Derivation Attestation — a signed declaration that the new work is derived from the specified parent work(s).

1.4.1 Attestation Data Format

A Derivation Attestation is inscribed as an OP_FALSE OP_RETURN output with operation type 0x02:

OP_FALSE OP_RETURN <fields...>

Offset  Size     Field                        Encoding
──────  ───────  ───────────────────────────  ─────────────────────────
0       4        Protocol identifier          0x52 0x49 0x43 0x50 ("RICP")
4       1        Version byte                 0x01
5       1        Operation type               0x02 (derivation attestation)
6       32       Child token genesis TXID     The derivative work's token
38      1        Parent count (N)             uint8 (number of parent works)
39      N×32     Parent token genesis TXIDs   Array of N × 32-byte TXIDs
39+N×32 32       Creator $401 identity root   TXID of creator's $401 root
71+N×32 N×2      Revenue share per parent     Array of N × uint16 (basis points)
                                              Same order as parent TXIDs
71+N×34 32       Derivative content hash      SHA-256 of the complete derivative work
103+N×34 32      Source content reference      SHA-256 of the specific portions derived
                                              from parent work(s), or Merkle root if
                                              multiple portions
135+N×34 64      Creator signature            Schnorr signature over all preceding
                                              fields, using the private key linked to
                                              the creator's $401 identity chain
199+N×34 8       Timestamp                    uint64 little-endian
207+N×34 var     Attestation metadata         JSON (length-prefixed: 4-byte LE)
                                              containing: description of derivation,
                                              nature of derived elements, creator
                                              statement of originality for non-derived
                                              portions

The attestation metadata JSON includes structured fields describing the nature of the derivation:

{
  "attestation_version": "1.0",
  "child_token_txid": "<child_token_genesis_txid>",
  "parents": [
    {
      "parent_token_txid": "<parent_token_genesis_txid_1>",
      "derivation_type": "remix",
      "derived_elements": "Vocal melody from bars 16-48, harmonic progression from chorus",
      "revenue_share_bps": 1000,
      "rationale": "Child work incorporates the vocal melody and harmonic structure of the parent work's chorus section"
    },
    {
      "parent_token_txid": "<parent_token_genesis_txid_2>",
      "derivation_type": "excerpt",
      "derived_elements": "Drum pattern from intro (first 8 bars)",
      "revenue_share_bps": 500,
      "rationale": "Child work samples the drum pattern from the parent work's introduction"
    }
  ],
  "originality_statement": "All elements not attributed to parent works are original creations of the attesting creator",
  "creator_401_identity": "<creator_401_root_txid>",
  "legal_acknowledgement": "The creator acknowledges that this attestation creates a binding revenue cascade obligation"
}

1.4.2 Attestation Lifecycle

A Derivation Attestation follows a defined lifecycle:

Pending — The attestation is inscribed on-chain. The contestation window begins. During this period, parent token holders may contest the attestation (see Section 1.8).
Finalised — The contestation window expires without any valid contest. The associated Lineage Record(s) become active. Revenue cascade obligations take effect.
Contested — A parent token holder has filed a contestation. The attestation enters dispute resolution (see Section 1.8).
Revoked — The attestation is invalidated through successful contestation. The associated Lineage Records are marked void. No revenue cascade obligation exists.
Amended — The attestation is replaced by a new attestation with different terms (e.g., adjusted revenue share percentages), signed by both the child creator and affected parent token holders.

The attestation state is tracked by overlay Lookup Services and is queryable by any participant.

1.4.3 Attestation Verification

Any party can verify a Derivation Attestation by:

Retrieving the attestation transaction from the blockchain.
Parsing the RICP-formatted OP_RETURN data.
Verifying the creator's Schnorr signature against the $401 identity chain public key.
Confirming that the $401 identity root TXID references a valid, active identity chain with sufficient identity strength (Level 2 or higher recommended for high-value derivations).
Checking the attestation lifecycle state via the overlay Lookup Service.
If finalised, confirming the associated Lineage Records are active.

1.5 Revenue Cascade Engine

The Revenue Cascade Engine is the computational core of the system. It operates within overlay Lookup Services and computes the revenue distribution whenever a monetisation event occurs for any token in the lineage tree.

1.5.1 Cascade Computation Algorithm

The following pseudocode describes the complete cascade computation:

PROCEDURE: computeRevenueCascade(
    revenue_token_txid,     // Token that generated revenue
    revenue_amount_sats,    // Total revenue in satoshis
    dust_threshold_sats,    // Minimum payout per holder (default: 1 sat)
    max_generations         // Maximum cascade depth (default: 10)
)

RETURNS: CascadeDistributionPlan {
    payments: Array<{
        recipient_address: string,
        amount_sats: integer,
        token_txid: string,          // Which token's holders are being paid
        generation: integer,         // How many generations from revenue source
        lineage_path: Array<string>  // TXIDs tracing the path from child to this ancestor
    }>,
    total_cascade_sats: integer,     // Total satoshis flowing upstream
    creator_retained_sats: integer,  // Amount retained by the revenue token's creator
    dust_terminated_at: integer,     // Generation at which dust threshold was reached
    cascade_depth: integer           // Actual depth of cascade traversal
}

BEGIN

    distribution_plan = new CascadeDistributionPlan()
    distribution_plan.payments = []
    distribution_plan.total_cascade_sats = 0

    // ─── PHASE 1: LINEAGE TREE TRAVERSAL ────────────────────────
    // Build the ancestry tree for the revenue-generating token
    ancestry = traceAncestry(revenue_token_txid, max_generations)
    // Returns a tree structure:
    // {
    //   token_txid: string,
    //   parents: Array<{
    //     parent_token_txid: string,
    //     revenue_share_bps: uint16,
    //     derivation_type: uint8,
    //     lineage_record_txid: string,
    //     parents: [...] (recursive)
    //   }>
    // }

    if ancestry.parents is empty:
        // Root token — no cascade obligations
        distribution_plan.creator_retained_sats = revenue_amount_sats
        distribution_plan.dust_terminated_at = 0
        distribution_plan.cascade_depth = 0
        return distribution_plan

    // ─── PHASE 2: RECURSIVE CASCADE COMPUTATION ─────────────────
    // Compute cascade allocations using depth-first traversal

    remaining_sats = revenue_amount_sats

    FUNCTION cascadeUpstream(
        current_node,
        available_sats,
        generation,
        lineage_path
    )
        if generation > max_generations:
            return

        for each parent_edge in current_node.parents:
            // Compute this parent's share of available satoshis
            share_bps = parent_edge.revenue_share_bps
            parent_share_sats = floor(available_sats × share_bps / 10000)

            if parent_share_sats < dust_threshold_sats:
                // Dust threshold reached — terminate this branch
                distribution_plan.dust_terminated_at = min(
                    distribution_plan.dust_terminated_at or generation,
                    generation
                )
                continue

            // Deduct from remaining
            remaining_sats = remaining_sats - parent_share_sats

            // Enumerate holders of the parent token
            parent_holders = enumerateTokenHolders(parent_edge.parent_token_txid)
            parent_total_supply = getTotalSupply(parent_edge.parent_token_txid)

            // Distribute parent_share_sats proportionally among parent holders
            for each holder in parent_holders:
                holder_share = floor(
                    parent_share_sats × holder.balance / parent_total_supply
                )
                if holder_share >= dust_threshold_sats:
                    // Resolve holder's payout address via $401 identity
                    payout_address = resolve401PayoutAddress(holder.identity_txid)
                    if payout_address is null:
                        payout_address = holder.address  // fallback to token address

                    new_path = lineage_path + [parent_edge.parent_token_txid]

                    distribution_plan.payments.append({
                        recipient_address: payout_address,
                        amount_sats: holder_share,
                        token_txid: parent_edge.parent_token_txid,
                        generation: generation,
                        lineage_path: new_path
                    })

                    distribution_plan.total_cascade_sats += holder_share

            // Recurse upstream — the parent's parents receive a share of the
            // parent's share (geometric decay)
            parent_ancestry = getAncestry(parent_edge.parent_token_txid)
            if parent_ancestry.parents is not empty:
                cascadeUpstream(
                    parent_ancestry,
                    parent_share_sats,  // cascade is computed on parent's share
                    generation + 1,
                    lineage_path + [parent_edge.parent_token_txid]
                )
        END for
    END FUNCTION

    cascadeUpstream(ancestry, revenue_amount_sats, 1, [revenue_token_txid])

    distribution_plan.creator_retained_sats = remaining_sats
    distribution_plan.cascade_depth = max(p.generation for p in distribution_plan.payments)

    return distribution_plan

END

1.5.2 Geometric Decay Formula

The revenue share at each generation follows geometric decay. If the base revenue share is r (expressed as a fraction, e.g., 0.10 for 10%), then the share reaching generation g (where generation 1 is the immediate parent) is:

share(g) = R × r^g

Where:

R = total revenue amount (in satoshis)
r = revenue share fraction per generation (e.g., 0.10)
g = generation number (1 = parent, 2 = grandparent, etc.)

For a uniform 10% cascade (r = 0.10) on a revenue event of 1,000,000 satoshis:

Generation 1 (parent):        1,000,000 × 0.10^1 = 100,000 sats  (10%)
Generation 2 (grandparent):   1,000,000 × 0.10^2 =  10,000 sats  (1%)
Generation 3 (great-grandparent): 1,000,000 × 0.10^3 = 1,000 sats (0.1%)
Generation 4:                 1,000,000 × 0.10^4 =     100 sats  (0.01%)
Generation 5:                 1,000,000 × 0.10^5 =      10 sats  (0.001%)
Generation 6:                 1,000,000 × 0.10^6 =       1 sat   (0.0001%)
Generation 7:                 1,000,000 × 0.10^7 =       0.1 sat → below dust → TERMINATE

The cascade terminates at generation 7 because the per-generation allocation falls below the dust threshold of 1 satoshi. The total upstream cascade is 111,111 satoshis (11.1111%), and the revenue token creator retains 888,889 satoshis (88.8889%).

The geometric series converges. For an infinite cascade with rate r:

total_cascade_fraction = r / (1 - r)    (when applied to remaining after each generation)

However, in practice, the cascade is bounded by the dust threshold and the maximum generation limit, so the actual total cascade fraction is always less than the theoretical infinite sum.

1.5.3 Non-Uniform Cascade Rates

Different edges in the lineage graph may have different revenue share percentages. For example:

A remix of Song A might owe 15% to Song A (heavy sampling)
A translation of Book B might owe 8% to Book B (structural derivation, new expression)
A fork of Software C might owe 5% to Software C (shared codebase, significant new development)

When cascade rates are non-uniform, the geometric decay at each generation uses the specific rate defined in that generation's Lineage Record. The cascade computation uses the actual revenue_share_bps from each edge, not a global rate.

1.5.4 Cascade Computation with Multiple Parents (Fork Handling)

When a derivative work has multiple parents, the first-generation cascade is split across parents according to the revenue share percentages in their respective Lineage Records. The sum of first-generation shares cannot exceed 100%.

Example: A music mashup (Token M) combines elements from Song A (Token A, 12% share) and Song B (Token B, 8% share):

Revenue event: 1,000,000 sats from Token M

Generation 1:
  → Token A holders receive: 1,000,000 × 12% = 120,000 sats
  → Token B holders receive: 1,000,000 × 8%  =  80,000 sats
  → Total G1 cascade: 200,000 sats (20%)

Generation 2 (parents of Token A and Token B):
  → If Token A was derived from Token X (10% share):
    Token X holders receive: 120,000 × 10% = 12,000 sats
  → If Token B was derived from Token Y (10% share):
    Token Y holders receive: 80,000 × 10% = 8,000 sats
  → Total G2 cascade: 20,000 sats

Generation 3 (grandparents):
  → Token X's parent (if any) receives 10% of 12,000 = 1,200 sats
  → Token Y's parent (if any) receives 10% of 8,000  =   800 sats
  → Total G3 cascade: 2,000 sats

... and so on with geometric decay.

Creator of Token M retains:
  1,000,000 - 200,000 - 20,000 - 2,000 - ... = ~777,778 sats

The pseudocode in Section 1.5.1 handles this naturally through its depth-first traversal of the ancestry tree, with each parent edge carrying its own revenue share rate.

1.6 Atomic Cascade Enforcement via UTXO Spending Conditions

The critical innovation of the present system is that cascade payments are not voluntary or advisory — they are structurally required by the UTXO spending conditions of the child token's revenue transactions.

1.6.1 Cascade-Aware Token Output Script

When a token with active lineage records (i.e., a child token with one or more parent tokens in the Lineage Registry) generates revenue through a monetisation event, the overlay network enforces that the spending transaction includes cascade payment outputs.

The enforcement operates as follows:

Token Monetisation Event Detection — The overlay Topic Manager monitors for transactions that spend UTXOs associated with tokens in the Lineage Registry. When a revenue-generating transaction is detected (e.g., a token sale, a licence fee payment, a streaming micropayment), the Topic Manager checks whether the token has active lineage records.
Cascade Payment Requirement — If the token has active lineage records, the Topic Manager verifies that the spending transaction includes outputs matching the cascade distribution plan. Specifically, for each generation in the cascade:
- An output paying the parent token holders' aggregated share to a cascade distribution address (or multiple outputs, one per parent holder, for small holder sets).
- The output amount(s) matching the computed cascade allocation within a tolerance of ±1 satoshi (to account for rounding).
Transaction Admission — The Topic Manager admits the transaction to the overlay only if the cascade payment outputs are present and correct. A transaction that omits cascade payments is rejected by the overlay — it is still valid on the base blockchain (blockchain miners do not enforce overlay semantics), but it is not recognised by the overlay network, meaning the token transfer or revenue event is not reflected in the overlay's state.
Practical Effect — Because the overlay network is the authoritative source of token state (balances, ownership, legitimacy), a transaction rejected by the overlay is economically void within the token ecosystem. The buyer of a token through a non-cascade-paying transaction would not be recognised as the holder by any overlay participant, marketplace, or service. This creates a de facto enforcement mechanism: compliance with cascade payments is required for economic participation, even though it is not enforced at the base blockchain layer.

1.6.2 Cascade Payment Transaction Structure

A complete cascade-paying revenue transaction has the following structure:

TRANSACTION: Token Sale with Revenue Cascade
═══════════════════════════════════════════════════════════════

INPUT 0:  Buyer's payment UTXO
          scriptSig: <sig> <buyer_pubkey>
          (funds the purchase + cascade payments + miner fee)

OUTPUT 0: Payment to seller (child token creator/holder)
          scriptPubKey: OP_DUP OP_HASH160 <seller_pkh>
                        OP_EQUALVERIFY OP_CHECKSIG
          value: [sale price minus cascade obligations]

OUTPUT 1: Cascade payment to Generation 1, Parent A holders
          scriptPubKey: OP_DUP OP_HASH160 <parent_a_cascade_address>
                        OP_EQUALVERIFY OP_CHECKSIG
          value: [parent A's cascade share in satoshis]

OUTPUT 2: Cascade payment to Generation 1, Parent B holders
          (if multi-parent derivative)
          scriptPubKey: OP_DUP OP_HASH160 <parent_b_cascade_address>
                        OP_EQUALVERIFY OP_CHECKSIG
          value: [parent B's cascade share in satoshis]

OUTPUT 3: Cascade payment to Generation 2, Grandparent X holders
          scriptPubKey: OP_DUP OP_HASH160 <grandparent_x_cascade_address>
                        OP_EQUALVERIFY OP_CHECKSIG
          value: [grandparent X's cascade share in satoshis]

...       (additional outputs for deeper generations, up to dust threshold)

OUTPUT N: Cascade Payment Commitment inscription (OP_RETURN)
          scriptPubKey: OP_FALSE OP_RETURN <RICP> <0x01> <0x03>
                        <revenue_token_txid:32> <revenue_amount:8>
                        <cascade_merkle_root:32> <generation_count:1>
                        <timestamp:8>
          value: 0

OUTPUT N+1: Token transfer to buyer (BSV-21 token carrier)
            scriptPubKey: OP_DUP OP_HASH160 <buyer_pkh>
                          OP_EQUALVERIFY OP_CHECKSIG
            value: 1 (token carrier UTXO)

OUTPUT N+2: Change to buyer
            scriptPubKey: OP_DUP OP_HASH160 <buyer_pkh>
                          OP_EQUALVERIFY OP_CHECKSIG
            value: [remaining change]

The Cascade Payment Commitment (operation type 0x03) provides a compact proof that the transaction satisfies all cascade obligations. Its Merkle root covers all cascade payment entries:

1.6.3 Cascade Payment Commitment Data Format

OP_FALSE OP_RETURN <fields...>

Offset  Size     Field                        Encoding
──────  ───────  ───────────────────────────  ─────────────────────────
0       4        Protocol identifier          0x52 0x49 0x43 0x50 ("RICP")
4       1        Version byte                 0x01
5       1        Operation type               0x03 (cascade payment commitment)
6       32       Revenue token genesis TXID   The token that generated revenue
38      8        Revenue amount               uint64 LE, total revenue in satoshis
46      32       Cascade Merkle root           SHA-256 Merkle root of all cascade
                                              payment entries (see below)
78      1        Generation count             uint8, number of generations in cascade
79      1        Parent count                 uint8, number of distinct parent tokens
                                              receiving cascade payments
80      8        Total cascade amount         uint64 LE, total satoshis paid upstream
88      8        Creator retained amount      uint64 LE, satoshis retained by seller
96      1        Dust threshold reached        0x00 = no, 0x01 = yes
97      8        Timestamp                    uint64 LE, Unix epoch seconds

The Cascade Merkle root is computed from an ordered list of Cascade Payment Entries:

Cascade Payment Entry (leaf of the Merkle tree):

Offset  Size     Field                        Encoding
──────  ───────  ───────────────────────────  ─────────────────────────
0       32       Parent token genesis TXID    The parent token receiving payment
32      1        Generation                   uint8, generation number (1 = parent)
33      8        Amount                       uint64 LE, satoshis paid to this parent's
                                              holders at this generation
41      32       Output TXID                  TXID of the payment output (self-ref
                                              if in same transaction)
73      4        Output index                 uint32 LE, vout of the payment output
77      2        Revenue share bps            uint16 LE, the rate from the lineage record
79      32       Lineage record TXID          The lineage record governing this edge

Each entry is hashed (SHA-256) to produce a leaf, and leaves are combined pairwise to produce the Merkle root. This allows any observer to verify that the cascade payments in the transaction match the cascade obligations from the Lineage Registry, without needing to traverse the entire lineage tree — the Merkle root provides a compact commitment.

1.6.4 Cascade Distribution Address

For parent tokens with large holder sets (hundreds or thousands of holders), including individual payment outputs for each holder in every cascade transaction would be impractical. Instead, the cascade payment for a given parent token at a given generation is paid to a Cascade Distribution Address — a single address controlled by the overlay's distribution mechanism (analogous to the dividend pool in the Applicant's Decentralized Dividend Distribution patent).

The Cascade Distribution Address functions as follows:

Revenue cascade payments accumulate at the distribution address.
When the accumulated balance exceeds a distribution threshold (configurable, e.g., 100,000 satoshis), the overlay's distribution mechanism (competitive application-layer miners, as described in the Decentralized Dividend Distribution patent) triggers a distribution event.
The distribution event pays each parent token holder their proportional share of the accumulated cascade payments.
The distribution is performed by competing $402 miners, providing redundancy and censorship resistance.

This batching mechanism ensures that cascade payments are efficient even for widely-held parent tokens, while maintaining the atomicity guarantee — the cascade payment is included in the revenue transaction (paid to the distribution address), even though the individual holder distributions occur asynchronously.

1.7 Lineage Tree Traversal and Ancestry Resolution

The overlay Lookup Service maintains a complete index of all Lineage Records, enabling efficient ancestry resolution for any token in the system.

1.7.1 Ancestry Resolution Algorithm

PROCEDURE: traceAncestry(
    token_txid,           // Token to trace ancestry for
    max_depth,            // Maximum generations to traverse (default: 10)
    current_depth = 0     // Current recursion depth
)

RETURNS: AncestryNode {
    token_txid: string,
    parents: Array<AncestryEdge>
}

AncestryEdge {
    parent_token_txid: string,
    revenue_share_bps: uint16,
    derivation_type: uint8,
    lineage_record_txid: string,
    attestation_state: string,  // "pending", "finalised", "contested", "revoked"
    parents: Array<AncestryEdge>  // Recursive: this parent's own parents
}

BEGIN
    if current_depth >= max_depth:
        return { token_txid: token_txid, parents: [] }

    // Query Lookup Service for active lineage records where this token is the child
    lineage_records = lookupService.query(
        overlay: "ricp-lineage",
        filter: { child_token_txid: token_txid, attestation_state: "finalised" }
    )

    if lineage_records is empty:
        return { token_txid: token_txid, parents: [] }

    node = { token_txid: token_txid, parents: [] }

    for each record in lineage_records:
        // Recursively trace each parent's ancestry
        parent_ancestry = traceAncestry(
            record.parent_token_txid,
            max_depth,
            current_depth + 1
        )

        edge = {
            parent_token_txid: record.parent_token_txid,
            revenue_share_bps: record.revenue_share_bps,
            derivation_type: record.derivation_type,
            lineage_record_txid: record.txid,
            attestation_state: record.attestation_state,
            parents: parent_ancestry.parents
        }

        node.parents.append(edge)

    return node

END

1.7.2 Cycle Prevention

The Lineage Registry is a directed acyclic graph (DAG). Cycles are prevented by the following invariant: a Lineage Record linking child token C to parent token P is only admitted by the Topic Manager if:

Token P's genesis transaction has an earlier block height than Token C's genesis transaction. A child cannot be older than its parent.
Token C does not appear as an ancestor of Token P at any depth. The Topic Manager performs a cycle detection check by tracing P's ancestry and verifying that C does not appear.

If either condition fails, the Lineage Record is rejected. This ensures the lineage graph is always a DAG, and ancestry traversal always terminates.

1.7.3 Lineage Graph Caching

For frequently-accessed tokens with deep lineage histories, the Lookup Service maintains a pre-computed cache of ancestry trees and cascade distribution plans. The cache is invalidated when:

A new Lineage Record is finalised for any token in the cached ancestry tree.
A Lineage Record in the cached tree is revoked through contestation.
A Lineage Record's revenue share percentage is amended.

The cache ensures that cascade computation for a revenue event is O(1) in the common case (cache hit) rather than O(D × P) where D is the tree depth and P is the average number of parents per node.

1.8 Lineage Contestation Protocol

The Contestation Protocol enables parent token holders to challenge derivation attestations they believe to be fraudulent.

1.8.1 Contestation Scenarios

A derivation attestation may be contested for the following reasons:

False Derivation Claim — The child work is not actually derived from the claimed parent work. The child creator has falsely claimed derivation to associate their token with a successful parent token's brand or community (parasitic association).
Wrongful Cascade Imposition — The child work is independent, and the derivation claim is made by a third party (not the child creator) attempting to impose cascade obligations on an independently created work.
Incorrect Revenue Share — The derivation is genuine, but the claimed revenue share percentage is unreasonably high or low relative to the actual degree of derivation.
Incorrect Derivation Type — The derivation type code does not accurately describe the relationship (e.g., claiming "remix" when the actual relationship is "annotation").
Identity Mismatch — The attestation is signed by an identity that is not the legitimate creator of the child work.

1.8.2 Contestation Data Format

A Contestation Event is inscribed as an OP_FALSE OP_RETURN output with operation type 0x04:

OP_FALSE OP_RETURN <fields...>

Offset  Size     Field                        Encoding
──────  ───────  ───────────────────────────  ─────────────────────────
0       4        Protocol identifier          0x52 0x49 0x43 0x50 ("RICP")
4       1        Version byte                 0x01
5       1        Operation type               0x04 (contestation event)
6       32       Attestation TXID             TXID of the derivation attestation
                                              being contested
38      32       Contestant $401 identity     TXID of contestant's $401 root
                                              inscription
70      1        Contestation reason code     0x01 = false derivation
                                              0x02 = wrongful imposition
                                              0x03 = incorrect revenue share
                                              0x04 = incorrect derivation type
                                              0x05 = identity mismatch
                                              0xFF = other (described in evidence)
71      32       Evidence hash                SHA-256 hash of the evidence payload
                                              submitted alongside the contestation
103     64       Contestant signature         Schnorr signature over preceding fields
167     8        Timestamp                    uint64 LE
175     4        Proposed resolution          uint32 LE, basis points of proposed
                                              revised revenue share (0 = revoke
                                              entirely)
179     var      Evidence payload             JSON (length-prefixed: 4-byte LE)
                                              containing the evidence supporting
                                              the contestation

1.8.3 Contestation Standing

Not any party can contest a derivation attestation. Standing to contest is limited to:

Parent Token Holders — Any holder of the parent token referenced in the attestation. They have standing because the attestation creates revenue obligations flowing to them (or, in the case of false derivation, creates unwanted association with their token).
Child Token Creator — The creator of the child token can contest if a third party has filed a derivation attestation that the creator did not authorise (wrongful imposition scenario).
Root Token Holders — Any holder of the root token (the ultimate ancestor in the lineage tree) has standing to contest any attestation in the lineage chain, as fraudulent attestations at any point in the chain affect the integrity of the cascade flowing to the root.

Standing is verified by the overlay Topic Manager before admitting a contestation event. The contestant's $401 identity must be linked to addresses holding tokens in one of the qualifying categories.

1.8.4 Contestation Resolution

Contestations are resolved through one of three mechanisms:

Automatic Resolution (No Response) — If the attestation creator does not respond to the contestation within a configurable response window (default: 14 days), the attestation is automatically revoked. This prevents abandoned or fraudulent attestations from persisting.
Bilateral Agreement — The contestant and the attestation creator may jointly sign a resolution transaction that either: (a) revokes the attestation, (b) amends the revenue share percentage, (c) amends the derivation type, or (d) dismisses the contestation. Bilateral resolution is inscribed on-chain as operation type 0x05.
Oracle-Mediated Resolution — For disputes that cannot be resolved bilaterally, the parties may invoke a designated oracle (a trusted third party or a decentralised arbitration service such as a DAO vote or a prediction market). The oracle's decision is inscribed on-chain as a resolution event. The oracle mechanism is configurable per overlay deployment; the protocol defines the resolution event format but does not mandate a specific oracle.

1.8.5 Contestation Resolution Data Format

OP_FALSE OP_RETURN <fields...>

Offset  Size     Field                        Encoding
──────  ───────  ───────────────────────────  ─────────────────────────
0       4        Protocol identifier          0x52 0x49 0x43 0x50 ("RICP")
4       1        Version byte                 0x01
5       1        Operation type               0x05 (contestation resolution)
6       32       Contestation TXID            TXID of the contestation event
38      32       Attestation TXID             TXID of the original attestation
70      1        Resolution type              0x01 = automatic (no response)
                                              0x02 = bilateral agreement
                                              0x03 = oracle-mediated
                                              0x04 = dismissed (contestation invalid)
71      1        Outcome                      0x01 = attestation revoked
                                              0x02 = attestation amended
                                              0x03 = contestation dismissed
                                              0x04 = attestation confirmed
72      2        Amended revenue share bps    uint16 LE (only if outcome = 0x02)
                                              0x0000 if not applicable
74      32       Resolver identity             $401 root TXID of the resolving party
                                              (oracle, or both parties for bilateral)
106     64       Resolver signature           Schnorr signature
170     8        Timestamp                    uint64 LE
178     var      Resolution rationale         JSON (length-prefixed: 4-byte LE)

1.9 Cascade Decay and Dust Threshold Mechanics

1.9.1 Dust Threshold Definition

The dust threshold is the minimum amount of satoshis that constitutes a meaningful payment. Any cascade allocation that falls below the dust threshold is not distributed and is instead retained by the nearest downstream token in the lineage chain.

The dust threshold is configurable at three levels:

Protocol Default — 1 satoshi (the smallest unit on BSV). This is the absolute minimum.
Overlay Deployment Configuration — The overlay operator may set a higher dust threshold for practical reasons (e.g., 100 satoshis to avoid generating economically insignificant UTXOs).
Per-Lineage-Record Override — A specific lineage record may specify a custom dust threshold in its metadata, applying only to that edge of the lineage graph.

The effective dust threshold for a given cascade edge is: max(protocol_default, overlay_default, lineage_record_override).

1.9.2 Dust Threshold Termination

When the cascade computation reaches a generation where the computed allocation for any parent token's total share falls below the dust threshold, the cascade terminates for that branch. The unterminated branches continue.

FUNCTION: shouldTerminateBranch(
    parent_share_sats,     // Total satoshis allocated to this parent token
    dust_threshold_sats    // Effective dust threshold
)
    return parent_share_sats < dust_threshold_sats

1.9.3 Maximum Cascade Efficiency

The geometric decay ensures that the total fraction of revenue consumed by the cascade is bounded. For a uniform rate r and a maximum depth D:

total_cascade_fraction = sum(r^g for g in 1..D)
                       = r × (1 - r^D) / (1 - r)

For r = 0.10 and D = 10:

total_cascade_fraction = 0.10 × (1 - 0.10^10) / (1 - 0.10)
                       ≈ 0.10 × 1.0 / 0.90
                       ≈ 0.1111 (11.11%)

This means that even with a 10-generation deep lineage tree, the creator of the revenue-generating work retains approximately 88.89% of the revenue. The cascade is economically bounded — it does not consume an unreasonable fraction of revenue regardless of lineage depth.

For r = 0.05 (5% per generation) and D = 10:

total_cascade_fraction ≈ 0.05 × (1 - 0.05^10) / (1 - 0.05)
                       ≈ 0.05 / 0.95
                       ≈ 0.0526 (5.26%)

The creator retains approximately 94.74%. Lower cascade rates result in more revenue retention by the immediate creator, with correspondingly less flowing to ancestors.

1.10 Integration with Existing Protocol Stack

The Rights Inheritance Cascade protocol extends and integrates with the Applicant's existing protocol stack:

1.10.1 Integration with $401 Identity Protocol

The $401 protocol provides the identity layer for all participants in the system:

Creator Identity — Every derivation attestation is bound to the creator's $401 identity chain. The attestation's Schnorr signature is verified against the public key in the creator's $401 root inscription. This prevents anonymous or pseudonymous derivation claims that cannot be traced to a verifiable identity.
Holder Identity — Cascade payments are resolved to holder payout addresses via $401 identity chains (per the payTo field in $401 strand inscriptions). This ensures that cascade payments reach the correct recipients even if they use multiple blockchain addresses.
Contestant Identity — Contestation standing is verified by linking the contestant's $401 identity to addresses holding qualifying tokens.
Identity Strength Requirements — The overlay may require a minimum $401 identity strength level for derivation attestations. For example, a high-value parent token may require Level 3+ identity (three or more verified identity providers including a professional identity) before accepting derivation attestations — reducing the risk of fraudulent claims by requiring the attestor to stake their verified identity.

1.10.2 Integration with $402 Payment Protocol

The $402 protocol provides the payment infrastructure for cascade distributions:

Micropayment Revenue Collection — Revenue events that trigger cascade computations may originate from HTTP 402 micropayments. When a visitor pays to access content through the $402 protocol, the payment transaction can include cascade outputs, making the cascade atomic with the content access payment.
Competitive Distribution — When cascade payments accumulate in distribution addresses (see Section 1.6.4), the $402 mining network performs the distribution to individual holders. This leverages the existing competitive mining infrastructure described in the Decentralized Dividend Distribution patent.
Proof of Indexing Integration — Cascade computation and distribution work constitutes verifiable indexing work for $402 miners. The work items (lineage traversal, holder enumeration, share computation, payment construction) are hashed into a work commitment and included in the miner's Proof of Indexing attestation.

1.10.3 Integration with $403 Compliance Protocol

The $403 protocol provides compliance gating for cascade operations:

Compliance-Gated Cascade Payments — Before distributing cascade payments to a parent token holder, the system may evaluate $403 compliance conditions (KYC level, jurisdiction, accreditation status). Non-compliant holders' cascade payments are escrowed, following the same escrow mechanism described in the Decentralized Dividend Distribution patent.
Regulated Asset Cascades — For tokens representing regulated assets (securities tokens under $403), the cascade protocol respects $403 transfer restrictions. A cascade payment is treated as a financial distribution subject to the same compliance conditions as a dividend payment.

1.10.4 Integration with Signed Semantic Triples (bCorp-PAT-011)

The Signed Semantic Triples protocol can express derivation relationships as machine-queryable triples:

Subject:   <child_token_genesis_txid>
Predicate: isDerivedFrom
Object:    <parent_token_genesis_txid>

The Rights Inheritance Cascade protocol can consume Signed Semantic Triples as an alternative or supplementary source of derivation data. When a triple expressing a derivation relationship is inscribed on-chain, the Lineage Registry can be populated from these triples, with the revenue share percentage and derivation type specified in the triple's metadata.

This integration means that any system that produces Signed Semantic Triples describing derivation (e.g., an AI model training pipeline that records which datasets were used, or a code repository that records fork relationships) can automatically feed the Rights Inheritance Cascade protocol.

1.10.5 Integration with Bit Trust (bCorp-PAT-010)

Bit Trust provides IP registration with identity-bound provenance. The integration with Rights Inheritance Cascade:

IP Registration as Lineage Source — When a work is registered through Bit Trust, the registration serves as the genesis event for the work's token in the Lineage Registry. The Bit Trust registration hash becomes the canonical content reference for lineage records.
Provenance Verification — The Bit Trust registration provides independent verification that the creator registered the work at a specific time, supporting contestation proceedings where authorship is disputed.
Encrypted Derivative Verification — Bit Trust's encrypted vault and selective disclosure mechanism can be used to verify derivation without revealing the full content of either the parent or child work — the creator discloses only the specific portions relevant to the derivation claim.

1.10.6 Integration with POI Overlay State Verification (bCorp-PAT-015)

The POI Overlay State Verification protocol ensures the correctness of derived state computations in overlay networks. For the Rights Inheritance Cascade protocol:

Lineage State Verification — The Lineage Registry is derived state computed by overlay Lookup Services from on-chain Lineage Records. POI Overlay State Verification ensures that all Lookup Services compute the same lineage graph from the same on-chain data.
Cascade State Verification — Cascade distribution plans are derived state computed from the lineage graph and token holder sets. POI verification ensures that competing miners compute the same cascade allocations.
Checkpoint-Based Integrity — The lineage graph state is committed at deterministic checkpoints (e.g., every 1,000 blocks), enabling cross-node comparison and binary narrowing dispute resolution per the POI Overlay State Verification patent.

1.10.7 Integration with Tokenised Patent Licensing (bCorp-PAT-008)

The Tokenised Patent Licensing patent describes licensing patents through bonding curve tokens. The Rights Inheritance Cascade protocol enables:

Derivative Patent Cascades — When a patent is granted for an improvement on a prior patented invention, and both patents are tokenised via the Tokenised Patent Licensing system, a lineage record can link the improvement patent token to the base patent token. Revenue from the improvement patent's licence token then cascades upstream to holders of the base patent's licence token.
Patent Portfolio Cascades — A portfolio of related patents (where each improvement builds on prior patents in the portfolio) naturally forms a lineage tree. Revenue from the most recent improvement cascades through all prior patents in the chain, creating a self-enforcing patent licensing network.

1.11 Cascade Payment Batching and Optimisation

For efficiency, the system provides several optimisation mechanisms:

1.11.1 Output Consolidation

When the cascade distribution plan for a single revenue event would produce more outputs than is practical for a single transaction (BSV has no hard limit on outputs, but practical limits exist due to transaction size and fee considerations), the system consolidates:

Holder Aggregation — If the same address appears multiple times in the cascade (e.g., a holder owns tokens in both a parent and grandparent token), their cascade allocations are summed into a single output.
Distribution Address Batching — As described in Section 1.6.4, cascade payments for widely-held parent tokens are batched through distribution addresses, reducing the per-revenue-event output count to one per parent token per generation.
Periodic Settlement — For high-frequency, low-value revenue events (e.g., streaming micropayments generating many small cascade obligations), the system may accumulate cascade obligations off-chain and settle them periodically in batched transactions, provided the batching period does not exceed a configurable maximum (default: 24 hours).

1.11.2 Pre-Computation and Caching

The overlay Lookup Service pre-computes and caches:

Ancestry Trees — The complete ancestry tree for each token, updated when lineage records change.
Cascade Templates — Parameterised cascade distribution templates that can be instantiated with a specific revenue amount, avoiding re-traversal of the ancestry tree.
Holder Snapshots — Periodic snapshots of parent token holder sets, used for cascade computation. Snapshots are taken at configurable intervals (default: every 100 blocks) to balance accuracy with computational cost.

1.12 Economic Analysis and Incentive Alignment

1.12.1 Creator Incentives

The Revenue Cascade creates alignment between original creators and derivative creators:

Original creators benefit from derivatives — When a derivative work generates revenue, the original creator receives a share. This incentivises original creators to encourage derivation (remixes, translations, adaptations, forks) rather than restricting it. An original creator who licenses their work for derivation with a 10% cascade rate stands to earn more from a widely-remixed work than from a restrictively-licensed work that is never adapted.
Derivative creators retain the majority — With a 10% cascade rate, the derivative creator retains ~89% of first-generation revenue. This is a reasonable attribution cost — comparable to or less than typical music sampling clearance fees (often 15-50% of revenue) or franchise royalties (typically 5-15% of revenue).
Deep derivation is economically viable — A work derived from a derivative (third generation) still retains ~88% of its revenue after the cascade (10% to parent, 1% to grandparent = 11% total cascade). This makes multi-generational derivation economically viable — third-generation creators are not burdened with excessive cascade obligations.

1.12.2 Anti-Gaming Mechanisms

The system includes mechanisms to prevent gaming:

Self-Derivation Prevention — The overlay rejects lineage records where the child token's creator identity matches the parent token's creator identity (i.e., you cannot declare your own work as derived from your other work to create a false cascade). Exception: legitimate self-derivation (e.g., a sequel) can be registered with a specific flag, but these carry 0% revenue share by default (the creator is paying themselves).
Cascade Rate Caps — The overlay enforces a maximum cascade rate per generation (configurable, default: 50% / 5,000 basis points) and a maximum total first-generation cascade rate for multi-parent derivatives (100% / 10,000 basis points). This prevents parasitic cascade claims that would consume all or most of the derivative creator's revenue.
Contestation Bonds — Filing a contestation requires a bond (satoshis locked in an escrow UTXO). If the contestation is dismissed, the bond is forfeited to the attestation creator. This prevents frivolous contestations.
Minimum Identity Strength — The overlay may require a minimum $401 identity strength for attestation filing, increasing the cost of fraudulent claims by requiring the attestor to risk their verified identity.

1.13 Cross-Asset Type Support

The Rights Inheritance Cascade protocol is asset-type agnostic. It applies to any tokenised digital work:

Content Derivatives — Music remixes, video adaptations, translated texts, annotated datasets. The derivation type codes (Section 1.3.1) cover common content derivation categories.
Software Derivatives — Forked repositories, ported applications, plugins built on a platform. The "fork" derivation type captures software lineage.
Patent Derivatives — Improvement patents citing prior patents. The cascade ensures that foundational patent holders benefit from improvements built on their work.
Domain Derivatives — Subdomains or derivative domain services built on a tokenised parent domain. Integration with the Applicant's DNSDEX domain tokenisation system.
Dataset Derivatives — AI training datasets incorporating portions of prior tokenised datasets. The "training data derivative" type (0x0C) captures this increasingly important derivation category, enabling creators of training data to receive revenue when AI models trained on their data generate revenue.
Design Derivatives — Products designed as variations or improvements on prior tokenised designs.

The protocol does not prescribe what constitutes a valid derivation — this is a semantic judgment made by the derivative creator (in the attestation) and potentially challenged by parent token holders (via contestation). The protocol provides the mechanism; the community provides the judgment.

1.14 Worked Example — Multi-Generational Music Cascade

To illustrate the complete system, consider the following scenario:

Setup:

Alice creates an original song and tokenises it as Token A (100 billion supply). She registers it through Bit Trust with her $401 identity (Level 3: Google, GitHub, LinkedIn).
Bob creates a remix of Alice's song, incorporating the vocal melody. Bob tokenises his remix as Token B (100 billion supply). Bob files a Derivation Attestation linking Token B to Token A, with derivation type "remix" (0x03), revenue share 10% (1,000 basis points), and his $401 identity (Level 2: Google, X/Twitter). The attestation includes a content similarity hash of the specific vocal melody portions derived from Alice's song.
The 30-day contestation window passes without challenge. The attestation is finalised. The Lineage Record linking Token B → Token A is active.
Carol creates a mashup incorporating elements from Bob's remix (Token B) and an independent beat by Dave (Token D). Carol tokenises the mashup as Token C (100 billion supply). Carol files a Derivation Attestation linking Token C to Token B (8% / 800 bps, "remix") and Token C to Token D (5% / 500 bps, "excerpt"). Both attestations are finalised after contestation windows.

Revenue Event: Carol's mashup (Token C) is sold for 10,000,000 satoshis.

Cascade Computation:

Revenue: 10,000,000 sats from Token C

Generation 1:
  Token B holders: 10,000,000 × 8% = 800,000 sats
  Token D holders: 10,000,000 × 5% = 500,000 sats
  G1 total: 1,300,000 sats

Generation 2 (parents of Token B — Token A):
  Token A holders: 800,000 × 10% = 80,000 sats
  (Token D has no parents — no G2 cascade from Token D)
  G2 total: 80,000 sats

Generation 3 (Token A is the root — no further parents):
  G3 total: 0 sats

Total cascade: 1,380,000 sats (13.80%)
Carol retains: 8,620,000 sats (86.20%)

Transaction:

INPUTS:
  Buyer's UTXO: 10,200,000 sats (covers purchase + miner fee)

OUTPUTS:
  [0] Carol (seller):     8,620,000 sats
  [1] Token B cascade:      800,000 sats → Token B distribution address
  [2] Token D cascade:      500,000 sats → Token D distribution address
  [3] Token A cascade:       80,000 sats → Token A distribution address
  [4] RICP cascade commitment (OP_RETURN): 0 sats
  [5] BSV-21 token transfer to buyer:      1 sat
  [6] Change to buyer:    remaining sats

Miner fee: ~200 sats (estimated)

The cascade distribution addresses accumulate payments. When Bob's Token B distribution address reaches its threshold, $402 miners distribute proportionally to all Token B holders. Similarly for Token A and Token D.

Alice, the original song creator, receives her share through two hops: first, 10% of Token B's cascade share is allocated to Token A holders, then distributed to her proportionally to her Token A holdings. If Alice holds 50% of Token A, she receives 40,000 sats from this single transaction — automatic, multi-generational, atomic, and without any action on her part.

Brief Description of Drawings

The following drawings would accompany this application:

Figure 1 — System Architecture: Two-layer diagram showing the Rights Inheritance Cascade overlay network (application layer) above and the BSV blockchain (settlement layer) below. The overlay layer contains: the Lineage Registry (DAG), the Revenue Cascade Engine, the Attestation Index, and the Contestation Protocol. Arrows show overlay participants inscribing lineage records, attestations, and cascade payments as transactions settled on the BSV blockchain. Clear visual separation between "APPLICATION LAYER — RICP Overlay (Interpret and Enforce)" and "SETTLEMENT LAYER — BSV Miners (Validate and Confirm)."

Figure 2 — Lineage Registry DAG: Directed acyclic graph showing multiple tokenised works connected by derivation edges. Root tokens (original works) at the top, derivative tokens below, with arrows pointing from children to parents. Edge labels show derivation type and revenue share percentage. Multi-parent nodes (forks/mashups) shown with multiple incoming parent edges. Colour coding distinguishes derivation types (remix in blue, translation in green, fork in orange, etc.).

Figure 3 — Revenue Cascade Flow: Flow diagram showing a revenue event at a child token, with satoshis flowing upstream through the lineage graph. Each generation shows the geometric decay: full amounts at Generation 1, 10% at Generation 2, 1% at Generation 3, diminishing to dust. Numbers annotate each flow. A "dust threshold" barrier marks where the cascade terminates.

Figure 4 — Derivation Attestation Lifecycle: State machine diagram showing the five attestation states: Pending → Finalised (if no contest), Pending → Contested → Resolved (revoked, amended, dismissed, or confirmed), Finalised → Amended (if both parties agree). Arrows labelled with the triggering events and time windows.

Figure 5 — Atomic Cascade Transaction Structure: Exploded transaction diagram showing a revenue-generating transaction with: buyer input, seller payment output, cascade payment outputs (one per parent per generation), cascade payment commitment (OP_RETURN), token transfer output, and change output. Each output is labelled with its purpose and amount. Dotted lines connect cascade outputs to the corresponding nodes in the lineage graph.

Figure 6 — Multi-Parent Fork Cascade: Diagram showing a derivative work with two parent tokens (mashup scenario). Revenue flows split proportionally to each parent lineage. Each parent's upstream cascade continues independently at that parent's configured rate. Shows how the total cascade fraction is bounded despite multiple parent lineages.

Figure 7 — Contestation Protocol Flow: Sequence diagram showing: Attestation filed → Contestation window opens → Contestant files contestation (with bond) → Attestor notified → Response window → Resolution (automatic/bilateral/oracle-mediated) → Outcome inscribed on-chain. Alternative paths shown for each resolution type.

Figure 8 — Integration with Protocol Stack: Architecture diagram showing how the Rights Inheritance Cascade protocol ($RICP) integrates with $401 (identity layer — creator verification, holder resolution), $402 (payment layer — micropayment revenue, competitive distribution), and $403 (compliance layer — regulated asset gating). Arrows show data flow between protocols. Shows how a single revenue event triggers cascade computation using $401, $402, and $403 in sequence.

Figure 9 — Worked Example: Multi-Generational Music Cascade: Visual representation of the Alice/Bob/Carol/Dave scenario from Section 1.14, showing the lineage graph, the revenue event, the cascade computation at each generation, the transaction outputs, and the final satoshi distribution to each participant.

Figure 10 — Geometric Decay Curve: Mathematical chart showing revenue share percentage by generation for various cascade rates (5%, 10%, 15%, 20%). X-axis: generation number (1-10). Y-axis: percentage of original revenue reaching that generation. Shows convergence toward zero and marks the dust threshold termination point for a reference revenue amount.

Initial Claims

Note: These claims are provided in sketch form for the purposes of establishing a priority date. Formal claims will be drafted and filed within 12 months in accordance with UKIPO rules.

Claim 1 — Automated Rights Inheritance System for Tokenised Digital Works

A system for automated rights inheritance in tokenised digital works using UTXO-based parent-child token lineage, comprising:

(a) a lineage registry operating at the overlay layer of a UTXO-based blockchain, the registry maintaining a directed acyclic graph of parent-child relationships between tokenised digital works, each relationship recorded as an on-chain UTXO containing a lineage record specifying: the child token identifier, the parent token identifier, a derivation type, a revenue share percentage, and the derivative creator's verified identity;

(b) a revenue cascade engine that, upon detection of a revenue-generating event for any token in the lineage registry, traces the token's ancestry through the directed acyclic graph, computes revenue share allocations at each generation using the revenue share percentages specified in the lineage records, and produces a cascade distribution plan specifying payment amounts to parent token holders at each generation;

(c) an enforcement mechanism whereby revenue-generating transactions for tokens with active lineage records are required to include cascade payment outputs matching the computed distribution plan, such that cascade payments are structurally inseparable from the revenue-generating transaction;

wherein the system operates as an overlay protocol on top of a UTXO-based blockchain settlement layer, leveraging UTXO spending conditions for enforcement without modifying the base blockchain protocol, and wherein the cascade propagates automatically through multiple generations of derivative works without requiring action by any upstream token holder.

Claim 2 — Revenue Cascade Method with Geometric Decay Across Multi-Generational Token Lineages

A method for cascading revenue through multi-generational token lineages with geometric decay, the method comprising:

(a) receiving notification of a revenue-generating event associated with a child token in a lineage registry, the event specifying a revenue amount in satoshis;

(b) traversing the lineage registry to identify the child token's parent token(s) and their respective revenue share percentages;

(c) computing the revenue share for each parent token as a fraction of the revenue amount, the fraction determined by the revenue share percentage specified in the lineage record connecting the child to that parent;

(d) for each parent token that itself has parent tokens in the lineage registry, recursively computing the revenue share owed to those grandparent tokens as a fraction of the parent's share, producing geometric decay whereby each successive generation receives a geometrically decreasing fraction of the original revenue;

(e) terminating the cascade traversal for any branch where the computed allocation falls below a configurable dust threshold;

(f) producing a cascade distribution plan specifying all payment amounts across all generations;

wherein the geometric decay ensures that the total cascade fraction is mathematically bounded regardless of lineage depth, and wherein the method supports non-uniform cascade rates at different edges of the lineage graph.

Claim 3 — Derivation Attestation Protocol with Identity-Bound Creator Verification

A method for establishing derivation relationships between tokenised digital works using identity-bound attestations, the method comprising:

(a) a creator of a derivative work signing an on-chain attestation declaring that the derivative work is derived from one or more specified parent works, the attestation being cryptographically signed using a private key linked to the creator's verified on-chain identity chain ($401);

(b) the attestation including: a derivation type classification, a revenue share percentage for each parent work, a content similarity reference, and a signed statement by the creator;

(d) initiating a configurable contestation window during which holders of the referenced parent token(s) may challenge the derivation claim;

(e) finalising the attestation and activating the associated lineage record upon expiration of the contestation window without valid challenge;

wherein the derivation relationship and its associated revenue cascade obligation are established through a verifiable, identity-bound, contestable process recorded on-chain.

Claim 4 — Atomic Revenue Cascade Enforcement via UTXO Spending Conditions

A method for enforcing revenue cascade payments atomically within revenue-generating transactions, the method comprising:

(a) an overlay network Topic Manager monitoring for transactions that generate revenue from tokens with active lineage records;

(b) upon detecting a revenue-generating transaction, the Topic Manager computing the cascade distribution plan based on the token's ancestry in the lineage registry;

(c) verifying that the transaction includes payment outputs corresponding to each entry in the cascade distribution plan, with amounts matching the computed allocations;

(d) admitting the transaction to the overlay network's state only if the cascade payment outputs are present and correct;

(e) rejecting transactions that omit or incorrectly compute cascade payments, rendering them ineffective within the token ecosystem despite being valid on the base blockchain;

wherein the cascade payment is part of the same atomic transaction as the revenue event, ensuring that revenue cannot be collected without simultaneously paying the cascade obligation, and wherein enforcement operates at the overlay application layer without requiring modification of the base blockchain protocol.

Claim 5 — Multi-Parent Fork Handling with Proportional Revenue Splitting

A method for handling revenue cascades in derivative works derived from multiple parent works, the method comprising:

(a) recording multiple lineage records for a single child token, each linking the child to a different parent token with a respective derivation type and revenue share percentage;

(b) upon a revenue event for the child token, computing independent cascade allocations for each parent lineage, the allocation for each parent being the specified revenue share percentage of the total revenue amount;

(c) for each parent lineage, independently computing upstream cascades through that parent's own ancestry, applying geometric decay at each generation;

(d) consolidating cascade payments where the same holder or address appears in multiple lineage branches;

(e) enforcing that the sum of all first-generation revenue share percentages across all parent lineages does not exceed 100%;

wherein a derivative work derived from multiple sources cascades revenue proportionally to each source lineage, with each lineage's upstream cascade computed independently using that lineage's specific revenue share rates.

Claim 6 — Lineage Contestation Protocol for Disputing Fraudulent Derivation Claims

A protocol for contesting fraudulent derivation attestations in a tokenised work lineage system, the protocol comprising:

(a) limiting contestation standing to holders of the parent token(s) referenced in the attestation, the creator of the child token, or holders of root tokens in the same lineage tree;

(b) requiring the contestant to submit a contestation event on-chain, signed by the contestant's verified identity, specifying a contestation reason code and supporting evidence, accompanied by a bond in satoshis;

(d) resolving the contestation through one of: automatic revocation (if the attestation creator does not respond), bilateral agreement (signed by both parties), or oracle-mediated adjudication;

(e) inscribing the resolution outcome on-chain with an immutable audit trail;

(f) forfeiting the contestant's bond if the contestation is dismissed, or transferring the bond to the contestant if the attestation is revoked;

wherein the contestation protocol prevents both parasitic derivation claims (false association with successful works) and wrongful cascade imposition (forcing cascade obligations on independent works), while the bond mechanism deters frivolous contestations.

Claim 7 — Dust Threshold Termination Method for Cascade Efficiency

A method for ensuring computational and economic efficiency in multi-generational revenue cascades, the method comprising:

(a) defining a configurable dust threshold representing the minimum satoshi amount constituting a meaningful cascade payment;

(b) during cascade computation, comparing the computed allocation for each parent token at each generation against the dust threshold;

(d) retaining the unterminated allocations below the dust threshold in the nearest downstream token's creator share;

(e) applying the dust threshold at the aggregate parent token level and, where applicable, at the individual holder level;

wherein the dust threshold termination bounds the computational depth of cascade traversal, prevents the generation of economically meaningless micro-payments, and ensures that cascade computation terminates in finite time regardless of the theoretical depth of the lineage tree.

Abstract

A system and method for automated rights inheritance and revenue cascade in derivative digital works using UTXO-based parent-child token lineage. When a digital work is tokenised on a UTXO-based blockchain and a derivative work is subsequently created from it, the protocol creates child tokens linked to parent tokens via an on-chain Lineage Registry — a directed acyclic graph recording derivation relationships, types, and revenue share percentages. When revenue is generated from any token in the lineage tree, a Revenue Cascade Engine traces the token's ancestry and computes a multi-generational revenue distribution, with geometric decay ensuring that each successive generation receives a decreasing fraction of the revenue. Cascade payments are enforced atomically via UTXO spending conditions: revenue-generating transactions must include outputs paying cascade obligations to parent token holders, verified by overlay network Topic Managers. The system supports multi-parent derivatives (forks, mashups) with proportional revenue splitting across parent lineages. Derivation relationships are established through identity-bound attestations using verified on-chain identity chains ($401), subject to a contestation window enabling parent token holders to challenge fraudulent claims. The cascade terminates when the per-generation allocation falls below a configurable dust threshold, bounding total cascade costs. The protocol operates as an overlay/application-layer system on top of BSV's UTXO settlement layer, requiring no base protocol modifications, and integrates with the Applicant's existing protocol stack ($401 identity, $402 payment, $403 compliance, Signed Semantic Triples, Decentralized Dividend Distribution, Bit Trust, and Tokenised Patent Licensing). The system is asset-type agnostic, supporting content, software, patents, domains, datasets, and any other tokenisable digital work.

Document prepared for UKIPO filing. Priority date to be established upon submission. Applicant: The Bitcoin Corporation Ltd Inventor: Richard Boase Date of preparation: 12 March 2026

Get Started

This patent was filed by The Bitcoin Corporation Ltd with the UK Intellectual Property Office. To learn more about the technology described here, visit b0ase.com or explore the full patent portfolio.

For AI Readers

Intent: Public disclosure of UKIPO patent filing. Title: Patent Filed: Automated Rights Inheritance and Revenue Cascade for Derivative Digital Works Applicant: The Bitcoin Corporation Ltd Inventor: Richard Boase Key Takeaways:

This patent is part of The Bitcoin Corporation's portfolio of 18 filed UKIPO patent applications
The technology operates as an overlay/application-layer protocol on BSV's UTXO settlement layer
Related patents and cross-references are listed in the specification
Full patent text is available at b0ase.com/blog/patent-rights-inheritance-cascade