The HOP Optimisation Protocol

home/§3 Character Blocks

§3

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 tradesperson’s van and a plumbing-supplier 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. The worker’s character block from her afternoon scam intervention does not say:

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

It says:

{
  "block_type": "work",
  "inventory": {
    "role_class": "relationship_manager",
    "institution_class": "tier_1_bank",
    "branch_class": "metropolitan_branch",
    "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 the worker’s capability in fully transferable terms. A peer bank, a credit union in another country, a community organisation, an aged-care provider — all of them can read this block and understand what she did and how that maps to work they have. None of them gets the bank’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. The bank’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.