BookGraph
Home / concepts

Mycel Protocol Architecture

[CONVICTION]

Mycel implements the four-protocol-layers as a concrete protocol suite organized around a minimal kernel, four core protocols, and a MIME-like domain extension mechanism. The design follows the internet pattern: keep the kernel small enough that multiple independent implementations can be built, audited, and kept in sync. Push domain meaning to typed extensions.

The Stack

Mycel sits in the protocol stack between agent/application protocols above and physical systems below:

graph TD
    A["Application Plane<br/>A2A / MCP / HTTP / WebRTC"] --> B["Domain Proof Standards<br/>MIPs (MIME-like extensions per domain)"]
    B --> C["Mycel-Core Kernel<br/>identity, proofs, verify, coordinate,<br/>settle, federation, policy packs"]
    C --> D["OpenGrid / IDN<br/>attested edge compute + model delivery"]
    D --> E["Physical World<br/>humans, robots, sensors, facilities"]

    style A fill:#4a90d9,color:#fff
    style B fill:#7b68ee,color:#fff
    style C fill:#e74c3c,color:#fff
    style D fill:#f39c12,color:#fff
    style E fill:#27ae60,color:#fff
  • Application plane: agents + apps (A2A / MCP / HTTP / WebRTC)
  • Domain proof standards: MIPs (MIME-like extensions per domain)
  • Mycel-core kernel: identity, proofs, verify, coordinate, settle, federation, policy packs
  • OpenGrid / IDN: attested edge compute + model delivery
  • Physical world: humans, robots, sensors, facilities

Mycel does not replace transport protocols (HTTP/3, QUIC, WebRTC, MQTT), agent interaction protocols (MCP, A2A), identity standards (DIDs, X.509), or payment rails (UPI, SEPA, bank transfers). It specifies the layer that turns those interactions into proof-carrying coordination.

An MCP tool call can carry a Mycel proof reference. An A2A message can embed a proof payload. A WebRTC session can be wrapped by a session-MIP that defines what proofs must be emitted.

Two Verification Planes

Mycel cleanly separates two verification surfaces:

Control-plane integrity (deterministic): identities, signatures, revocation, state machines, nonces, timestamps, replay protection. This is cryptographic and binary -- either the signature is valid or it is not.

Reality-plane validity (probabilistic): did the claimed physical event occur? This is verified by AI + sensing + economics, producing calibrated probabilities and dispute processes.

The separation is non-negotiable. It prevents "AI verified" from weakening cryptographic rigor, while avoiding the opposite trap of forcing the physical world into brittle deterministic oracles. See verification-infrastructure for the conceptual foundation.

Eight Universal Invariants (K1-K8)

The kernel defines the minimal, non-negotiable rules that all implementations MUST support:

K1: Identity and Attestation -- Every entity has cryptographic identity rooted in hardware. Device keys, software supply-chain attestations, calibration chain attestations.

K2: Proof Object Format -- Universal envelope with domain-specific payloads. Signatures, expiry, revocation pointers. The basic unit of Mycel, analogous to a packet in TCP/IP.

K3: Verification API -- Two-layer verification: deterministic envelope validation plus probabilistic claim validation. Test vectors for interoperability.

K4: Coordination Contract State Machine -- Universal workflow for agreeing on work: DRAFT -> REQUESTED -> OFFERED -> COUNTERED -> ACCEPTED -> EXECUTING -> PROVING -> DISPUTE -> SETTLED -> CLOSED.

K5: Settlement Semantics -- Verifiable Contribution Receipts (VCRs) mint when proofs are accepted. Dispute windows, holdbacks, clawbacks.

K6: Federation Rules -- Trust anchors, rotation, revocation. Capability announcements and admission.

K7: Policy Packs -- Local governance constraints encoded as first-class objects. Machine-checkable rules for privacy, safety, economics, and dispute handling.

K8: Verification-Model Attestation -- The AI models that produce probabilistic results are themselves part of the trust chain. Model identity, certification benchmarks, deployment attestation.

The Four Core Protocols

graph LR
    subgraph "Protocol Flow"
        AT["1. Attestation<br/>Who/what is this?<br/>Hardware roots, calibration"] --> DI["2. Discovery<br/>Who can do what?<br/>Capabilities, policies"]
        DI --> CO["3. Coordination<br/>How do we agree?<br/>Contracts, state machines"]
        CO --> SE["4. Settlement<br/>How does value flow?<br/>VCRs, payouts, disputes"]
    end
    SE -.->|"incentivizes"| AT

    style AT fill:#2ecc71,color:#fff
    style DI fill:#3498db,color:#fff
    style CO fill:#9b59b6,color:#fff
    style SE fill:#e67e22,color:#fff

Node Topology

graph LR
    P["Producer<br/>sensor / robot / facility"] -->|"emits evidence"| V["Verifier<br/>AI model + attestation"]
    V -->|"issues proof"| C["Coordinator<br/>contract state machine"]
    C -->|"triggers payout"| S["Settler<br/>VCR + payment rail"]
    S -.->|"receipt feeds back"| P

    style P fill:#27ae60,color:#fff
    style V fill:#2980b9,color:#fff
    style C fill:#8e44ad,color:#fff
    style S fill:#d35400,color:#fff

Proof Flow: Evidence Stays Local, Proofs Travel

sequenceDiagram
    participant Local as Local Vault<br/>(evidence stays here)
    participant Node as Producer Node
    participant Verifier as Verification AI
    participant Network as Mycel Network
    participant Relying as Relying Party

    Node->>Local: Store raw evidence<br/>(video, sensor data, logs)
    Node->>Verifier: Submit evidence digests +<br/>device attestation
    Verifier->>Verifier: AI verification<br/>(confidence scores)
    Verifier->>Network: Emit compact proof object<br/>(claim + digest + confidence)
    Network->>Relying: Proof travels freely
    Note over Local: Raw evidence never<br/>leaves the vault
    Relying-->>Local: Audit/dispute only<br/>(if needed)

1. Attestation Protocol

How a node, device, sensor, robot, or software component proves what it is and how it was calibrated. This is the trust foundation -- every other protocol depends on it.

The attestation chain binds: hardware root of trust (TPM/TEE) -> measured boot and software integrity -> sensor calibration validity -> model certification and deployment. A proof is only meaningful if the system can answer: who measured, what code ran, and whether it was calibrated.

2. Discovery Protocol

How capabilities are advertised and found -- a verifiable directory for "who can do what, where, under what policies." Nodes publish supported MIPs, physical capabilities, constraints (location, compliance, hours), and policy pack references.

Discovery queries can be resolved at federation scope (local registries), regional scope (indices), or global scope (directories for routing). Evidence is never exposed through discovery.

3. Coordination Protocol

How parties negotiate and execute contracts for work. The state machine lifecycle: request -> offer -> counter -> accept -> execute -> prove -> dispute/close. Every transition is signed by the relevant parties and time-bounded.

A coordination contract binds: parties and roles, the work specification, required proofs and thresholds, dispute windows and holdbacks, and settlement splits and payout rails. This is Ostrom's commons governance encoded as a state machine.

4. Settlement Protocol

How accepted proofs mint receipts (VCRs), trigger payouts, and manage disputes/holdbacks. Settlement does not require a new token -- it may use any payment rail (UPI, SEPA, bank transfer, stablecoin). What is standard is the receipt format, the dispute window, and the split rules.

A VCR specifies: what was verified, who contributed (operator, facility, verifier, model provider, community pool, protocol treasury), what cash flows they are entitled to, and what dispute/holdback rules apply. VCRs are not speculative assets. They are receipts that direct cash flow through existing payment partners.

MIPs: Domain Proof Standards

[REFRAME]

MIPs (Mycel Improvement Proposals) are to Mycel what MIME types are to HTTP. The transport stays generic; meaning becomes typed, composable, and independently evolvable.

In HTTP: Content-Type: text/html, Content-Type: application/json, Content-Type: image/png. Same protocol. Different content types.

In Mycel: mip-hlt-001/poc (Proof of Causation), mip-edu-001/pom (Proof of Mastery), mip-mfg-001/poq (Proof of Quality). Same kernel. Different proof types.

A MIP defines: claim schemas, required evidence classes, verification pipelines, confidence thresholds, audit rules, and settlement defaults. A MIP becomes a standard only after a written spec, a reference implementation, and an interoperability demo with two independent implementations.

Domain Modules (Illustrative)

  • MIP-HLT (Health): Proof of Outcome / Care. Personalized baseline models, causal attribution, pay-for-outcome with holdbacks.
  • MIP-EDU (Education): Proof of Mastery / Agency. Rubric-specific models, longitudinal competence, competency-based progression.
  • MIP-MFG (Manufacturing): Proof of Quality / Process. Metrology, QC models, calibration chain validation, warranty holdbacks.
  • MIP-SCM (Supply Chain): Chain-of-custody and condition. Sensor fusion, anomaly detection, per-leg escrow.
  • MIP-ENR (Energy): Proof of Generation / Carbon Intensity. Attested meters, cross-check with grid certificates.
  • MIP-AGR (Agriculture): Proof of Origin / Stewardship. Practice models, seasonal baselines, regeneration premiums.
  • MIP-TSK (Tasks/Robotics): Proof of Execution / Proficiency. Geometric + semantic verification.

Each domain has its own proof types but shares the same kernel. The proof plane is shared across domains; the meaning is domain-specific.

The Proof Object

The basic unit of Mycel is the proof -- a signed, portable object that binds a domain claim to evidence digests, device/software attestations, and a verification result including uncertainty. A proof answers five questions:

  1. What is being claimed? (MIP-defined payload)
  2. Who produced the evidence and ran the verifier? (issuer, node attestation)
  3. What model, code, and calibration chain was used? (model attestation)
  4. What evidence exists? (digests and location, not raw data)
  5. What is the verifier's result and confidence? (layered confidence scores, aggregate, decision)

Proofs are offline verifiable at the envelope level. A relying party validates by: resolving the signer identity, verifying signatures, checking attestation validity, evaluating policy pack constraints, and optionally checking transparency logs for revocation freshness. Evidence is not required for basic validation -- only for audit and dispute.

Verification AI

[EVIDENCE]

Physical verification cannot be purely cryptographic. Sensors are imperfect. Humans can lie. Cameras can be spoofed. Mycel makes this explicit through layered confidence:

  • Authenticity confidence: Did attested hardware capture the evidence? Is the software pipeline measured?
  • Measurement confidence: Are sensors calibrated? Are readings physically plausible? Do redundancies agree?
  • Semantic confidence: Does the evidence support the claim according to the domain model?
  • Attribution confidence (optional): Did the intervention cause the outcome? Are confounders controlled?

The fundamental operation is universal: Evidence + Claim -> AI Model -> Confidence Score. What varies is evidence type, claim type, and the trained model. Models exist on a specificity ladder from foundation (generic perception) through domain, workflow, site, and personal (subject-specific baselines).

MMP Core: The Reusable Mesh Substrate

[CONVICTION]

The v2 mesh protocol family revealed that the lower protocol layers are not OpenGrid-specific. They are general coordination primitives that every Mesocosm network needs. This insight led to splitting the protocol surface into three layers:

Mycel trust grammar -- identities (did:mycel), proof envelopes, vault and consent semantics, MIPs, settlement, federation trust anchors, policy packs. The shared trust foundation.

MMP Core (Mycelial Mesh Protocol) -- the reusable locality and coordination substrate. Defines ParticipantDescriptor, LocalityScope, ColonyDescriptor, ProfileMembership, CapabilityEnvelope, FederationTreaty, and ReceiptRef. Provides identity and enrollment, bootstrap and discovery, overlay maintenance (T-Man for static attributes, SWIM for liveness), capability advertisement, and federation. Multiple mesh profiles inhabit the same colony/canopy/federation topology without collapsing into one undifferentiated network.

Domain-specific mesh profiles -- each with different demand objects, lifecycle state machines, and feedback signals. OMP (OpenGrid Mesh Profile) for compute routing, session lifecycle, and model distribution. Arena's challenge routing, research profiles, capability formation, and capital routing each extend MMP Core with their own semantics.

This split matters because without it, every Mesocosm network reinvents its own coordination layer. With it, a single Meso Valley site runs one mesh instance serving all networks simultaneously. A factory node is discoverable as compute (OpenGrid), research site (Macrocosm), training venue (Microcosm), and asset (capital network). The same SWIM health detection, T-Man overlay, and federation surface serve all purposes.

The OMP protocol suite (OMP-0 through OMP-9) provides ten distinct protocol concerns with a clean dependency chain as the build order: OMP-0 (identity) through OMP-1 (bootstrap), OMP-2 (overlay + health), OMP-3 (capability), OMP-4 (routing), OMP-5 (sessions), OMP-6 (feedback), OMP-7 (federation), OMP-8 (model distribution), OMP-9 (settlement).

Application Protocol Compatibility

MMP/OMP does not compete with application protocols. They operate at completely different layers:

  • MCP (Model Context Protocol) answers: how does an agent connect to tools and data sources?
  • A2A (Agent-to-Agent) answers: how do two agents discover each other and hand off tasks?
  • UCP (Universal Commerce Protocol) answers: how does an agent complete a commercial transaction?
  • WebRTC, HTTP, QUIC, ROS2, OPC UA, FHIR, EPCIS remain unchanged as transport and domain protocols.

MMP answers the question none of them address: where should this agent physically run, how do agent teams form locally, how do those teams discover other teams across boundaries, and how does the factory floor's agent cluster coordinate with the supply chain's cluster without a central platform capturing the traffic? MMP is the substrate layer underneath all of them.

Related

Tags: mycelprotocolarchitectureattestationdiscoverycoordinationsettlementkernelMIPsMMPmesh

Backlinks