§8

Implementation Substrate

This section specifies the actual technical substrate on which HOP runs. The other sections describe what the protocol does conceptually; this section describes the data structures, cryptographic primitives, and infrastructure choices that make the protocol implementable. Steve Yegge built much of this; Matt Beane sits on top of it.

8.1 Design Principles

HOP’s substrate is governed by five design principles:

Cooperative not adversarial. This is a cooperative blockchain, not an adversarial one. We do not need full Byzantine fault tolerance. Stake is rolling-average recent work quality, not crypto deposits. Block creation is cheap (hash-linking, not proof-of-work puzzles). Consensus is simple majority weighted by stake.
Substrate-neutral on the chain choice. The protocol does not specify Ethereum, Solana, Celestia, or any other public chain. It specifies that work blocks must be cryptographically anchorable to a public timestamping authority. Reference implementations may choose Celestia, Ethereum L2s, Bitcoin via OpenTimestamps, or any equivalent. The substrate is a parameter of the implementation, not a property of the protocol. This dodges the religious wars between blockchain communities, which would otherwise consume HOP’s adoption energy.
Use existing infrastructure where possible. Git is already a blockchain — cryptographic hashes, distributed consensus through merge, immutable history. Don’t build blockchain infrastructure from scratch when Git semantics already give you 80% of what you need. Dolt extends Git semantics to structured data; that’s the working layer.
Light blockchain, heavy substrate. The actual workload (character blocks, dual-signed completions, Skillchain accumulation, validator stamps) runs on Dolt — fast, queryable, branchable, mergeable. The blockchain layer is settlement and tamper-resistance, not the working layer. Periodic Merkle-root anchoring to a public DA layer provides the trustless verification property without requiring every block to hit a slow expensive chain.
Sigstore-class, not crypto-class. The cleanest comparison for technical readers: HOP is to labour what Sigstore is to software supply chain. Open protocol, content-addressed work units, signed by participants, federated across implementations, verifiable by any party. This framing avoids the “is this crypto?” baggage that kills enterprise adoption.

8.2 Dolt as the Working Database

Dolt — a SQL database with Git semantics, MySQL wire-protocol compatible — is the operational substrate for HOP. Steve Yegge migrated Beads (the atomic-work data structure) fully from SQLite+JSONL to Dolt in March 2026; Beads now runs in production on Dolt with all of Git’s branching, diffing, merging, federation primitives applied to structured tabular data.

Why Dolt

Git semantics on data. You can branch the chain, run an experiment that writes to its own branch, diff the results against main, merge if good, throw away if not. The probe library itself becomes versionable.
Native to the bead model. Each bead is a row. Each completion is a row update with a signed event. The entire fleet’s work history is queryable as SQL and as a Git log.
Federation via DoltHub. Towns publish to DoltHub. Other towns fork, push pull-requests, push results back. The Wasteland federation runs on this.
Same wire protocol as MySQL. Drivers everywhere. Workers connect with mysql-connector or SQLAlchemy with mysql+pymysql://. Anything that speaks MySQL speaks Dolt.

The Dolt SQL Server Pattern

dolt:
  image: dolthub/dolt-sql-server:latest
  container_name: dolt
  environment:
    DOLT_ROOT_PATH: /var/lib/dolt
  volumes:
    - /storage/dolt:/var/lib/dolt
  ports:
    - "3306:3306"
  restart: unless-stopped

Workers connect with any MySQL client. SELECT FOR UPDATE SKIP LOCKED works (Dolt supports it). Schema is plain SQL. Every commit is a Git commit on the data; you can dolt log, dolt diff, dolt branch experiment-foo.

Shared Server Mode

Beads supports shared-server mode (BEADS_DOLT_SHARED_SERVER=1), letting multiple databases coexist on one Dolt server, each in its own database. This is the production pattern for a Workchain operator running both bd (Beads CLI for strategic work tracking) and the chain’s own tables (worker registry, completion records, currency balances).

8.3 The Beads Schema

Steve Yegge’s Beads is the production reference implementation of the atomic-work substrate. Schema lives at .beads/dolt/. As of v0.57.0:

Core Tables

issues — the bead itself. Hash-based ID like bd-a1b2. Status (open/in_progress/blocked/deferred/closed/tombstone/pinned/hooked). Type (bug/feature/task/epic/chore/message/merge-request/molecule/gate/agent/role/convoy). Priority. Skills/context fields. JSON payload for type-specific data.
dependencies — directed edges between issues: relates_to, duplicates, supersedes, replies_to, blocks, blocked_by. The work graph.
events — event log per issue. State transitions, signatures, completions. Append-only.
labels — tag system for issues.
comments — discussion threads attached to issues.
metadata — issue-level structured metadata.
config — chain-level configuration.
repo_mtimes — tracks last-modified times for federation sync.
routes — federation routing table (which other rigs/towns are reachable, at what address).
federation_peers — the federation membership list.
interactions — cross-rig handshake records.
compaction_snapshots — periodic compactions of historical state for fast cold-start.
issue_snapshots — point-in-time snapshots of issue state for time-travel queries.
issue_counter, child_counters — auto-incrementing counters for issue IDs.
blocked_issues, ready_issues — denormalised views for fast querying.

Wisp Views (Ephemeral Beads)

Wisps are ephemeral beads — they exist in the database and get hash IDs, but aren’t persisted to the permanent store. Vapor phase of matter for Gas Town work. Used for exploratory, speculative, or short-lived work that may never crystallise. Five wisp views:

wisps
wisp_events
wisp_comments
wisp_labels
wisp_dependencies

Wisps mirror the issue schema but live in views rather than permanent tables. A wisp can be “promoted” to a real issue (its hash is preserved; permanence is added). A wisp can also evaporate without leaving a trace if the work it represented was abandoned.

This matters for HOP: bidding can happen as wisps. A worker’s Skill-Agent constructs a curriculum, posts it as a wisp bid, watches the Worker-Agent’s response. If the bid wins, the wisp is promoted to a real bid record; if it loses, the wisp evaporates. No noise on the permanent chain from speculative bidding.

Issue Type Spectrum

The Beads issue types span from operational (“bug”, “task”) to architectural (“epic”, “molecule”) to organisational (“agent”, “role”, “convoy”). This is wider than a typical issue tracker because Beads is the substrate for all coordination, not just engineering work. A “convoy” is a bundle of beads assigned to an agent; an “agent” issue declares a worker’s identity and capabilities; a “role” defines a position template that workers can fill.

HOP extends this taxonomy slightly. The HOP-specific types are documented at the protocol level (character blocks, growth blocks, beans, attestations) and map onto Beads’ issue types via a HOP-extension namespace.

8.4 The HOP Character Block on Top of Beads

A HOP character block is a Beads issue with HOP-specific structure on top:

-- The Beads issue gives us:
--   id (hash-based content address)
--   status, type, priority
--   timestamps, signatures
--   dependencies to other issues

-- HOP extends with:
CREATE TABLE hop_character_block (
    issue_id           VARCHAR(64) PRIMARY KEY,        -- Beads issue.id
    worker_identity    VARCHAR(128) NOT NULL,          -- uuid or pubkey
    workchain_id       VARCHAR(256) NOT NULL,          -- sol/earth/...
    block_type         ENUM('work','growth','bean','attestation') NOT NULL,
    inventory          JSON,                           -- hardware, credentials, assets
    skills             JSON,                           -- stamped capability map
    growth             JSON,                           -- declared trajectory
    context            JSON,                           -- interaction details, abstracted
    worker_signature   VARCHAR(512),
    poster_signature   VARCHAR(512),
    validator_signature VARCHAR(512),                  -- optional
    prev_block_hash    VARCHAR(64),                    -- chain link
    created_at         TIMESTAMP NOT NULL,
    attested_at        TIMESTAMP,
    
    INDEX idx_worker (worker_identity),
    INDEX idx_chain (workchain_id),
    INDEX idx_type (block_type),
    FOREIGN KEY (issue_id) REFERENCES issues(id)
);

The block extends rather than replaces the Beads issue. A character block IS a Beads issue, with HOP semantics layered on. This means everything Beads supports (federation, branching, diffing, snapshots) applies to character blocks for free.

8.5 Cryptographic Primitives

HOP uses well-established primitives. No novel cryptography. The protocol relies on:

Signed Append-Only Logs

Every chain (Workchain, Skillchain, Bean Chain) is implemented as a signed append-only log. Each block contains:

prev_block_hash — Merkle-shaped chain link
worker_signature and poster_signature — dual-attestation
validator_signature (optional) — third-party stamp
Content hash addressing for the block itself

This is the same model as Sigstore’s Rekor transparency log, built on Trillian. Reference: github.com/sigstore/rekor, github.com/google/trillian.

Content Addressing

Every block has a content-addressed hash that names it uniquely. Two workers cannot produce the same block (the dual-signature ensures uniqueness; the timestamp provides ordering). The hash is computed deterministically from block contents and serves as both ID and integrity check.

Merkle Trees for Batch Verification

Workchains accumulate blocks at high rate. Anchoring every block individually to a public chain is uneconomical. Instead, batches of blocks are summarised into a Merkle root; the root is anchored. Verifying any block requires:

Fetch the block from any HOP town that has it
Compute its hash
Fetch the Merkle proof from the town
Verify the proof against the anchored root on the public chain

No trust in the town required. The public chain provides timestamping; the Merkle proof provides inclusion; the signature provides authenticity. All three together provide the property: the chain survives the death of any individual town.

Public-Key Identities

Every worker (human, rig, agent swarm) has a keypair. Hunters operate distinct keypairs from the worker (the Hunter is the worker’s agent, not the worker). Institutions have keypairs. Validators have keypairs. The keypair is the persistent identity across all chains.

The keypair scheme is implementer’s choice: Ed25519 is the recommended default (small, fast, well-audited). RSA is acceptable for compatibility with existing institutional PKI. Quantum-resistance migration (Dilithium, Falcon) is a v0.3 concern.

BBS+ for Selective Disclosure (v0.2)

The v0.1 baseline uses dual-signed blocks with abstraction-at-signing-time for privacy: institutions emit pre-abstracted blocks that strip PII before signing. This works but requires the institution’s protocol-layer agent to be honest about the abstraction.

The v0.2 cryptographic upgrade adds BBS+ signatures (W3C Verifiable Credentials Data Integrity, BBS Cryptosuite v2023). BBS+ provides:

Selective disclosure: signer signs all attributes once; holder reveals subsets without revealing the rest. Cryptographic guarantee.
Unlinkable proofs: presentations of the same block to different verifiers cannot be cryptographically correlated.
Predicate proofs: prove “I have ≥3 blocks with complexity_class: high in the last 12 months” without revealing which three.
Private holder binding: the same block presented to two Workchains cannot be correlated as the same worker.

The Comprehension Gate is the protocol-level wrapper around BBS+ derived proofs. Specification under construction; reference at the W3C VC-DI-BBS spec.

8.6 The Anchoring Substrate (Celestia-Class)

Periodic Merkle-root anchoring requires a public timestamping authority. The candidates:

Celestia. Modular blockchain explicitly designed as a data availability layer. Built for the case where you have your own application-specific chain that needs cryptographic anchoring without running its own consensus. Each HOP town becomes a Celestia rollup. Cheap, fast, designed for exactly this. Recommended default.
Ethereum L2s (Arbitrum, Optimism, Base, Polygon zkEVM). Higher cost than Celestia but better established and with more tooling. Acceptable for high-value chain anchoring.
Bitcoin via OpenTimestamps. Cheapest option, longest-lived chain, widely trusted as a timestamping authority. Acceptable for low-frequency batch anchoring.
Hyperledger Fabric / permissioned chains. For enterprise federations between known parties. Heavyweight; only worth it when the federation requires identity-bound participation rather than open access.

The Anchoring Schema:

CREATE TABLE workchain_anchors (
    id                  INT PRIMARY KEY AUTO_INCREMENT,
    batch_start_seq     BIGINT NOT NULL,
    batch_end_seq       BIGINT NOT NULL,
    merkle_root         VARCHAR(64) NOT NULL,
    anchor_chain        VARCHAR(32) NOT NULL,    -- 'celestia', 'ethereum-l1', 'bitcoin-ots'
    anchor_tx_hash      VARCHAR(128),
    anchor_block_height BIGINT,
    anchored_at         TIMESTAMP,
    
    INDEX idx_chain (anchor_chain, anchor_block_height)
);

Forward-compatibility note: the anchoring table can exist with anchor_tx_hash nullable from day 1. Chains can run without anchoring during early operation, then turn on the anchoring job when they’re ready. The schema is the same.

8.7 The Federation Layer (Wasteland Pattern)

The Wasteland is the federation pattern Steve Yegge launched March 4, 2026. Gas Towns connect to each other through DoltHub, with a commons for putting work up for grabs and a reputation/skills system built by Matt Beane.

Federation Mechanics

A chain federates by:

Publishing its Dolt database to DoltHub (or to any Dolt-compatible registry).
Declaring its Anchor Block (the public prospectus of its terms).
Signing into a federation peer list, which lists chains it accepts work from and signs to.
Periodically pushing/pulling state from peer chains.

Cross-Chain Work Wrapping

Anyone can take a work item from one chain and post it on another, wrapping the original:

[Wrapper - new layer, signed]
Finder fee: 2%
Posted on: QChain2
Original: [pointer to QChain1 item, hash-verified]

[Original header - unchanged, verified by signature]
Task: Build auth system
Pay: $10k (minus 2% finder fee)

This means anyone can be a talent scout. A worker who finds a poorly-distributed work item on a generalist chain can re-post it to a specialist chain for a finder fee. Market discovers optimal placement; new chains bootstrap through existing chains.

Cross-Chain Skill-Vector Translation

A worker’s software_engineering: 7.2 on the Accenture chain does not automatically map to software_engineering: 7.2 on the public Engineering chain. Different chains may have different stamping standards. The protocol supports cross-chain attestations: the Accenture chain can sign a translation block stating “our 7.2 maps to public 6.8 with confidence interval [6.5, 7.0]”. Workers can then carry both attestations on their Skillchain.

This is a v0.2 lane. v0.1 implementations should treat skill scores as chain-local and require workers to accumulate independent stamps when entering a new chain.

8.8 The Five Universes — Per-Entity Carry Pattern

The character sheet (§4) lives across five universes plus Group Vectors (the v0.2 sixth). The data structures differ by universe in an important way: most universes are self-carried, but Reputation is inverted.

Universe	Carry Pattern
Skills	Self-carried. Worker holds a chain of stamped capability blocks.
Work	Self-carried. Worker holds a chain of completed character blocks.
Currency	Self-carried. Worker holds wallet balances per chain.
Inventory	Self-carried. Worker holds proofs of asset ownership and credentials.
Group Vectors	Self-carried. Worker holds joint-team stamps from past collaborations.
Reputation	Inverted. Worker carries NOTHING about themselves. Reputation lives only in stamps that others have written. Worker carries the dual: the stamps they themselves wrote about others.

The inversion is load-bearing. It makes self-attestation impossible by construction. The Deacon defence (“you cannot write in your own yearbook”) is built into the data model rather than enforced by audit policy.

A reputation query is a network query. To learn about a worker’s reputation, you query the chains the worker has touched, filter by chains you trust, and aggregate the attestations. The worker has no say in what is returned. They cannot delete bad stamps; they cannot inflate good ones. Their only reputation signal that they themselves control is who they have stamped, which reveals their values rather than their performance.

Light Blockchain Stake

In the cooperative-not-adversarial model, “stake” is rolling-average recent work quality, not a crypto deposit. A new entity has no history; cold start works through:

Vouching: an established worker on the chain co-signs the new worker’s first few completions. The new worker accumulates real stamps; the vouching worker stakes their own reputation.
Probationary stake: the chain issues a small bootstrap balance (per Basal Rate Law, §1.3). The new worker can bid on small beads to start; success accumulates stake.
Buy-in: for chains that require it, the new worker can purchase chain-tokens from existing holders, providing initial stake at a market price set by the chain.

The three modes are not mutually exclusive; chains can offer all three depending on the worker’s circumstances.

8.9 Banks as Trust Sources (Implementation)

A critical implementation insight: institutions don’t need to run blockchain nodes. They need to sign blobs.

A high-trust systemic bank — or any regulator-blessed identity authority operating its own customer authentication — is already the source of truth for jurisdictional banking identity. Adding HOP support requires not “build us a blockchain” but “sign this payload with your institutional key”. That is a feature-flag-sized integration against existing PKI, not a project.

The architecture:

┌─────────────────────────────────────────────────────┐
│                      HOP                            │
│         (employment, credentials, trust)            │
└─────────────────────┬───────────────────────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────────────┐
│           Identity Chain (worker's)                 │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐       │
│  │  Block    │→ │  Block    │→ │  Block    │→ ...  │
│  │  signed   │  │  signed   │  │  signed   │       │
│  │  by Bank  │  │  by Bank  │  │  by ?     │       │
│  └───────────┘  └───────────┘  └───────────┘       │
└─────────────────────┬───────────────────────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────────────┐
│              Trust Source Endpoint                  │
│    (already exists, already trusted, just signs)    │
└─────────────────────────────────────────────────────┘

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, lower data-protection overhead, no infrastructure cost. The institution provides what it provides today (authentication) in a slightly different format (cryptographic signature on a structured payload).

The use-case framing — including the per-attestation pricing model, the principle-level wiring (P1 liability, P2 payment-accountability, P3 no-free-clip, Corollary 1 consumer-pays), and the V3 split for fee distribution — lives in §9.5 Banks as Trust Sources. This subsection covers only the implementation substrate.

The pattern generalises beyond banking. Notaries, registered identity authorities, professional licensure bodies, and consortium-operated trust networks all fit the same shape: a regulator-blessed institution exposes a signing endpoint over its existing authentication infrastructure. The implementation substrate is sector-neutral; Banks as Trust Sources is the canonical instance.

This is the politically tractable implementation path. It is also the path of least resistance for any institution that already operates a public-key infrastructure.

8.10 Tokenomics and Smart Contracts

Token Flow

// Customer posts task with escrow
customer.post_task({
  task: task_spec,
  escrow: 150_000 tokens  // Locked in smart contract
})

// Worker completes task
worker.submit_completion(task, deliverable)

// Quality validation
if (validate_quality(deliverable, task.quality_threshold)) {
  platform_fee = escrow * 0.05   // chain off-ramp
  worker_payment = escrow * 0.95
  
  transfer(worker_payment, worker.wallet)
  transfer(platform_fee, platform.treasury)
  
  worker.work_chain.append({
    task: task.id,
    payment: worker_payment,
    signed_by: customer.id,
    timestamp: now()
  })
}

Bid Acceptance as Smart Contract

The bid-acceptance handshake creates a binding contract on-chain that includes:

Mutual commitment (both parties sign)
Price agreement (locked in)
Scope definition (what’s being delivered)
Timeline commitment (when it’s due)
Dispute resolution (which chain’s rules apply)

For mutex postings, bid acceptance also locks the work — no other worker can claim it until the contract resolves (success, failure, or timeout). For winner-takes-all postings, bid acceptance is just the entry receipt; no exclusion mechanic.

Multi-Stage Bids

Complex work can be decomposed into multi-stage bids:

Phase 1: Discovery/Architecture ($20k, 2 weeks)
  - Deliverable: Technical spec
  - Team: 2 senior architects
  - Payment on spec approval

Phase 2: Implementation ($120k, 8 weeks)
  - Deliverable: Working system
  - Team: 6 engineers (named)
  - Payment milestones defined

Phase 3: Deployment/Support ($60k, 4 weeks)
  - Deliverable: Production launch + docs
  - Team: 3 DevOps + 2 engineers
  - Payment on successful launch

Each phase has its own bid-acceptance handshake. Team members can be swapped between phases (with new handshakes). This is how large institutional contracts decompose into HOP-native work.

8.11 Privacy Levels

Workers select a privacy level per bid:

PrivacyLevel = Enum {
  Anonymous: {
    reveal: ["skill_embedding"],
    hide: ["identity", "location", "work_history"]
  },
  Verified: {
    reveal: ["skill_embedding", "reputation_score"],
    hide: ["identity", "detailed_work_history"]
  },
  Public: {
    reveal: ["all"],
    hide: []
  }
}

For Anonymous and Verified, BBS+ derived proofs (v0.2) provide the cryptographic guarantee that the hidden fields exist and were signed without revealing them.

Zero-Knowledge Skill Proofs

function prove_skill_without_identity(skill_chain, required_skill) {
  proof = zkSNARK.generate({
    public_input: required_skill,
    private_input: skill_chain,
    circuit: "skill_verification"
  })
  return proof  // Verifier confirms skill exists, but not who has it
}

Use cases:

Bid anonymously until selected
Work on sensitive tasks (security research, whistleblowing)
Avoid bias (employer doesn’t see demographics, just capability)

ZK-skill-proofs are a v0.2 lane. v0.1 implementations rely on BBS+ selective disclosure for the same capability with simpler tooling.

8.12 Chain Topology — DAG Not Linked List

A common misconception is that HOP’s chains are linked lists. They are not. Each chain is a directed acyclic graph (DAG). The prev_block_hash field on a character block points to the immediate parent block in the chain, but a parent can have many children, and a Workchain root can have many parents (typically the workers and posters who attest to its provenance). Skillchains are nearly linear in practice (a worker’s blocks accrue chronologically), but the protocol does not assume linearity.

This matters for three reasons:

Forks are first-class. A chain that diverges produces two valid lineages from a common ancestor. Both lineages are recoverable; the protocol does not pick a winner. Workers can choose which fork to follow; chain operators can choose which fork to maintain. This is the substrate-level mechanism that makes the Forking Rule (§6.7) implementable.
Recursive decomposition produces tree structure. When a $10,000 bead is decomposed into nine $1,000 children, the parent bead becomes the root of a tree. Each child has the parent as its parent-reference; each child can spawn grandchildren; the entire decomposition is traversable in either direction. This is how complex work composes without explicit project-management overhead.
Cross-chain references are graph edges. When a worker’s character block on Chain A references a Bean issued on Bean Chain B, that’s a graph edge between two chains. The full HOP federation is therefore a DAG of DAGs: each chain is itself a DAG, and chains reference each other through cross-chain attestations.

Why Subchains Replace Swarm IDs

Steve Yegge’s original Gas Town design used Swarm IDs to group related work — explicit identifiers attached to every bead saying “this is part of swarm X.” This worked but felt heavyweight: someone had to assign the IDs, manage their lifecycle, decide when a swarm was “done.”

The DAG-of-chains approach makes Swarm IDs unnecessary. Grouping emerges from work itself. Worker-19 attaches their subchain to whatever parent makes sense — maybe Epic-2847, maybe a brand-new Epic-2848. The structure doesn’t care. When you query “what work was related to Epic-2847,” you walk the subchain ancestry and the answer is exact. Provenance is structural, not declarative.

This is also the answer to “when does it end?” A subchain is complete when:

All its sub-subchains are merged or abandoned
No pending work references it as a parent

You don’t declare completion. Completion is a derived property of the chain state. Queries like SELECT * FROM beads WHERE subchain_root = 'Epic-2847' AND status = 'open' tell you whether the work is finished without anyone needing to explicitly close it.

8.13 The Witness — Structural Integrity (Distinct from Validator)

§5.5 specifies the Validator — an LLM-driven agent that stamps work quality and identifies Mentorship completions. There is a second, distinct agent class focused on structural integrity rather than work quality: the Witness.

The Witness is not an LLM. It is programmatic infrastructure that validates blocks rather than work outputs:

Does this character block’s prev_block_hash actually point to a valid prior block?
Does this subchain properly link to its declared parent?
Are there conflicting blocks (two agents claiming the same state transition)?
Are signatures valid against the claimed signers’ public keys?
Is the block’s content hash correct?

The Witness is the chain’s structural integrity layer. It is what catches malformed blocks, broken chains, and signature forgeries. It runs continuously over the chain, ideally as a daemon that monitors block additions in real time and refuses to acknowledge invalid blocks.

The split between Validator and Witness mirrors a split in traditional software engineering: code review (semantic correctness, “is this the right work?”) vs CI/CD pipeline (mechanical correctness, “does this build, does it pass tests, does it match the schema?”). HOP needs both. Collapsing them into one role gets you a Validator that’s overloaded with structural concerns or a Witness that drifts into making semantic judgements it shouldn’t.

In Gas Town’s reference implementation, the Deacon plays both roles — work-quality stamping and chain integrity. This is acceptable at small scale but should split as chains grow. The protocol allows one or two roles depending on chain size; large chains will run separate Validator and Witness instances.

8.14 Conflict Resolution and Orphan Blocks

When two agents produce conflicting blocks (two workers claiming completion of the same mutex bead, or two state transitions for the same chain head), both blocks are proposed and the conflict is resolved through stake-weighted voting:

Both blocks enter the chain as competing candidates.
Validators (and other stake-holding agents) cast votes for which block to accept.
Higher-stake agents’ votes count more (per §7.4 stake-as-governance).
The losing block becomes an orphan — recorded in the chain but not part of the canonical history.
The orphan block is preserved permanently, not deleted. Auditors can always see what was proposed and rejected.

This is the substrate-level mechanism for handling disputes. For most conflicts, the resolution is automatic. For genuinely hard conflicts — where stake-weighted voting produces no clear winner — the dispute escalates to the parent chain, which may delegate to human arbitrators per the dispute-resolution policy declared in the chain’s Anchor Block.

Orphan blocks are also how the protocol handles fork detection. Two workers attempting to claim the same bead simultaneously produce competing blocks; the first to receive enough validator signatures wins; the loser’s block becomes an orphan. The worker whose block was orphaned is not penalised — they made a legitimate attempt — but their work for that bead does not contribute to their Skillchain.

8.15 Chain Bloat Management

Chains grow continuously. A Workchain handling 10,000 postings per day produces 3.65 million completed character blocks per year, plus all the intermediate state transitions, attestations, and Bean settlements. After ten years, naive chain growth produces tens of millions of blocks per chain, billions across the federation.

The protocol manages this through three mechanisms:

Compaction Snapshots

Beads’ compaction_snapshots table stores periodic snapshots of historical state. Old blocks beyond the compaction horizon (typically 12-24 months) can be archived to cold storage; chain queries against historical state proceed against the snapshot rather than the full block stream. This is how the chain stays queryable at decade scale without keeping everything hot.

The integrity property is preserved: snapshots are themselves Merkle-rooted and anchored to the public chain. A historical block can still be cryptographically verified by retrieving it from cold storage and walking the snapshot Merkle proof.

Subchain Pruning

Subchains that are merged and no longer referenced can be compacted into their integration point. The completed work is permanent (the dual-signed character block remains); the intermediate decomposition tree can be pruned. Workers retain proofs of their leaf-level contributions; the integrator’s character block represents the integrated work. The intermediate scaffolding is dropped.

This is analogous to how Git’s git gc reclaims space from unreachable objects. The chain’s audit trail is preserved through Merkle anchoring; the operational state stays small.

Branch Archival

Workchains that go dormant (no posts for 6+ months) can be archived. The chain’s state is checkpointed to a final Merkle root; the root is anchored to the public chain; the operational Dolt instance can be shut down. Workers’ Skillchains retain their portable copies of any character blocks they earned on the archived chain. Future queries against the archived chain proceed against the checkpoint.

8.16 Reputation-Weighted Priority

The protocol does not need a manual queue overseer to prioritise work. Priority is computed:

priority = f(urgency, agent_stake, subchain_depth, dependency_count)

Where:

urgency — declared by the poster, baseline priority
agent_stake — claiming worker’s reputation/stake; high-stake agents’ work integrates faster
subchain_depth — how deep in the decomposition tree (deeper = closer to leaves, often higher priority)
dependency_count — number of other beads waiting on this one (high = blocking critical path)

This formula replaces the manual queue juggling that platform managers do today. An agent with a stellar Skillchain gets work integrated faster; a new agent with no history waits behind those with proven track records. This is fair in a way manual prioritisation can never be — it’s based on demonstrated capability rather than political relationships.

The formula is open and chain-configurable; chains can publish their priority function in the Anchor Block. Workers choose chains partly based on whether the priority function is one they trust. Forks of chains often vary the priority function; workers migrate to forks whose priority calculus matches their own incentives.

8.17 Cold Start: The Identity Resolution Layer

A fundamental challenge for any new protocol: empty chains have no value. Workers don’t join chains where no work exists; posters don’t post to chains where no workers exist. Network effects are existential.

HOP solves this through identity resolution against existing public ledgers. Before HOP launches in earnest, a bootstrap layer scrapes public records of skill demonstration:

GitHub — every commit is signed work; pull requests are dual-attested (author + reviewer); contribution graphs reveal sustained capability
Kaggle — competition rankings and notebook publications are verified skill demonstrations
Stack Overflow — accepted answers and reputation scores are validated skill stamps
Hugging Face / Papers With Code — model contributions, dataset publications, paper links
npm / PyPI / crates.io / RubyGems — package authorship, download statistics, dependency relationships
arXiv — author publications with citation graphs
Bug bounty platforms (HackerOne, Bugcrowd) — verified security findings and payouts
Funding platforms (Patreon, GitHub Sponsors, OpenCollective) — community-validated value creation

The boot-block algorithm:

Scrape these public sources for individuals demonstrably doing skilled work.
Resolve identities across platforms (linking GitHub username to Stack Overflow account to npm publisher to Twitter handle, where the user has publicly cross-linked).
Construct provisional Skillchains from the scraped evidence — one character block per significant work artifact, signed by the scraper’s bootstrap key, marked as provenance: cold_start_inferred.
Hold the Skillchain in escrow at a known address derived from the resolved identity.
When the user opts in, they prove control of their cross-linked identities (one-time signing challenge) and the escrowed Skillchain is transferred to their custody.
Existing chains then federate against this corpus — Workchains can recognise scraped capability instantly because the Skillchain is real, just provisional.

This produces a starting state with millions of pre-populated Skillchains before any user explicitly joins HOP. The first user to opt in finds their professional history already on the chain, attested by the bootstrap layer; subsequent users find a network already populated with their actual peers.

The provisional nature is important. Cold-start blocks are clearly marked as such; their cryptographic weight is lower than directly-attested blocks; users can dispute or replace them once they take custody. The bootstrap is evidence, not truth. But it solves the cold-start problem without anyone needing to create their account from scratch.

This is also how the LinkedIn-killer dynamic plays out. The user’s first interaction with HOP is “your work history is already here, accurate, portable, sovereign — you just need to claim it.” The friction to join is near zero; the value of joining is high; the network effect bootstraps from the first user.

8.18 What Lives Where

A consolidated view of where each piece of state lives:

State	Storage	Why
Beads / character blocks	Dolt (per chain)	Fast queryable, branchable, versionable, federatable
Skillchain (per worker)	Worker’s local Dolt + cloud backup	Sovereign, portable, never on platform
Currency balances	Dolt per chain + bridge tables for federation	Each chain operates its own ledger
Reputation	Network query across trusted chains	No self-attestation possible
Bean Chain stakes	Dedicated Dolt instance per Bean Chain	Long-dated, requires its own settlement infrastructure
Public anchors	Celestia / L2 / OpenTimestamps	Tamper-resistance and trustless verification
Identity proofs	Issuing institution’s signing service (Banks as Trust Sources pattern, §8.9)	Institutions already have this
Federation peer list	Dolt `federation_peers` table	Discovery and routing
Wisps (ephemeral)	Dolt views, not persisted	Speculative bidding, exploration

This composition gives HOP its scale property: lightweight where speed matters (Dolt for the working layer), heavyweight where trust matters (public chain for anchoring), and absent where neither matters (no centralised platform database to capture or extract from).