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.

Note on namespace. The namespace conventions used throughout this section — sol/earth/..., parent/child anchoring, closed-vs-open namespace trees, federation treaties — are specified in §7 Namespace & Trust Hierarchy. This section assumes those mechanics. Readers wanting the full namespace specification should consult §7 first.

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. a Tier-1 bank, a ride-share cooperative, a research collective). 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 banking-sector block, a ride-share platform 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.

A worker’s seven years at a Tier-1 institution do not belong to that institution. They belong to the worker. If the worker leaves to take a role in a different sector, they carry their character blocks with them — each describing capability in transferable terms, each cryptographically attested by their former employer. The institution loses an employee but retains the ability to attest. The worker 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 (a Tier-1 institution runs its own internal Bean Chain), per-industry (a national construction sector 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.