BookGraph
Home / evolution

Mycel: Evolution of the Vision

[CONVICTION]

The Mycel whitepaper went through five major versions in rapid succession (January 2026), each rewrite deepening and restructuring the same core insight. Tracking the evolution reveals which ideas were load-bearing from the start, which emerged through iteration, and what the thinking process looks like when a protocol specification is born.

The core insight never changed: physical-world claims need a portable proof primitive that combines cryptographic integrity with probabilistic reality-plane verification. Everything else evolved.

v0.2: The Bitcoin-Style Paper (January 2, 2026)

Framing: "A Peer-to-Peer Protocol for Proof-Carrying Physical Events." Written in the style of Satoshi's Bitcoin paper -- terse, precise, narrowly scoped.

What it established:

  • The proof as the basic unit (analogous to a packet in TCP/IP)
  • The four protocol families: Attestation, Discovery, Coordination, Settlement
  • The proof envelope structure: claim + attestation + evidence digest + verification result
  • MIPs as domain extensions (the MIME analogy)
  • OpenGrid as the node network
  • Explicit uncertainty -- probabilistic verification, not binary truth
  • The "evidence stays local, proofs travel" design principle
  • VCRs (Verified Contribution Receipts) as settlement primitives

What it lacked: The paper treated the protocol as a narrow technical proposal. It was self-consciously minimal -- it stated what Mycel does not do (no new blockchain, no new token, no transport replacement) more forcefully than what it enables. The narrative scope was limited to the protocol mechanics.

Audience: Technical reviewers. Engineers who would evaluate the protocol surface area.

v2.0: The Vitalik-Style Paper (January 6, 2026)

Framing: "The Internet for Atoms" -- a technical paper in the style of Ethereum's whitepaper. The title itself signals a shift: from a narrow protocol proposal to a systemic vision.

What changed:

  1. The Lightning Network analogy emerged. v0.2 positioned Mycel vaguely as an "overlay protocol." v2.0 found the right analogy: "Mycel is closer to Lightning for atoms than a new L1." Contracts are local state machines between parties. No global chain required. Proofs are portable objects referenced by hash. This was a clarifying move -- it told builders exactly where Mycel sits in the stack.

  2. The four-plane architecture crystallized. The paper introduced a clean layering: Application plane (agents/apps), Proof plane (Mycel-core + MIPs), Compute plane (OpenGrid/IDN), Reality plane (devices/sensors/facilities). v0.2 had the pieces but lacked this compositional clarity.

  3. The two-plane verification separation became explicit. Control-plane (deterministic, cryptographic) versus reality-plane (probabilistic, AI-assisted). v0.2 had this in practice but v2.0 named it as "non-negotiable" -- a design decision that prevents "AI verified" from weakening crypto, and prevents crypto from forcing brittle determinism on physics.

  4. K1-K8 universal invariants were formalized. The minimal kernel went from a narrative description to eight numbered invariants. This was the move from "here's what we think the protocol should do" to "here are the rules every implementation MUST follow."

  5. Reference hardware profiles appeared. Edge-Micro (home gateway, microclinic) and Edge-Rack (microfactory cluster) with concrete specs: TEE-capable CPUs, 32-64 GB memory, NVMe storage. The protocol started touching physical reality.

  6. Performance targets were stated. <50ms time-to-first-token for voice, <250ms for proof verification, <2s for settlement. These numbers made the system buildable rather than theoretical.

What it lacked: The paper was still primarily protocol-focused. Production, ownership, and economic architecture received limited treatment.

v2.3: The Balaji-Style Paper (January 6, 2026)

Framing: "A proof-and-settlement layer for physical coordination and permissionless production." Written in the style of Balaji Srinivasan -- narrative-first, politically aware, systems-level. Split into Part I (narrative) and Part II (specification).

What changed:

  1. The compression/decompression thesis entered. "Industrial-scale coordination relied on lossy compression: we replaced rich reality with thin proxies (certificates, checklists, reputations). AI + sensors + robotics allow decompression." This connected Mycel to the broader lossy-compression argument in the Mesocosm framework. The protocol was no longer just infrastructure -- it was the mechanism of value decompression.

  2. "Distribution is how atoms scale" became a first principle. "You can fork a codebase, a ledger, or an online community. You cannot fork a watershed, a grid, a clinic, or a factory floor." This insight shaped everything downstream: federations instead of global consensus, local governance instead of universal rules, distributed ownership instead of platform control.

  3. Distributed ownership became a protocol concern. v2.3 introduced ownership descriptors, NodeCos, co-ops, SPVs, community entities. Ownership was no longer a footnote. The paper argued that because nodes are physical infrastructure, ownership structure determines whether the network serves communities or extracts from them.

  4. Graduated verification levels (VL0-VL4) appeared. The oracle mitigation stack evolved from a narrative to a structured framework: bonds, holdbacks, clawbacks, and audits as economics, not just technology.

  5. The "three costs collapsing" framing appeared. Perception (sensors + telemetry), judgment (foundation models), actuation (robots + microfactories). This is the deflationary-cascade applied specifically to physical verification -- and it explains why Mycel is tractable now, when it was not possible five years ago.

  6. The minimal loop was defined. Every Mycel workflow reduces to five steps: discover capability -> negotiate contract with required proofs -> execute work and record evidence locally -> run verification to emit proofs -> settle value when proofs accepted. This became the canonical description of how the protocol operates.

v3.0: The Technical Whitepaper (January 2, 2026)

Framing: "Protocol Suite, OpenGrid Node Architecture, and Probabilistic Verification." The first version written as a proper specification document with a table of contents, numbered sections, normative/illustrative distinctions, and detailed subsections.

What changed:

  1. The four names were disambiguated. Mesocosm (the thesis), Mycel (the protocol suite), Mycel Network (the federated network), OpenGrid (the compute substrate). v0.2-v2.3 used these terms loosely; v3.0 made the boundaries precise.

  2. Full MIP specifications appeared. Each domain module (HLT, EDU, TSK, MFG, SCM, ENR, AGR) received its own section with purpose, evidence types, proof types, verification layers, and reference implementation notes. The protocol became implementable domain by domain.

  3. The node software stack was decomposed. Five services per node: (1) identity and attestation agent, (2) evidence vault, (3) model runtime, (4) Mycel-core runtime, (5) federation and routing. This was the first time the internal architecture of a node was specified at implementation granularity.

  4. Voice governance was introduced. "How do communities affected by infrastructure have voice?" Policy packs became the mechanism for encoding local governance as machine-checkable constraints. This connected to Ostrom's commons governance principles.

  5. Cross-domain composition was specified. Multi-MIP verification, proof composition, supply chain examples showing how proofs chain across domains into DAGs.

  6. The specification became normative. MUST/SHOULD/MAY language, test vectors, conformance requirements, interoperability demos required for MIP standardization.

v4.0: The Technical Whitepaper, Refined (January 3, 2026)

Framing: Streamlined from v3.0. Tighter organization, more explicit about what is normative versus illustrative. Written for "engineers and researchers building agent systems, robotics, edge compute, identity/attestation, verification models, and settlement rails."

What changed:

  1. Distributed ownership was elevated to a top-level section. Three roles were separated: owner (economic rights), operator (day-to-day), governor (voice rights over policy). v4.0 argued these are often conflated and must be distinguished for the network to serve diverse communities -- from worker-owned cooperatives to investor-backed SPVs to municipal boards.

  2. Ownership descriptors became concrete. JSON-structured objects with node identity, operator, legal wrapper (coop/spv/trust/municipal), beneficial ownership splits, governance mechanisms (1p1v/delegated/quadratic), and cashflow policies. This made "distributed ownership" machine-legible.

  3. Financing patterns were enumerated. Operator-owned, local SPV, cooperative/community trust, hybrid. The key insight: ownership can be distributed without requiring a token. Equity and revenue shares can use conventional legal structures.

  4. "Distributed vs. decentralized" was made explicit. In bits, "decentralized" often means forkable. In atoms, you cannot fork a watershed or a factory floor. Mycel is designed for distribution -- federation of local networks with local governance -- not decentralization in the crypto sense.

  5. The VCR distribution example became specific. Operator 35%, node owner 25%, model provider 20%, expert pool 15%, protocol treasury 5%. These numbers made the economics tangible.

  6. The implementation roadmap became pragmatic. "Start with one substrate and one domain" -- not a grand launch but an incremental build path. Reference deliverables: Mycel-core SDK, one MIP reference implementation, node enrollment and attestation, proof emission and validation end-to-end, settlement adapter for one payment rail.

What Held Constant

Across all five versions, certain elements never wavered:

  • The proof as the basic unit
  • Evidence local, proofs travel
  • Four protocol families (attestation, discovery, coordination, settlement)
  • MIPs as MIME-like domain extensions
  • Probabilistic verification with explicit uncertainty
  • No new blockchain, no new token required
  • Federation over global consensus
  • OpenGrid as the node substrate

What Evolved Most

The largest evolution was in scope and ambition. v0.2 proposed a narrow protocol. v4.0 describes an architecture for civilizational-scale coordination of physical production, with distributed ownership, governance, and financing as first-class concerns. The protocol didn't change much. The understanding of what it enables -- and what it requires beyond code -- grew enormously.

The second major evolution was the framing. The same protocol was described through four rhetorical lenses: Bitcoin (narrow technical), Vitalik (systemic technical), Balaji (political-economic narrative), and engineering spec (normative). Each lens revealed different aspects of the same design. The Balaji framing introduced the compression/decompression thesis and ownership. The Vitalik framing formalized the invariants and performance targets. The engineering spec made it buildable.

Related

  • ventures/mycel/overview -- current state
  • ventures/mycel/protocol-architecture -- the architecture as specified
  • ventures/mycel/internet-for-atoms -- the core thesis
  • four-protocol-layers -- the conceptual foundation that Mycel implements
  • distributed-abundance -- the economic model the protocol enables
Tags: mycelmycelevolutionwhitepaperprotocol-designvision