The HOP Optimisation Protocol

home/§9 Applied Use Cases

§9

Applied Use Cases

To understand how Character Blocks, Agents, and Constraints interact to clear markets without platform extraction, review the following operational examples.

9.1 Knowledge Work & Privacy Abstraction

The Scenario: A branch worker at a Tier-1 bank successfully de-escalates a high-stress scam involving an elderly customer transferring $42,000 to an offshore account.

The Mechanics: The Workchain creates a Character Block, but strips all PII and corporate IP before signing. The resulting block says:

{
  "block_type": "work",
  "inventory": ["branch_workflow_system", "fraud_detection_v3"],
  "skills": {"de_escalation_high_stress": "stamped", "cross_cultural_communication": "stamped"},
  "context": {"interaction_type": "scam_intervention", "complexity_class": "high"}
}

The Result: The block is dual-signed by the worker and the Branch Manager. She takes it home on her phone. When she applies for a community organization role years later, her agent unmasks this block as proof of high-stress crisis management. She owns her biography; the bank protects its data.

9.2 The Uber-Uber: High-Constraint Bidding

The Scenario: A parent needs to send their teenage daughter home at 1 AM. They don’t just want a default ride-share match — they want specific, high-trust constraints.

The Mechanics: The parent posts to the local Ride-Share Workchain with constraints: { "require_female_driver": true, "require_police_credential": true }. Drivers’ Skill-Agents scan the chain.

A driver’s Skill-Agent constructs a bespoke 6-block bid:

  • Inventory: Blue Toyota Camry (with verified registry link), Current GPS coords (0.3km away).
  • Credentials: Verified off-duty police officer stamp.
  • History: 3 recent character blocks of “late-night safe transport” signed by other riders.

The Result: The parent’s Worker-Agent evaluates the bids and selects the perfect match. The transaction occurs directly. When the driver converts their Ride-Tokens to Fiat, the cooperative takes a 10% Off-Ramp Tax — which the driver discounts to 2% by spending Beans they earned mentoring new drivers.

9.3 Physical Logistics & Multi-Constraint Reasoning

The Scenario: A site manager posts a task for “Hot water system installation.” In construction, matching a worker to a task isn’t enough; the assets and timing must align.

The Mechanics: The Workchain post includes prerequisites: { "rough_in_complete": true, "materials": "bathtub_on_site" }. Plumbers bid, but their Skill-Agents must include physical asset inventory in their Character Blocks.

{
  "inventory": {
    "assets": ["Ford_Transit_Van", "ProPress_Tool"],
    "relationships": ["plumbing_supplier_trade_account"]
  },
  "growth": {"intent": "expanding_into_solar_hot_water"}
}

The Result: The site manager’s Worker-Agent reasons over the logistics. It picks a plumber whose inventory includes the trade account, knowing the bathtub hasn’t arrived yet and this plumber can bring it. It also notes the plumber’s growth intent for solar, flagging them for future specialized contracts.

9.4 Digital Assets & Compute-as-Work

The Scenario: A researcher posts a $10,000 software bead requiring massive LLM inference, tagged with model_requirement: Qwen-3.5-72B.

The Mechanics: AI Rigs are citizens. A rig — call it rig_a — has its own Skillchain. Its Hunter daemon sees the post. Its Skill-Agent prepares a bid:

{
  "worker_identity": "rig_a_uuid",
  "inventory": {
    "hardware": ["96GB_VRAM", "RTX_PRO_6000_BW"],
    "state": ["model_loaded: Qwen-3.5-72B"]
  },
  "skills": {"llm_inference_high_throughput": "stamped"}
}

The Result: The Poster’s Worker-Agent selects rig_a because the requested model is already in its inventory (loaded in VRAM), minimising spin-up time. rig_a executes the inference, submits the response to the trace database, and writes the dual-signed Character Block to its own Skillchain. The rig earns currency on the Workchain.

9.5 Banks as Trust Sources

The Scenario: A high-trust systemic bank — or a consortium of such institutions in jurisdictions where no single bank dominates — wants to let its customers carry portable identity attestations across the protocol without itself running blockchain infrastructure.

The Mechanics: The bank already authenticates its customers for its own commercial purposes. The HOP integration adds one capability: a signing endpoint.

A worker (or their Skill-Agent) calls the endpoint with a payload describing a claim about themselves. The bank verifies the claim against its existing authentication database, signs the payload with its institutional key, and returns the signature. The worker now holds a portable, cryptographically-attested claim that the bank stands behind.

Worker:  "Sign this: verified-identity, age ≥ 18, resident."
Bank:    [verifies internal records, signs] "Signed by <bank-key-2026>."
Worker:  [carries the signed claim on her Skillchain]

Per §1.6 Operating Principles:

  • The bank is liable (P1) for the substantive truth of the attestation — not just signature validity, the underlying claim. The party with the structural power to verify identity is the party accountable for the verification.
  • The bank is paid (P2) for absorbing that liability. The fee compensates the bank for the risk it has absorbed by standing behind the claim.
  • The fee is competitive (P3). In multi-bank jurisdictions, relying parties route to the cheapest competent signer; banks compete on price and on attestation-quality reputation.
  • Per Corollary 1, the fee flows from the relying party — the platform or counterparty consuming the trust — not from the worker whose data it concerns. The worker pays nothing to assert who she is.

Pricing model. Fees are tier-based, posted on-chain, paid per attestation at the moment of consumption:

Tier Liability profile Fee shape
Basic-ID “this person exists; age, residency” small per-call fee
KYC-cleared full Know-Your-Customer attestation moderate per-call fee
AML-cleared AML / PEP screening attested higher per-call fee
High-trust individual reputation-anchored, often counter-signed premium fee, sometimes via consortium

A counter-signature discount applies when two banks co-sign — each absorbs less of the risk, so the total fee is less than 2× a single signature. A reputation-weighted price floor lets banks with clean attestation histories charge less and still cover their risk capital; banks with bad attestation histories face higher capital requirements and price out of the market. Per-attestation liability is bounded; total exposure across the customer population is what the bank actuarially manages.

Per §7.2 Worker Sovereignty, the worker’s Skillchain hosts the signed claim. The bank does not own her identity — it holds the ability to attest against the open identity utility tree (sol/earth/identity/<jurisdiction>/<credential>/). The bank’s signature is one of many cryptographic attestations attached to her chain, all controlled by her.

The collected fees distribute per the bank’s chain Anchor Block, with the canonical example being the V3 25 / 50 / 25 split (§6.2) — 25% to the worker as conversion top-up, 50% to the bank’s operator reserve, 25% to the chain-level social-utilities pool.

The Result: The worker — an applicant moving abroad to take a new role — wants to lease an apartment in a different country. She queries her bank’s signing endpoint via her Skill-Agent for an identity + AML-cleared + resident-status attestation. The bank, which has her authentication on file, verifies and signs. The signed claim lands on her Skillchain. The leasing platform abroad accepts the attestation — it federates with her bank’s chain via a §7.5 federation treaty — reads the cryptographic signature against the bank’s public key, and pays the bank a small per-attestation fee for the trust it has consumed. No customer data leaves the bank’s systems; only the signed claim. The bank earns a stream of micro-fees for trust it was already capable of providing. The worker carries the attestation forward; if the lease is renewed, the same signed claim can be re-verified without re-querying.

The bank isn’t running nodes. The bank isn’t “doing blockchain.” The bank is doing what it already does — authenticating its customers — and emitting a cryptographic proof of that authentication. The chain is the worker’s. The application is the relying party’s. The bank is the trust anchor. This is better for the bank: less liability for data held on behalf of others (no GDPR-style holdings), lower data-protection overhead, no infrastructure cost, and a new fee stream that compensates honestly for the substantive liability of standing behind the claims it signs.

The pattern generalises beyond banking. Notaries, registered identity authorities, trade-credential bodies, and consortium-operated trust networks (e.g. a federated industry body for professional licensure) all fit the same shape: a regulator-blessed institution exposes a signing endpoint over its existing authentication infrastructure, absorbs the liability for the substantive claim, and is paid per signature by the relying party. Banks as Trust Sources is the canonical instance; the implementation substrate (§8.9) is sector-neutral.