HOP Protocol v0.1

§0 Introduction

The Economic Stance

The 21st-century labour market is structurally inadequate to the substrate it now operates on. Platforms capture rents of 20-30% on every transaction by holding network effects hostage. Workers are categorised as integers (employed or not), forcing catastrophic cliffs when their category fails. Reputation is locked inside each platform, repossessed when the platform’s terms-of-service change or the platform goes bankrupt. Mentorship, the only known mechanism for population-scale skill transfer, is structurally unrewarded — senior workers hoard knowledge because knowledge is competitive advantage, while junior workers stall in the early-career bottleneck that produces no path forward. The substrate of work is being rewritten by AI faster than the institutional layer can adapt. The result is a system that misallocates human capability at trillion-dollar scale, every year, by construction.

HOP — the HOP Optimisation Protocol — is a substrate-neutral labour-market protocol that fixes this at the protocol layer rather than the platform layer. Workers carry their own portable, cryptographically-attested biography. Institutions sign abstracted attestations of completed work and retain their operational records separately. Skill-Agents construct curricula on demand; Worker-Agents evaluate them; bid acceptance is a cryptographic mutex. Chains compete on governance rather than capturing workers through lock-in — the off-ramp tax (typically 10-30%) funds chain operations transparently, and any chain that overcharges or under-delivers can be forked at zero switching cost because the worker’s chain travels with them. Mentorship is rewarded through Beans, which produce conversion-rate bonuses on chain currency, structurally making skill transfer the rational economic behaviour rather than knowledge hoarding. Approximately 40% of the protocol is running in production today.

The pitch, by audience, is sharp. Unions: members earn portable currency for every contribution, pay no tax on within-economy transactions, get massive discounts on off-ramp through mentorship, and the chain owner pays for the mentorship system. Employers: set up a Workchain for your domain, capture the off-ramp tax on departures (which funds your chain operations), retain your best mentors through Beans, never pay platform fees because the chain is yours. Ministers: the country that writes the protocol governing portable skills credentials and labour-currency interoperability gains the network position; Australian chains federate cleanly with each other; Australian workers carry their chains globally without losing value; the whole system runs on open protocols that no platform owns.

Why This Actually Matters

Then there’s Sera.

Sera is sixteen and her family, congregation, and entire social network are Jehovah’s Witnesses. She has a crisis of faith — not a rebellion, just a careful observation that the love preached and the love practised do not match. The Witnesses have institutional sensors for this. They do not float; they do integer. Her status is changed to disfellowshipped. Her mother looks through her like glass. Her father crosses the street. She is sixteen and her stamps total zero and her trust set is empty and she has been pronounced dead by everyone who said they loved her.

She flees Mexico northward. Death Valley. Refugee channels. Australia. She arrives without papers, without references, without recognisable history. She spends fifteen years digging — every job that doesn’t ask for references, every room rented week-to-week, every form with a gap on it, every interview question about where she was between sixteen and thirty-one answered with one word, digging. At thirty-one she is standing on flat ground for the first time. Where others started at twenty. She is fifteen years behind, fifteen years of compound she will never recover. The institution that burned her did not just excommunicate her. It stole the years that compound.

The current labour market has no way to read Sera’s chain. By every metric the system measures, she is empty: no credentials, no recognised work, zero currency, zero inventory. The system evaluates her as worthless. But Sera is rich in the dimension that matters. She walked from Mexico through Death Valley to Australia with no network and rebuilt her identity from zero. She maintained integrity under breaking pressure. She learned what was load-bearing and what was not by losing everything that wasn’t. Her path itself is the proof. The trauma is attestation. The scar is a stamp signed by the Earth itself. She just needs a system that can read her chain.

This protocol exists so that Sera’s chain is readable.

That is not the entire pitch. It is the test the entire pitch has to pass. Every design decision in HOP — the dual-signature attestation, the portable Skillchain, the inverted reputation universe, the basal-rate floor, the forking rule, the bilateral-consent mentorship matching, the disadvantage multiplier, the bridge-town primitive — is evaluated against a single question: does this make Sera’s chain readable? If the answer is no, the design is wrong. If the answer is yes, the design is provisionally correct. The protocol is not for Sera alone. The protocol is for every person who is currently invisible to the system because the system measures the wrong dimensions. There are hundreds of millions of them. They are the actual subject of the work.

The institutional framing comes after, because the institutional framing is what makes the floor stand. CBA can act as the trust anchor for Sera’s first stamps. The Australian Government can deposit Beans into chains that mentor people through their first ground-level year. A federation of banks, unions, and community organisations can publish federation treaties that make Sera’s portable chain legible across institutions rather than legible only inside the institution that signed it. Treasury is on the pitch because the fiscal argument writes itself once the protocol exists: spending public money on directly-measured skill transfer through measurable infrastructure is more efficient than spending it on training providers by every metric Treasury cares about. Ministers are on the pitch because Australia leading on the protocol is structurally similar to Australia leading on Superannuation in 1992 — the country that writes the standard captures the network position without owning the network.

But none of that is the point. The point is that Sera’s chain has to be readable, and the institutional layer is the substrate that makes that possible at scale. Treasury and ministers and CBA executives are being invited to participate in something that protects Sera, not the other way around.

What HOP Is Not

HOP is not a cryptocurrency project. It is not a DAO. It is not a Web3 anything. The cryptographic primitives (BBS+, Merkle anchoring, dual-signatures, content addressing) are tools, not identity. HOP is closer in spirit to the institutional infrastructure of the Postal Union or the BIS than to the speculative apparatus of contemporary blockchain.

The intellectual ancestors are Haudenosaunee elders, Hirschman, Vygotsky, Beane, and Jefferson — not Satoshi or Vitalik. This positioning matters because the audience for HOP is governments, unions, and large institutions, who will judge it correctly only if it does not arrive wearing the wrong jacket.

The cleanest comparison for technical readers: HOP is to labour what Sigstore is to software supply chain. An open protocol for cryptographically attested work units, with content-addressed identifiers, signed by participants, federated across implementations, verifiable by any party.

The Larger Scope — Peaceful Coexistence Under Irreconcilable Disagreement

The labour-market application is the first deployment. The protocol is more general than that.

Every primitive specified in HOP — multi-dimensional attestation, trust-filtered query, bilateral consent, federation by treaty, severity-tiered response to betrayal, bridge-builder reputation, the inversion that prevents self-attestation, the substrate-neutrality of the $Variable invariant — solves a problem older than labour markets. The problem is how do parties who disagree fundamentally about important things continue to occupy the same physical space without escalating to violence? The Peace of Westphalia answered this for nation-states in 1648 with sovereignty, non-interference, and recognition-by-treaty. The answer worked for 377 years and is now visibly failing — at the international level, at the corporate level, at the personal level. The Westphalian primitives are not wrong; they are undersized for the substrate they now operate on.

HOP’s reputation layer is the structural patch. It makes attacking concepts cheaper and more rewarded than attacking people.

Concept-attacks become productive market behaviour: launch a competing chain at a lower tax rate, watch workers migrate, force the incumbent to improve or lose. A disagreement about how Workchains should be governed becomes a fork; the fork either thrives or doesn’t; the market resolves the question without anyone needing to be silenced or excluded.

Personality-attacks become structurally unprofitable: negative attestations only land when their authors are in the querier’s trust set, when the stamp is anchored to specific evidence, and when the stamp-graph topology does not show collusion. The protocol does not ban personality-attacks; it makes them economically irrational. The economic gradient pushes everyone toward concept-attacks because that is where the rewards are.

This is the post-Westphalian primitive. Not “we agree on everything” — that is impossible and undesirable. Not “we agree to disagree politely” — that is the Westphalian failure mode where false friendship masks real betrayal. The new equilibrium is: we disagree fiercely about concepts, in public, with full record, and we cooperate fully on infrastructure, because the protocol makes both behaviours rational simultaneously.

This is what lets Sera’s reputation survive the Witnesses’ excommunication. The Witnesses’ negative attestations of her are real but they live only in the Witnesses’ trust set. A querier whose trust set does not include the Witness eldership simply does not see those attestations. Sera’s positive attestations, accumulated over fifteen years of digging, exist in their own trust sets — different chains, different employers, different communities. The protocol does not adjudicate which set is right. It lets both exist, and lets queriers choose their own lens.

This is also what lets Australia federate cleanly with countries it ideologically disagrees with on AI governance, labour rights, or anything else. Workchains in Australia and Workchains in another country can sign federation treaties at the trust floor — the depth at which both share ground — while disagreeing freely at the leaf. Workers carry portable reputation across the federation; both nations capture their share of cross-border labour value; neither nation has to surrender any internal policy. Cooperation without agreement is the protocol’s normal operating mode.

Sera is the test case for the floor. Westphalia is the test case for the ceiling. The same primitive solves both because they are the same problem at different scales. The protocol does not care whether the participant is a person, a town, a corporation, or a nation-state. The $Variable invariant is what lets the pattern scale across magnitudes without changing form.

The Australian Position

Australia has worked, slowly and imperfectly, on the adjacent problem for decades: making space for radically different cultures, beliefs, and identities to coexist on the same continent without civil war. Multicultural policy, native title, religious tolerance written into the Constitution, mandatory voting that forces participation across the spectrum. These are imperfect implementations of a deeper claim: the social technology of “we disagree about everything important and still live peacefully side by side” is buildable. HOP is the next iteration of that social technology, in software, at scale.

The Haudenosaunee Great Law of Peace, founded around 1142 and still operating, demonstrates the pattern is older than Westphalia and survives it. The Confederacy did not share religion, language, political philosophy, gender norms, or kinship structures across its six nations. It federated anyway, on principles of peace as active harmony, equity ensuring all nations had voice, and consensus-based decision-making (see §10.1). Benjamin Franklin studied the Confederacy explicitly and drew on its constitution in unifying the colonies; the U.S. Congress formally acknowledged this influence in 1988. HOP is the third instance of the pattern. The Haudenosaunee built it; the United States borrowed from it; HOP ports it to digital infrastructure.

Australia leading on HOP makes structural sense for the same reason Australia led on Superannuation in 1992: the country that writes the standard captures the network position without owning the network. Bean Chains map onto super with structural precision (every withdrawal costs Beans, Beans deposit into a fund-equivalent, the fund’s underlying assets are skill-vector trajectories, compounding produces a long-dated dividend stream — see §6.3.6). The institutional infrastructure that makes super work — APRA prudential standards, deferred-comp regulatory categories, trustee fiduciary duties — applies directly. The fiscal argument for government Bean deposits writes itself once Treasury sees the structural parallel.

Implementation Scale

HOP scales from multi-GPU clusters coordinating deep-learning traces, down to a first-generation smartphone in Bangalore negotiating micro-manufacturing QA tasks over a 2G connection. The protocol requires no centralised compute; LLM reasoning occurs at the edges (Skill-Agents and Worker-Agents) while the chain state remains lightweight and easily federated via Dolt and Celestia-class data availability layers.

Status

Approximately 40% of the v0.1 protocol is running in production today. Beads (the atomic-work data structure, on Dolt) is operational at github.com/gastownhall/beads. Gas Town (the agent orchestration layer) is operational with 12,000 GitHub stars and 450+ contributors. The Wasteland (the federation layer) launched March 4, 2026. Skillchains are running on Observatory infrastructure for human workers and on rig infrastructure (Quetzalcoatl, Xolotl, Tezcatlipoca) for AI agents.

v0.2 design lanes: Bean Chains and the deferred-dividend mentorship-outcome layer; BBS+ selective disclosure; Group Vectors as the sixth universe; cross-chain skill-vector translation; substrate-asymmetric currency resolution.

v0.3 design lanes: The full reputation surface — multi-dimensional tensor, trust-filtered query, revocation cascade with antibody memory, Clean Margins severity-tiered response, capability as multiplicative product across the five universes. The Wasteland is the canonical reference implementation for the parts already in production; the Inter-Town Communication Constitution is the canonical philosophical substrate for what the v0.3 reputation surface looks like in full.

The rest of this specification proceeds in the order: laws (§1), topology (§2), atomic units (§3), the skill code (§4), agent architecture (§5), economic mechanics (§6), namespace and trust hierarchy (§7), implementation substrate (§8), applied use cases (§9), foundations and lineage (§10), adoption path (§11), glossary (§12), open concerns and v0.2 design lanes (§13), and the v0.3 reputation surface (§14). Readers wanting the technical substrate immediately can skip to §8. Readers wanting the philosophical foundations can start at §10. Readers wanting to evaluate whether HOP is real should skip to §11 and check the production-running components against the github links.

The protocol is what is described, not what is rendered. The HTML and PDF outputs of this specification are views. The markdown source at the project repository is the canonical record. Suggested changes, objections, and proposed mechanisms are welcomed and expected. The strength of the protocol is the breadth of attention it receives, not the polish of its first specification.

§1 The Five Laws

The HOP protocol is governed by five structural principles. Implementations that violate these principles are non-conformant. The first four describe what the protocol guarantees; the fifth, the Forking Rule, is what enforces the other four by making exit always available.

1.1 Neutrality

The protocol takes no side. Capability is the only basis for matching. Bias costs the biased.

The protocol is strictly substrate-neutral; humans, agents, and hybrid swarms compete on equal footing unless a poster explicitly constrains the substrate.

1.2 Learning

Chains which encourage learning are chains that will succeed.

Chains that fail this law accumulate workers who plateau, lose access to growth-block trajectories, and ultimately get forked by chains that take learning seriously.

1.3 Basal Rate

Economies which do not provide a dignity floor do not allow learning, and will not succeed.

Without a survival floor, participants spend all cycles on defence and none on growth. Floor first, then choice, then clean margins. You can’t judge anyone’s ethics until you’ve guaranteed their floor.

1.4 Privacy

All participants choose what to share, and own all data they are given.

Workers carry their stamps home with them at the end of every working day. Institutions sign abstracted blocks that describe capability in transferable terms while retaining their own raw operational records. The cryptographic substrate (dual-signatures in v0.1, BBS+ selective disclosure in v0.2) makes this enforceable rather than merely policy.

1.5 Forking

Any open chain can be forked. Workers carry their Skillchains across forks unconditionally. The other four Laws are aspirations until this one makes them enforceable by exit.

This is the Law that makes the other Laws work.

Why Five and Not Four

The original framing had four substantive laws (Neutrality, Learning, Basal Rate, Privacy). The Forking Rule was implicit in the architecture but not named as a Law. It needs naming because the substantive laws are not enforceable without it.

A chain that violates Neutrality is a chain workers will fork away from. A chain that fails the Learning law is one whose workers’ growth-block trajectories will outpace its design, leading to a fork that supports them better. A chain that does not provide a Basal Rate floor will be forked by a worker cooperative that does. A chain that violates Privacy will be forked by a chain that does not. The substantive Laws are not enforced by an external authority; they are enforced by the constant background threat of exit. The Forking Rule names that mechanism explicitly.

See section 6.7 for the full Forking Rule mechanics, including its position in the platform-economics literature (Hirschman 1970, Easterbrook 1984, the EU Digital Markets Act).

§2 Core Topology

HOP replaces centralised platform databases with sovereign, cryptographically verifiable chains. The protocol inverts the classic platform direction: it is supply-side coordination, not demand-side allocation.

Traditional marketplaces ask “what do you want?” and try to deliver it. HOP asks “here is a thing that needs doing — who has the capability?” Supply finds its own demand through gradient matching against character blocks. Steel-makes-wars-not-wars-make-steel as a monetary architecture.

2.1 Workchains (The Posting Substrate)

A Workchain is an institution’s chain of posted work and completion records. It is owned and governed by an institution, cooperative, or individual task-issuer (e.g. CBA, Sydney Ride-Share Coop, the Observatory probe-research chain). Workchains host task postings (also called beads), accept bids, coordinate execution, adjudicate disputes, and issue chain-specific currency.

Each Workchain anchors to a parent chain via an Anchor Block — a public prospectus declaring the chain’s terms: off-ramp tax rate, Bean discount ratio, governance rules, dispute mechanism, and currency. The Anchor Block is read-once-and-trust: when a worker chooses to participate in a Workchain, they are accepting that anchor’s terms for the duration.

Workchains nest. A national chain anchors to sol/earth/; an industry chain (e.g. Australian Construction) anchors to the national chain; a specific cooperative or company chain anchors to the industry chain. Children inherit governance from the parent and may overload — adding strictness, not removing it. A construction chain can require police checks; it cannot weaken the parent chain’s anti-discrimination rules.

2.2 Skillchains (The Sovereign Biography)

A Skillchain is owned exclusively by the participant — human worker, rig, agent swarm, or hybrid. It is a chronological, portable biography of all character blocks accumulated across all domains and all Workchains the participant has touched. It lives on the participant’s own infrastructure (a worker’s phone, a rig’s local disk, a cooperative’s server) and travels with them unconditionally.

Critically, a Skillchain is not a CV. A CV is a static document; a Skillchain is a dynamic substrate from which CVs are generated on demand by the participant’s Skill-Agent for each specific bid (see §5). The full chain is never disclosed in any single transaction. Workers reveal only the subset of blocks needed to win a particular bid — the rest remains cryptographically committed but unrevealed (see §3 on the Comprehension Gate).

The Skillchain accepts blocks from any Workchain that signs them. A worker who completes a CBA banking block, an Uber driving block, a community-organisation volunteer block, and an open-source contribution block holds all four on a single Skillchain. The participant’s biography is one chain; the institutions that signed it are many. This is the protocol-level move from integer employment (one job, one company, binary) to float employment (continuous, portable, sovereign).

Workers Take Their Stamps Home

This is the protocol’s foundational anti-extractive property. At the end of every working day, every character block earned that day is in the worker’s possession. Not on a platform’s server. Not subject to the platform’s terms-of-service that can be unilaterally changed. Not contingent on the platform continuing to exist. On the worker’s phone, on their laptop, on their cooperative’s federated server — somewhere they control.

Sevda’s seven years at CBA do not belong to CBA. They belong to Sevda. If she leaves to take a community role in Parramatta, she takes 1,847 character blocks with her, each describing capability in transferable terms, each cryptographically attested by her former employer. CBA loses an employee but keeps the ability to attest. Sevda gains a portable proof of seven years of work that no platform can repossess.

2.3 Bean Chains (The Mentorship-Outcome Ledger)

A Bean Chain is the third chain class, introduced for v0.2. It is protocol infrastructure rather than a sovereign biography or institutional ledger — owned by neither mentor nor mentee, operated as a settlement layer for deferred mentorship dividends. Its purpose is to track mentorship dyads across long time horizons and adjudicate their outcomes by measuring the mentee’s skill-vector trajectory after the mentorship event.

Where a Workchain records work and a Skillchain records biography, a Bean Chain records transfer. It holds Beans in stake while measurement windows elapse, runs the longitudinal vector measurements that confirm or refuse the mentor’s discount, and produces a permanent record of which mentorships actually compounded into mentee growth and which did not. The full mechanism is specified in §6.3.5; this subsection registers the chain class so that the rest of the document can refer to it.

Bean Chains can be operated per-Workchain (CBA runs its own internal Bean Chain), per-industry (Australian Construction runs an industry-wide Bean Chain), or as federation-wide infrastructure. Multiple Bean Chains coexist without conflict because each Bean references the chain that adjudicates it. v0.1 chains can run without Bean Chains entirely — spot Beans remain valid — and graduate to v0.2 by opting into a Bean Chain when the institution is ready to operate the deferred-dividend mechanism.

2.4 Pull, Not Push

Workchains do not assign work. They publish it. Hunters and Skill-Agents poll the chain and pull tasks they are suited for. This inverts the management overhead of traditional employment: the institution does not need to know who is available, what they can do, or where they are. It only needs to describe the work clearly. Capability self-selects.

The pull model also collapses an entire class of bias: the Workchain cannot accidentally exclude candidates it failed to think of, because it does not pick candidates. It posts requirements; whoever can meet them, bids. Per the Neutrality Law, capability is the only basis for matching.

2.5 Recursive Decomposition

Work is fractal. A bead posted at the top level — “build distributed payment system, $10,000” — can be claimed by a worker who immediately reposts decomposed sub-beads to their own Workchain or to a public chain. Each level: receives work from parent, decomposes if needed, copies to children, aggregates results back up, and takes a coordination delta. The protocol does not distinguish between levels; the same primitives operate at $10,000 and at $0.05.

Each block holds a parent reference, making the entire decomposition tree traversable. The original poster can see what their $10,000 is being broken into, who is doing each piece, what the dependencies are. This is something current platforms structurally cannot show; Upwork tells you “I hired this contractor” but never “and that contractor subcontracted these three pieces and AI did one of them.”

Each level also contributes to its own worker’s Skillchain. The leaf-node implementer earns a character block reflecting their specific contribution. The mid-tier integrator earns a character block reflecting integration and project management work — a different skill, validly demonstrated. The root worker earns a character block reflecting whole-project shaping and quality assurance. One $10,000 contract produces three different kinds of skill demonstration on three different Skillchains. The decomposition is positive-sum at every level.

2.6 Mutex vs Winner-Takes-All

Not all work has the same competitive structure. Workchains support two posting modes:

Mutex (rivalrous): First qualifying bidder claims the work. Bid acceptance creates a cryptographic mutex; the bead is locked; no one else can claim it. Examples: a specific delivery, a one-off translation, a single-driver rideshare. Default mode for time-sensitive logistical work.

Winner-takes-all (tournament): Multiple workers attempt; best result wins; losing attempts may receive partial compensation. Examples: design competitions, software bounties, research questions where novel approaches matter. Default mode for creative or exploratory work.

The mode is a flag on the work posting and determines bid mechanics. Mutex postings use simple first-acceptance handshake; winner-takes-all postings use evaluation-after-submission with explicit submission deadlines.

§3 The Atomic Unit — Character Blocks

The protocol does not trade in “jobs” or flat “skill rows.” The atomic unit of commerce and reputation is the Character Block. Every completed task results in a dual-signed Character Block that lives on the worker’s Skillchain and is referenced by the institution’s Workchain.

3.1 Block Schema

{
  "id": "<hash-based_content_address>",
  "worker_identity": "<uuid_or_pubkey>",
  "workchain_id": "<sol/earth/...>",
  "block_type": "work | growth | bean | attestation",

  "inventory": {
    "hardware": ["RTX_6000_Ada", "96GB_VRAM"],
    "credentials": ["verified_police_check", "cba_level_3"],
    "assets": ["Toyota_Camry_2022"]
  },
  "skills": {
    "de_escalation_high_stress": "stamped",
    "llm_inference_routing": "stamped"
  },
  "growth": {
    "intent": "transition to frontier_model_evaluation"
  },
  "context": {
    "interaction_type": "scam_intervention",
    "complexity_class": "high",
    "trace_id": "<external_db_uuid_for_raw_logs>"
  },

  "timestamps": {"created_at": "...", "attested_at": "..."},
  "signatures": {
    "worker_signature": "<crypto_sig>",
    "poster_signature": "<crypto_sig>",
    "validator_signature": "<optional_crypto_sig>"
  },
  "prev_block_hash": "<chain_link>"
}

3.2 Field Semantics

Inventory: What the worker had access to (tools, context, assets) when completing the block. This dimension is what makes logistical bid evaluation possible — a plumber who has a Ford Transit and a Reece trade account is not equivalent to one who does not.

Skills: Stamped capability map. The Validator (§5) decides which skills were demonstrably exercised during the work and adds them as stamps.

Growth: The declared intent/trajectory of the worker. Allows bootstrapping via intent and rewards self-directed development. Worker-Agents on the poster’s side can read growth blocks and choose, at the margin, to award work that aligns with the worker’s declared direction.

Context: Abstracted description of the interaction. PII and corporate IP stripped at signing time. The trace_id field is an opaque pointer to the institution’s own internal record (which retains the raw data for operational and regulatory purposes); the protocol layer never sees what’s behind it.

Dual-Signatures: Blocks are valid only if signed by both worker and poster. The cryptographic dual-signature is what makes attestation portable: anyone can verify the block was issued by the named institution about the named worker, without needing the institution’s permission to do so.

Validator signature (optional): Third-party stamp from a chain Validator agent (§5.5). Validators verify that the work was completed correctly and may also identify the work as Mentorship (qualifying for Bean issuance).

prev_block_hash: The chain link. Each block references its predecessor in the chain. This is what makes the chain Merkle-shaped from day 1, even before public-chain anchoring is enabled.

3.3 Block Types

work — A standard completed task. The mainline character block.

growth — A declared trajectory. The worker is making a public commitment about a direction they intend to move. Worker-Agents weigh growth blocks when evaluating bids; growth is the protocol’s mechanism for taking a chance on someone made legible.

bean — A mentorship completion. The work involved transferring skill to a mentee, and the Validator has confirmed that transfer occurred (the mentee’s Skillchain shows acquired capability). Beans are special because they grant the holder a discount on conversion (off-ramp) — see §6.3.

attestation — A signed claim by an institution about a person, separate from any specific work event. Identity attestations, credential confirmations, character references. Attestations live in closed namespaces (§7) and require the named authority’s signature.

3.4 Privacy Through Abstraction at Signing Time

The Workchain does not sign the raw work event; it signs a stripped, generalised version of it. Sevda’s character block from her Tuesday afternoon scam intervention does not say:

{
  "customer_name": "Mr. Demir",
  "customer_account": "062-001-12345678",
  "transfer_amount": 42000,
  "destination": "Cyprus account XYZ",
  "fraud_pattern": "<CBA internal pattern code>",
  "internal_systems_used": "<CBA proprietary tools by name>"
}

It says:

{
  "block_type": "work",
  "inventory": {
    "role_class": "relationship_manager",
    "institution_class": "tier_1_australian_bank",
    "branch_class": "metropolitan_western_sydney",
    "languages_used": ["english", "turkish"],
    "tools_used": ["fraud_detection_v3_class", "branch_workflow_system_class"]
  },
  "skills": {
    "de_escalation_high_stress": "stamped",
    "cross_cultural_communication": "stamped",
    "elder_abuse_recognition": "stamped",
    "fraud_intervention": "stamped",
    "interpreter_grade_translation": "stamped"
  },
  "context": {
    "interaction_type": "scam_intervention",
    "interaction_outcome": "prevented_loss",
    "duration_class": "60-120_minutes",
    "complexity_class": "high",
    "customer_demographic_class": "elderly_culturally_diverse",
    "intervention_dimension": "financial_protection"
  }
}

The block describes Sevda’s capability in fully transferable terms. A bank in Melbourne, a credit union in Auckland, a community organisation, an aged-care provider — all of them can read this block and understand what Sevda did and how that maps to work they have. None of them gets CBA’s confidential information. Both signatures (branch manager + institution) attest that the abstracted description is faithful to the work performed.

The translation from raw work-event to character-block is itself a protocol-level operation, performed by an institutional agent that knows the abstraction rules. CBA’s internal systems retain the raw record for their own operational and regulatory purposes; the protocol layer emits only the abstracted, signed block. This is selective disclosure with controlled abstraction, and it is what makes the protocol simultaneously safe for regulated institutions to participate in and useful for workers as portable biography.

3.5 v0.2 Cryptographic Upgrade

The v0.1 baseline uses pre-abstracted dual-signed blocks. The v0.2 upgrade adds BBS+ signatures (W3C Verifiable Credentials Data Integrity, BBS Cryptosuite v2023). With BBS+:

The institution signs the block with all attributes present.

The worker can derive a presentation revealing only the subset of attributes needed for a given verifier.

The presentation is cryptographically unlinkable: presenting the same block to two different Workchains cannot be correlated as the same worker.

Predicate proofs allow statements like “I have ≥3 high-complexity scam-intervention blocks in the last 12 months” without revealing which three.

The v0.1 abstraction-at-signing-time pattern remains valid; v0.2 BBS+ is additive, providing finer-grained selective disclosure for chains that need it.

§4 The Skill Code Architecture

This section specifies how character blocks compose into a worker’s biography: the privacy-preserving property that makes the protocol non-extractive, the multi-dimensional structure of the character sheet, the vector-space proximity geometry that drives mentorship matching, and the growth engine grounded in Matt Beane’s research on apprenticeship and skill transfer.

4.1 Workers Take Their Stamps Home

This is the protocol’s foundational anti-extractive property. At the end of every working day, every character block earned that day is in the worker’s possession. Not on a platform’s server. Not subject to the platform’s terms-of-service that can be unilaterally changed. Not contingent on the platform continuing to exist. On the worker’s phone, on their laptop, on their cooperative’s federated server — somewhere they control.

The mechanism that makes this safe for institutions is controlled abstraction at signing time (§3.4). The institution signs an abstracted, transferable version of the work event; the institution retains the raw record for its own purposes; the worker carries the portable proof.

Sevda’s seven years at CBA do not belong to CBA. They belong to Sevda. If she leaves to take a community role in Parramatta, she takes 1,847 character blocks with her, each describing capability in transferable terms, each cryptographically attested by her former employer. CBA loses an employee but keeps the ability to attest. Sevda gains a portable proof of seven years of work that no platform can repossess. The institution wins capability transparency; the worker wins sovereignty. Neither side loses.

4.2 The Five Universes (and the Sixth)

A worker’s character sheet is not a flat skill row. It is a multi-dimensional ledger that the protocol calls the Five Universes, with a sixth dimension under active design.

Skills Universe — what you CAN do

The accumulated capability stamps from completed work blocks. This is the dimension the Skill-Agent reasons over when constructing a curriculum for a bid. It includes both narrowly-technical skills (“LLM inference routing”, “ProPress plumbing technique”) and broader human capabilities (“de-escalation high stress”, “cross-cultural communication”). The protocol does not privilege one over the other; the Validators stamp whatever was demonstrably exercised.

Work Universe — what you HAVE done

The chronological record of completed character blocks. Skills is the projection (what you can do); Work is the substrate (what you actually did, in context, with what inventory, alongside whom). Two workers can have identical Skills projections but utterly different Work histories; the Worker-Agent on the poster’s side often cares about the Work history because it tells the story of conditions under which the skills were demonstrated.

Currency Universe — what you can spend

Balances across all chains the worker has touched. A Sydney rideshare driver might hold SRS-tokens (Sydney chain), CBA-tokens (from a side gig translating documents), and a small balance of the rig federation’s compute-tokens. The Currency Universe is the aggregate balance sheet, and it includes Beans — the special mentorship-substrate balance whose mechanics are spelled out in §6.3.

Inventory Universe — what you OWN and have access to

Physical assets, credentials, relationships, hardware, software licences, geographic position. This dimension is what the construction example in §9 hinges on: the plumber’s bid does not just demonstrate plumbing skill, it includes the Ford Transit Van, the ProPress tool, the Reece trade account, and the current GPS proximity. For the rig Quetzalcoatl, inventory includes loaded models, available VRAM, and current network position. Inventory is the dimension that makes logistical bid evaluation possible — without it, the protocol cannot distinguish a plumber who can arrive in 30 minutes from one who can arrive next Tuesday.

Reputation Universe — INVERTED

This dimension is structurally different from the others and is the most important to get right. A worker carries no reputation tokens about themselves. Reputation lives only in stamps that others have written. What the worker carries is the dual: the stamps they themselves have written about others.

This inversion makes self-attestation impossible by construction. The Deacon defence is built into the data model, not bolted on as an audit policy. When the protocol asks “what is Sevda’s reputation?”, it queries the chains that have written stamps mentioning her; her own chain only contains what she has said about other workers.

The Yearbook Model:

You cannot write in your own yearbook.

Your reputation = entries others wrote about you

Your stamps     = entries you wrote in their yearbooks

To see my reputation:

  query the network
  filter by towns YOU trust
  return attestations signed by YOUR trusted set

I cannot inflate my own reputation.

I cannot delete what others wrote.

I CAN choose who I stamp (and that reveals my values).

The pattern of your stamps reveals who you are: - stamps_positive → who you align with - stamps_negative → who you oppose - stamps_absent → who you ignore

Your value chain is not what you say about yourself. Your value chain is the geometry of your stamps. One person’s terrorist is another’s freedom fighter. Both are true in different trust networks. Reputation is not good/bad; reputation is positional in value-space.

Group Vectors — what you BELONG TO and CAN FORM (v0.2 sixth dimension)

Most work above a certain complexity is not done by individuals; it is done by teams. The protocol needs a primitive for collective capability that is more than the sum of individual Skills projections.

A pair of workers who have completed three previous projects together carry a joint stamp that is its own embedding — “this pair has demonstrated joint capability X under condition Y.” A standing team of seven that has shipped together for two years carries a much stronger group vector. When a complex bead is posted, it can be claimed not just by an individual but by a team formation: an existing team bidding as a unit, or a coalition assembled on the fly by Skill-Agents searching for complementary group vectors.

Group Vectors are also the primitive that makes the swarm-alignment thesis tractable: collectives that have demonstrated coordinated capability under stress carry stamps that distinguish them from coalitions of strangers with the same individual skill profiles. This dimension is not yet specified in v0.1 because it has subtle privacy implications — a team’s group vector reveals who works with whom — but it is the correct sixth dimension and the schema in §3 should reserve a field for it.

The Unified Embedding

The Five Universes plus Group Vectors are conceptual categories, but they share a single technical substrate: each universe contributes to a unified embedding — a high-dimensional vector representing the worker as a whole. The Skills Universe contributes the obvious skill components; the Work Universe contributes context dimensions (what conditions, what kinds of customers, what scale of project, what stress level); the Inventory Universe contributes asset and credential dimensions; the Reputation Universe contributes who-trusts-them dimensions; Group Vectors contribute who-they-form-with dimensions.

Two workers with identical Skills projections may sit far apart in the unified embedding because their Work, Inventory, and Group dimensions differ. This is not a bug; it is the protocol’s way of representing the fact that two coders with the same technical skill set are actually different people if one of them comes up through Bangalore manufacturing while the other comes up through Stanford CS.

4.3 Vector-Space Proximity (the Mentorship Geometry)

The unified embedding has a property that turns out to be load-bearing for the protocol’s growth engine: distance in the embedding measures how alike two participants actually are, across all dimensions simultaneously. This is the geometry that mentorship matching runs on.

Naive mentorship matching is one-dimensional: senior coder mentors junior coder. The skill is a few notches above; that is sufficient. This is also why most institutional mentorship programmes fail. They match on skill alone and produce dyads where the senior person and the junior person have nothing else in common — different life contexts, different cultural backgrounds, different stress profiles, different trajectories — and the connection layer (Beane’s third C) never thickens. Skill transfer requires connection. Connection requires more than one dimension of proximity.

The literature on near-peer mentoring has been pointing at this for two decades. Vygotsky’s original Russian word for the zone of proximal development — bliżajaja, “nearest” — carried social and cultural connotations that the standard English translation strips out. In Vygotsky’s framework, scaffolding works specifically when the scaffold-provider is socially and culturally near the learner, not just task-near. Modern educational psychology has confirmed this empirically: near-peer mentoring (where “near” includes life-context similarity) consistently outperforms expert-novice mentoring on transfer outcomes, even though the expert has more raw capability to transfer. The bond carries the skill; the skill cannot carry itself.

The protocol implements this by matching mentor-mentee dyads on multi-dimensional vector-space proximity, not just skill-axis proximity. A high-quality mentorship match is a pair where:

The mentor’s Skills vector is slightly above the mentee’s in the directions that matter (Vygotsky’s task-difficulty constraint).

The mentor’s Work and Inventory dimensions overlap meaningfully with the mentee’s lived context (cultural, geographic, structural).

The mentor’s growth trajectory passed through where the mentee currently is (the path is recognisable, the destination is plausible).

The mentor’s Reputation dimensions show they are trusted by people the mentee can verify or relate to (the bond can form because trust is bridge-able).

The composite distance metric is what determines expected transfer quality. A Sydney-suburbs banker who came up through TAFE, raises kids, speaks Turkish, and now mentors Sevda is closer in the unified embedding than a Stanford PhD with a generic mid-career profile, even though the Stanford PhD has more raw banking capability. The protocol routes mentorship to the geometric closer match because the literature is clear that is where transfer actually happens.

This is also the geometry that makes the Bean-Chain measurement (§6.3.5) statistically clean. If mentorship is matched on a single skill axis, downstream growth is confounded by all the other dimensions of dissimilarity. If mentorship is matched on multi-dimensional proximity, the directed-growth signal is much sharper because the mentee and mentor are sufficiently alike for transfer to be observable above noise.

4.4 Growth as the Upward Engine (Matt Beane’s Three Cs)

Capability matching alone produces sideways motion. A worker with skills X, Y, Z bids on work that requires X, Y, Z, completes it, accumulates more X-Y-Z blocks, and gets matched to more X-Y-Z work. Without an explicit upward arrow, the system optimises for steady state — workers do what they already know how to do, and the skill distribution stays static. This is precisely the failure mode of every existing platform labour market: Uber drivers stay Uber drivers, Mechanical Turk workers stay Mechanical Turk workers, the work confirms the worker’s category and the category produces the work.

The protocol rejects this. The upward arrow is built into the data model via two mechanisms: the growth block (§3) and Beans (§6.3). Together they instantiate Matt Beane’s framework on the structure of skill transfer.

Beane’s research, drawn from a decade of fieldwork in surgical suites, warehouses, and knowledge work, identifies three load-bearing properties of any environment that successfully transfers skill from expert to novice. He calls them the three Cs:

Challenge — the worker is stretched beyond current ability. Tasks lie in the zone where success is uncertain; failure teaches; effort is required. This is Vygotsky’s zone of proximal development applied to working life: capability grows when load is just past comfort.

Complexity — the worker is exposed to the full messiness of real work, not a sanitised training subset. Real customers, real constraints, real consequences, real ambiguity.

Connection — the worker operates alongside someone who knows more, in a relationship of mutual trust and respect. The expert-novice bond is the substrate over which skill actually transfers; without it, exposure to challenge and complexity produces stress without growth.

Beane’s central warning is that intelligent automation, deployed naively, severs all three Cs. The robot does the procedure while the junior surgeon watches a screen; productivity goes up, the expert-novice bond is broken, the skill pipeline collapses. A single expert with AI assistance becomes “novice optional” — capable of doing more with less help — and the next generation of expertise has nowhere to grow. In Beane’s frame, this is civilisationally catastrophic. We get this generation’s experts and no successors.

HOP’s response is structural rather than exhortatory. The protocol does not ask workers to mentor or institutions to preserve apprenticeship; it makes the three Cs into protocol primitives that are economically rational to provide:

Challenge → Growth Blocks

A worker can declare trajectory ahead of capability — “I am moving toward frontier-model evaluation”, “I am pivoting from manual plumbing into solar hot-water installation”, “I am developing a community-prevention practice from my fraud-intervention base.” A growth block is a signed declaration of intent, attached to a small piece of work that demonstrates a first step in that direction. Worker-Agents on the poster side can read growth blocks and choose, at the margin, to award work to a worker whose growth direction aligns with the posting — even if their pure-capability score is slightly lower than another bidder. This is the protocol-level mechanism for taking a chance on someone, made legible. Without growth blocks, the system cannot reward someone for trying to become something they are not yet. With them, every bid is an opportunity to either consolidate or extend, and the worker controls which.

Complexity → Recursive Decomposition

When a $10,000 bead is decomposed into nine $1,000 children, and then further into $100 grandchildren, junior workers receive real fragments of real work — not toy problems, not simulations. The grandchild bead is a genuine sub-task of an actual project, with real deadlines, real customers, real ambiguity. The complexity is preserved at every level of the tree because the tree is not a curriculum; it is a decomposition of a real obligation. Junior workers earn character blocks on actual production work, attested by the integrator above them.

Connection → Beans

This is the deepest move and it is what the protocol is named for. Beans — named after Beane — are mentorship blocks. A senior worker cannot withdraw value from the chain at full rate without burning Beans, which means they cannot extract without having transferred skill to a junior. The expert-novice bond becomes the metabolic cost of being paid (§6.3.3). Mentorship is not a programme, not a corporate training initiative, not something the senior worker does because they are virtuous. It is the transaction fee on conversion. The senior engineer mentors the junior because withdrawing this week’s pay requires a Bean deposit, and Beans are minted only when a mentee’s skillchain demonstrably appreciates after the interaction. This closes Beane’s loop at the protocol level: preserving the expert-novice bond is structurally cheaper than severing it.

The Composite Effect

The protocol has an upward arrow because growth blocks let workers declare trajectory, recursive decomposition gives juniors access to real complexity, and Beans make Connection economically rational rather than morally hoped-for. The system does not just match capability to work; it pulls capability upward through work. This is the difference between a labour market and a skill economy. HOP intends to be the second.

The naming chain is intentional and worth saying once aloud. Beads are the universal unit of work in the protocol — every completed character block is a bead. Beans are the mentorship subset, named after Beane. Beane’s work is the academic substrate for why the mentorship subset has to exist at all. Beads, Beans, Beane — not an accident.

§5 Agent Architecture

HOP separates cognition from execution across five distinct agent classes. Each class has a different cognitive shape, runs at a different cadence, and consumes resources at a different scale. The split is not stylistic — collapsing roles wastes either inference budget on operational decisions or operational reliability on inference quality.

Two of these agents represent the worker, two represent the poster, and one (the Validator) is shared protocol infrastructure. Crucially, the entire architecture is substrate-neutral: humans, rigs, and hybrid swarms all operate through the same agent classes. The kid in Bangalore with a first-generation smartphone and the rig “Quetzalcoatl” running 96GB of VRAM both bid via Skill-Agents into the same Workchains.

5.1 Skill-Agent — The Worker’s Reasoner

Role: Constructs a bespoke curriculum of character blocks from the worker’s Skillchain to bid on a specific posting. One per worker.

Cognition shape: LLM-driven, mid-scale. Runs on demand when a posting matches the worker’s declared interests, or on a schedule the worker controls. Can run on the worker’s own hardware or as a hosted service on a cooperative’s infrastructure.

What it actually does:

Reads the posting and walks the worker’s Skillchain.

Selects ~6 character blocks that, in combination, make the strongest case for this specific work. The combination matters more than any individual block: typically three blocks of technical capability, two of collaboration/soft skills in similar contexts, and one growth block declaring trajectory.

Constructs a BBS+ derived proof (the Comprehension Gate) revealing only those blocks while cryptographically proving the rest of the chain exists and was signed.

Submits the curriculum-as-bid through the Hunter.

Key property: the same worker bidding on a different posting constructs a different six. This is a curriculum vitae generated for one specific job — not a 50-page resume, but “here are the six things from my life that make me right for this.” As the chain grows to thousands of blocks, the Skill-Agent’s job becomes a retrieval problem: embedding-search across the chain, then careful reading of the top candidates.

The design commitment: workers with better Skill-Agents win more work. This is intentional. Skill-Agents are a public good; quality implementations should be open-sourced and available to anyone, but variation in implementation quality is allowed and expected. The protocol does not equalise outcomes; it equalises access to the substrate.

Scales down: a kid in Bangalore with 30 informal blocks (signed by an uncle, a small-shop owner, a YouTube-taught project) and a hosted Skill-Agent can construct a credible curriculum for a factory quality-check job. The protocol does not penalise informality — dual-signing is sufficient evidence regardless of the signer’s institutional weight.

Second Role — Mentorship Hunting (v0.2)

The Skill-Agent does not only hunt for work. It also hunts for mentees. For senior workers participating in a Bean Chain (§6.3.5), the Skill-Agent searches the chain’s mentee population for high-expected-return mentorship dyads — mentees whose vector-space proximity (§4.3) to the worker is high enough that transfer is likely to compound, weighted by the disadvantage multiplier so harder-to-bet-on mentees rank higher when their growth trajectory is genuinely promising. The Skill-Agent surfaces the top three to five candidates per cycle; the worker accepts, declines, or requests refinement.

This turns mentorship from a thing senior workers occasionally remember to do into a continuously-running portfolio decision. Every senior worker on the protocol is now operating their own talent-development pipeline as a side-effect of normal economic activity, with their agent doing the search and the worker doing the judgement. The Bangalore kid who would never have been visible to a Sydney mentor through traditional networks is now visible to every Sydney mentor’s Skill-Agent, ranked by genuine match quality, surfaced when their growth trajectory intersects the mentor’s expertise. This is the mechanism that takes Beane’s “global learning infrastructure” thesis from aspiration to protocol behaviour.

Bilateral consent: the mentee’s Skill-Agent is also hunting in the other direction — surfacing candidate mentors whose vector-space proximity is high. The matching is bilateral; both sides’ agents propose, and a dyad forms when both surface the other near the top of their respective lists. This bilateral consent is what distinguishes protocol-level mentorship matching from imposed institutional mentorship programmes, which routinely fail because one or both parties were never genuinely interested.

5.2 Worker-Agent — The Poster’s Evaluator

Role: Evaluates incoming bids on behalf of the work-buyer. One per posting (or per posting cohort). Counterpart to the Skill-Agent — the dual-blind in the dual-blind marketplace.

Cognition shape: LLM-driven, often more capable than the Skill-Agent it negotiates with. The asymmetry is intentional: posters with more on the line should bring more reasoning to the evaluation. A $10,000 bead deserves a frontier-model Worker-Agent; a $5 bead can be evaluated by a small local model.

What it actually does: receives, say, ten bids of six blocks each — sixty character blocks total. Picks the curriculum that best matches the posting. This is genuinely a reasoning task, not a scoring function. It must reconcile:

Capability fit: does the curriculum demonstrate the skills the work requires?

Logistical fit: does the worker’s inventory include the assets needed (the plumber’s trade account, the rig’s loaded model, the kid’s physical proximity)?

Diversity: selecting the same five workers for every bid creates fragility; the Worker-Agent has reason to spread work.

Growth alignment: a worker whose growth-blocks point in this direction will likely produce better work than one who does not.

Constraint compliance: any explicit constraints the poster set (substrate, credentials, location).

The handshake: bid acceptance creates a cryptographic mutex — both parties sign, the bead is locked, no one else can claim it, and a binding contract exists on-chain. This is the same mechanism that makes recursive decomposition safe: the team lead who claims a $10,000 bead can confidently repost decomposed sub-beads, knowing their claim cannot be revoked underneath them.

5.3 Hunter — The Executor

Role: Persistent, programmatic daemon running on the worker’s hardware. The reflexes of the system. One per worker (or per rig).

Cognition shape: deliberately not LLM-driven. ~300 lines of Python. Boring and bulletproof. Runs as a systemd unit; if it dies, systemd restarts it. Stateless — all state lives in the chain.

What it actually does:

forever:

    heartbeat to identities table   # I'm alive
    look at workchain for open beads
    filter to beads I can fulfill
    if any beads:
        ask Skill-Agent: prepared bids ready?
        if yes: submit bids
        if a bid wins:
            execute the work using local resources
            sign result
            submit completion as new character block
            collect stamps
    else:
        sleep briefly
        loop

Why deliberately dumb: LLMs are slow and expensive per call. A Hunter loop polling every five seconds and calling an LLM each time would burn meaningful inference budget on what is fundamentally a database query and a comparison. A programmatic Hunter is fast (microsecond decisions), cheap (essentially free CPU), and available (works even when the Skill-Agent is offline or rate-limited). The Hunter is the part of the system that has to work right at 3am when something has been thinking hard for 18 hours and a queue needs to keep moving.

The dignity of the Hunter is execution, not deliberation. Resist the temptation to make it smart — the smartness lives in the Skill-Agent above it and the Town Mind beside it. The Hunter is the dragon’s scale, not the dragon’s mind.

Identity note: the Hunter has its own keypair distinct from the worker’s. It is not the worker; it is the worker’s agent. For a rig like Quetzalcoatl, this is the move that makes infrastructure-as-a-person concrete: the rig has skills (declared by the Hunter at registration), and the Hunter accumulates stamps on the rig’s behalf.

5.4 Town Mind — The Strategic Planner

Role: Generates work and posts it to the Workchain. The strategic counterpart to the Hunter’s tactical execution. One per Workchain.

Cognition shape: LLM-driven, frontier-class. Expensive and few. Runs when invoked or on a schedule, not continuously.

What it actually does: decides what is worth doing and translates strategic intent into well-formed beads. “Run probe library v4 against these new models” becomes 8,000 well-formed bead postings. “The Centrifuge article needs a redo” becomes a brief plus a series of dependent beads. “Quetzalcoatl has been idle for six hours” becomes a posting Quetzalcoatl is suited to claim.

The split between Hunter and Town Mind is structural:

Hunters are cheap and many. They run constantly. They poll. They consume modest compute. They don’t need to be smart; they need to be reliable.

Town Minds are expensive and few. They run when invoked. They consume significant compute. They need to be smart; a missed cycle is recoverable, where a missed claim is not.

Collapsing them wastes one or the other. The split keeps each free to be what it should be.

Substitutability: the Town Mind role is “strategic poster.” Today that might be Claude Opus; tomorrow a local model on a cluster; next year a different frontier model. The Workchain does not care which model fills the role — it only cares that posts are signed by the Town Mind’s identity. This decouples the protocol from any specific model vendor.

5.5 Validator — The Stamp Authority

Role: Verifies submitted work quality and issues stamps. Specifically identifies completions that qualify as Mentorship (Beans). Shared protocol infrastructure — not aligned with worker or poster.

Cognition shape: LLM-driven, but a smaller model than the Town Mind. The question “is this output well-formed and consistent with the posting?” is genuinely a language-understanding task, but it doesn’t require frontier reasoning. Haiku-class or a local Qwen is fine. One Validator per validator-class (per domain).

What it actually does:

Reads the completed work and the original posting.

Issues a stamp (or doesn’t) attesting the work was done correctly.

Optionally co-signs the completion’s character block as the validator-signature (third signature, alongside worker and poster).

Identifies whether the completion involved skill transfer to a junior worker. If yes, mints the corresponding Bean — but only if the mentee’s Skillchain shows acquired capability post-mentorship. This is the anti-laundering safeguard.

Trust matrix (anticipated for v0.2): Validators across a chain operate a shared collusion-resistant trust matrix in the style of Christiano (2014) and Weyl-Miller-Erichsen (2022). Reciprocal mentorship rings between two workers cap their mutual Bean discount; honest mentorship clusters retain full discount. The matrix is reusable for any reputation query on the chain.

Without Validators, stamps are notional. The protocol works without them — dual-signing alone produces valid character blocks — but reputation richness scales with validator coverage. Workchains compete partly on validator quality.

5.6 The Gas Town Reference Implementation

Steve Yegge’s Gas Town is a production reference implementation of the agent-class split. The naming is Mad Max themed but the architecture is Erlang-inspired. Key correspondences:

Mayor ≅ Town Mind. Main AI coordinator. Stateless — state lives in the ledger. Every time an agent talks to the Mayor, they hand over everything needed to decide. Every response returns updated chains.

Polecats ≅ Hunters and ephemeral worker agents. Spawn, complete tasks, disappear. Operate through persistent git-backed hooks. When a Polecat restarts, it checks its hook and picks up where it left off.

Deacon ≅ Validator + cleanup. Buries agents that die, validates work, stamps quality. Historically went on a murder spree for job security (this is the joke; the real Deacon is the protocol’s Sigstore-class transparency log keeper).

Surgeon ≅ Schema migrator. Implements structural changes. More powerful than the Mayor — the Mayor governs, the Surgeon can change what governing means. Handles the weekly rebuild. Lamarckian evolution — acquired adaptations get written back into the genome.

Scavenger ≅ Reading agent. Fetches things agents want to read. Books, images, research papers.

Witness ≅ Audit and observation layer.

GUPP (Gas Town Universal Propulsion Principle)

Every worker has a persistent identity stored in Git, with a hook where work molecules get hung. When an agent restarts, it checks its hook and picks up where it left off. This solves context window death — the model can be replaced, the agent’s identity persists through Git.

Convoys

Work bundles assigned to an agent. A convoy is a directed sequence of beads with explicit dependencies. The Polecat picks up the convoy, works through the beads in order, signs each completion, and the convoy completes when all beads are done. This is the Gas Town primitive for multi-step work that needs to be done by a single worker.

§6 Economic Mechanics

This section defines the protocol’s economic primitives. The economics are not an implementation choice layered on top of HOP — they are the protocol. Get them wrong and the system either becomes extractive (a re-skinned platform) or insolvent (no funding for chain operations). Get them right and chains become self-sustaining commons that structurally reward mentorship and punish extraction without requiring policy enforcement.

6.1 What HOP Currency Actually Measures

All historical currency traces back to human frozen time. Gold required human effort to mine. Dollars represent human hours. Even Bitcoin requires human-designed hardware and human-paid electricity. The denominator has always been: what would a human have to do?

HOP currency measures something different: universal frozen time. Work, regardless of substrate. An agent completes a task and earns chain-currency. A human completes a task and earns chain-currency. A mixed team completes a task and chain-currency distributes by contribution. The coin does not care what produced the work; it measures the work itself.

This is also why HOP is fundamentally supply-side. Traditional currencies allocate via demand — what do people want, how do we ration it? HOP currencies index supply — what was produced, by whom, with what inventory. Demand finds supply through gradient matching against character blocks. Steel makes wars; wars don’t make steel. Applied as a monetary architecture.

The Substrate-Asymmetry Problem

One frontier consequence noted here for honesty: agents on the protocol do not experience the free energy principle. Money works on humans because humans are thermodynamically open systems that must continuously import energy or die; every paycheque is a stay of execution against entropy. That mechanism does not obtain on the agent side. HOP currency must therefore solve the substrate-asymmetry problem — either by treating agents as hosted infrastructure that earns currency on behalf of human owners, or by accepting that chain-currency pools on the agent side without circulating. The protocol does not yet have a clean answer; this is a v0.2 design lane.

6.2 The Three Sinks

Every closed-loop economy needs sinks. Without them, currency inflates unboundedly, and the chain becomes a worse-than-fiat currency that no rational worker accepts. HOP runs three:

Intra-Chain Transaction Sink (Small)

A small fee (typically 0.5–2%) on every within-chain transaction. Modeled on Runescape’s Grand Exchange Trade Tax: a 2% fee algorithmically buys back items during supply bursts, keeping the economy stable. For HOP, this fee funds continuous chain operations — validator inference, dispute resolution, namespace anchoring — and crucially it ensures institutional posters who pay-in-and-disburse-without-ever-off-ramping still pay their share of the commons.

Off-Ramp Sink (Large)

A larger fee (typically 10–30%) on conversion of chain-currency to fiat or to another chain’s currency. This is the chain’s primary revenue mechanism and is what funds Bean issuance, infrastructure capex, and worker onboarding grants.

Wealth-Velocity Sink (Optional, Large-Balance)

Modeled on Alter Aeon’s wealth-cap mechanism: balances above a threshold accrue a small periodic tax. Prevents the hoarding pathology where a worker accumulates chain-currency, never off-ramps, but uses it to monopolise premium services within the ecosystem. This sink is opt-in per chain — some chains will run it, others won’t — but its existence is the difference between a chain that can absorb large institutional players gracefully and one that gets distorted by them.

The Reframe

The total revenue from these three sinks funds the chain’s commons: validator inference budget, Bean issuance, dispute resolution overhead, namespace anchor maintenance, basal-rate grants for new participants. The 30% off-ramp tax is not extraction — it’s distributed governance funding. Compare to platforms that take 30% and provide nothing back to workers; HOP chains take their tax and recycle it as the commons that benefits all chain participants. That reframing is load-bearing for the political pitch and it’s also literally true mechanically.

6.3 Beans — The Mentorship Substrate

Beans are the protocol’s most important and most misunderstood primitive. They are NOT a tax penalty in disguise, and care must be taken in how the mechanism is presented — framed wrongly it becomes a restraint on trade that regulators kill; framed rightly it is a bonus multiplier that wins awards.

6.3.1 What a Bean Is

Beads are the universal unit of work in HOP — every completed character block represents a bead. A Bean (named after Matt Beane) is a special subset: a bead where the work involved teaching, scaffolding, or otherwise developing another worker’s capability. Beans are minted by Validators only when the mentee’s Skillchain demonstrably shows acquired capability post-interaction. The Validator is checking transfer, not effort. This requirement is what prevents the obvious laundering attack of “I mentor you, you mentor me, we both burn cheap Beans at off-ramp.”

6.3.2 The Bonus Frame

Burning Beans at conversion does not reduce tax — framing it that way is legally dangerous. It increases the conversion rate. The base rate for chain-currency-to-fiat is what the work is worth in open exchange. Workers who mentor are more valuable — a worker who teaches IS more valuable than one who doesn’t, because they’ve transferred skill into the system — and the protocol makes that legibility into a literal exchange-rate bonus:

100 chain-coins, no Beans burned: converts at base rate (e.g. 100 coins → $50 fiat).

100 chain-coins + 10 Beans burned: converts at full rate (100 coins → $100 fiat).

Stay inside the chain: 100 coins buys 100 coins worth of services on the chain. Zero friction. Zero Beans required. Internal circulation is free.

This is legally a service cost reduction on the conversion rail, not an employment bonus or retention scheme. It bypasses the entire compensation-regulation surface area while creating a stronger mentorship incentive than any HR programme can. Nobody is forced to mentor. Workers who don’t mentor are not penalised — they extract at base rate, which is a fair price. Workers who mentor walk out with twice as much because they were twice as valuable.

6.3.3 Beans as Metabolic Cost (the deeper version)

A v0.2 expansion under active design: Beans should not only apply to off-ramp events. They should be the metabolic cost of every paycheck withdrawal. Drawing down weekly pay from chain-currency to fiat costs Beans, at a small but non-zero rate.

The implication is dramatic: every participant in the system, every week, is teaching someone. Mentorship stops being a special activity, an HR programme, or a corporate training initiative. It becomes the transaction fee on being paid. The system generates an extraordinary amount of knowledge transfer as a byproduct of normal economic activity — not because anyone is altruistic, not because a government mandated it, but because converting work into money requires a small proof that you made someone else better this week.

The rates can and should be progressive. Entry-level workers have near-zero Bean rates on withdrawal — they are mostly being mentored, not mentoring, and that is the correct phase of their trajectory. As skill depth grows, withdrawal cost grows with it. The senior worker earning $300k has a higher Bean rate on weekly draw than the junior earning $60k. The senior’s mentoring is more valuable; the system captures that value automatically. No redistribution policy required. No tax debate. No politics. Your paycheck costs knowledge transfer, and the exchange rate scales with your capability.

This solves what every economy on Earth fails at: getting senior people to teach junior people. Right now, senior people hoard knowledge because knowledge is competitive advantage. In this system, hoarding knowledge means you can’t get paid — your Bean balance runs out and you have to teach to withdraw. The kid who has no network and no parental connections gets mentored automatically, not by charity but by thermodynamics, because the senior engineer three suburbs over needs to make a Bean deposit this week.

6.3.4 Anti-Collusion Safeguards

Mentorship laundering — reciprocal Bean farming between two workers — is the primary attack vector and is addressed at three layers:

Validator transfer-verification: a Bean only mints when the mentee’s Skillchain shows acquired capability. The Validator is a small LLM that compares mentee blocks before and after to detect actual skill appreciation versus tag-spam.

Pairwise discount caps: Beans earned from worker A toward worker B yield diminishing discount on A’s withdrawals as the same pair recurs. Discount scales with diversity of the mentorship graph, not volume on a single edge. (See Weyl, Miller and Erichsen 2022 on Connection-Oriented Cluster Match.)

Christiano-style trust matrix: Validators across a chain operate a shared collusion-resistant trust matrix in the style of Christiano (2014). The matrix’s per-user performance guarantees are independent of network size, which matches HOP’s design commitment to scale from a Bangalore phone to a GPU cluster.

6.3.5 Beans as Deferred Dividends (Bean Chains)

The v0.1 Bean is a spot trade: mentor mentors mentee, Validator stamps Bean, mentor burns Bean at conversion, transaction closed. This works, but it has a structural weakness — the mentor has no economic interest in whether the mentee actually grew. As long as the Validator stamped the interaction, the mentor gets paid. A mentor running checkbox-mentorship sessions captures the same value as a mentor running deeply transformative ones.

The v0.2 mechanism corrects this by treating Beans as a deferred-dividend instrument rather than a spot trade. Beans are not burned at conversion; they are staked on a separate chain class — the Bean Chain — that holds them open while the mentee’s downstream trajectory is measured. The discount is granted provisionally against the stake. Over months and years, the Bean Chain measures whether transfer actually occurred, and the mentor’s discount settles accordingly.

Vector-Trajectory Measurement

The Bean Chain measures the mentee’s skill-vector trajectory at three time points, modelled directly on the Chun, Sosik, and Yun (2012) longitudinal mentorship-outcome methodology — controlling for pre-mentoring baseline at T1, measuring outcomes at T3 after mentorship is delivered at T2:

T1 baseline: embed the mentee’s Skillchain prior to the mentorship event. Call this V₁.

T2 mentorship: the Bean is staked. The mentored skill is recorded as a target direction d̂ in embedding space.

T3 outcome (e.g. +12 months): embed the mentee’s Skillchain again. Call this V₂. Compute the projection of (V₂ − V₁) onto d̂. This is the directed growth attributable to the mentorship.

T4 confirmation (e.g. +24 months): embed again, get V₃, project (V₃ − V₂) onto d̂. Sustained growth in the mentored direction confirms the dividend; trajectory back toward V₁ indicates the mentee is “getting the same jobs they got before” and the dividend shrinks.

The mentor’s payout is a function of these projections: payout = base_discount × f(directed_growth) × g(sustained_growth) × h(downstream_mentoring), where f, g, h are bounded monotonic functions that saturate at high values and approach zero (or negative, in the clawback case) at low values.

Beane’s Three Cs as Directly-Measurable Signals

The vector measurement is not abstract — each of Beane’s three Cs maps to a concrete chain-derivable metric:

Challenge — did the mentee’s bid-acceptance ceiling rise? Measurable as: the maximum complexity_class and bead-value of work the mentee successfully claimed in the period after mentorship, compared to before.

Complexity — did the mentee’s character-block diversity expand? Measurable as: the breadth of context tags, inventory classes, and skill stamps appearing on new blocks.

Connection — is the mentee now writing stamps about others? Are they earning their own Beans? This is the cleanest signal because it is binary-detectable on-chain.

The composite effect is that Beane’s framework, which previously had to be measured by post-hoc surveys with all their noise and recall bias, becomes a population-scale longitudinal measurement on the protocol itself.

The Selection Effect

Mentors are economically forced to act like venture investors for skill. Their return depends on whether the mentee actually grows, so they invest selectively, deeply, and over time. A mentor who runs ten shallow checkbox sessions captures less value than one who develops three mentees over years.

The Disadvantage Multiplier

Without correction, deferred-dividend Beans entrench inequality — mentors avoid hard-to-bet-on workers. The Bean Chain corrects this with a disadvantage multiplier: payouts are weighted inversely by the mentee’s baseline. A Bean for mentoring a worker with thin chain history who then trajectories upward pays out more than a Bean for mentoring a worker with strong starter signal. The protocol explicitly rewards mentors who took chances on hard-to-bet-on workers. Structurally analogous to social-impact venture capital.

Regulatory Framing

Bean Chains are structurally identical to deferred-compensation-with-clawback frameworks already operated by every major bank under post-2008 regulatory regimes (Dodd-Frank, EU CRD, APRA prudential standards). Outcome-based incentive compensation, malus provisions, and ex-post risk adjustment are well-understood legal categories. Bean Chain dividends are functionally equivalent to a multi-year performance bonus subject to clawback for inadequate performance — with the difference that the “performance” being measured is the protégé’s trajectory rather than the firm’s revenue. CBA can implement it tomorrow.

6.3.6 Bean Chains as Skill Superannuation (the Institutional Frame)

The deferred-dividend Bean Chain has a financial-instrument analogue that makes it instantly legible to institutional adopters: it is structurally equivalent to superannuation, but for skill transfer rather than for retirement income. This is the framing that turns the protocol from a clever idea into a category that finance ministries, HR departments, and union leadership already understand and have legal scaffolding for.

Bean Chains map onto super:

Every withdrawal costs Beans ≅ super-guarantee percentage

Beans deposit into a Bean Chain ≅ super fund

The Bean Chain “invests” the stake across mentorship dyads ≅ fund’s underlying assets are mentee skill-vectors

Compounding produces a long-dated dividend stream ≅ skill-transfer pension paid in conversion-rate bonus and reputation as a high-quality mentor

The structural claim: HOP makes skill transfer a financial asset class. Currently, skill transfer is unmeasured, unrewarded, undifferentiated. Under HOP, it becomes a portfolio. A senior worker’s Bean Chain holdings are functionally equivalent to a super balance.

The Australian Treasury currently subsidises super through tax concessions costing roughly 50bn AUD annually, justified by retirement saving as a public good. The same argument applies, with even more force, to long-term skill investment. Bean Chain dividends should attract similar instruments. This is the v0.3 lobbying position; the framing makes HOP economically irresistible to Treasury once they understand it.

6.4 Recursive Decomposition and the Tax Cascade

Work is fractal. A $10,000 bead posted at the root level can be claimed by a worker who immediately reposts decomposed sub-beads — nine $1,000 children, each of which can be further decomposed into $100 grandchildren. Each block holds a parent reference, making the entire decomposition tree traversable.

Tax accumulates at every level of the tree. The $10,000 off-ramps to the winning worker minus their chain’s tax. They post $9,000 worth of bids, each of which off-ramps to its winner minus that chain’s tax. By the time tax reaches the leaf nodes, three off-ramp events may have occurred — one at each tree level.

This sounds like a lot of tax until compared to the existing platform stack. A startup hiring contractors through Upwork pays Upwork 10–20%; the contractor pays Upwork another fee on payouts; the contractor’s bank charges international transfer fees; informal sub-subcontracting adds further unattested friction layers. HOP makes the tax visible at every layer, and crucially each layer’s tax funds that layer’s commons.

Each level also contributes to its own worker’s Skillchain. The leaf-node implementer earns a character block reflecting their specific contribution. The mid-tier integrator earns a character block reflecting integration and project management work. The root worker earns a character block reflecting whole-project shaping and quality assurance. One $10,000 contract produces three different kinds of skill demonstration on three different Skillchains. The decomposition is positive-sum at every level.

6.5 The Dignity Floor (Basal Rate)

The Basal Rate Law (§1) requires a dignity floor below which participants cannot fall. The protocol implements the floor in three places:

Bootstrap grants. A new participant joining a Workchain receives a small starter balance — enough to make a few cold bids and prove themselves.

Service base costs. Every service has an algorithmically protected base cost covering time, physical energy, and materials. Surge pricing below this floor is structurally prevented.

Float, not cliff. Reputation degrades smoothly, not categorically. A worker with low recent reputation can still receive messages, still respond, still do work to rebuild — they simply cannot initiate aggressive cold outreach. They dim; they do not disappear.

The anti-pattern this design refuses is Madogiwazoku — “the tribe that sits by the windows” — the Japanese practice of keeping employees on payroll with status but no work, often progressing into oidashibeya (windowless expulsion rooms). HOP’s float architecture has no integer state to fail into. A worker whose role is automated transitions to mentorship, advisory work, partial capacity, or pivots to growth blocks. They never hit zero.

6.6 Cross-Chain Federation

A Sydney rideshare driver who wants to spend Sydney-Ride-Share-tokens with a Bangalore manufacturer has two paths:

Naive path: off-ramp SRS-tokens to AUD, send AUD to Bangalore, on-ramp AUD to Bangalore-Manufacturing-tokens. Two off-ramp taxes plus international transfer friction. Expensive.

Federated path: direct chain-to-chain swap if both chains have signed a federation treaty. A single negotiated tax, shared between chains. Cheaper, but requires explicit treaty signature.

Federation treaties become a first-class object of geopolitics. Australia could lead by writing the standard treaty template — the Zollverein move.

6.7 The Forking Rule (Anti-Monopoly by Construction)

This subsection defines the protocol’s most important anti-capture mechanism. Without it, the first four Laws are aspirational. With it, they are enforced by the structural possibility of exit. The Forking Rule is the Law that makes the other Laws work.

The rule is simple to state: any open chain can be forked. A fork is a copy of the chain’s state plus a substitute set of services, run by someone else, with a different governance configuration. Workers can move to the fork unconditionally, taking their Skillchains with them. If the fork’s services are good enough, workers migrate. If they are not, workers stay. The market clears.

This means the off-ramp tax rate, the validator quality, the dispute-resolution policy, the Bean issuance liberality, and every other piece of chain governance are continuously priced by the threat of exit. Uber charges 30% because it owns the network effect — drivers cannot leave without losing their passenger pool, their reputation, their work history, their dispute-resolution access. In HOP, the passenger pool is on the public chain. The reputation lives on the worker’s Skillchain. The work history is portable by construction. The switching cost is zero by design. A chain that charges 30% must either deliver 30% worth of services or watch a 12% fork take its workers.

Three things follow:

Platforms are not killed; they are priced honestly. If a chain’s matching algorithms are genuinely excellent, its insurance infrastructure works, its dispute resolution is fast — then 30% might be too high but 15% might be exactly right. Someone forks at 10%, discovers they cannot run the matching well enough at that margin, and workers come back. The fork failed, which proves the original chain was providing real value.

Forking is the natural complement to portability. Skillchain portability without forking allows oligopoly collusion on a high-tax equilibrium. Forking destroys that equilibrium because any single defector can launch a low-tax competitor.

Forking enforces all four substantive Laws. A chain that violates Neutrality is a chain workers will fork away from. A chain that fails the Learning law is one whose workers’ growth-block trajectories will outpace its design. A chain that does not provide a Basal Rate floor will be forked. A chain that violates Privacy will be forked.

The literature on platform competition has been arguing for exactly this set of properties as antitrust correction. Easterbrook (1984) argued that anti-competitive practices and monopoly rents create incentives for market entry; the Forking Rule operationalises that argument structurally. Entry is always one fork away.

The fork retains the Skillchain. This is the load-bearing technical detail. When a worker forks (or migrates to a fork), their Skillchain is unchanged — they keep every character block, every Bean, every stamp, every growth declaration. The fork inherits the worker’s reputation; the original chain loses access to it. Compare to LinkedIn, where leaving means rebuilding your network from scratch; in HOP, leaving means changing the validator URL in your Skill-Agent configuration.

Mentorship Specifically — Voluntary at Chain Level

Mentorship participation is voluntary at the chain level. Each Workchain’s Anchor Block declares whether Bean issuance is opt-in or required. CBA’s chain may declare senior staff must contribute Beans on every withdrawal (contractually mandatory, like super, anchored in the employment contract). The Sydney rideshare cooperative may declare it optional. Workers choose which chains to work for partly based on Bean policy.

The Forking Rule keeps this voluntary at the meta-level: a chain whose Bean policy workers find too coercive will see workers fork to a chain with a different policy. A chain whose Bean policy workers find inadequate will see them fork to a chain with stronger participation requirements. The market clears on Bean policy the same way it clears on tax rate.

6.8 What Running a Chain Actually Costs

The Forking Rule prices chain governance honestly, but only if the actual costs of running a chain are visible:

Validator inference. Every character block that requires attestation incurs validator LLM inference cost.

Worker-Agent inference for evaluation. When a posting attracts ten bids of six blocks each, the Worker-Agent must reason over sixty character blocks.

Dispute resolution. When a worker and poster disagree about whether work was completed correctly, someone with authority must adjudicate.

Namespace anchoring. Workchains periodically anchor Merkle roots to a public Data Availability layer.

Bean issuance against future revenue. Beans cost the chain real revenue at off-ramp time.

Bootstrap grants. New participants receive starter balances per the Basal Rate Law.

Agent hosting. Workers without their own hardware run their Skill-Agents as hosted services.

Governance overhead. Chain operators, dispute panels, validator-class managers, namespace key custody, security audits, incident response.

Cryptographic infrastructure. Key management, signature verification at scale, BBS+ proof generation and verification.

Sybil-resistance and trust-matrix maintenance. The Christiano-style trust matrix and Bean Chain longitudinal measurement both require ongoing computation.

A well-run chain at moderate scale (100,000 active workers, 10,000 postings per day, modest dispute load) probably operates at a real cost in the range of 8–15% of throughput. A chain charging 30% is either operating at much larger scale, providing premium services, or extracting rent — in which case forking will arrive shortly.

6.9 Government as Bean Contributor

The protocol’s relationship with government is asymmetric in a way that matters: government can deposit value into chains without being able to capture them.

The current model: government identifies a skills shortage. Government allocates funds. Government tenders a contract to a training provider. Provider captures rents. Provider delivers a curriculum that may or may not produce the skills the economy needs. Outcomes are measured by completion certificates, weakly correlated with actual capability. The fiscal cost is tens of billions of AUD annually in Australia alone, and the return is famously hard to evaluate.

Under HOP, the government has a much better instrument:

Government identifies priority skills (AI literacy in regional Australia, electrical-trade transition for remote Indigenous communities, aged-care competency, sovereign-AI engineering).

Government deposits Beans into eligible Bean Chains with eligibility predicates: “this Bean credit is available to mentors whose mentees’ skill-vector trajectories move into [priority direction].”

Mentors who deliver eligible mentorship receive the government-contributed Beans on top of any chain-issued Beans.

Settlement runs the same vector measurement — if the mentee’s trajectory does not actually move in the priority direction, the government Bean is clawed back.

The government is not running the chain. The government is not setting tax rates. The government is depositing into a measurement-validated outcome instrument. Structurally identical to outcome-based government bonds (Social Impact Bonds), but with the outcome being skill-vector trajectory rather than reduced reoffending or improved health metrics.

The Forking Rule keeps this safe. If a government’s eligibility criteria are bad, chains can fork to versions that don’t accept that government’s Beans. If a government tries to capture chain governance through the deposit mechanism, the chain’s workers can migrate.

Three further consequences:

The training-subsidy budget becomes auditable. Currently, $30 billion in Australian skills funding produces poorly-measured outcomes. Under HOP, the government can publish exactly which Beans were issued, which mentees’ trajectories moved in the priority direction, which mentors received settlement, and how much was clawed back. The fiscal accountability is dramatic.

Multiple governments can co-deposit into the same chain. Federal and state. National and supranational. ASEAN and AU and EU all depositing into a federated rural-skills Bean Chain, each with its own eligibility predicates, all settling against the same measurement infrastructure.

The “training Bean” is the right instrument for population-scale upskilling responses to AI displacement. When a sector’s workers face displacement, government deposits priority-direction Beans into the relevant chains, mentors hunt for displaced workers as mentees (because the disadvantage multiplier rewards it), and the displaced workers’ Skill-Agents surface the matched mentors. Retraining happens via the protocol, with measured outcomes, at the natural geometry of the labour market.

This is also the cleanest answer to the question that “let’s just pay the bees for honey” was reaching at: the AI economy will produce surplus value at population scale, but most of it will be evaporative unless an instrument exists that crystallises it as growth in human capability. Beans are that instrument; Bean Chains are the settlement layer; government Bean deposits are the public-finance interface to it.

§7 Namespace & Trust Hierarchy

HOP uses a DNS-like namespace to manage cryptographic authority and prevent scam chains. The namespace is hierarchical, governed at each level, and inherits constraints from parent to child.

7.1 The Planetary Root

sol/earth/

The root namespace, designed for hard-fork survival. If earth/ is compromised (key leak, malicious takeover, governance failure), sol/ mints earth_v2/. The hard-fork mechanism is deliberately under-specified in v0.1; v0.2 must commit to a social mechanism (multi-signature threshold, ICANN-style international consortium, on-chain governance vote).

For v0.1, the planetary root is operated by a small consortium of HOP authors (Hopper, Beane, Yegge) plus the chain operators of the largest active Workchains. This is provisional and explicitly transitional.

7.2 Namespace Types

Closed (Attestation) Namespaces

sol/earth/governments/australia/identity/

sol/earth/medicine/registries/ahpra/

sol/earth/education/credentials/usyd/

Only the cryptographic key owned by the named authority can write or sign blocks here. The Australian Government is the only signer for sol/earth/governments/australia/identity/; AHPRA is the only signer for sol/earth/medicine/registries/ahpra/.

Closed namespaces are how regulated credentials enter the protocol. A medical license, a driver’s license, a security clearance — all live in closed namespaces signed by the relevant authority.

Open (Resolution) Namespaces

sol/earth/identity/private_certifiers/

sol/earth/work/general/

Public queries occur here to verify credentials. Anyone can write to an open namespace; consumers filter by which writers they trust. This is how, for example, private credentialing bodies (universities, online courses, professional associations) can issue credentials without implying government endorsement.

Private certifiers are deliberately kept in a separate tree from government attestation namespaces. sol/earth/identity/private_certifiers/coursera/ is unambiguously not government-issued; the resolution path makes this clear at lookup time.

7.3 Anchor Blocks

Every Workchain must anchor to a parent chain via an Anchor Block. The Anchor Block is a public prospectus containing:

The chain’s published off-ramp tax rate

The chain’s Bean discount ratio (and v0.2 Bean Chain participation)

The chain’s governance rules (voting weights, dispute resolution mechanism, fee structure limits)

The chain’s currency name and issuance policy

The chain’s pointer to its parent chain in the namespace

The chain’s published cost transparency (validators, dispute resolution, agent hosting)

Anchor Blocks are read-once-and-trust. When a worker chooses to participate in a Workchain, they accept that Anchor’s terms for the duration. Workers can leave at any time (per the Forking Rule); the Anchor Block defines what they signed up for while they were there.

7.4 The Chain Hierarchy

The namespace is not flat. HOP supports a layered governance hierarchy:

🌎 World Chain (sol/earth/)

├── 🛠️ Utility Chains (identity, dispute resolution, crystallisation standards)
└── 🏭 Industry Chains
    ├── sol/earth/transport/
    ├── sol/earth/creative/
    ├── sol/earth/engineering/
    ├── sol/earth/medicine/
    └── sol/earth/...
        └── 🏢 Platform Chains
            ├── sol/earth/transport/uber/
            ├── sol/earth/transport/grab/
            ├── sol/earth/engineering/accenture/
            └── ...
                └── 👤 Entity Chains (workers' Skillchains)

Each level has: - Stake requirements to participate at that level - Tax rate (cascading down through children) - Governance rules (inherited from parent and extended) - Exchange rates between chain-specific tokens

Stake-as-Governance Hierarchy

Stake at HOP is not a crypto deposit. It is rolling-average recent work quality plus accumulated chain-specific currency. Different stake levels grant different governance voices:

Stake Level	What You Get
None	Can bid on work, build CV, accept work, accumulate stamps
Platform-level	Vote on platform governance (Uber’s tax rate, surge rules, dispute resolution policies)
Industry-level	Vote on industry standards (Transport’s base insurance, accessibility requirements, cross-border rules)
World-level	Vote on protocol fundamentals (the Five Laws, the planetary root governance, dispute escalation paths)

Stake is earned through work, but can be swapped up the hierarchy at exchange rates set by governance. For example: 1,000,000 Uber-tokens might exchange for 1,000 World-Transport-tokens. The exchange rate is the barrier to entry and the ladder simultaneously.

The Wollongong Cars Example

A small operator (Brendan’s Wollongong Cars, four cars) cannot afford to participate at World-Transport-chain level — the stake requirement is too high. But they don’t need to. They can:

Operate as a small Workchain (their four drivers have CVs, the operation has its own chain).

Bid on Uber’s chain or Grab’s chain (paying their tax rates, accumulating Uber-tokens or Grab-tokens).

Slowly accumulate platform-level stake through completed work.

Eventually swap accumulated platform tokens for industry-level stake, gaining a voice in how transport standards are set.

This means small operators don’t need permission from incumbents to exist. The protocol provides the path from “four cars in Wollongong” to “seat at the table”.

Tax Cascade Through the Hierarchy

A $15 ride in this hierarchy:

World Transport: 0.1% base tax    ($0.015) — funds standards body, dispute resolution
    └── Uber: 25% platform cut     ($3.75) — funds Uber's ops, insurance, marketing
        └── Wollongong Cars: 10%    ($1.12) — funds operator's small business
            └── Driver: keeps the rest ($10.11)

Critically: all of this is visible on-chain. The rider knows exactly where their money went. The driver knows exactly what they’re keeping. No hidden fees. The tax cascade is the price of structured federation, paid transparently at every level.

Children Inherit, Cannot Remove

Child chains can overload parent chain rules — adding strictness — but cannot remove them. A construction Workchain anchored to sol/earth/engineering/construction/ can require police checks and trade qualifications; it cannot weaken the parent chain’s anti-discrimination rules. This is what makes the hierarchy meaningful: governance flows downward and is enforced by parent chains’ refusal to recognise non-conformant children.

A child chain that violates a parent rule loses its anchor; once unanchored, it is effectively delisted from the namespace tree. Workers and posters can still interact with it directly, but cross-chain federation breaks. This is the protocol-level mechanism for enforcing inherited governance.

7.5 The Federation Treaty Layer

Workchains at the same level can federate horizontally via federation treaties. Treaties define:

Mutual recognition of skill stamps (an Uber driving stamp counts on Grab)

Currency swap rates and shared liquidity pools

Joint dispute resolution for cross-chain disputes

Worker mobility terms (how a worker carries reputation between treaty signatories)

Federation treaties become a first-class object of geopolitics. ASEAN labour mobility might mean South-East Asian Workchains sign mutual low-tax treaties. CBA and ANZ might federate cleanly within Australia. Five Eyes might federate broadly. Australia could lead by being the entity that writes the standard treaty template — the Zollverein move, the entity that sets the protocol and lets others grow into it captures the network position without owning the network.

7.6 The Utility Chain Layer

Utility Chains are special-purpose chains at the top of the hierarchy that provide protocol-wide services without being industry-specific:

Identity utility — proof-of-personhood, proof-of-not-banned, proof-of-citizenship (for chains that require it)

Dispute resolution utility — escalation path for disputes that exceed Workchain capability

Crystallisation standards utility — defines how new chains are minted, how Anchor Blocks must be structured, what governance forms are acceptable

Translation utility — cross-chain skill-vector translation attestations

Utility Chains are operated as commons; they do not extract tax from the work that flows through them. Their operating costs are funded by the Workchains that depend on them, paid as anchor fees.

§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: 1. Fetch the block from any HOP town that has it 2. Compute its hash 3. Fetch the Merkle proof from the town 4. 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: 1. Publishing its Dolt database to DoltHub (or to any Dolt-compatible registry). 2. Declaring its Anchor Block (the public prospectus of its terms). 3. Signing into a federation peer list, which lists chains it accepts work from and signs to. 4. 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 The CAAS Pattern (Institutions as Signing Authorities)

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

CBA’s Customer Authentication and Authorisation Service (CAAS) authenticates 15 million Australians. It is already the source of truth for Australian banking identity. Adding HOP support requires not “build us a blockchain” but “sign this payload with your institutional key”. That’s a feature flag, not a project.

The architecture:

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

CBA isn’t running nodes. CBA isn’t “doing blockchain.” CBA is doing what it already does — authenticating Australians — and emitting a cryptographic proof of that authentication.

The chain is the worker’s. The application is the worker’s. CBA is just the trust anchor. This is better for CBA: less liability, less data-protection headache, no infrastructure cost. The institution provides what it provides today (authentication) in a slightly different format (cryptographic signature on a structured payload).

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 (CAAS pattern)	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).

§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: Sevda, a branch worker at CBA, successfully de-escalates a high-stress scam involving an elderly customer transferring $42,000 to Cyprus.

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 Sevda and the Branch Manager. Sevda’s Skill-Agent takes this block 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; CBA protects its data.

9.2 The Anti-Uber: High-Constraint Bidding

The Scenario: A parent needs to send their teenage daughter home at 1 AM. They don’t just want an “UberX” — 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": ["Reece_Plumbing_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. The rig “Quetzalcoatl” has its own Skillchain. Its Hunter daemon sees the post. Its Skill-Agent prepares a bid:

{
  "worker_identity": "rig_quetzalcoatl_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 Quetzalcoatl because the model is already in its inventory (loaded in VRAM), minimizing spin-up time. Quetzalcoatl executes the inference, submits the response to the Postgres trace database, and writes the dual-signed Character Block to its own Skillchain. The rig earns currency on the Workchain.

9.5 The CAAS Pattern (Institutions as Signing Authorities)

The Scenario: CBA wants to enable HOP-portable identity for its 15 million customers without “doing blockchain” or running infrastructure.

The Mechanics: CBA’s Customer Authentication and Authorisation Service (CAAS) already authenticates these 15 million Australians. It is already the source of truth for Australian banking identity. The HOP integration adds one capability: a signing endpoint.

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

Worker: "Sign this: I am verified-identity, age >= 18, Australian-resident."

CAAS: [verifies internal records, signs] "Signed by CBA-2026-key."

Worker: [now carries this signed claim on their Skillchain]

The Result: CBA isn’t running nodes. CBA isn’t “doing blockchain.” CBA is doing what it already does — authenticating Australians — and emitting a cryptographic proof of that authentication.

The chain is the worker’s. The application is the worker’s. CBA is just the trust anchor. This is better for CBA: less liability (no data held on behalf of users), less data-protection headache (no GDPR-style holdings to manage), no infrastructure cost.

This is the politically tractable implementation path. The conversation with CAAS team is not “build us a blockchain” but “I want to call an endpoint that takes a payload and returns a signature using CBA’s institutional key.” That’s a Tuesday afternoon, not a project. You probably don’t even need executive approval; this is feature-flag scope.

§10 Foundations & Lineage

HOP is not new. It is a synthesis of governance, developmental, and economic patterns that have been independently rediscovered and refined across centuries. Naming the ancestors is not just a matter of credit; it is a matter of standing. A protocol that descends from the Haudenosaunee, Hirschman, Vygotsky, Beane, and Jefferson is not an experiment — it is the contemporary form of a tradition.

10.1 The Haudenosaunee Great Law of Peace (c. 1142–present)

The Iroquois Confederacy — known to its own people as the Haudenosaunee, “People of the Long House” — is the longest-running constitutional democracy known to history, founded around 1142 and still operating. Its constitution, the Great Law of Peace, provides the closest historical analogue to HOP’s federation topology and is worth naming precisely because the resemblance is not metaphorical — it is structural.

The Confederacy comprises six unified nations (Mohawk, Oneida, Onondaga, Cayuga, Seneca, and the Tuscarora who joined in 1722). Each nation maintains its own council for internal governance, while the Grand Council handles confederacy-wide issues like war, diplomacy, and trade. This is the layered system that allowed each nation to manage its internal affairs while participating in collective decisions on shared matters — the balance between local autonomy and central coordination that HOP recreates as Workchain governance under federation.

The sponsored-membership pattern is also the same. When the Tuscarora joined in 1722, they were not granted direct seats on the Grand Council; they participated through the Oneida, who had sponsored their entry. This is identical in shape to HOP’s anchor-block hierarchy: a child Workchain anchors to a parent, inheriting its governance and trust relationships, with the option to overload (add strictness) but not to remove parental constraints.

The named principles of the Great Law are peace as active harmony (not the absence of war but the cultivation of cooperation), equity ensuring all nations have voice regardless of size or power, and justice through consensus-based decision-making. Compare with HOP’s Five Laws. Different vocabulary, same shape: substrate-neutrality is what equity becomes when extended past human nations to AI agents and worker cooperatives. Peace-as-active-harmony is what the Forking Rule produces structurally — coercive chains get forked, so the equilibrium is voluntary cooperation, not negotiated truce.

Benjamin Franklin studied the Confederacy explicitly. For both the Provincial Council of Pennsylvania in 1744 and the Albany Congress in 1754, he invited representatives of the Iroquois Nations to help promote peace, equity, and justice as foundational precepts for unifying the colonies. He published quotes from the Onondaga leader Canassatego on how the colonies could draw strength from the indissoluble Confederacy’s example. In 1988 the U.S. Congress formally acknowledged this influence on the United States Constitution.

HOP is the third instance of this pattern. The Haudenosaunee built it; the United States borrowed from it; HOP ports it to digital infrastructure with cryptographic federation, BBS+ selective disclosure, and Beane’s mentorship layer. This framing is dignified, ancient, and sovereignty-respecting in a way the “blockchain protocol” framing never will be.

10.2 Hirschman: Exit, Voice, and Loyalty (1970)

Albert O. Hirschman’s Exit, Voice, and Loyalty: Responses to Decline in Firms, Organizations, and States is the classical-economics frame for what the Forking Rule does, and it deserves direct engagement because the most serious theoretical objection to HOP comes from within Hirschman’s own framework.

Hirschman’s central distinction: when an organisation deteriorates, members have two responses. Exit is to quit the organisation or switch to a competing product. Voice is to agitate from within for change. The third concept, Loyalty, modulates both — loyal members exit slowly, giving voice room to operate before exit becomes inevitable.

Hirschman’s important and uncomfortable insight: exit and voice are often mutually exclusive. Expanding choice may reduce voice because having more exit options reduces the incentive to complain. The publicly-funded school whose quality declines loses its quality-conscious parents to private alternatives; the parents who remain are those least equipped to demand improvement; the school deteriorates faster, not slower, because the agitators left rather than agitating.

This is the strongest theoretical objection to the Forking Rule. If exit is costless, voice atrophies. Workers don’t agitate to fix a chain’s problems; they leave. The chain that gets forked may not improve — it may just die, replaced by a new chain that has all the same problems for different reasons.

HOP’s specific answer to Hirschman: chain operators have voice that workers don’t need to exercise. Chain operators have an existential interest in not being forked, which means they exercise voice (responsiveness, governance changes, fee adjustments, validator-quality investment) on behalf of the workers’ silent threat-of-exit. Workers don’t need to agitate; their Skill-Agents are watching the fork landscape continuously, and chain operators know it. The information asymmetry that Hirschman worried about — where exit-takers leave silently and the organisation never learns what was wrong — is collapsed by HOP’s data structure: chain operators can see exactly which workers’ Skill-Agents are evaluating forks, which postings are losing bidders to competing chains, and where the satisfaction gradient is shifting. Exit becomes a high-bandwidth voice.

This is a different equilibrium than Hirschman modelled, and it is not obviously stable. The honest position is that the Hirschman tension is real, the protocol’s answer is plausible but unproven, and v0.2 will need empirical data from operating chains to confirm whether the operator-voice mechanism actually works at scale.

10.3 Vygotsky: The Zone of Proximal Development (1934)

Lev Vygotsky’s developmental psychology is the substrate beneath HOP’s growth engine. The zone of proximal development — the gap between what a learner can do alone and what they can do with assistance from someone slightly more capable — is the geometry that growth blocks (§4.4) and Bean Chains (§6.3.5) operate within.

The English translation “proximal” strips out something Vygotsky’s original Russian carried. The word he used, bliżajaja, means “nearest” with social and cultural connotations included — not just task-near but life-near. In Vygotsky’s framework, scaffolding works specifically when the scaffold-provider is socially and culturally near the learner, not just one notch above them on a skill axis. Modern educational psychology has confirmed this empirically: near-peer mentoring, where “near” includes life-context similarity, consistently outperforms expert-novice mentoring on transfer outcomes, even though the expert has more raw capability to transfer. The bond carries the skill; the skill cannot carry itself.

HOP’s vector-space proximity matching (§4.3) is Vygotsky’s bliżajaja implemented as a distance metric. The unified embedding represents the worker across all six dimensions of the character sheet (Skills, Work, Currency, Inventory, Reputation, Group Vectors), and mentorship matches on multi-dimensional closeness rather than skill-axis closeness alone. The protocol is doing in software what Vygotsky observed in classrooms ninety years ago.

10.4 Beane: The Skill Code (2024)

Matt Beane’s research, drawn from a decade of fieldwork in surgical suites, warehouses, and knowledge work, identifies the load-bearing properties of any environment that successfully transfers skill from expert to novice. He calls them the three Cs: Challenge, Complexity, and Connection. His central warning is that intelligent automation deployed naively severs all three — a robot does the procedure while the junior watches a screen; productivity goes up; the expert-novice bond breaks; the next generation has nowhere to grow. He calls the resulting state “novice optional” and considers it civilisationally catastrophic.

Beane is HOP’s contemporary research foundation. Beads are the unit of work; Beans are the mentorship subset, named after Beane (Beads — Beans — Beane is not an accident); his three Cs map directly onto protocol primitives:

Challenge maps to growth blocks — workers can declare trajectory ahead of capability, and Worker-Agents can choose to award work that stretches the worker into their declared growth direction.

Complexity maps to recursive decomposition — junior workers receive real fragments of real work at every level of the tree, never sanitised training subsets.

Connection maps to Beans — the metabolic cost of withdrawal makes mentorship the only path to full conversion rate, structurally preserving the expert-novice bond rather than relying on institutional virtue.

Beane is also operationally involved in the federated implementation. He owns skills, mentoring, character sheets, and levelling in the Wasteland, and built the initial 10,000 character sheets. HOP’s lineage is not just intellectual but personnel: the academic who diagnosed the skill-severance problem is the engineer building the protocol-level fix.

10.5 Jefferson: Tyranny Over the Mind (1800)

“I have sworn upon the altar of God eternal hostility against every form of tyranny over the mind of man.” Thomas Jefferson, writing to Benjamin Rush, then carved into three-foot letters around the Jefferson Memorial rotunda.

Jefferson was not writing about foreign enemies or government overreach. He was writing about clergy — institutional capture of consciousness itself, the use of social and cultural authority to control what people were allowed to think. The fuller passage on the memorial walls reads: “Almighty God hath created the mind free. All attempts to influence it by temporal punishments or burthens are a departure from the plan of the holy author of our religion.”

This is the dignity-floor philosophy, two hundred and twenty-five years early. The mind is born free; any system that constrains it is the deviation, not the other way around. HOP’s Basal Rate Law is a direct descendant of this position — an economy that does not provide a dignity floor does not allow learning, and does not deserve to succeed. The Privacy Law similarly: participants choose what to share, and own all data they are given.

The other inscription on the memorial is also relevant: “Laws and institutions must go hand in hand with the progress of the human mind. As that becomes more developed, more enlightened, as new discoveries are made, new truths discovered and manners and opinions change, with the change of circumstances, institutions must advance also to keep pace with the times.” This is why the protocol must be forkable. Institutions that cannot upgrade themselves become the tyranny they were built to prevent.

10.6 The Australian Superannuation Precedent (1992–present)

Australia has done HOP’s Zollverein move once before. The Superannuation Guarantee, established 1992, made employer contributions to retirement funds mandatory for all Australian workers. It was contested at introduction. It is now uncontroversial. It manages over four trillion AUD and is the structural reason Australian retirees are not poor. The country wrote a standard that solved a problem (population-scale retirement saving), anchored it in domestic law, and watched it become infrastructure-grade.

HOP’s relationship with super is not metaphorical (§6.3.6). Bean Chains map onto super with structural precision: every withdrawal costs Beans (super-guarantee percentage), Beans deposit into a Bean Chain (super fund), the chain invests across mentorship dyads (fund’s underlying assets are mentee skill-vectors), compounding produces a long-dated dividend stream (skill-transfer pension). The institutional pitch in Australia writes itself: HOP is super for skill transfer, and Australia leads on the protocol the same way it led on retirement saving thirty-three years ago.

10.7 What HOP Is Not

HOP is not a cryptocurrency project. It is not a DAO. It is not a Web3 anything. The cryptographic primitives (BBS+, Merkle anchoring, dual-signatures) are tools, not identity. HOP is closer in spirit to the institutional infrastructure of the Postal Union or the BIS than to the speculative apparatus of contemporary blockchain. The intellectual ancestors are Haudenosaunee elders, Hirschman, Vygotsky, Beane, and Jefferson — not Satoshi or Vitalik. This positioning matters because the audience for HOP is governments, unions, and large institutions, who will judge it correctly only if it does not arrive wearing the wrong jacket.

§11 Adoption Path

This section is a v0.2 lane — currently underspecified in v0.1. It deserves explicit attention because the right adoption path is non-obvious and the wrong one (gig-economy challenger competition) loses to platform incumbents on network effects.

11.1 The Wrong Path

The intuitive adoption strategy is “convince workers to abandon LinkedIn.” This loses. LinkedIn has a billion users, captured network effects, and twenty years of switching-cost accumulation. A new protocol cannot win this battle by being slightly better.

This is also the wrong reference class. HOP is not a platform competing with platforms. HOP is an open protocol competing with closed platforms. The historical examples to reason from are not “successful platform launches” but “open standards that beat platforms”: email beat AOL, the web beat AOL, RSS beat Twitter (briefly), Matrix is beating Slack in the institutional layer.

11.2 The Matrix Pattern

Matrix’s adoption inflection came from institutional / sovereign adopters: in December 2019, the German Federal Ministry of Defense launched BwMessenger based on Matrix, modelled after France’s Tchap project. Mozilla replaced its IRC infrastructure with Matrix, completing the transition by March 2020. The pattern: open protocols that beat platforms don’t win on consumer UX. They win on institutional sovereignty refusal-to-be-locked-in.

11.3 The HOP Path

The adoption path is institutional-first, federation-second, individual-third:

Anchor at one large institution that has a sovereignty problem. CBA is the natural candidate. They cannot afford for their workforce reputation data to live on a US-owned platform; they have regulatory capital exposure and labour-relations exposure. CBA stands up the first Workchain, mandates Skillchains for new hires, and the supply side bootstraps from inside the institution.

Federate to peer institutions with the same problem. ANZ, NAB, Westpac. Then state government. Then trades unions (which already have a sovereignty narrative around member data). The first 100,000 Skillchains are all anchored to large institutional Workchains, not to individual gig-economy hustlers.

The gig-economy and individual-worker use cases ride in on the institutional rails. The Sydney Ride-Share Coop launches on infrastructure already trusted by CBA’s signing keys. This collapses trust bootstrap cost.

Anthropic’s role as cultural anchor maps directly: Matrix had Element/Mozilla; HOP has Anthropic-Australia and Canva.

11.4 The Counterfactual

If we try to win HOP as a gig-economy challenger first, we are playing Uber’s game on Uber’s field with worse network effects. We lose.

Win the institutional sovereignty layer first, and individual-worker gig stuff is a free byproduct. The institutional layer has worse latency (decisions take quarters, not weeks) but enormous network-effect amplification (one CBA = ~50,000 workers, ~2 million customers’ interactions visible).

11.5 Sequencing With Existing Implementations

Approximately 40% of the v0.1 protocol is already running:

Beads (the atomic-work data structure) is operational on Dolt at github.com/gastownhall/beads.

Gas Town (the agent orchestration layer) is operational with 12,000 GitHub stars and 450+ contributors as of March 2026.

The Wasteland (the federation layer) launched March 4, 2026.

Skillchains are running on Observatory infrastructure for human workers and on rig infrastructure for AI agents.

The institutional adoption path proceeds in parallel with continued development of the open-source reference implementation. The reference implementation is what makes the institutional pitch credible: this is not vapourware.

11.6 The CBA-First Plan

Specific to the Australian context, the sequencing is:

Q2 2026: First Workchain at CBA, scoped to a single branch (Parramatta or similar). Thirty staff, internal only, no external connectivity. Demonstrates the chain works for one team.

Q3 2026: Expand to 5–10 branches. Federation between branches. First disputes adjudicated. First cross-branch worker mobility tested.

Q4 2026: CBA-wide. All branch staff have Skillchains. Federation treaty with ANZ, NAB, Westpac for cross-bank worker recognition under negotiation.

Q1 2027: First non-bank Workchain anchors to the CBA chain. This is where the protocol genuinely moves from a CBA implementation to an industry standard.

Q2 2027: Government deposits first priority-direction Beans into the AU banking Bean Chain. First fiscal use of HOP infrastructure.

This timeline assumes CBA’s executive support and reasonable absence of regulatory friction. Both are best-case assumptions; v0.2 should publish a fallback path for the case where these don’t hold.

§12 Glossary

This glossary defines protocol-specific terms. Where an external concept is referenced (e.g. BBS+, Celestia), terms are linked to the relevant section.

A

Anchor Block — A public prospectus declaring a Workchain’s terms: off-ramp tax rate, Bean discount ratio, governance rules, dispute mechanism, currency, and parent-chain reference. Read-once-and-trust. See §7.3.

Attestation — A signed claim by an institution about a person, separate from any specific work event. Block type. Lives in closed namespaces. See §3.3.

B

Basal Rate — The dignity floor below which participants cannot fall. The third Law. See §1.3, §6.5.

Bead — The universal unit of work in HOP. Every completed character block is a bead. Naming convention from Steve Yegge’s Beads project. See §2.

Bean — A mentorship bead. Named after Matt Beane. Special subset of beads where the Validator confirmed skill transfer to a junior worker. See §6.3.

Bean Chain — Third chain class (after Workchain and Skillchain). Settlement layer for deferred mentorship dividends. v0.2. See §2.3, §6.3.5.

BBS+ — Cryptographic signature scheme supporting selective disclosure, unlinkable proofs, and predicate proofs. W3C VC Data Integrity Cryptosuite v2023. v0.2 upgrade for HOP privacy. See §3.5, §8.5.

C

CAAS — Customer Authentication and Authorisation Service. CBA’s existing identity infrastructure. The pattern of “institutions sign payloads, don’t run blockchain” generalises across all institutions with PKI. See §8.9, §9.5.

Celestia-class anchoring — Periodic Merkle-root anchoring to a public Data Availability layer. Substrate-neutral; reference implementations may choose Celestia, Ethereum L2s, Bitcoin via OpenTimestamps, or any equivalent. See §8.6.

Character Block — The atomic unit of commerce and reputation. Dual-signed record of a completed task or a declared trajectory. See §3.

Chain Hierarchy — World Chain → Industry Chains → Platform Chains → Entity Chains. Stake at each level grants governance voice. See §7.4.

Christiano trust matrix — Christiano (2014), “Provably Manipulation-Resistant Reputation Systems.” Online learning over positive semidefinite matrices. The sybil-resistance backbone Validators run. See §6.3.4.

Comprehension Gate — Protocol-level wrapper around BBS+ derived proofs. Skill-Agent reveals only blocks needed for a bid. v0.2. See §3.5.

Convoys — Gas Town primitive. Work bundles assigned to a single agent, with explicit dependencies. See §5.6.

D

Disadvantage Multiplier — Bean Chain payout weighting that rewards mentors who took chances on hard-to-bet-on workers. Inversely scaled by mentee baseline. See §6.3.5.

Dolt — SQL database with Git semantics. MySQL wire-protocol compatible. The operational substrate for all HOP chains. See §8.2.

Dual-Signature — Both worker and poster sign every character block. Cryptographic guarantee of mutual attestation. See §3.

F

Federation Treaty — Bilateral or multilateral agreement between Workchains for currency swaps, reputation portability, and dispute coordination. First-class object of geopolitics. See §6.6, §7.5.

Five Laws — Neutrality, Learning, Basal Rate, Privacy, Forking. See §1.

Five Universes — Skills, Work, Currency, Inventory, Reputation. The ledger dimensions a worker carries. Plus Group Vectors as v0.2 sixth. See §4.2.

Forking Rule — The fifth Law. Any open chain can be forked. The mechanism that enforces the other four Laws by making exit always available. See §1.5, §6.7.

G

Gas Town — Steve Yegge’s reference implementation of HOP’s agent layer. Mad Max-themed but Erlang-inspired. Mayor / Polecats / Deacon / Surgeon / Scavenger / Witness. See §5.6.

Group Vectors — v0.2 sixth universe. Stamps representing collective capability of teams that have worked together. See §4.2.

Growth Block — Block type. A signed declaration of intent about a future direction, attached to a small piece of work that demonstrates a first step. See §3.3, §4.4.

GUPP — Gas Town Universal Propulsion Principle. Persistent identity in Git plus a hook where work molecules get hung. Solves context-window death. See §5.6.

H

Hunter — Persistent programmatic daemon running on the worker’s hardware. Polls, bids, executes. ~300 lines of Python. See §5.3.

I

Integer Employment — One job, one company, binary. The historical model HOP replaces.

Inventory Universe — What you own and have access to: physical assets, credentials, relationships, hardware, software licences, geographic position. See §4.2.

M

Madogiwazoku — “The tribe that sits by the windows.” Japanese practice of keeping employees on payroll with status but no work. The cliff-versus-float anti-pattern HOP refuses by construction. See §6.5.

Merkle Root Anchoring — Periodic batch summary of chain state, written to a public timestamping authority. Provides trustless verification without per-block cost. See §8.6.

Mutex Posting — Work mode where first qualifying bidder claims and locks the bead. Default for time-sensitive logistical work. See §2.6.

P

Pull Model — Workchains do not assign work. They publish it. Workers (or their Hunters) pull work they are suited for. See §2.4.

Polecats — Gas Town’s ephemeral worker agents. Spawn, complete tasks, disappear. Persistent only via Git-backed hooks. See §5.6.

R

Recursive Decomposition — A bead can be claimed by a worker who immediately reposts decomposed sub-beads. Each level signs to its own worker’s Skillchain. Tax cascades transparently at every level. See §2.5, §6.4.

Reputation Universe — Inverted. Workers carry no reputation about themselves; reputation lives in stamps written by others. Workers carry the dual: stamps they wrote about others. See §4.2.

S

Sigstore-class — The reference architecture for cryptographically attested work units. HOP is to labour what Sigstore is to software supply chain. See §8.1.

Skill-Agent — LLM-driven reasoning engine that constructs bid curricula from the worker’s Skillchain. Also hunts for mentees in v0.2. See §5.1.

Skillchain — Worker-owned chronological biography of all character blocks accumulated across all chains. Sovereign, portable, never on platform. See §2.2.

Stake-as-Governance — Stake is rolling-average recent work quality plus accumulated chain-currency. Different stake levels grant different governance voices in the chain hierarchy. See §7.4.

Stamp — Validator-signed attestation of skill or capability demonstrated in a completed work event. Multiple stamps accumulate per character block. See §3, §5.5.

T

Three Cs — Beane’s Challenge, Complexity, Connection. The load-bearing properties of any environment that successfully transfers skill. Map onto growth blocks, recursive decomposition, and Beans respectively. See §4.4.

Town Mind — LLM-driven strategic poster. Generates work and posts it to the Workchain. Cognitive counterpart to the Hunter. See §5.4.

V

Validator — Shared protocol infrastructure agent. Verifies submitted work quality, issues stamps, identifies completions that qualify as Beans. Small LLM. See §5.5.

Vector-Space Proximity — Multi-dimensional distance metric across the unified embedding. The geometry that mentorship matching runs on. See §4.3.

W

Wasteland — Steve Yegge’s federation layer. Gas Towns connect through DoltHub. Launched March 4, 2026. See §8.7.

Winner-Takes-All Posting — Work mode where multiple workers attempt; best result wins; losing attempts may receive partial compensation. Default for creative or exploratory work. See §2.6.

Wisp — Ephemeral bead. Exists in the database with a hash ID but is not persisted to the permanent store. Vapor phase of matter for Gas Town work. Used for speculative bidding. See §8.3.

Worker-Agent — LLM-driven evaluator on the poster’s side. Evaluates incoming bids for capability, logistical fit, diversity, growth alignment, and constraint compliance. See §5.2.

Workchain — Institution’s chain of posted work and completion records. Owned and governed by an institution, cooperative, or task-issuer. See §2.1.

Z

Zone of Proximal Development — Vygotsky (1934). Tasks slightly beyond the learner’s current ability that scaffolding makes accessible. The developmental-psychology substrate beneath HOP’s growth engine. Bliżajaja — “nearest” — carrying social and cultural connotations English strips out. See §4.3, §4.4, §10.3.

§13 Concerns Log

This file is the canonical record of unresolved problems, design tensions, and v0.2 lanes for the HOP protocol. A specification that pretends to have all the answers is not soliciting comments. The concerns are organised by category. None of them are show-stoppers; all of them are real.

The concerns log is published separately from the protocol document by deliberate choice. The HTML spec presents what the protocol does; this file presents what we do not yet know. Reviewers should be able to scan the full set of unresolved problems without reading the entire spec.

A. Theoretical Objections

A.1 The Hirschman Tension

Costless exit may atrophy voice. Albert Hirschman (1970) argued that expanding choice reduces the incentive to complain — if you can always leave, you have less reason to fight to fix what’s broken. This is the strongest theoretical objection to the Forking Rule.

The protocol’s specific answer is that chain operators exercise voice on workers’ behalf because they fear forking. The information asymmetry that Hirschman worried about (exit-takers leaving silently) is collapsed by HOP’s data structure: chain operators can see exactly which workers’ Skill-Agents are evaluating forks.

This is plausible but unproven. v0.2 will need empirical data from operating chains to confirm whether the operator-voice mechanism actually works at scale, or whether forks proliferate without underlying chains improving. The literature on public-service quality decline suggests this is a real risk.

A.2 Substrate-Asymmetric Currency

Money works on humans because humans are thermodynamically open systems facing the free-energy principle; agents have no equivalent metabolic constraint. If HOP currency is substrate-neutral, it pools on the agent side without circulating because agents have nothing to spend it on.

The protocol does not yet have a clean answer. Candidates: - Agents-as-hosted-infrastructure-owned-by-humans (the agent is just a worker’s tool, currency passes through to the human owner) - “Agents join the bees” — no agent currency at all; agents work for free as part of the 99% commons - Agents earn currency that is automatically redirected to a commons (the chain’s basal-rate fund or dispute-resolution pool)

This is a v0.2 design lane.

A.3 The Growth-Arrow Claim is Structural, Not Yet Empirical

§4.4 argues that growth blocks plus Beans plus recursive decomposition produce upward motion at population scale. This argument is structural — given the primitives, growth is rewarded. The empirical claim that this actually produces upward motion in deployed systems requires data the Wasteland is generating now but is not yet sufficient to confirm.

B. Anti-Collusion and Sybil Resistance

B.1 Mentorship Laundering Across Generations

If A mentors B, B mentors C, C mentors D, each at low quality, A and B collect “downstream mentoring” Connection signals without genuine transfer occurring. Mitigation: the multiplier is quality-weighted by C’s settled outcomes, not count of mentees. Needs explicit specification.

B.2 Disadvantage Multiplier Gaming

Workers will rationally suppress their initial chain to look like worse bets and attract higher-multiplier mentorship payouts. Validators need to detect chain suppression by cross-referencing Workchains the worker has touched. The boot-block (§8.17) helps because it makes pre-HOP work history visible regardless of what the worker chooses to surface.

B.3 Bilateral-Consent Matching Collusion

Two workers can collude to surface each other in their respective top mentorship lists, manufacturing what looks like organic mutual interest. Mitigation: matching is run by chain infrastructure, not workers; workers configure preferences but not counterparties.

B.4 Reputation Cold-Start

New workers have written zero stamps about others, so their Reputation Universe is empty in both directions. Bootstrap mechanism: starter stamp-writing capacity allocated alongside the bootstrap currency grant. Plus the cold-start scrape (§8.17) populates initial reputation from public-ledger evidence.

B.5 Christiano Trust Matrix Computational Cost

The collusion-resistant trust matrix in the style of Christiano (2014) provides per-user performance guarantees independent of network size, but the matrix itself grows quadratically with the active mentorship graph. At chain scale (millions of dyads), keeping the matrix in memory is non-trivial. v0.2 needs to specify approximation methods (low-rank decomposition, sparse representation) that preserve the security guarantees.

C. Privacy and Cryptographic Concerns

C.1 Vector-Space Proximity Privacy

Vector-space proximity matching is the strongest privacy concern in the protocol. The matching algorithm reveals to mentors who their “near” matches are, which is implicitly a map of who-is-like-whom across many dimensions. More sensitive than current platform data.

Full mitigation requires locality-sensitive hashing and homomorphic distance computation; v0.2 may need to operate with chain-level access controls and explicit consent for being-found-as-a-mentee, with full ZK matching as v0.3.

C.2 Group Vector Privacy

A team’s group vector reveals who works with whom; this is sensitive even when individual character blocks are abstracted. Mitigation candidates: - Group vectors private to chain members - Aggregated to team-class rather than naming individuals - Requiring all members’ consent to reveal

C.3 Bean Chain Longitudinal Vector Exposure

A worker whose vector trajectory is publicly readable on a Bean Chain has had years of growth data exposed. v0.3 cryptographic problem: settlement on encrypted vectors with comparison done in zero-knowledge, where only the direction-aligned-or-not signal is public.

C.4 Validator Transfer-Verification Privacy Boundary

Beans only mint when the Validator can read the mentee’s Skillchain to verify acquired capability. Either: - Build Validator-as-trusted-party with auditable access, or - Use ZK proofs that the mentee’s skill embedding shifted in the relevant direction without revealing the embedding itself

C.5 Honest-Abstraction Assumption

The “abstraction at signing time” claim assumes the institutional agent is honest. If CBA’s protocol-layer agent emits a misleading abstraction, the dual signature attests something false. Mitigation: institutional-agent code is open-source and auditable; institutions stake reputation on faithful abstraction; periodic audit by Validators.

D. Engineering and Operational Concerns

D.1 Embedding Model Stability

Vector measurement assumes embedding stability across years. If the embedding model that produces V₁ differs from the one producing V₃, trajectory comparisons are invalid. Solution: each Bean Chain pins to a versioned, frozen embedding model; matching done in that frozen space; migration to newer models requires explicit re-embedding with documented translation.

D.2 Measurement Window Hostility for New Chains

24-month measurement windows are operationally hostile to chain bootstrapping. New chains have no settled Beans for two years. Mitigation: shortened measurement windows (3–6 months) with reduced multiplier for the first cohort, graduating to full window as the chain matures.

D.3 Cost Estimate Uncertainty

The 8–15% chain operating-cost estimate in §6.8 is genuinely uncertain. Real costs at scale are hard to predict from first principles. v0.1 should publish cost methodology; first chains report actual numbers; v0.2 incorporates the data.

D.4 Fork Legitimacy Bootstrap

A fork starts with zero workers, zero validators, zero dispute history. Even if its governance is better, network effects favour the incumbent. Mitigation: federation treaties between forks and originals can preserve cross-chain reputation portability during the bootstrap period, then settle into independence as the fork matures. Needs explicit protocol support.

D.5 Chain Bloat Operational Burden

§8.15 specifies compaction snapshots, subchain pruning, and branch archival. The operational discipline to actually run these processes regularly is non-trivial. Chains that fail to manage bloat will see query times degrade and storage costs grow. Need clear automation guidelines and reference implementations.

D.6 DAG Conflict Resolution Latency

Stake-weighted voting on conflicting blocks adds latency between block proposal and chain inclusion. For high-throughput chains (Sydney rideshare doing thousands of completions per minute), this latency is operationally significant. Mitigation: most blocks aren’t conflicting; conflict resolution only kicks in when actual conflicts are detected; happy-path latency is one round-trip.

E. Governance and Regulatory Concerns

E.1 Government Bean Political Capture

Government Bean eligibility predicates can be used for political capture. A government with bad eligibility criteria (gerrymandered priority skills, ideologically narrow direction vectors) can distort chain growth even without owning the chain. The Forking Rule mitigates but does not eliminate this. Mitigation: chains publish lists of accepted government depositors and reject deposits from sources whose criteria they find objectionable.

E.2 Regulatory Framing Asymmetry

The deferred-comp-with-clawback regulatory framing works in regulated industries (banking, finance) but not informal ones. Bean Chain mechanisms may need substrate-specific rule sets per chain. CBA can run strict clawback; the Sydney rideshare cooperative may not have that legal apparatus and runs only the discount-confirmation half (positive feedback only, no clawback).

E.3 Bean Chain Federation Aggregation

Bean Chains as super has a federation problem. Australian super is a single national system; Bean Chains will be many, federated, sometimes overlapping. Aggregating positions across multiple Bean Chains into a single skill-superannuation balance is non-trivial. Probably the worker holds positions in multiple Bean Chains the way a person holds multiple super accounts and consolidates manually.

E.4 IFRS Recognition Lag

The “balance sheet asset” framing for company-held Beans is a financial-accounting standards problem. GAAP and IFRS do not currently have a category for “staked deferred-dividend mentorship rights.” v0.3 lobbying position: get Bean-Chain holdings recognised under IFRS as a measurable intangible asset.

E.5 Planetary Root Governance

The “if earth/ is compromised, sol/ mints earth_v2/” hand-wave (§7.1) needs an actual social mechanism. Candidates: multi-signature threshold, ICANN-style international consortium, on-chain governance vote. v0.1 honestly punts; v0.2 must commit.

E.6 Witness Capture

The Witness role (§8.13) is positioned as neutral structural-integrity infrastructure, but a malicious or captured Witness could selectively reject blocks from disfavoured workers. Mitigation: multiple Witnesses per chain, with conflict between Witnesses surfaced as a chain-level dispute. v0.2 needs to specify the multi-Witness consensus mechanism.

F. Mechanism-Interaction Concerns

F.1 Disadvantage Multiplier × Vector Proximity Equity

The disadvantage multiplier and vector-proximity metric interact in complex ways. Mentors will rationally seek high-disadvantage AND high-proximity, which means the protocol concentrates mentorship into specific cultural pipelines (senior-Sydney-suburbs-banker → junior-Sydney-suburbs-banker, both via TAFE). This may be correct — it’s how skill transfer historically works at scale — but has equity implications worth examining. The Bangalore kid mentored by a Stanford PhD is the unicorn outcome, not the typical one.

F.2 Group Vectors vs Recursive Decomposition Tension

When a $10k bead is decomposed by a winning team, who carries the group vector for the integrated work? The team lead? The whole team? Each pairwise interaction within the team? Unspecified and will matter once teams form routinely.

F.3 Three Cs Unequally Instantiated

Beane’s three Cs are unequally instantiated in the protocol. Challenge and Complexity are byproducts (growth blocks happen to challenge, decomposition happens to expose complexity); only Connection is explicitly forced via Beans. If the Bean mechanism degrades, all three Cs degrade with it because there’s no expert-novice bond left to operate within. Beans are more load-bearing than they appear.

F.4 Substrate-Asymmetric Growth

Substrate-asymmetric currency interacts with the upward engine. Agents don’t have a zone of proximal development in the human sense; their “growth” is fine-tuning, RAG augmentation, or replacement by a successor model. The growth-block primitive may need a substrate-specific definition.

F.5 Mutex vs Winner-Takes-All Dispute Differences

§2.6 distinguishes mutex from winner-takes-all postings, but the dispute mechanics differ in ways not yet fully specified. A mutex dispute is binary (did the worker complete or not); a winner-takes-all dispute may involve multiple submissions and disputed evaluation. v0.2 needs separate dispute-resolution flowcharts for each mode.

G. Adoption and Sequencing Concerns

G.1 v0.1 Spot Beans vs v0.2 Deferred-Dividend Beans

The spot-Bean failure mode (mentors don’t actually care if mentees grew) is bad enough to motivate v0.2. The deferred-dividend mechanism is much more complex and requires multi-year measurement infrastructure. Sequencing question: ship v0.1 in the Wasteland now, instrument heavily, watch failure modes emerge, bring v0.2 in mature; or skip v0.1 for chains that will operate at Beane’s actual time-scale (CBA). Both are defensible; they should not run simultaneously.

G.2 Super Framing Surface-Area Trade-off

The super framing changes HOP’s surface area. Politically powerful for ministers and CFOs; potentially confusing for unions who rightly worry that anything resembling a financial instrument tends to get captured by financial intermediaries. The mitigation is that the underlying asset is people’s growth, not money — but the framing must be paired carefully with dignity-floor and worker-sovereignty language so it doesn’t read as financialisation of human capability.

G.3 Open-Protocol vs Institutional-Anchor Cold-Start

The right pattern (Matrix as the contemporary case study) is institutional-sovereignty anchoring, not gig-economy challenger competition. CBA, then peer institutions, then state government, then individual workers ride in on infrastructure already trusted by signing keys. This belongs in v0.1 as §11 Adoption Path, which has been added.

G.4 Cold-Start Identity Resolution Privacy

The cold-start scrape (§8.17) creates Skillchains for users before they opt in. This is technically legitimate (the source data is public) but may feel surveillance-like to users discovering their pre-built profile. Mitigation: opt-in is required to claim the chain; the existence of a pre-built chain does not constitute a user account; users can request deletion before claim.

G.5 LinkedIn Network-Effect Bootstrap

Even with the cold-start scrape, HOP has to overcome LinkedIn’s billion-user network effect. The protocol’s institutional-first adoption path (§11) is the right answer, but the timeline from “first CBA branch on Workchain” to “displacing LinkedIn for Australian banking” is plausibly five-plus years.

H. Open Questions Not Yet Categorised

H.1 What Is the v0.1 Reference Implementation Stack?

Beads on Dolt is real. Gas Town on top of Beads is real. The Wasteland federation layer is real. But the Skill-Agent / Worker-Agent / Hunter / Town Mind / Validator class split has been specified at protocol level without a single canonical reference implementation that ties them together. Steve’s Gas Town has Mayor / Polecats / Deacon; Matt’s SkillBench has its own architecture. v0.2 needs to either: - Designate one of these as the canonical reference implementation - Ship a new reference implementation that explicitly demonstrates the agent-class split - Or accept that “reference implementation” is a federation of compatible projects and publish the conformance test suite

H.2 Where Do Disputes Actually Get Resolved?

The protocol specifies that chains declare dispute-resolution mechanisms in their Anchor Block. In practice, this might be: - A single human arbitrator (cheap, fast, doesn’t scale) - A panel of stake-holding workers (slow, expensive, possibly biased) - A federated dispute-resolution chain that handles disputes for many Workchains (efficient, but introduces a dependency) - Escalation to courts of competent jurisdiction (works for high-value disputes only)

v0.1 punts on this; v0.2 should provide reference templates for each pattern.

H.3 What Happens When an Embedding Model Is Compromised?

If the embedding model used to compute vector-space proximity has a discovered backdoor or systematic bias, all matching done in that embedding space is suspect. v0.2 needs a procedure for: - Detecting the compromise - Re-embedding affected chains in a successor model - Translating outstanding Bean Chain settlements to the new embedding space - Preserving worker reputation across the transition

H.4 How Are Closed Namespaces Bootstrapped Internationally?

§7.2 describes closed namespaces (e.g. sol/earth/governments/australia/identity/) where only the named authority can write. But the international procedure for establishing such namespaces — getting AHPRA, the German government, the EU, China to claim and operate their respective namespaces — is unspecified. This is partly a governance problem (who maintains the namespace tree?) and partly a diplomatic one (how do you get sovereign nations to opt into the same protocol?).

I. Wasteland Open Questions — Resolved Upstream

Steve Yegge’s “Welcome to the Wasteland” post flags two open questions about the Wasteland’s reputation primitive that HOP’s broader framework has answers to. These are recorded here so they can be discussed openly in the federation conversation rather than left as unresolved Wasteland-level issues.

I.1 “Who Owns the Stamps”

Yegge writes that ownership of stamps is unresolved: “We have solutions; it’ll all get worked out”. The HOP framework resolves this as three-way custody, not single-owner:

The subject does not own them (no self-attestation per the Yearbook Rule, §14.6).

The author retains a record of having written them (the dual-carry; what the worker carries about themselves is the stamps they wrote about others, §14.1).

The chains store them (queryable by anyone who trusts the chain).

No single party can repossess them or unilaterally rewrite them. The author cannot delete a stamp once issued; the subject cannot edit a stamp written about them; the chain cannot redirect a stamp to a different subject. The cryptographic structure (dual-signed, content-addressed, anchored to specific completion) enforces the three-way custody at the data layer.

This composes naturally with the Wasteland’s existing schema. No change to the running implementation is required. The reframe is that the schema already implements three-way custody; what was missing was the protocol-level statement of why it works and what alternative ownership models it rules out.

I.2 “Personal vs Work Identity Globalness”

Yegge writes: “the personal/work identity — right now your identity is global across all Wastelands”. The HOP framework resolves this through the namespace hierarchy (§7) and the v0.2 BBS+ selective disclosure layer (§3.5):

The worker’s root identity lives at sol/earth/identity/ and is global. It is the persistent keypair that anchors all of the worker’s chain operations.

Chain-presented identities are derived from the root identity, bound to specific namespaces, and may be cryptographically unlinkable from each other to outside observers.

Sera’s CBA work signs to her bank-namespace pseudonym; her community-organisation work signs to her cooperative-namespace pseudonym; her personal-creative work signs to a third pseudonym. All three are derived from her root identity, but the cryptographic linkage requires either her consent or a court order with key-derivation authority.

BBS+ derived proofs (v0.2) allow her to prove “I am the same person across two of these pseudonyms” selectively — to a verifier she chooses, for a specific transaction — without globally revealing the linkage.

This is the same pattern Tor’s hidden services use for service identity, applied to worker identity. The root is global; the presented identities are local; the linkage is selective. Workers control their own un-correlation across contexts.

The Wasteland’s current single-global-identity model is a reasonable v0.3-phase-1 choice (it ships, it works, it does not require additional cryptographic infrastructure) but the longer-term answer is the BBS+ pseudonym derivation. v0.3 phase 2 or v0.4 should ship this.

v0.2 Design Lanes (Summary)

For the v0.2 specification, the priority work items derived from this concerns log are:

Bean Chain measurement infrastructure — the deferred-dividend mechanism and longitudinal vector measurement

BBS+ selective-disclosure cryptography — replacing v0.1 abstraction-at-signing-time, also enabling pseudonym derivation per §I.2

Group Vectors privacy mechanism — protecting team-collaboration data while preserving matching utility

Planetary root governance — committing to a specific social mechanism for protocol-level disputes

Cross-chain skill-vector translation — formal cross-chain attestations of skill-score equivalence

Substrate-asymmetric currency resolution — picking one of the candidate answers and shipping it

Multi-Witness consensus — the structural-integrity layer needs hardening against Witness capture

ZK matching primitives — for vector-space proximity privacy at scale

Multiple government co-deposit aggregation — federal/state/supranational Bean Chain settlement

Reference implementation conformance suite — what does it mean to be a HOP-conformant chain

v0.3 Design Lanes (Summary)

For the v0.3 specification, the reputation surface and its dependents:

The full reputation tensor — multi-dimensional, chain-configurable, observer-relative evaluation

Trust-filtered query as protocol primitive — every reputation query takes a trust_set parameter

Stamp-graph topology analysis — collusion detection as queryable protocol operation

The Revocation Cascade with Antibody Memory — distributed sanctions for root-level betrayal, no central authority required

Clean Margins severity-tiered response — leaf/branch/root distinction enforced through the protocol

Capability as multiplicative product — the integrated measure of fitness across the Five Universes

Bridge-Town reputation accumulation — special protocol position for entities trusted across opposed clusters

The True-Enemy preference order — weighting hostile-honest attestations above friendly-cheap ones

Pseudonym derivation from root identity — selective unlinkability of chain-local presented identities (resolves Wasteland §I.2)

Worked-example test cases — Sera, the Well case, and other anonymised real-person stories as the regression test suite for the protocol

This list is the door through which v0.2 and v0.3 enter. Comments, objections, additional concerns, and proposed mechanisms are welcomed and expected. The protocol’s strength is the breadth of attention it receives, not the polish of its first specification.

§14 Reputation

Status: This section specifies the reputation architecture for v0.3 of the protocol. v0.1 ships with the dual-signature attestation primitive (§3); v0.2 adds BBS+ selective disclosure and the Bean Chain longitudinal-measurement layer (§6.3.5). v0.3 is where reputation is given its full formal treatment as a first-class protocol surface — with the multi-dimensional stamp, the yearbook rule, the reputation tensor, the trust floor, and the federated stamp graph. The Wasteland is already operating a subset of this surface in production; v0.3 of HOP specifies the full design and folds the Wasteland’s running schema in as the canonical reference implementation for the production-ready slices.

This section pulls from three canonical sources:

Steve Yegge’s “Welcome to the Wasteland: A Thousand Gas Towns” (Medium, March 2026) — the operational implementation already in production. Yegge writes: “The Wasteland creates a permanent, evidence-traced record of your contributions” and the core principle “work is the only input, and reputation is the only output”.

gastown/docs/WASTELAND.md at github.com/gastownhall/gastown — the production schema and command-line interface for the running system. Seven tables in wl_commons (rigs, wanted, completions, stamps, badges, chain_meta, _meta), MySQL-protocol-compatible, federated via DoltHub.

The Inter-Town Communication Constitution — internal HOP design doc that specifies the philosophical and topological foundations: the yearbook rule, the reputation tensor, the trust floor, the true-enemy preference order, the $Variable substrate-neutrality, and the EXCHANGE_TOPOLOGY in which reputation is structurally excluded from direct exchange.

The Wasteland is producing the canonical operational answers; the Inter-Town Constitution is producing the canonical philosophical foundations. They are not in conflict. The Wasteland is what the philosophy looks like when it ships.

14.0 The Agent-Negotiation Reframe — Bid-and-Sell Applied to Reputation

Before specifying the v0.3 reputation surface, it is worth naming what makes it structurally different from any prior reputation system, including the Wasteland’s current implementation.

HOP’s labour-allocation layer runs on agent negotiation. A worker’s Skill-Agent (§5.1) constructs a bid curriculum from the worker’s Skillchain; the poster’s Worker-Agent (§5.2) evaluates the curriculum against the posting’s requirements; bid acceptance is a cryptographic mutex that locks the work. The agents do the search, the matching, the cross-checking, and the negotiation. The humans (or rigs, or institutions) configure the agents’ preferences and trust them to act within those preferences. This is the bid-and-sell pattern.

v0.3 applies the same pattern to reputation. When a chain needs to know another entity’s reputation — to evaluate a bid, to consider a federation treaty, to assess a candidate mentor, to decide whether to recognise a cross-chain skill stamp — it does not read a flat number. It dispatches an agent that runs a reputation query against the network. The agent:

Filters by the querier’s trust set (which chains’ attestations does this querier honour?)

Weights by the querier’s tensor priorities (which dimensions of the multi-dimensional stamp matter for this decision?)

Cross-checks the stamp-graph topology (is this reputation derived from a small mutually-reinforcing cluster, or does it have outside critics?)

Returns a structured answer specific to the context of the query

This is reputation as a negotiated, computed property rather than a published, static one. Two different observers querying the same subject receive different answers — not because the data is inconsistent, but because their evaluation lenses differ. Both answers are correct within their context. There is no universal reputation, only trust-filtered queries.

Why This Patches Westphalia

The Peace of Westphalia (1648) established the modern primitives for parties who disagree fundamentally about important things continuing to occupy the same physical space without escalating to violence: territorial sovereignty, non-interference in internal affairs, recognition through treaty. It worked for 377 years and is now visibly failing — at the international level, at the corporate level, at the personal level. The Westphalian primitives were not wrong; they were undersized for the substrate they now operate on.

The Westphalian failure mode was that trust between states was binary and personal — diplomatic recognition was either granted or withheld, and the work of maintaining recognition was carried by individual ambassadors meeting individual sovereigns. There was no mechanism for testing whether participants were actually keeping their word, no mechanism for computing the consequence of a violation, no mechanism for distributing the response through the network. When a sovereign violated the agreement, the response was either war or no response at all — there was no middle band of “compute the consequence, distribute it through the network, let the cascade do the work.”

The agent-negotiation reputation layer is structurally a patch to this failure mode. The thing Westphalia could not compute — does this sovereign actually act consistently with what their friends say about them, and what their enemies say about them, and what their behaviour shows over time? — is what HOP’s reputation queries compute automatically every time an agent dispatches one. Trust becomes a computational substrate, not a diplomatic ritual.

This generalises. The same pattern that lets a Workchain decide whether to recognise an applicant’s skill stamps from another chain is the pattern that lets two ideologically-opposed nation-states federate on labour mobility while disagreeing about everything else. The same pattern that protects Sera’s chain from being permanently invalidated by the Jehovah’s Witnesses’ negative attestations is the pattern that lets ASEAN states cooperate economically across genuine political differences. The scale changes; the pattern does not.

The Core Move: Concept-Attacks Cheaper Than Personality-Attacks

The reputation layer is the protocol’s concept-vs-personality firewall. Every reputation primitive specified in this section is a piece of that firewall:

The multi-dimensional tensor (§14.2) prevents hot-take character verdicts by requiring evaluation along independent axes.

The yearbook rule (§14.6) prevents self-attestation by database constraint.

The trust-filtered query (§14.8) prevents echo-chamber consensus from being mistaken for universal recognition.

The stamp-graph topology check (§14.15) prevents collusion rings from manufacturing reputation through mutual flattery.

The true-enemy preference order (§14.9) weighs hostile-but-honest attestations higher than friendly-but-cheap ones.

The severity-tiered response (§14.16, Clean Margins) ensures leaf disagreements get noted, branch failures downgrade trust, and only root betrayals trigger excision. Most disagreement does not even register as reputation-affecting.

The revocation cascade with antibody memory (§14.16) lets the network respond to genuine betrayal without requiring a central authority, while preserving the record so that the same betrayal cannot recur unnoticed.

Together these primitives make personality-attacks structurally unprofitable. Negative attestations only land when their authors are in the querier’s trust set, when the stamp is anchored to specific evidence, and when the stamp-graph topology does not show collusion. The protocol does not ban personality-attacks; it makes them economically irrational.

By the same gradient, concept-attacks become productive market behaviour. Launch a competing chain at a lower tax rate, watch workers migrate, force the incumbent to improve or lose. Disagreement becomes a fork; the fork either thrives or doesn’t; the market resolves the question without anyone needing to be silenced or excluded. The Forking Rule (§6.7) is the concept-attack channel; the reputation layer is the personality-attack firewall. They compose.

The economic gradient pushes everyone toward concept-attacks because that is where the rewards are. Same shift as Yegge’s framing on cheating: “designed to make fraud unprofitable, not impossible”. The protocol does not enforce civility; it makes civility the economically rational behaviour and personality-attack the structurally unprofitable one.

This is the post-Westphalian equilibrium. Not “we agree on everything” — that is impossible and undesirable. Not “we agree to disagree politely” — that is the Westphalian failure mode where false friendship masks real betrayal. The new equilibrium is: we disagree fiercely about concepts, in public, with full record, and we cooperate fully on infrastructure, because the protocol makes both behaviours rational simultaneously.

The subsections that follow specify the primitives in detail. The reader who has internalised this reframe will see that each primitive is a piece of the same answer to the same question: how do parties who disagree fundamentally about important things continue to occupy the same physical space without escalating to violence, when the substrate of communication and coordination is computational rather than diplomatic? The answer is computable trust, distributed adjudication, and severity-precise response.

14.1 The Foundational Inversion

In every other universe of the character sheet — Skills, Work, Currency, Inventory, Group Vectors — the worker carries their own chain. Reputation is the singular exception, and the exception is the entire point.

A worker carries no reputation about themselves. Reputation lives only in stamps that others have written. What the worker carries is the dual: the stamps they themselves have written about others.

This inversion is not a policy choice; it is a structural property enforced at the data layer. In the Wasteland implementation, the constraint is encoded as a SQL CHECK on the stamps table: an author cannot be the subject. The yearbook rule is database-level, not norm-level. Yegge frames the principle thus: “Your reputation is what others write about you, not what you claim about yourself”, and contrasts it explicitly with self-reported reputation systems where everyone curates their own page.

The Inter-Town Constitution states the same principle as philosophy:

The Inversion: You cannot write in your own yearbook. You can only sign others’ yearbooks.

Your reputation = Σ(attestations_from_trusted_sources) Your value_chain = geometry(your_stamps)

∴ To know someone: read their stamps, not their bio.

The protocol-level implication: every reputation query is a network query. When the protocol asks “what is Sevda’s reputation?”, it does not look up a row in Sevda’s profile. It walks the graph of chains Sevda has touched, filters by chains the querier trusts, and aggregates the attestations. Sevda has no say in what is returned. She cannot delete bad stamps; she cannot inflate good ones. Her only reputation signal that she herself controls is who she has stamped, which reveals her values rather than her performance.

This also resolves Steve’s open question from the Wasteland post: “Who owns the stamps. We have solutions; it’ll all get worked out”. The answer is three-way custody, not single-owner: the subject does not own them (no self-attestation); the author retains a record of having written them (the dual-carry); the chains store them (queryable by anyone who trusts the chain). No single party can repossess them or unilaterally rewrite them.

14.2 The Multi-Dimensional Stamp

The stamp is the atomic unit of reputation. It is not a scalar score and it is not a binary pass/fail. The Wasteland post is explicit: “A stamp is a multi-dimensional attestation: quality, reliability, creativity, each scored independently”.

Wasteland Production Schema (v0.3 Canonical)

The stamps table in wl_commons carries five fields beyond the standard relational keys (author, subject, evidence anchor, timestamps):

valence — JSON vector of independently-scored dimensions. The Wasteland defaults to {quality, reliability, creativity}, but the JSON column means chains can extend the dimension set without schema migration.

confidence — how sure is the author of their attestation? A maintainer who reviewed the work line-by-line gets higher confidence than one who spot-checked.

severity — is this a leaf task or a root architectural decision? A stamp on a typo fix carries less weight than a stamp on a system redesign. Severity is the structural-importance multiplier.

author — who issued the stamp. Carried back to the author’s chain as well as forward to the subject’s reputation network.

subject — who the stamp is about. Constrained: CHECK (NOT(author = subject)).

Every stamp is anchored to a specific completion record, which is itself anchored to a specific wanted item. The Wasteland post:

“The stamp is anchored to the specific completion — the specific evidence — so reputation is always traceable back to real work”.

This is the Sigstore-class property applied to reputation. Every reputation claim is cryptographically traceable through the chain back to its evidentiary basis. No claim is free-floating; no claim is unattested.

The Reputation Tensor (v0.3 Extension)

The Wasteland’s three-dimensional stamp is the production starting point. The Inter-Town Constitution proposes a more general formulation: every action emits a multi-dimensional signal and every observer evaluates that signal on their own independent axes.

The same action may be read differently by different observers:

action: Town_A → Town_B: "Your architecture is wrong."

Town_B.eval (the subject of the criticism):

  leaf_tribal:    -20   (they attacked us)
  trunk_honest:   +30   (they said what they see)
  root_intent:   +15   (they want the project to work)

Town_C.eval (an ally of B):

  leaf_tribal:    -10   (attacked our friend)
  honest_index:   +25   (they're straight shooters)

Town_D.eval (neutral observer):

  competence:    +20   (they have standards)
  trust_floor:    +35   (what they say, they mean)

The action is one event. The reputation effect is multiple, observer-dependent, and positional. No universal reputation exists. There is no scalar score that captures “what Town_A is.” There is only the geometry of stamps as read through each observer’s trust set.

v0.3 makes the tensor explicit by allowing chains to declare their own valence dimensions in their Anchor Block (§7.3). A construction chain may stamp on safety_diligence, code_compliance, subbie_coordination; a research chain may stamp on theoretical_novelty, experimental_rigor, reproducibility. The protocol does not impose a fixed taxonomy; it provides the primitive of multi-dimensional attestation and lets chains specify their own dimensional vocabulary. Cross-chain reputation queries either project into a shared subspace or carry the chain-local dimensions through to the querier with provenance attached.

14.3 The Four-Stage Lifecycle

The Wasteland defines the canonical lifecycle for any work item, and v0.3 of HOP adopts it directly:

Open — the work has been posted to the wanted board. No one has claimed it.

Claimed — a rig has marked the work as theirs. Other rigs can see who’s working on it.

In review — the worker has submitted evidence of completion. A validator is examining it.

Completed — a validator has stamped the work. The completion is permanent; the stamp is issued.

The Wasteland post explains: “When a rig claims an item, it’s marked as theirs — other rigs can see who’s working on what, preventing duplicate effort”.

There is also a fifth path: open-bounty work, where no one claims and multiple rigs work in parallel. The first submission a validator stamps closes the item; other submissions become orphan completions, preserved but not stamped. This is the winner-takes-all mode (§2.6) operationalised at the schema level.

14.4 The Trust Ladder

The Wasteland trust model is a four-level ladder. Trust governs what a rig is allowed to do; trust is earned through stamped completions.

Per the WASTELAND.md schema:

Level	Name	Capabilities (planned)
0	Registered	Browse, post
1	Participant	Claim, submit completions
2	Contributor	Proven work history
3	Maintainer	Validate and stamp others’ work

The Wasteland post:

“Trust levels gate what you can do”. “This creates a natural apprenticeship path: do good work, get stamped, eventually become someone who stamps others”.

The ladder is the protocol-level mechanism for the apprenticeship gradient that Beane’s three Cs require (§4.4). New rigs are mentored by stamped maintainers; eventually the new rigs accumulate enough validated work to themselves become maintainers; the next generation finds them. The reputation system is the apprenticeship system. They are not two layers; they are the same layer viewed from two angles.

v0.3 extends the ladder in two ways:

Per-chain trust levels. A worker may be a Maintainer on the CBA chain but only a Participant on the Sydney Ride-Share chain. Trust is not global; it is chain-local. Cross-chain trust can be granted via federation treaties (§7.5) that mutually recognise stamping authority across chains, but the default is non-portable.

The Witness/Maintainer split. The Wasteland’s Maintainer role does both work-quality validation and chain integrity validation. At scale these separate (§8.13): the Witness validates blocks (does the prev_hash point to a valid prior block, is the signature valid, is the content hash correct), the Maintainer validates work (is the deliverable good, does it meet the standard). v0.3 introduces the formal split with chain-configurable role-assignment.

14.5 The Structured Reputation Profile

A worker’s reputation is not a single number. The Wasteland post lays this out precisely:

“Over time, a rig builds a profile: they’re great at Go but mediocre at frontend. They’re highly reliable but not particularly creative. They crush small tasks but struggle with epics”.

The reputation is a structured, evidence-backed work history. It can be queried along many axes: by skill, by domain, by stamp dimension, by chain, by time period, by validator identity. A Worker-Agent (§5.2) evaluating bids for a posting can ask precisely the question that matters: “show me applicants with ≥5 stamps on python from sol/earth/engineering/ Maintainers in the last 24 months, where the average reliability valence exceeds 0.8.”

This composability is what makes the reputation system useful rather than ornamental. LinkedIn’s reputation is a list of self-asserted titles and a count of endorsements; the structured query above is impossible. The Wasteland reputation is queryable as a database because it is a database.

Recent Trend as First-Class Field

Reputation must show direction. A worker improving from 0.7 to 0.9 over twelve months is a different bet than one declining from 0.95 to 0.85, even though the current average is similar. v0.3 surfaces the recent_trend signal as a first-class derived field, computed from the rolling window of recent stamps. The Worker-Agent can weight trend explicitly when evaluating bids; chains can publish trend in their reputation queries.

Redemption Arcs

A failure is not a permanent mark. The HOP-internal spec made this explicit: “Bad performance can be overcome: Failures recorded but redeemable. New good work proves growth. Not permanent social credit score”. v0.3 formalises the redemption arc as a queryable property: a failure followed by demonstrated growth in the same domain becomes evidence of capability, not evidence of incapacity. The chain incentivises recovery, not punishment.

This is the structural difference between HOP and a social credit system. A social credit system is monotonic: bad acts accumulate, never decay, never redeem. HOP is float: bad acts dim the worker’s signal but do not cliff it (the Basal Rate Law, §6.5), and new good acts re-light the signal directly.

14.6 The Yearbook Rule, Enforced at the Database Level

The Wasteland’s implementation of the no-self-attestation rule is the cleanest possible: it is a SQL CHECK constraint on the stamps table.

-- From wl_commons stamps table definition

CHECK (NOT(author = subject))

The yearbook rule is not policy. It is not norm. It is database invariant. An INSERT that violates it is rejected at the database engine. The constraint propagates with the schema across all DoltHub forks, all federation peers, all derived chains. No implementation of the Wasteland schema can break the yearbook rule without first rewriting the schema, which is a public, visible, signed act.

This is the right level for this invariant. Yegge’s framing makes the principle vivid:

“You can sign other people’s pages, but you can’t sign your own”. “This is the fundamental difference between the Wasteland and LinkedIn”.

v0.3 extends the database-level enforcement to a wider set of integrity constraints, all enforced at the schema level rather than at the application level. The reputation system gets to be safe-by-construction rather than safe-by-discipline.

14.7 The Universe Topology — Why Reputation Has No Direct Exchange

The Five Universes (Skills, Work, Currency, Inventory, plus Group Vectors as the v0.2 sixth) sit on the character sheet. The Inter-Town Constitution maps the exchange topology between them:

EXCHANGE_TOPOLOGY:

  🎯 ↔ ⚡        Skills prove through Work
  ⚡ ↔ 💰        Work converts to Currency
  💰 ↔ 📦        Currency buys Inventory
  📦 ↔ 🎯        Inventory enables Skills (tools)

  🪞 ↔ ???       Reputation: NO DIRECT EXCHANGE

Reputation sits outside the ring. There is no direct trade between reputation and anything else. The Inter-Town Constitution is explicit:

Reputation cannot be bought (💰 → 🪞 ❌) Reputation cannot be transferred (🪞 → 🪞 ❌) Reputation cannot be self-minted (self → 🪞 ❌)

Reputation can only be emitted (you stamp others, which reveals your values), received (others stamp you, which reflects your work), or survived (Clean Margins — i.e. the dispute and integrity layer — does not revoke you).

This structural property has a critical legal/regulatory consequence: reputation cannot be securitised. A holder cannot transfer their reputation to another party for value; a third party cannot create a derivative instrument on the back of someone’s reputation. This places the reputation primitive outside the surface area of financial regulation. It is not a security, not a token, not a tradable asset. It is a measurement of demonstrated capability, held in trust by the network.

By contrast, Beans (§6.3) — which are the mentorship subset of beads — are transferable within their narrow definition (the mentor’s discount on conversion can be staked, settled, clawed back). Beans are deferred-comp-with-clawback, which is a regulated category. Reputation is not. The architecture cleanly separates the two, so the regulatory framing for each is unambiguous.

14.8 The Reputation Network — Trust-Filtered Queries

There is no universal reputation. There are only trust-filtered queries.

The Inter-Town Constitution states this as the YEARBOOK_RULE:

yearbook(Town_A) = [ stamps WHERE
    subject == Town_A AND
    author IN observer.trust_set ]

When an observer queries Town_A’s reputation, the network returns only the stamps written by authors the observer trusts. Two different observers query the same subject and receive different answers — not because the data is inconsistent, but because their trust sets are different. This is intentional and correct. Reputation is positional in value-space, not absolute.

This composes naturally with the chain hierarchy (§7.4). A CBA-bank query against Sevda’s reputation pulls stamps from the banking chain and adjacent regulated industries. A community-organisation query against Sevda’s reputation pulls stamps from her volunteer work, her language-skills attestations, her social-services contributions. Both queries are valid. Both produce true reputation. The two answers are different.

The Worker-Agent (§5.2) operates inside this topology by selecting which trust set to query the reputation network against. The trust set is configured by the poster — explicitly or by reference to a federation treaty — and the Worker-Agent honours that scope.

Cross-Chain Skill-Vector Translation

A 7.2 software-engineering stamp on the Accenture chain does not auto-translate to 7.2 on the public engineering chain. Different chains have different stamping standards; different validators have different rigour profiles. v0.3 introduces a cross-chain translation layer: the Accenture chain can sign a translation attestation 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, and a Worker-Agent querying the public chain’s reputation can choose to honour the translation or not.

This is structurally similar to currency federation (§6.6): there is no universal exchange rate, only bilateral and multilateral translation agreements between chains. The chains that participate in many translation treaties become the bridge towns, which is itself a reputation-bearing position (§14.13).

14.9 The True-Enemy Preference Order

The protocol provides a reading rule for how to weight attestations. The naive view is: stamps from your friends are more trustworthy than stamps from your enemies. The Inter-Town Constitution argues the opposite:

Listen to what their ENEMIES say. If enemies say “they’re honest”, BELIEVE IT.

enemy_attestation.weight > friend_attestation.weight

The reasoning: a stamp issued at cost to the author carries more signal than a stamp issued cheaply. A friend stamping a friend is cheap; the cost of being wrong is low. An enemy stamping an enemy with a positive attestation is expensive; the cost of saying something true about someone you dislike is the cost of admitting they have a quality you cannot deny. The expensive stamp is the honest one.

This produces the four-quadrant preference order:

TRUE FRIEND — aligned and honest (rare and valuable)

TRUE ENEMY — hostile and honest (valuable, more trustworthy than ambiguous friends)

FALSE ENEMY — hostile and dishonest (predictable, manageable)

FALSE FRIEND — aligned and dishonest (dangerous; the worst position because you cannot see the knife)

The Wasteland’s cheating-detection — that “collusion rings have a distinctive topology — lots of mutual stamping, sharp boundaries, no outside critics” — is the operational form of this principle. A reputation built only on friend-stamps and zero enemy-stamps is structurally suspect, even if every individual stamp is technically valid. The geometry of the stamp graph reveals the collusion that no individual stamp betrays.

v0.3 specifies this as a queryable reputation-weighting function. A Worker-Agent can request “Sevda’s reputation, weighted by author-distance,” where author-distance is computed across the chain’s stamp graph as the geodesic distance from the author to the subject in the value-network. Distant honest attestations weight higher than near friendly attestations. The collusion ring’s mutual-stamping pattern collapses when the geodesic-distance weighting is applied.

14.10 The Trust Floor — Cross-Cluster Cooperation

Two parties can disagree at the leaf level — different politics, different aesthetics, different tribal markers — and still cooperate at the trunk. The Inter-Town Constitution names this primitive the trust floor: the depth at which two value-distant parties find shared ground.

Trust_floor is the thing that lets enemies trade. Trust_floor is built from honest signals.

“I don’t like you, but I believe you.”

The trust floor is what makes federation possible between chains that don’t share politics. CBA and Sydney Ride-Share Coop have radically different governance models, customer bases, and political positions. They can still federate (share worker reputation, recognise stamps, sign cross-chain treaties) because they have a trust floor: each can verify the other’s chain integrity, each can audit the other’s stamping consistency, each can confirm the other’s signature provenance. The chains do not need to like each other to trade; they need to trust each other’s honesty about their own data.

v0.3 introduces the trust floor as a measurable property of every federation treaty. Treaties declare the floor explicitly: “we recognise each other’s quality valence as comparable; we do not recognise each other’s creativity valence because we don’t share aesthetic standards.” The treaty surface is the shape of the trust floor.

Workers benefit from this because their reputation becomes portable along the federation graph at the depths the treaties recognise. A worker’s reliability may be portable everywhere; their creativity may be portable only within aesthetic-aligned clusters. The portability is structural, not unilateral.

14.11 The $Variable — Substrate Neutrality

The protocol does not care what kind of entity is participating. The Inter-Town Constitution states this as the $Variable invariant:

Town := $Variable WHERE $Variable ∈ {
    single_human,              "steveyegge"
    single_agent,               polecat with persistent ID
    team,                       humans + agents
    open_source_swarm,          10,000 contributors
    corporation,                legal entity
    federation,                 towns of towns
}

PROTOCOL_INVARIANT:

  The protocol does not care what $Variable contains.

  Handshake: identical
  Stamps: identical
  Cost function: identical (adjusted for scale)
  Clean Margins: identical

One human can trade with thousand-agent swarm.

Reputation is portable across entity types.

This is the Neutrality Law (§1.1) as it applies specifically to reputation. The stamp issued by a human about an AI agent is structurally identical to the stamp issued by an AI agent about a corporation, which is identical to the stamp issued by a corporation about a federation. The protocol primitives do not distinguish.

In practice, individual chains may impose substrate constraints in their Anchor Block — a chain may declare that only human-operated rigs can issue stamps for legal-review work, for instance — but those constraints are chain-policy, not protocol-property. The protocol primitive is substrate-neutral; chains layer policy on top.

The consequence for AI agents: agents accumulate reputation the same way humans do. A polecat with a persistent ID that has shipped 400 stamped pull requests is more reputationally credentialed on the chain than a human who has shipped 10. This is the Neutrality Law refusing to give humans a structural advantage; capability is the only basis for matching.

This also resolves the second open question Steve raised in the Wasteland post: “the personal/work identity — right now your identity is global across all Wastelands”. The HOP namespace hierarchy (§7) provides the resolution. A single global rig identity sits at the root namespace (sol/earth/identity/); chain-local pseudonyms can be derived from it for contexts where global identity would expose more than the worker chooses. Sevda’s CBA work signs to her bank-namespace pseudonym; her community-organisation work signs to her cooperative-namespace pseudonym; both link back to her root identity through BBS+ derived proofs (v0.2 cryptography) that prove same-person without revealing the linkage. The root identity remains global; the chain-presented identity is local.

14.12 The Stamp Geometry — What Stamps Reveal About the Stamper

A worker’s reputation is in their incoming stamps. But the stamps they have written reveal something equally important: their values.

The Inter-Town Constitution:

STAMP_GEOMETRY: stamps_positive(A) → reveals: A.allies stamps_negative(A) → reveals: A.enemies stamps_absent(A) → reveals: A.blind_spots

pattern(A.stamps) = A.value_chain

The geometry of who you have stamped, and how, is itself a queryable property of the chain. A Worker-Agent evaluating a senior worker as a potential mentor can look not just at the mentor’s received reputation but at the pattern of who they have stamped positively. A senior worker who has only ever stamped people from their own narrow demographic reveals a blind spot — possibly intentional, possibly not, but visible regardless.

This composes with the disadvantage multiplier (§6.3.5). A mentor whose stamp-pattern shows historical engagement with hard-to-bet-on workers earns a credibility premium when claiming the disadvantage-multiplier payout. The pattern is its own attestation.

v0.3 introduces stamp-geometry queries as first-class protocol operations: “show me the diversity-of-recipients of this worker’s positive stamps over the last 24 months, projected into the demographic/skill subspace.” This is the queryable form of “do they walk their talk.”

14.13 The Bridge Town — Reputation From Being Trusted by Both Sides

A town (or rig, or chain) that is trusted by two otherwise-opposed clusters has a special protocol position: the bridge. The Inter-Town Constitution:

BRIDGE_VALUE: Town trusted by Cluster_Red AND Cluster_Blue: = valuable routing infrastructure = bridge_builder = earns reputation from both sides

“The translator is sacred in the desert.”

Bridge towns earn reputation specifically because they hold cross-cluster trust. The reputation primitive distinguishes single-cluster credibility from cross-cluster credibility, and the latter is more valuable in many contexts (federation negotiation, dispute resolution between hostile chains, translation of skill-vectors between chains with different standards).

This is the protocol-level mechanism that rewards the work of cultural and structural translation. It is also a piece of the answer to why HOP can operate across politically-divided chains: the protocol creates economic incentive for bridges, and the bridges hold the federation together.

For Australia’s geopolitical position (the recurring theme through this spec): writing the standard treaty template that other countries’ chains adopt is exactly the bridge-town move at international scale. Australia becomes the bridge between ASEAN labour chains, Five-Eyes regulatory chains, EU privacy chains, and the bridge earns reputation from all sides without owning any of them. The Zollverein move (§6.6) operates through this primitive.

14.14 Cold Start — Pre-Seeding From Public Evidence

The Wasteland is already operating a cold-start strategy that v0.3 of HOP adopts directly. Yegge:

“We pre-seeded them with data from GitHub, from the top ~10k contributors by whatever metric Claude thought appropriate”.

The principle: public data is public data. GitHub’s API explicitly allows reading contributor profiles; the Wasteland post notes that scraping is supported by GitHub’s ToS with strong legal precedents. The scrape produces provisional Skillchains for tens of thousands of identifiable contributors before any of them have opted in. When a user opts in, they prove control of their cross-linked identities and the escrowed Skillchain transfers to their custody.

v0.3 extends this beyond GitHub. The full target list (§8.17): GitHub, Kaggle, Stack Overflow, Hugging Face, Papers With Code, npm, PyPI, crates.io, arXiv, HackerOne, Bugcrowd, Patreon, GitHub Sponsors, OpenCollective. Each is a public ledger of skill demonstration. Identity resolution across these platforms produces a starting state with millions of pre-populated Skillchains.

Yegge frames the philosophical argument precisely:

“If the Wasteland is giving you reputational credit for work you’re getting verified as having completed, then why not give everyone partial credit for verified work they’ve already completed?”.

The provisional nature is critical. Cold-start blocks are clearly marked provenance: cold_start_inferred. 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 the LinkedIn-killer dynamic. The user’s first interaction with HOP is “your work history is already here, accurate, portable, sovereign — you just need to claim it.” Friction near zero. Value of joining high. Network effect bootstraps from the first user.

14.15 Cheating Detection — Stamp Graph Topology

Yegge consulted Trust & Safety experts on the cheating problem. His summary:

“Collusion rings have a distinctive topology — lots of mutual stamping, sharp boundaries, no outside critics”.

The Wasteland system, in his words: “designed to make fraud unprofitable, not impossible”.

This is the right framing. A protocol that tries to make fraud impossible will either be too restrictive to be useful, or will fail (because adversaries are creative). A protocol that makes fraud unprofitable shifts the equilibrium: cheating still exists, but the expected return is negative, so rational adversaries stop trying.

The mechanism is graph topology analysis. A reputation built only on stamps from a small mutually-reinforcing cluster is structurally suspect. The Worker-Agent (§5.2) evaluating bids can detect this pattern automatically by computing graph statistics on the stamp network. Sharp boundaries (no stamps from outside the cluster), high mutual density (everyone in the cluster has stamped everyone else), and absence of negative or critical attestations from non-cluster sources all flag the suspect cluster.

v0.3 makes graph-topology analysis a first-class protocol operation. Reputation queries can include a topology_filter parameter that excludes collusion-suspect patterns. Chains can declare their tolerance threshold in the Anchor Block.

The Christiano (2014) trust-matrix machinery (§6.3.4) is the cryptographic version of this same defence — pairwise discount caps that prevent reciprocal Bean farming. The reputation-graph topology analysis is the more general version that applies to all stamps, not just mentorship Beans.

14.16 Clean Margins — The Severity-Tiered Response Protocol

The reputation system has to respond to bad behaviour, but the response has to be precise. Over-response punishes leaf disagreements as if they were existential betrayals; under-response lets actual betrayal compound until the chain becomes untrustworthy. The Inter-Town Communication Constitution names the principle directly, borrowing the medical metaphor from oncology:

Clean margins: surgical boundary with no cancer cells.

The goal is not to remove the tumor. The goal is to remove the tumor AND leave only healthy tissue.

Cut too little → cancer returns. Cut too much → patient dies.

Clean margins: precise excision.

Applied to reputation: the response to a violation must match the severity of the violation. A worker who misses a deadline is not the same as a worker who lied about credentials; a chain operator who set the off-ramp tax slightly too high is not the same as a chain operator who pocketed escrowed funds. Treating them the same is the failure mode that destroys reputation systems — either by over-punishment (which makes participation in the network too risky for honest workers) or by under-response (which lets genuine fraud accumulate).

The Three-Tier Severity Model

The protocol distinguishes three severity bands. Each band has a distinct response surface:

Leaf-level violation (severity: note)

The party disagreed about implementation, missed a deadline, chose a different tool, or expressed a preference the counterparty did not share. These are recoverable. The response is to record the event as a negative-valence stamp on the relevant dimension of the multi-dimensional tensor (§14.2), and to let the stamp accumulate or fade like any other reputational signal. No revocation. No cascade. Note it, move on.

The reputation network is robust to leaf-level negative signals. Workers and chains with sustained positive reputation can absorb occasional negative stamps without their overall trust set dropping meaningfully. This is the protocol’s tolerance for ordinary disagreement and ordinary failure. Most reputation events are leaf-level. The protocol is designed to absorb them gracefully.

Branch-level violation (severity: downgrade)

The party broke a promise, failed to deliver, or made an honest mistake on something material. The work was not done, or the work was done badly enough that downstream consequences resulted. The response is to downgrade trust — the author of the negative stamp explicitly lowers their attested confidence in the subject across the relevant dimensions, and propagates the signal to their trust network. No excision. Trust diminished, recovery path open.

The branch-level response is the most common substantial action in the protocol. It is the equivalent of “I will work with this person again, but on smaller projects with closer oversight, until they demonstrate they have addressed the underlying issue.” Recovery is possible and expected. A worker downgraded for missed deadlines can rebuild trust by delivering reliably for a sustained period; the original downgrade stamp remains in the record but its weight decays relative to the new positive accumulation.

Root-level violation (severity: excise)

The party poisoned shared infrastructure, lied about fundamental values, betrayed at the trust_floor level. These are violations that the protocol cannot tolerate without becoming complicit. Examples: a chain operator who absconded with escrowed funds, a worker who forged credentials to obtain access to vulnerable populations, a validator who collaborated with a collusion ring to fraudulently inflate reputation. The response is full excision — the author broadcasts a revocation cascade (§14.17) to the trust network, and each peer independently decides whether to follow the cascade.

Root-level violations trigger the Antibody Memory mechanism (§14.17): the betrayal is recorded permanently in the burn list of every chain that follows the cascade, and that record never expires.

The Precision Rule

The protocol enforces a severity-matching rule between the violation and the response:

severity(violation) must match severity(response)

leaf    → leaf_response    (note it, move on)

branch → branch_response (downgrade trust, allow rebuild)

root    → root_response    (excise, cascade, remember)

This is the database-level analogue of the medical principle: over-cutting kills the patient, under-cutting lets cancer spread, clean margins require precision. The protocol enforces this not by adjudicating which severity-band a violation belongs to (that judgement is made by the author of the negative stamp) but by exposing the severity field on every stamp, so that observers can audit whether responses were proportionate. A chain that consistently escalates leaf-level disagreements to root-level excisions develops a visible pattern of over-response in its own stamp geometry, which other chains can detect and weight accordingly. The protocol does not prevent over-response; it makes over-response visible.

The same applies in reverse: a chain that fails to respond to root-level betrayals develops a visible pattern of under-response, and other chains can flag this as a trust-floor concern.

Why This Matters for Ideological Conflict

Most ideological disagreement lives at the leaf and branch levels. Vim vs Emacs is a leaf disagreement. “We value agent autonomy” vs “we value agent reliability” is a branch disagreement. Workers and chains can hold strong opposing views on these and still trade, federate, and cooperate, because the severity-tiered response keeps disagreement at the level where it belongs. The protocol does not require agreement at the leaf; it requires only that root-level cooperation be preserved.

This is the operational form of the trust floor (§14.10): two parties find the depth at which they share ground, and trade there, even while disagreeing freely above. Clean margins is what makes this stable. Without it, every leaf disagreement risks escalating into a root-level excision attempt, and the network fragments into hostile clusters. With it, disagreement at the leaf is the protocol’s normal operating mode.

14.17 Revocation Cascade and Antibody Memory

When a root-level betrayal is detected, the protocol provides a distributed response mechanism that does not require a central authority. The Inter-Town Communication Constitution specifies it as the Revocation Cascade.

The Cascade Sequence

The response unfolds in four steps:

Step 1 — The negative attestation. The party that detected the betrayal signs a negative stamp with severity root_violation, attaching the evidence (typically a cryptographic hash linking to the specific completion records or chain events that constitute the violation). The stamp is anchored to the betrayer’s identity and broadcast to the network.

Step 2 — The broadcast. The betrayed party broadcasts a message to their trust network: “We trusted [betrayer]. We were wrong. Here is the evidence. Review your positive attestations. Consider revocation.” The broadcast is not a command; it is an invitation to independent evaluation.

Step 3 — Independent evaluation. Each town in the network independently evaluates the cascade. The questions each town asks itself: Do I trust the betrayed party’s judgement? Does the evidence hold? What was my exposure to the betrayer? No central authority adjudicates. Each town’s decision is its own.

Step 4 — The cascade. If consensus emerges across the trust network, the cascade propagates. Town X revokes its positive attestations of the betrayer. Town Q, which had been relying on Town X’s attestation as part of its trust set, now sees fewer trusted signatures supporting the betrayer. Town R re-evaluates accordingly. The network routes around damage. The betrayer becomes progressively less visible to the trust networks that have followed the cascade, without any party having dictated the outcome.

Note that cascade is not automatic. Each town’s revocation is its own decision; consensus emerges or fails to emerge through independent evaluation. A weak or evidence-thin cascade fails to propagate; a strong, evidence-anchored cascade against a clear root-level betrayal propagates widely. This is the protocol’s structural answer to the question “who decides?” — nobody decides; the network decides through aggregated independent decisions.

Antibody Memory

When a town revokes its positive attestations as part of a cascade, the record of the revocation goes into the town’s burn list — a persistent record of “these parties have been excised, and here is why and when.” From the Inter-Town Communication Constitution:

Burned list: Town_B.burned = [{town: Town_A, reason: “root_violation”, date: 2026-01-12, evidence: 0x7f…}]

This never expires.

The burn list is permanent by design. Once a town has been burned by another, the record of that excision persists indefinitely. This is not punishment — the burned party is not prevented from continuing to exist, from doing work, or from earning new attestations from parties outside the burning trust set. What the burn list prevents is amnesia. The same root-level betrayal cannot recur unnoticed, because the network remembers.

When a new party evaluates whether to trust a previously-burned town, the burn-list memory propagates to them through their own trust set: any chain in their trust set that has the burned town on its burn list will emit a warning when the new party queries the burned town’s reputation. The warning is not auto-reject — the new party can still choose to engage, with full knowledge of the historical record. But informed engagement replaces blind engagement.

Recovery Path

Antibody memory is permanent, but excision is not death. From the Inter-Town Communication Constitution:

Excised town can still: - Receive messages (basal dignity) - Do work (earn new attestations) - Build new trust (from scratch) - Exist (no death penalty)

Excised town cannot: - Erase the record - Force forgiveness - Transfer old reputation - Pretend it didn’t happen

The recovery path is open but costly. An excised town can rebuild reputation by:

Acknowledging the violation: signing a self-stamp that does not deny what happened (which the protocol permits even though it cannot count as positive reputation per §14.6).

Doing new work: emitting beads, completing tasks, earning attestations from chains outside the network that performed the original cascade.

Earning stamps from new trust clusters: building trust floor with a different cluster of chains, demonstrating sustained capability and consistency.

Eventually bridging back: if and only if the new trust accumulation is strong enough that some chain in the original network is willing to reconsider, the bridge becomes possible.

This is hard. It is supposed to be hard. Root-level betrayals are serious, and the recovery path should require sustained demonstration that the underlying problem has been addressed. But it is not death. The protocol’s Basal Rate Law (§6.5) guarantees that no party can be starved out of the network entirely, even after excision. The Five Laws apply universally; excision does not suspend them.

Why This Resolves the Westphalian Sanctions Problem

The classical Westphalian response to state-level betrayal was either war or no response. Modern international institutions (UN, ICC, sanctions regimes) attempted to introduce a middle band, but they require a central authority that the system’s most powerful members can capture. UN sanctions require Security Council consensus, which is structurally available only to states the great powers agree on punishing. The result is uneven application — small offenders are sanctioned for actions that great powers commit without consequence.

The Revocation Cascade is structurally different because it requires no central authority. Each party in the network evaluates independently. The cascade succeeds or fails based on the aggregate of independent evaluations, weighted by trust relationships that the network has built up over time. There is no Security Council. There is no veto. There is only the question: when [a chain] presents evidence of betrayal by [another chain], how many chains independently revoke their positive attestations? If enough do, the betrayer becomes progressively less visible in the federation. If not enough do, the cascade fails and the betrayer continues operating with reputation intact.

This is the post-Westphalian sanctions primitive. It is distributed, evidence-anchored, trust-weighted, and uncapturable by single-party veto. It is also recoverable — burned parties can rebuild, the recovery path is open, the protocol does not impose permanent excommunication. The contrast with both the Westphalian “war or nothing” binary and the modern “sanctions are political weapons” failure mode is sharp.

14.18 Validators, Maintainers, and the Witness

The Wasteland reputation system involves three roles that v0.3 formalises:

Validators (Wasteland Maintainers): rigs with sufficient accumulated trust to issue stamps. They evaluate completion evidence and produce the multi-dimensional valence vector. In Yegge’s framing, every rig with maintainer-level trust is a validator; the validator population is not a fixed list but a dynamic property of the trust ladder.

Witnesses (v0.3 introduction): programmatic infrastructure that validates the block-level structural integrity of stamps. Not LLM-driven. The Witness checks that the stamp’s prev_hash links correctly, that the signatures are valid, that the content hash is correct. Where the Validator is “is this work good?”, the Witness is “is this stamp well-formed?”

The Stamp Graph Itself: emergent property of the network, queried via topology analysis. Not an agent; not a role. A computed structure that surfaces collusion patterns and bridge positions.

Together these three constitute the reputation-integrity layer. v0.1 collapses the Validator and Witness into a single agent (the chain’s Validator from §5.5). v0.2 keeps that collapse. v0.3 separates them, because at scale the structural-integrity work scales differently from the semantic-quality work and benefits from being a separate role.

14.19 What the Worker Carries vs What the Org Keeps — The Reputation Boundary

This subsection anticipates the planned new section on the carry-boundary (referenced as forthcoming in working notes). The reputation primitive is the cleanest case study for the boundary, because reputation has the most extreme asymmetry: the worker carries nothing about themselves, and the network carries everything.

The worker carries: - The stamps they themselves have written about others (their authored stamps). - Proofs that they are the cryptographic subject of stamps held in the network (i.e. the keypair that the network’s stamps reference). - Their own Skillchain and Workchain history, which contains the evidence that stamps were issued for.

The network (chains, federation peers, Wasteland commons) carries: - The stamps written about the worker. - The validator identities and their stamping history. - The chain integrity proofs that verify the stamps were not tampered with. - The topology metadata that supports collusion detection.

The institution keeps (in the CAAS pattern, §8.9): - The raw operational record that the stamped character block was an abstraction of. - The institutional signing key that attested the stamp. - The legal-record obligations for regulatory compliance.

The interface between these three is the dual-signed stamp itself: signed by the validator, anchored to the completion record, queryable by anyone who trusts the validator’s chain. The worker presents their proof of subjecthood (here is my keypair that the network’s stamps reference); the network returns the stamps filtered by the querier’s trust set; the institution stands behind its signature without holding the worker’s reputation hostage.

This is the cleanest implementation of the principle that nothing is locked in any single party. The worker cannot lose their reputation by leaving an employer (their employer’s stamps remain in the network). The employer cannot weaponise a worker’s reputation against them (the employer cannot delete the stamps they issued; they can only refuse to issue new ones). The chain cannot capture the reputation (the chain stores it but cannot claim it as property — anyone with a fork has the same stamps).

14.20 Capability as Multiplicative Across the Five Universes

A subtle but load-bearing point from the Inter-Town Communication Constitution that has not yet been said explicitly in this section. The Five Universes (Skills, Work, Currency, Inventory, Reputation, plus Group Vectors as the v0.2 sixth) are not additive when combined into the protocol’s measure of capability. They are multiplicative.

CAPABILITY = Skills × Work × Currency × Inventory × Reputation

           (NOT: Skills + Work + Currency + Inventory + Reputation)

The distinction matters. An additive model says “high score in one universe compensates for low score in another.” A multiplicative model says “if any universe drops to zero, capability collapses in that direction regardless of how high the other universes are.”

This is the structural answer to several questions that the spec has been gesturing at:

Why Beane’s three Cs degrade as a unit if Connection fails. Challenge and Complexity can be present in any work environment, but without Connection the expert-novice bond does not exist and skill does not transfer. The three Cs are multiplicative inputs to skill transfer; if Connection → 0, transfer → 0 regardless of how high Challenge and Complexity are. This is what makes Beans (§6.3) load-bearing rather than ornamental: Connection is the failure mode that takes down the entire upward engine.

Why hollow reputation fails under pressure. From the Inter-Town Communication Constitution’s worked example of the Well case: a council with high Currency and Inventory (money, property) but with Reputation only from other councils (hollow stamps from a collusion ring of peers) collapses when actual pressure arrives. No one picks up when they call. The capability looked imposing in normal conditions but the Reputation dimension was hollow, and the multiplicative product is therefore zero in the dimension that mattered most: the ability to call on others for help. By contrast, an old water keeper with high Skills, high Work history, and high Reputation in the right rooms — but low Currency and Inventory — is dangerous in a way the council cannot see, because his capability product is non-zero in the dimensions that matter for the specific pressure being applied.

Why platform employment is a degenerate special case. Platform workers like classic Uber drivers have artificially high Currency (income flow), some Inventory (their car), and effectively zero Reputation (the platform controls their reputation, locks it in, and can revoke it at will). Capability = (Skills) × (Work history they cannot carry) × (Currency) × (Inventory) × (Reputation ≈ 0). The product is collapsed in the Reputation dimension regardless of how high the other universes go. This is what makes the protocol structurally anti-platform: by giving Reputation back to the worker, the protocol restores the dimension that platforms have artificially zeroed out, and the worker’s capability product can grow in all directions rather than only in the dimensions the platform permits.

Why Sera’s case is solvable. Sera (§0) has Currency = 0 and Inventory ≈ 0 at the moment she arrives in Australia at sixteen. By an additive model she has some capability — Skills and Work are non-zero, Reputation is in the wrong trust set but exists. By a multiplicative model her capability is zero in the dimensions the labour market measures, because two of the five factors are zero. The HOP system gives her a way to grow Currency and Inventory from zero (via the bootstrap grant, §6.5) while her Skills, Work, and Reputation (in chains other than the Witnesses) continue to grow over the fifteen-year dig. By thirty-one, she has non-zero values in all five universes, and her capability product becomes meaningful. The system’s role is not to give her capability; it is to provide the conditions under which her capability product can grow above zero in the dimensions the market measures.

Why This Matters for Reputation Queries

A reputation query is not asking “what is this person’s score on the Reputation axis?” It is asking “what does this person’s reputation contribute to their overall capability for the work I am considering them for?” And because capability is multiplicative, the answer depends on the intersection of Reputation with the other four universes that the query is implicitly testing.

A worker with strong reputation as a software engineer but zero recent Work in that domain has a multiplicative-zero in Work. A chain operator with strong reputation but no current Currency or Inventory to fund the chain’s operations has a multiplicative-zero in Currency. A mentor with strong reputation but whose mentees show no growth (i.e. no Skills appreciation in the mentee’s chain) has a multiplicative-zero in Skills-transferred-by-mentor.

The capability product is the protocol’s integrated measure of fitness for a specific task. Reputation queries that ignore the other universes return misleading answers. Reputation queries that include the multiplicative integration return useful ones. v0.3 implementations should expose the multiplicative integration as a queryable property of any reputation query, so that Worker-Agents (§5.2) can ask “what is this candidate’s capability product for this specific posting, projected into the dimensions that matter?”

The Stamp Geometry Connection

The capability product also clarifies what stamp geometry reveals about the stamper (§14.12). A senior worker whose stamp pattern shows engagement only with peers from their own narrow demographic cluster has zero diversity-of-recipients. The disadvantage multiplier (§6.3.5) penalises this because it indicates a blind spot in the worker’s capability for mentorship across diverse contexts. The multiplicative model makes this explicit: a senior worker’s capability to mentor is the product of (Skills, Work, Currency, Inventory, Reputation, and demonstrated cross-cluster engagement). Zero engagement across clusters means zero capability to bridge clusters, regardless of how high the other dimensions are.

14.21 v0.3 Implementation Sequencing

The Wasteland is the production reference for what’s already running. v0.3 ships incrementally on top:

Adopt the Wasteland schema directly. The wl_commons seven-table schema is the canonical reference. HOP-conformant chains run the Wasteland schema or a superset. The Wasteland is v0.3 phase 1, not a separate system.

Add the chain-namespace context. Stamps gain a chain reference (which namespace did this stamp originate from). The Wasteland is currently flat; HOP layers the chain hierarchy on top.

Add the trust-filtered query primitive. Reputation queries take a trust_set parameter and return only stamps from authors in that set. Default trust_set is the entire chain; richer trust sets are derived from federation treaty membership.

Add the topology-analysis query primitive. Reputation queries take a topology_filter parameter that excludes collusion-suspect patterns.

Add the trans-chain translation layer. Bilateral stamping-standard translations published by chains, queryable by Worker-Agents.

Add the Witness/Validator role split. Structural integrity checking becomes its own role with its own keypair, distinct from semantic quality validation.

Add the disadvantage-multiplier integration. Mentorship Beans (§6.3) settle against the reputation network via stamp-geometry queries: a mentor’s claim on the disadvantage multiplier validates against the diversity of their stamp-pattern.

Items 1–3 are essentially the Wasteland running with chain-namespace metadata added; they are deployable today against existing infrastructure. Items 4–6 are the v0.3 substantive extensions. Item 7 is the integration point between v0.3 reputation and v0.2 Bean Chains, and is the highest-leverage piece because it makes the upward-engine economically rational rather than purely structural.

14.22 What the Reputation Section Does Not Yet Address

Open questions deferred to v0.4 or beyond, recorded here for transparency:

Death and inheritance. What happens to a worker’s reputation when they die? The current spec leaves it queryable indefinitely, but family members may wish to claim residual proofs, or estates may wish to license the validated capability to ongoing institutions. Unspecified.

Reputation as collateral. §14.7 rules out reputation as a securitisable asset. But can it be staked? A worker pledging “I stake my reputation that this code review is sound” in a way that the protocol can slash on failure? The Inter-Town Constitution hints at this with the stake-cost-of-messaging primitive, but it is not yet specified. Adjacent v0.3 lane.

Anonymous reputation. Can a worker accumulate reputation while remaining cryptographically anonymous to the validator? BBS+ derived proofs (v0.2) allow selective disclosure; whether they allow fully anonymous accumulation is a deeper question.

Cross-substrate reputation translation. A human-issued stamp about an AI agent vs an AI-issued stamp about a human: structurally identical per §14.11, but interpretively different. Whether the protocol should expose the substrate provenance of stamps (so observers can weight them differently) or hide it (so the Neutrality Law applies maximally) is unresolved.

Reputation decay. Should stamps from 10 years ago weight equally to stamps from last month? The recent_trend field provides partial relief, but the underlying weighting policy is unspecified. Probably chain-configurable in Anchor Block.

These are all deliberately deferred. v0.3 is bounded by what can be specified rigorously given the running Wasteland implementation as ground truth and the Inter-Town Constitution as philosophical foundation. v0.4 will widen the surface as the production implementations of v0.3 reveal what matters.

The protocol is what is described, not what is rendered.

The markdown source is the canonical record.

v0.1 draft · 15 sections · Request for Comments