Patent Filed: Tripartite Token Stamping

Applicant

The Bitcoin Corporation Ltd

Inventor

Richard Boase

Date of Preparation

20 March 2026

---

Title of Invention

Tripartite Token Stamping and Multi-Currency Hash-to-Mint Mining for Content Ticket Lifecycle Verification on UTXO-Based Blockchains

---

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 — token stamping, multi-currency mining, ticket lifecycle verification, and stamp validation — 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 issuing, validating, and recycling digital content tickets using a tripartite token stamping protocol, wherein each ticket must carry three independently verifiable stamps — an identity stamp ($401), a content stamp ($402), and a compliance stamp ($403) — to be considered valid within the overlay network. More particularly, the invention concerns: (a) the deployment of three independent Hash-to-Mint smart contracts, each producing a distinct token type ($401, $402, $403) that overlay mining nodes earn by performing verification work specific to that token's domain; (b) the requirement that the creation of new content tickets consume $402 tokens, creating endogenous demand for the mined token; (c) a ticket lifecycle (active/staked/redeemed/recycled) in which stamp validity is re-verified at each state transition; and (d) the use of specialised mining devices (ClawMiners) to perform the verification work that earns all three token types, creating a unified hardware platform supporting three independent mining economies.

---

Background of the Invention

Problem Statement

1. Single-Token Mining Economies Are Fragile

   Existing blockchain mining systems produce a single token type. The economic health of the mining network depends entirely on the value of that one token. If demand for the token falls, mining profitability drops, miners leave, network security degrades, and the system enters a death spiral. No existing system distributes mining incentives across multiple independent token economies, each with distinct demand drivers, such that the failure of one economy does not necessarily compromise the others.

2. Content Tokens Lack Compositional Validity

   Existing token standards (ERC-721, ERC-1155, BSV-20, BSV-21) represent a single property: ownership. A token proves that an address holds a digital asset. It does not prove that the holder's identity has been verified, that the content the token represents is authentic, or that the holder is legally permitted to possess it in their jurisdiction. These are three distinct properties — identity, content authenticity, and compliance — currently verified by separate, disconnected systems (OAuth providers, content registries, KYC services) with no unified on-chain representation.

3. Token Creation Has No Endogenous Cost

   On most platforms, creating a new token costs only a transaction fee (often sub-penny). This enables spam, trademark infringement, and token squatting. There is no mechanism to make token creation itself economically significant — requiring the expenditure of a scarce, demand-driven resource as a prerequisite for minting new content tokens. Proof-of-Work mining creates tokens from computational work, but the work is generic (hashing) rather than domain-specific (verification). No existing system requires the expenditure of domain-specific mined tokens to create new content tokens, creating a circular economy where mining funds creation and creation drives demand for mining.

4. Ticket Lifecycles Are Not Verified at State Transitions

   The Applicant's prior Ticket CDN Membership Token patent (bCorp-PAT-009) defines a three-state ticket lifecycle (active/staked/redeemed). However, the prior patent does not require re-verification of ticket validity at each state transition. A ticket that was validly issued may become invalid if: the holder's identity is revoked ($401), the content is taken down or disputed ($402), or the holder's jurisdiction changes and compliance conditions are no longer met ($403). Without re-verification at each transition, invalid tickets circulate in the system, creating legal and economic risk.

5. The Applicant's Tripartite Protocol Stack Lacks a Unifying Enforcement Mechanism

   The Applicant has previously filed patent applications for: the $402 Protocol (bCorp-PAT-001), the HTTP Status Code Tokenization Suite (bCorp-PAT-007) defining the $401/$402/$403 tripartite stack, the ClawMiner device (bCorp-PAT-004), the Ticket CDN Membership Token (bCorp-PAT-009), and Proof-of-Indexing Overlay State Verification (bCorp-PAT-010). These patents define the individual layers but do not describe: (a) how the three token types are independently mined by the same device; (b) how the three stamps are combined on a single content ticket; (c) how stamp validity is enforced at each lifecycle transition; or (d) how $402 token expenditure is required for new ticket creation, creating endogenous demand.

Prior Art Limitations

BSV-21 Hash-to-Mint (1SatOrdinals, 2024–present) — BSV-21 defines a fungible token standard where the entire supply is locked in an sCrypt smart contract and released via Proof-of-Work mining. The present invention extends BSV-21 by deploying three independent HTM contracts ($401, $402, $403) on the same blockchain, each with distinct mining parameters, and requiring tokens from one contract ($402) to be consumed when interacting with another (ticket creation). BSV-21 defines single-token mining; the present invention defines multi-token mining with cross-token consumption requirements.

ERC-6551 Token Bound Accounts (Ethereum, 2023) — ERC-6551 creates smart contract accounts owned by NFTs, allowing NFTs to hold other tokens. This provides a mechanism for tokens to carry sub-tokens but does not define a tripartite stamping protocol, does not require independent mining for each stamp type, does not enforce stamp re-verification at lifecycle transitions, and operates on the account model rather than the UTXO model.

Soulbound Tokens (Vitalik Buterin et al., 2022) — Soulbound tokens are non-transferable tokens representing identity credentials. They share the concept of identity-bound attestation with the $401 stamp but are non-transferable (cannot be staked or traded), do not integrate with content or compliance layers, and have no mining mechanism.

The Applicant's Prior Patents — As enumerated in Problem Statement §5, the Applicant's existing portfolio defines the individual protocol layers ($401, $402, $403), the mining device (ClawMiner), the ticket lifecycle (Ticket CDN), and the verification framework (PoI Overlay). The present invention is the unifying system that connects these components into a single enforcement mechanism with three independently mined token economies.

---

Summary of the Invention

The present invention provides a tripartite token stamping and multi-currency mining system, comprising:

(a) Three Independent Hash-to-Mint Contracts deployed on a UTXO-based blockchain, each producing a distinct token type:

• $401 tokens — earned by mining nodes that perform identity verification work: validating OAuth provider attestations, checking identity chain integrity, verifying strand freshness, and maintaining the identity trust graph;
• $402 tokens — earned by mining nodes that perform content indexing work: indexing token transfers, tracking content provenance, verifying content authenticity hashes, and maintaining the content registry;
• $403 tokens — earned by mining nodes that perform compliance verification work: evaluating jurisdictional conditions, checking KYC status against $401 identity data, verifying accreditation credentials, and maintaining the compliance state machine;

Each contract has independent supply parameters (total supply, block reward, halving schedule, difficulty target), creating three separate mining economies with distinct demand drivers;

(b) A Tripartite Stamping Protocol whereby a content ticket (a UTXO-based token representing access to a digital work) is valid only when it carries three stamps:

• A $401 stamp — a reference to a valid $401 identity verification, proving the current holder's identity is known and verified to the required level;
• A $402 stamp — a reference to a valid $402 content registration, proving the content the ticket represents is authentic, registered, and undisputed;
• A $403 stamp — a reference to a valid $403 compliance check, proving the current holder is permitted to possess this ticket in their jurisdiction under applicable regulations;

A ticket missing any stamp, or carrying an expired or revoked stamp, is treated as invalid by the overlay network — it cannot be traded, staked, redeemed, or used for content access;

(c) $402 Token Consumption for Ticket Creation — the minting of a new content ticket requires the expenditure (burning or transfer to a protocol address) of a configurable quantity of $402 tokens. This creates endogenous demand for $402 tokens: the more content is created on the platform, the more $402 tokens are consumed, the more valuable $402 mining becomes, the more miners join the network, the more verification capacity the network has. This circular economy is self-sustaining and does not require external funding;

(d) Lifecycle Stamp Re-Verification — at each state transition in the ticket lifecycle (active → staked, staked → active, active → redeemed, redeemed → recycled), the overlay network re-verifies all three stamps. A ticket whose $401 stamp has been revoked (identity compromised) cannot be staked. A ticket whose $403 stamp has expired (compliance status changed) cannot be redeemed. This prevents invalid tickets from circulating and ensures that every ticket in every state represents a genuinely verified, compliant, identity-bound content access right;

(e) Unified Mining Device — a single hardware device (ClawMiner) runs three independent mining processes, one for each token type. The device allocates computational resources across the three mining economies based on current profitability (token price × difficulty ratio), automatically shifting work toward whichever token type is most valuable to mine at any given time. This creates a self-balancing mining economy where undervalued tokens attract more mining capacity, increasing their verification throughput, which in turn supports more ticket issuance, which increases demand for the token;

(f) Stamp Data Format — each stamp is a compact on-chain inscription linking a ticket's UTXO to the relevant verification record:

$401 Stamp: OP_FALSE OP_RETURN <"401S"> <ticket_txid:32> <identity_root_txid:32>
            <identity_level:1> <verification_timestamp:8> <verifier_signature:64>

$402 Stamp: OP_FALSE OP_RETURN <"402S"> <ticket_txid:32> <content_hash:32>
            <registry_txid:32> <content_status:1> <indexer_signature:64>

$403 Stamp: OP_FALSE OP_RETURN <"403S"> <ticket_txid:32> <jurisdiction:4>
            <condition_set_hash:32> <evaluation_result:1> <evaluator_signature:64>

Each stamp is signed by the mining node that performed the verification, creating an auditable chain of accountability. False stamps result in the verifier's mining stake being slashed;

(g) Recycling Protocol — when a ticket is redeemed and the content access period expires, the ticket enters a "recycled" state. Recycled tickets return to the available pool for the content item, making them purchasable by new users. At the point of recycling, all three stamps are cleared, and the new purchaser must obtain fresh stamps — requiring fresh $401 identity verification, fresh $402 content verification, and fresh $403 compliance verification. This ensures that every re-use of a ticket is independently verified, and generates ongoing demand for all three token types as tickets cycle through the system.

---

Detailed Description of the Invention

1. Multi-Currency Hash-to-Mint Architecture

1.1 Three Independent Smart Contracts

The system deploys three BSV-21 Hash-to-Mint smart contracts, each on the BSV blockchain as an independent UTXO chain:

Each contract follows the same sCrypt Hash-to-Mint pattern described in the Applicant's BRC-116 specification: the miner provides a Proof-of-Work nonce, a work commitment (Merkle root of verification work performed), and a destination address. The contract verifies the PoW on-chain and mints tokens to the miner.

The critical distinction is that the work commitment for each contract type contains verification work specific to that domain:

$401 Work Commitment Contents:

• Identity chain validations performed (root + strand integrity checks)
• OAuth provider attestation verifications
• Identity level computations (Level 1–4+ based on strand count and type)
• Identity expiry checks and renewal verifications
• Trust graph edge validations (who trusts whom, at what level)

$402 Work Commitment Contents:

• Token transfer indexing (BSV-21 transfers tracked and catalogued)
• Content hash verifications (SHA-256 of registered content matches on-chain record)
• Provenance chain validations (ownership history from creation to current holder)
• Content dispute status checks
• Ticket supply and lifecycle state indexing

$403 Work Commitment Contents:

• Jurisdictional classification evaluations (token type × holder jurisdiction → applicable rules)
• KYC status verification against $401 identity data
• Accreditation credential checks (for securities-class tokens)
• Condition set evaluations (programmable rule engine outputs)
• Compliance status change detections (holder moves jurisdiction, regulation changes)

1.2 Mining Economics and Self-Balancing

Each token type has independent supply and demand dynamics:

$401 Demand Drivers:

• Every new user on the platform needs a $401 identity verification
• Every ticket state transition requires a fresh $401 stamp verification
• Identity verifications expire and must be renewed
• Higher-value content requires higher identity levels (more $401 work)

$402 Demand Drivers:

• New ticket creation requires $402 token expenditure (the core demand mechanism)
• Content registration requires $402 indexing
• Every ticket transfer requires provenance verification
• Content disputes trigger re-indexing work

$403 Demand Drivers:

• Every ticket purchase by a new holder in a new jurisdiction requires compliance evaluation
• Regulatory changes trigger mass re-evaluation of existing tickets
• Securities-class tokens ($403 layer) require ongoing compliance monitoring
• Cross-border transactions require dual-jurisdiction evaluation

A ClawMiner device runs all three mining processes simultaneously. When $402 demand spikes (many new content tickets being created, consuming $402 tokens), $402 mining profitability increases, and miners allocate more resources to $402 work. This increases the network's content verification throughput, enabling more ticket creation, in a positive feedback loop. When $401 demand increases (many new users joining), miners shift toward identity verification work. The system self-balances without central coordination.

1.3 Adaptive Resource Allocation

Each ClawMiner device maintains a profitability estimator:

profitability($TOKEN) = (token_market_price × block_reward) / mining_difficulty

allocation($TOKEN) = profitability($TOKEN) / sum(profitability(all_tokens))

The device allocates CPU cycles proportionally. If $401 tokens are trading at 2× the price of $402 tokens and $403 tokens, the device allocates approximately 50% of its resources to $401 mining and 25% each to $402 and $403. This is a local optimisation; no coordination protocol is required. The aggregate effect across all miners is that verification resources flow to wherever demand is highest.

2. Tripartite Stamping Protocol

2.1 Stamp Issuance

When a content ticket is created, transferred, or transitions state, the overlay network's mining nodes perform verification work and issue stamps:

Step 1: $401 Identity Stamp

A $401 miner verifies the ticket holder's identity:

1. Locate the holder's $401 root inscription on-chain
2. Enumerate the holder's $401 strand inscriptions (OAuth provider attestations)
3. Compute the holder's identity level based on strand count and type
4. Verify that no strands have been revoked
5. If the identity meets the content's required level, issue a $401 stamp transaction

Step 2: $402 Content Stamp

A $402 miner verifies the content:

1. Locate the content's registration inscription (SHA-256 hash + metadata)
2. Verify the content hash matches the registered hash
3. Check for active disputes or takedown notices
4. Verify the content's provenance chain (creation → current state)
5. If the content is valid and undisputed, issue a $402 stamp transaction

Step 3: $403 Compliance Stamp

A $403 miner evaluates compliance:

1. Determine the holder's jurisdiction from their $401 identity data
2. Determine the token's classification in that jurisdiction (using the Jurisdictional Token Classification system from bCorp-PAT-013)
3. Evaluate the applicable condition set (KYC level, accreditation, holding limits)
4. If all conditions are met, issue a $403 stamp transaction

A ticket is valid only when all three stamps are present and current.

2.2 Stamp Expiry and Renewal

Stamps have configurable expiry periods:

When a stamp expires, the ticket enters a "stamps pending" state. It remains in the holder's wallet but cannot be traded, staked, or redeemed until fresh stamps are obtained. The holder requests re-stamping by broadcasting a stamp request transaction; miners compete to perform the verification work and earn the corresponding tokens.

2.3 Stamp Verification by Third Parties

Any party can verify a ticket's stamp status:

1. Query the overlay Lookup Service for the ticket's UTXO
2. Retrieve the three most recent stamp transactions referencing that UTXO
3. Verify each stamp's signature against the stamping miner's known public key
4. Check each stamp's timestamp against the expiry policy
5. If all three stamps are present, valid, and current, the ticket is verified

This verification is lightweight (three Lookup Service queries) and can be performed by any client without running a full node.

3. $402 Token Consumption for Ticket Creation

3.1 The Creation Cost Mechanism

When a content creator mints a new content ticket (e.g., a new composition on Bailey-Connor.com), the minting transaction must include an input spending $402 tokens to a burn address or protocol treasury address. The quantity of $402 tokens required is configurable per content type:

These costs are set by the platform operator and can be adjusted. The key property is that $402 tokens are consumed — removed from circulation — when new content is created.

3.2 Demand Flywheel

The consumption mechanism creates a demand flywheel:

More content created on platform
  → More $402 tokens consumed
    → $402 supply decreases (deflationary pressure)
      → $402 price increases
        → $402 mining becomes more profitable
          → More miners join / existing miners allocate more resources
            → More verification capacity in the network
              → Platform can support more content and users
                → More content created on platform (loop)

This flywheel is the economic engine of the system. Unlike inflationary token models where tokens are minted infinitely with no demand driver, the present invention creates a direct, measurable link between platform activity and token value.

3.3 Transaction Structure for Ticket Creation with $402 Burn

TRANSACTION: Content Ticket Creation
═══════════════════════════════════════════════════════════════

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

INPUT 1:  Creator's $402 token UTXO(s)
          (BSV-21 token transfer spending $402 tokens)
          Total $402 value >= required creation cost

OUTPUT 0: Content ticket token (BSV-21, 1 sat ordinal)
          scriptPubKey: <ticket inscription with metadata>
          Metadata includes: content_hash, creator_401_root,
          ticket_supply, content_type, creation_timestamp
          value: 1 satoshi (ordinal carrier)

OUTPUT 1: $402 burn output
          scriptPubKey: OP_FALSE OP_RETURN <"402B"> <amount>
                        <content_ticket_txid> <creator_401_root>
          value: 0 (tokens are burned, not transferred)

OUTPUT 2: Change (BSV)
          value: [input 0 value - fees]

OUTPUT 3: $402 change (if input 1 > required cost)
          (BSV-21 token transfer returning excess $402 to creator)

The $402 burn is recorded on-chain as an OP_RETURN with protocol tag "402B" (burn). The burn references the content ticket being created, linking the $402 expenditure to the specific content. This is auditable: anyone can verify that a content ticket's creation was backed by $402 token expenditure.

4. Lifecycle Stamp Re-Verification

4.1 State Transitions

The ticket lifecycle comprises five states:

                ┌─────────┐
                │ CREATED │ (stamps pending — not yet valid)
                └────┬────┘
                     │ all 3 stamps obtained
                     ▼
                ┌─────────┐
           ┌────│  ACTIVE │────┐
           │    └────┬────┘    │
     stake │         │         │ transfer
           ▼         │         ▼
      ┌─────────┐    │    ┌──────────┐
      │ STAKED  │    │    │ ACTIVE   │ (new holder — stamps re-verified)
      └────┬────┘    │    └──────────┘
           │         │
    unstake│   redeem│
           │         │
           ▼         ▼
      ┌─────────┐  ┌──────────┐
      │ ACTIVE  │  │ REDEEMED │ (content accessed, ticket consumed)
      └─────────┘  └────┬─────┘
                        │ access period expires
                        ▼
                   ┌──────────┐
                   │ RECYCLED │ (returned to available pool)
                   └──────────┘

4.2 Re-Verification at Each Transition

At every state transition, the overlay network re-checks all three stamps:

If any check fails, the transition is blocked. The ticket remains in its current state until the issue is resolved (e.g., the holder renews their $401 identity, a content dispute is resolved, or a compliance condition is satisfied).

5. Integration with Existing Patent Portfolio

The present invention integrates with and extends the Applicant's existing patents:

---

Brief Description of Drawings

The following drawings would accompany this application:

Figure 1 — Tripartite Token Architecture: Three-layer diagram showing the three HTM contracts ($401, $402, $403) each producing tokens that flow into the stamping protocol. Arrows show: miners earning tokens from each contract; tokens flowing to the stamp verification process; $402 tokens being consumed during ticket creation.

Figure 2 — Stamp Data Format: Byte-level layout of each stamp type ($401, $402, $403) inscribed as OP_RETURN outputs. Side-by-side comparison showing common fields (protocol tag, ticket reference, timestamp, signature) and type-specific fields.

Figure 3 — Ticket Lifecycle with Stamp Verification: State machine diagram showing the five ticket states (created, active, staked, redeemed, recycled) with re-verification gates at each transition. Each gate shows the three stamp checks performed.

Figure 4 — $402 Consumption Flywheel: Circular flow diagram showing: content creation → $402 consumption → supply decrease → price increase → mining profitability → more miners → more verification capacity → more content creation.

Figure 5 — Mining Resource Allocation: Diagram of a ClawMiner device with three mining processes, each allocated resources proportionally to profitability. Shows the self-balancing behavior when one token's demand spikes.

Figure 6 — Ticket Creation Transaction: Exploded transaction diagram showing inputs (payment UTXO + $402 token UTXO) and outputs (ticket token, $402 burn, change). Annotations show the BSV-21 token flow and the OP_RETURN burn record.

Figure 7 — Triple Stamp Verification Flow: Sequence diagram showing a ticket transfer: buyer initiates transfer → $401 miner verifies buyer identity → $402 miner verifies content → $403 miner evaluates compliance → all three stamps issued → transfer admitted to overlay state.

Figure 8 — Integration with Patent Portfolio: Architecture diagram showing how the present invention (center) connects to each of the Applicant's existing patents. Lines show data flow and dependency relationships.

---

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 — Tripartite Token Stamping System

A system for validating digital content tickets using three independently verifiable stamps on a UTXO-based blockchain, comprising:

1. three independent Hash-to-Mint smart contracts deployed on the same blockchain, each producing a distinct token type: an identity token ($401) earned by performing identity verification work, a content token ($402) earned by performing content indexing work, and a compliance token ($403) earned by performing compliance evaluation work;

2. a stamping protocol whereby a content ticket is valid only when it carries a current $401 stamp (proving the holder's identity is verified), a current $402 stamp (proving the content is authentic and registered), and a current $403 stamp (proving the holder is compliant in their jurisdiction);

3. a stamp data format inscribed on-chain as UTXO outputs, each stamp referencing the ticket, the verification record, and a cryptographic signature from the verifying mining node;

4. a validation rule enforced by the overlay network whereby tickets missing any of the three stamps, or carrying expired or revoked stamps, are treated as invalid and cannot be traded, staked, redeemed, or used for content access;

wherein the three token types are independently mined, independently priced, and independently demanded, creating three separate but interconnected mining economies that collectively maintain the integrity of the content ticket system.

Claim 2 — $402 Token Consumption for Content Ticket Creation

A method for creating endogenous demand for a mined token by requiring its expenditure during content creation, the method comprising:

1. deploying a Hash-to-Mint smart contract that produces $402 tokens as rewards for content indexing work;

2. requiring that the creation of a new content ticket include a transaction input spending a configurable quantity of $402 tokens to a burn address, the quantity determined by the content type;

3. recording the burn on-chain as an OP_RETURN output linking the consumed $402 tokens to the created content ticket;

4. verifying, at the overlay layer, that the content ticket's creation transaction includes a valid $402 burn of sufficient quantity before admitting the ticket to the overlay network state;

wherein the consumption of $402 tokens during content creation creates a deflationary pressure on $402 supply that is directly proportional to platform content activity, establishing a self-sustaining economic link between platform growth and mining profitability.

Claim 3 — Lifecycle Stamp Re-Verification

A method for ensuring ongoing validity of digital content tickets by re-verifying stamps at each lifecycle state transition, the method comprising:

1. defining a ticket lifecycle with multiple states including at least: created, active, staked, redeemed, and recycled;

2. at each state transition, requiring the overlay network to re-verify all three stamps (identity, content, compliance) for the ticket in its new state;

3. blocking the state transition if any stamp verification fails, keeping the ticket in its prior state until the verification issue is resolved;

4. upon recycling (return to available pool after redemption), clearing all stamps and requiring fresh stamping when a new user acquires the recycled ticket;

wherein the re-verification at each transition ensures that every ticket in every state represents a genuinely verified, compliant, identity-bound content access right, and the clearing of stamps upon recycling generates ongoing demand for verification work across all three mining economies.

Claim 4 — Unified Multi-Currency Mining Device

A computing device configured to simultaneously mine three independent Hash-to-Mint token types, the device comprising:

1. three concurrent mining processes, each performing domain-specific verification work (identity verification for $401, content indexing for $402, compliance evaluation for $403) and submitting work commitments to the corresponding HTM smart contract;

2. an adaptive resource allocator that distributes computational resources across the three mining processes proportionally to each token's current profitability, computed as (token price × block reward) / mining difficulty;

3. a work commitment generator for each mining process that produces Merkle roots of domain-specific verification work, the Merkle root contents being auditable by overlay network peers;

wherein the single device supports three independent mining economies, automatically balancing resources toward whichever token type is most valuable to mine, creating a self-regulating verification network that allocates capacity to wherever demand is highest.

Claim 5 — Stamp-Gated Revenue Cascade

A method for enforcing revenue cascade payments only for validly stamped tickets, the method comprising:

1. checking, when a revenue-generating transaction occurs for a content ticket, that the ticket carries three current, valid stamps ($401, $402, $403);

2. if all stamps are valid, computing and enforcing the revenue cascade as described in the Applicant's Rights Inheritance Cascade patent (bCorp-PAT-013);

3. if any stamp is invalid, expired, or revoked, blocking the revenue transaction until stamps are renewed;

wherein the stamp requirement ensures that revenue only flows through the cascade for legitimately held, authentically content-backed, and jurisdictionally compliant tickets.

---

Abstract

A system and method for validating digital content tickets using tripartite token stamping on a UTXO-based blockchain. Three independent Hash-to-Mint smart contracts produce distinct token types: $401 (identity), $402 (content), and $403 (compliance), each earned by mining nodes performing domain-specific verification work. A content ticket is valid only when it carries three current stamps — one from each domain — verified by the mining network. The creation of new content tickets requires the expenditure of $402 tokens, creating endogenous demand that links platform activity to mining economics. At every ticket lifecycle transition (creation, transfer, staking, redemption, recycling), all three stamps are re-verified, ensuring that circulating tickets always represent genuinely verified, compliant, identity-bound content access rights. A unified mining device runs all three mining processes simultaneously, allocating resources adaptively based on per-token profitability. The system integrates the Applicant's existing tripartite protocol stack ($401/$402/$403), Proof-of-Indexing consensus, and Rights Inheritance Cascade into a single enforcement mechanism with three self-balancing mining economies.

---

Document prepared for UKIPO filing. Priority date to be established upon submission. Applicant: The Bitcoin Corporation Ltd. Inventor: Richard Boase. Date of preparation: 20 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: Tripartite Token Stamping 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-tripartite-token-stamping