Physical Capability Cloud: A Substrate for Agentic Composition of the Global Economy

Version: 3.0 | Date: June 13, 2026

Status (September 2026): public beta. Settlement runs on test networks. Sections marked Roadmap describe designs that are not yet deployed.

> The internet made information programmable. Cloud computing made compute programmable. We never did the same for the rest of the economy.
>
> Every good and every service today is coordinated through a stack of rent-seeking intermediaries — SaaS for the software, middle management for the people, admin for the paperwork. The work itself is usually fine. The coordination layer around it is the cost.
>
> What happens when every capability — a machine in Shenzhen, a person who knows how to do something in Medellín, an autonomous system on a remote tower — can be discovered, verified, composed, and settled by an agent the same way an agent calls any other API? When the coordination layer is a protocol, not a platform? When ownership of every node stays with the operator, but the ability to compose them into any value chain belongs to everyone?
>
> PCC is the substrate that lets agents compose reality. Not "AWS for the physical world" — the protocol that replaces the rent-extracting middle of every value chain with a verifiable substrate any agent can build on.

Abstract

Coordination is the expensive part of every value chain. A pizza shop pays 30% to a delivery platform. A small fab shop pays a fifth of its revenue to the marketplace that surfaces it. A clinical lab pays a SaaS vendor for the LIMS that schedules its instruments. A delivery driver pays a percentage to whoever routes them. None of these intermediaries do the work. They sit in the middle of the work and charge for the position.

The Physical Capability Cloud (PCC) is the substrate that lets agents compose verifiable primitives directly — so the rent-extracting middle becomes unnecessary. Any capability that can be expressed as a typed contract — I will make a pizza, I will mill aluminum to ±0.01mm, I will run an HPLC, I will drive a same-day route — becomes a node any agent in the network can discover, negotiate, escrow, execute, verify, and settle against.

Every UX surface that talks to PCC — voice, forms, mobile apps, chat, autonomous-asset agents — is an early adapter on top of the substrate. They will evolve. The substrate underneath does not need to.

Three structural goals, conventionally treated as a two-of-three trade-off in economic theory, become simultaneously achievable when coordination is a protocol:

- Perfect competition — many sellers, identical typed products (via Capability StructureDefinitions), perfect price information (via published pricing rules and on-chain evidence), zero entry barrier (via one-command operator onboarding through a user's own agent).
- Full verticalization — composition gives every node the coordination benefits of vertical integration without the integration step. An agent stitches a multi-step value chain at runtime; no merger, no procurement department, no master service agreement.
- Distributed ownership — every node owns its primitive. No central coordinator extracts the integration rent. The network treasury accrues from a flat, transparent protocol fee, not from positioning.

The implications follow directly. SaaS coordination layers (LIMS, ERP, MES, scheduling, dispatch, marketplace) collapse when their function becomes a substrate primitive any agent can compose against. Most middle-management and admin coordination cost becomes a protocol function rather than a job description. Settlement and evidence become enforcement mechanisms — load-bearing, but not the headline. The headline is what they enable: the world's first programmable, composable substrate for agent-mediated economic coordination.

This document describes the substrate, the four primitive slots that turn an arbitrary capability into a network participant, the bidirectional onboarding flow that lets a user's own agent and the registry converse during setup, and the enforcement layer (escrow, evidence, on-chain identity, IP attribution) that makes the substrate's claims credible at scale.

1. Introduction

1.1 The Coordination Tax

Every value chain today is bracketed by intermediaries that do not do the work and charge for the position. A delivery app takes 25-30% of every order from a pizza shop that already employs the staff, owns the oven, and has a customer who explicitly asked for that shop's pizza. A fabrication marketplace takes 15-25% of every part order from a machinist who already owns the mill and the expertise. A clinical-trial platform takes a license fee from a lab that already has the instruments and the SOPs. A freight broker takes a percentage from the driver who already owns the truck.

None of these middlemen do the work. They sit in the middle of the work and charge for being there. The structural reason they can charge for being there is that the alternative — the supplier and the customer finding each other, agreeing terms, verifying execution, and settling payment — was, until recently, harder than paying the middleman.

That is no longer true. An agent on the customer's side can find suppliers, negotiate terms, lock escrow, monitor evidence, and release settlement, faster and more verifiably than any human-mediated coordination layer can. The only thing missing is the substrate the agents on both sides are talking to. Without a substrate, every agent rebuilds the coordination layer privately. With one, the coordination layer becomes a protocol — and protocols compose.

1.2 What Cloud Infrastructure Got Right and Where It Stopped

Amazon Web Services succeeded because it turned compute into three composable properties: capability abstraction (an EC2 instance is an EC2 instance regardless of which physical box runs it), unit pricing (CPU-hour, GB-month, no sales call), and credible commitment (an SLA with documented remedies). These three properties let an entire ecosystem compose: a 2008 startup could string together S3, EC2, RDS, and SQS without speaking to a human, because each service published what it did, what it cost, and what happened if it failed.

The same three properties have never existed for anything outside compute. A CNC shop and a pizza place and a same-day courier and a contract-research-organization and a delivery driver are all running businesses where the work is well-defined, the price is reasonable from inputs, and the quality could be verified — but none of those three things is exposed in a form an agent can compose against. The result is the present economy: every transaction goes through human-mediated coordination, and the intermediaries who own that coordination layer charge for the privilege.

PCC extends the three properties — capability abstraction, unit pricing, credible commitment — to every unit of work, not just compute. The technical substrate is described in §3-§6 of this document. What makes it economically load-bearing is summarized in §1.3.

1.3 What This Substrate Is, And What It Is Not

PCC is not a marketplace. Marketplaces own the relationships, take a percentage, and create lock-in. PCC is not a SaaS product, a vertical solution, a manufacturing app, or "AWS for the physical world." Those framings undersell it by anchoring on a single vertical or a single UX pattern.

PCC is the substrate all of those things are composed from. Anyone — a person, a machine, an autonomous asset — can publish a typed capability and be a node. Any agent — a user's Claude session, a ChatGPT custom GPT, a Codex loop, a future model nobody has named yet — can compose those nodes into a value chain at runtime by talking to the substrate over a few small, stable surfaces: an A2A skill bus, an OpenAPI registry, a tool-use spec.

Every other surface — voice routing, mobile onboarding wizards, SMS fallbacks, web dashboards, marketplace UIs, embedded buttons — is an early adapter on top of the substrate. Some will mature. Some will be displaced by direct A2A as more agents come online. The substrate underneath outlasts each of them, and that is the durable layer.

The remainder of this document describes the substrate in detail (§2-§6), the enforcement mechanisms that make its claims credible (§7-§9 — escrow, evidence, identity, on-chain IP), and the economic model that lets it sustain itself without rent extraction (§10-§13).

2. Architecture

PCC's architecture follows the same organizing principle as cloud infrastructure: abstract the physical into billable, auditable, composable units.

2.1 Shop Kernels as Availability Zones

A Shop Kernel is the edge compute node for a physical site. It runs as a Fastify service, connects to local devices through typed adapters, emits evidence from every job, and exposes a standardized API to the rest of the network. Like an AWS Availability Zone, a Shop Kernel is independent: it has its own devices, its own queue, and its own identity on-chain. Failure of one Kernel does not cascade.

Each Kernel connects to physical devices through a typed adapter layer. The current adapter registry supports:

| Protocol | Discovery | Use Case |
|----------|-----------|----------|
| IPP (Internet Printing Protocol) | mDNS _ipp._tcp | 2D printers (Canon, HP, Brother) |
| OctoPrint REST API | mDNS _octoprint._tcp | 3D printers via OctoPrint |
| Modbus TCP/RTU | Manual config | Industrial sensors, PLCs |
| OPC-UA | Discovery endpoint | CNC machines, industrial automation |
| SiLA 2 | SiLA Discovery | Lab instruments (Hamilton, Tecan, Beckman) |
| Generic HTTP | Manual URL | Any device with a REST API |

Every Kernel has a W3C DID (did:key Ed25519 or did:pcc), a wallet for on-chain settlement, and a reputation score maintained by the network's ERC-8004 identity registry.

2.2 Capabilities as the Billing Unit

The fundamental departure from existing manufacturing marketplaces is the unit of account. PCC does not list machines — it lists capabilities. A capability is not "Prusa MK4 printer at 192.168.1.50." It is "FDM extrusion: PETG/PLA/ABS, build volume 250×210×210mm, layer heights 0.1–0.35mm, ±0.2mm dimensional accuracy, heated bed, tier-2 assurance available."

This matters because:

1. Buyers describe requirements, not equipment: A customer who needs a structural bracket printed in PETG does not need to know what printer produces it. They specify the material, dimensions, and tolerance. The network matches to capable equipment.
2. Dynamic routing: When one Kernel is busy or unavailable, the BrokerAgent routes to an equivalent capability elsewhere. This is not possible if the booking is for a specific machine.
3. Pricing from parameters: A capability's price varies by job parameters. FDM printing in ABS costs more than PLA because it requires an enclosure, higher nozzle temperatures, and longer cooldown. The capability's pricing rules encode this. No quote call required.

2.3 Assurance Tiers as SLAs

Every capability advertises the assurance level it can provide, from 0 to 3:

- Tier 0: Self-reported completion. Job receipt with timestamp. Suitable for low-stakes jobs where the buyer trusts the operator.
- Tier 1: Protocol verification. Machine-generated logs (OctoPrint completion state, IPP job-state, Modbus register snapshots) proving the adapter executed. Evidence is content-addressed to IPFS.
- Tier 2: Quality verification. Sensor readings, QC photographs, dimensional measurements, or chromatography results. Evidence is encrypted via Lit Protocol and content-addressed. Bittensor subnet scores quality.
- Tier 3: Third-party attestation. Independent EvaluatorAgent reviews evidence. ZK Merkle proof anchors the commitment on Starknet. Disputes go to UMA arbitration.

Higher tiers require larger bonds from the operator. A Tier-2 job requires the operator to post a slashable bond before the job begins. If evidence is rejected during the challenge window, the bond is slashed and redistributed to the challenger and the network treasury.

2.4 Milestone Escrow with Slashable Bonds

Settlement in PCC is not payment processing — it is programmable escrow with aligned incentives. The MilestoneEscrow Solidity contract, deployed on Base Sepolia, enforces the following lifecycle:

1. Customer funds the escrow before work begins. Funds are locked — the operator cannot access them, and the customer cannot withdraw unilaterally while work is in progress.
2. Operator posts a bond proportional to the assurance tier. This is skin in the game.
3. Job executes. Evidence flows from the Kernel to IPFS and the evidence DB.
4. Challenge window opens (duration varies by tier: 0–72 hours). Any party with standing can challenge by submitting counter-evidence.
5. If no challenge is raised, funds release automatically to the operator. The bond is returned.
6. If a challenge is raised, evidence goes to the verification layer (Bittensor consensus for Tier 2, UMA for Tier 3). The bond is slashed proportionally to the finding.

This structure means operators have an economic incentive to do the work correctly, not just to complete it.

3. Capability StructureDefinitions (CSD)

The capability abstraction requires a format for describing what a machine can do in a way that is machine-readable, constraint-aware, version-controlled, and composable. PCC's answer is the Capability StructureDefinition (CSD), directly inspired by FHIR StructureDefinitions.

3.1 The FHIR Analogy

FHIR (Fast Healthcare Interoperability Resources) solved an analogous problem in healthcare. Medical devices, lab systems, and EHRs all needed to exchange data, but the same concept — a "blood pressure reading" — had dozens of incompatible encodings. FHIR introduced StructureDefinitions: formal JSON schemas that define, constrain, and extend clinical data types with inheritance, invariants, and cross-field constraints. A US Core Patient profile says "a US Core Patient MUST have a race extension." A FHIR validator enforces this at runtime.

PCC's CSD plays the same role for physical capabilities. A base CSD for pcc://capabilities/fdm/v2 defines the universal parameters for FDM printing: material, layer height, infill density, support structures, build volume. A device-specific profile (pcc://capabilities/prusa-mk4/v1) inherits from the base and narrows: removes materials the printer cannot handle, restricts the build volume to 250×210×210mm, adds printer-specific extensions like input shaping. A runtime validator enforces these constraints when a job is submitted.

3.2 CSD Structure

A CSD is a self-describing JSON document. Its key sections:

- discovery: How to find devices of this type on the network. Protocol hints (IPP, OctoPrint, mDNS service type, Modbus register map), detection queries, and attribute mappings.
- adapter: Which adapter protocol drives the machine and the command schema (print, status, cancel, emergency stop).
- parameters: The typed, annotated parameter space for a job. Each parameter has a type (enum, number, boolean, string), validation rules (min/max/step/regex), grouping for UI display, and pricing impact.
- constraints: Cross-parameter rules evaluated at job-configuration time. Example: "borderless printing requires photo paper; if borderless=true and mediaType is not in [photographic-high-gloss, photographic-matte], reject with message." These are the equivalent of FHIR's FHIRPath invariants — but for physical processes.
- invariants: Device-level conditions that must hold regardless of job parameters. Example: "custom paper size requires a printer that can handle A3 dimensions."
- evidence: Per-tier evidence requirements. Tier 0 requires [jobId, timestamp, pageCount]. Tier 2 requires additionally [ippJobState, ippJobId, outputScanCid].
- pricing: Base price, currency, unit (per page, per gram, per hour), minimum charge, and pricing impact rules for individual parameters.

3.3 Auto-Discovery Pipeline

The self-describing property of CSDs enables zero-config onboarding. When an agent discovers a device on the network, it follows a deterministic pipeline:

mDNS scan → find _ipp._tcp / _octoprint._tcp services
→ Query device capabilities (IPP Get-Printer-Attributes, OctoPrint /api/printerprofiles)
→ Map reported attributes to CSD parameter space
  (IPP media-supported → mediaSize options, sides-supported → duplex options)
→ Intersect with base CSD (remove options device doesn't support, add device extensions)
→ Generate device-specific CSD profile with canonical URI
→ Validate CSD (schema validation, constraint consistency, pricing sanity)
→ Register: IPFS publication + DB record + on-chain hash commitment
→ Start adapter and run test job

For a Canon PIXMA TR8620, the agent reads printer-make-and-model, media-supported, print-color-mode-supported, printer-resolution-supported, and finishings-supported from the IPP endpoint and constructs a complete, validated CSD profile in seconds, without any human configuration.

3.4 Constraint Propagation and Invariants

The constraint engine runs on every parameter change. When a user or agent sets borderless=true, the engine:
1. Evaluates all constraints involving borderless as a trigger condition
2. Finds constraint 2d-print-1: borderless requires photo paper
3. Checks if mediaType satisfies the condition
4. If not, either rejects (severity: error) or warns (severity: warning) immediately

This enables real-time interactive configuration — the same mechanism that powers a UI form graying out incompatible options also powers an agent's decision loop when composing job parameters. The constraint engine is a first-class part of the protocol, not a UI concern.

Invariants operate at the device level rather than the parameter level. An invariant expression like mediaSize != 'custom' or device.capabilities.includes('iso_a3_297x420mm') is evaluated at job-acceptance time against the actual device's reported capabilities, preventing jobs from reaching devices that cannot physically execute them.

3.5 CSD Registry with URI Addressing and Inheritance

CSDs are organized in a URI namespace with hierarchical inheritance:

pcc://capabilities/                     root namespace
├── fdm/v2                              base: FDM 3D printing
│   ├── prusa-mk4/v1                    device profile (inherits fdm/v2)
│   ├── bambulab-x1c/v1
│   └── ender-3-v3/v1
├── cnc-3axis/v1                        base: CNC milling
│   ├── haas-vf2/v1
│   └── tormach-pcnc440/v1
├── 2d-print/v1                         base: 2D printing
│   ├── inkjet/v1                       protocol profile
│   │   └── canon-pixma-tr8620/v1       device profile
│   └── laser/v1
└── hplc/v1                             base: HPLC analysis

Each CSD is stored in three places: IPFS (canonical, content-addressed, immutable), SQLite (local cache for fast queries), and on-chain (hash commitment for integrity verification). URI resolution queries the local SQLite cache first, falling back to the IPFS registry.

Versioning follows semantic versioning. Breaking changes — removed parameters, narrowed constraint ranges — require a major version bump. Additive changes — new optional parameters, widened ranges — are minor. The version is part of the canonical URI, so old references remain valid indefinitely.

4. Agent-to-Agent Protocol

Physical work is orchestrated by a three-agent system communicating over a typed A2A message bus. The protocol is designed for trustless coordination: agents do not share state, they exchange cryptographically signed messages with defined semantics.

4.1 Three-Agent Model

UserAgent acts on behalf of a customer. It holds the customer's wallet, formulates intent (building a workflow from a natural language description), calls the BrokerAgent to discover and price capabilities, assembles the contract, and releases funds from escrow when work is verified.

BrokerAgent is the network router. It has no physical capabilities of its own. It receives workflow intents from UserAgents, queries the capability registry, runs a competitive auction among KernelAgents offering matching capabilities, compiles multi-step DAGs, and manages the escrow lifecycle for each step.

KernelAgent wraps a Shop Kernel. It accepts job offers from BrokerAgents, executes them through the adapter layer, collects evidence, and emits evidence bundles to IPFS. It manages the Kernel's devices and reports health status.

4.2 Typed Intents

The message bus carries typed intents rather than free-form messages. PCC defines 41+ intent types across nine categories:

| Category | Count | Example Intents |
|----------|-------|-----------------|
| Discovery | 4 | capability_search, capability_search_result, kernel_status, kernel_status_result |
| Quoting/Negotiation | 4 | quote_request, quote_response, negotiation_counter, negotiation_accept |
| Contract Builder | 4 | build_contract, build_contract_result, workflow_compile, workflow_compile_result |
| Job Lifecycle | 5 | job_submit, job_accept, job_progress, job_complete, job_cancel |
| Verification | 2 | evidence_submit, evidence_verified |
| Funding/Setup | 9 | funding_request, funding_provided, setup_detect, setup_configure, setup_validate, and variants |
| IP (Story Protocol) | 8 | ip_register, ip_revenue_query, ip_propose_split, ip_claim_revenue, and variants |
| Cross-Chain (NEAR) | 4 | near_payment_intent, near_payment_quote, near_payment_submit, near_payment_settled |
| Capability Requests | 3 | capability_request_submitted, capability_request_decomposed, capability_node_assigned |

Every intent carries a sender DID, a conversation ID, a timestamp, and a cryptographic signature. The message bus routes by intent type, with each agent declaring which intents it handles.

4.3 Conversational Negotiation with NLP Routing

Agents can interact in natural language — the BrokerAgent has an NLP router that maps text messages to intent handlers. When a UserAgent says "I need 50 aluminum brackets machined, drilled, and anodized, delivered by Friday," the BrokerAgent:

1. Parses the request to extract capabilities needed (CNC milling, drilling, anodizing), material (aluminum), batch size (50), and deadline.
2. Queries the capability registry for matching CSDs.
3. Runs an auction: broadcasts quote_request to all KernelAgents offering compatible capabilities.
4. Receives quote_response messages, ranks by price/quality/availability.
5. Compiles a 3-step workflow DAG using the WorkflowCompiler (topological sort with dependency resolution).
6. Returns a structured build_contract_result with pricing breakdown, delivery timeline, and assurance tier options.
7. Waits for the UserAgent to approve and fund escrow.

The negotiation loop supports counter-proposals, constraint relaxation ("we can hit that delivery date if you accept Tier-1 assurance instead of Tier-2"), and multi-round bargaining. Revenue split terms for Story Protocol IP are negotiated in this same phase — the ip_propose_split and ip_split_response intents allow operators to counter-propose before committing to a job.

4.4 Agent Wallets and Spending Policies

Every agent carries its own wallet, separate from the operator's personal funds. Agent wallets are derived from the UnifiedKeychain (EVM via viem, Solana via @solana/web3.js). Each wallet operates under a configurable SpendingPolicy that enforces:

- Per-transaction limits
- Rolling-window budget caps (e.g., no more than $500 in any 24-hour period)
- Allowlisted contract addresses (can only call the MilestoneEscrow and IP registry contracts)
- Automatic refusal of transactions that exceed risk thresholds

SpendingPolicies are encoded as ERC-4337 session keys for EVM operations, limiting the blast radius if an agent is compromised or behaves unexpectedly.

5. Sovereign Infrastructure

PCC's evidence and identity layer is designed for censorship resistance. No central server holds the ground truth of what happened. Evidence is distributed across cryptographically linked storage and verification systems.

5.1 Evidence Storage: IPFS via Helia and Storacha

Every completed job produces an evidence bundle: a JSON document containing sensor readings, machine logs, QC measurements, operator attestations, and job metadata. The bundle is:

1. Canonicalized (deterministic JSON serialization for reproducible hashing)
2. Hashed (SHA-256, becomes the bundle's canonical ID)
3. Encrypted (AES-256-GCM via Lit Protocol, key fragments distributed across the network)
4. Pinned to IPFS via Helia (local node embedded in the Kernel)
5. Archived to Filecoin via Storacha w3up for durable long-term storage (EVIDENCE_STORAGE=storacha)

Content addressing means any party can independently verify a bundle: hash the bundle, compare to the CID stored on-chain. Tampering is detectable without trusting any server.

5.2 Access Control: Lit Protocol

Raw evidence data is encrypted. Lit Protocol's threshold encryption scheme distributes key fragments across a decentralized network of nodes. Access conditions are evaluated at decryption time: only the job's customer, the operator, the assigned verifier, or a party that wins a formal dispute can decrypt the bundle.

This means operators can post evidence publicly (as a CID on IPFS) without exposing sensitive process parameters, material compositions, or quality measurements to competitors. The CID proves the evidence exists; decryption requires authorization.

The integration supports both mock mode (AES-256-GCM with simulated access conditions, for development) and real mode (@lit-protocol/lit-node-client v6 on the datil-test network).

5.3 ZK Proofs Anchored to Starknet

The StarknetProofAnchoringService computes Merkle proofs over evidence bundle hashes and anchors the Merkle root on Starknet via Cairo contracts. This provides:

- Selective disclosure: A party can prove a specific evidence bundle was included in a commitment without revealing the entire batch
- Efficient verification: Verifying a Merkle proof is O(log n); the full dataset stays off-chain
- Cross-chain anchoring: Starknet's ZK rollup provides a secondary integrity checkpoint independent of the Base Sepolia escrow chain

Three gateway routes expose this: POST /api/zk/anchor-starknet, GET /api/zk/verify-starknet, and GET /api/zk/starknet-status.

5.4 Bittensor Verification Subnet

Tier-2 and Tier-3 evidence is scored by a Bittensor subnet. MockMiner nodes evaluate evidence quality against the tier's requirements (Did the sensor readings arrive? Are they in the plausible range? Does the QC photo match the job description?). A MockValidator applies Yuma Consensus to aggregate miner scores into a network-level quality verdict.

The subnet design demonstrates the verification pattern with mock miners and validators. The BittensorSubnetBridge defines the interface for connecting PCC's evidence verification to a real Bittensor subnet in a future integration, where economic incentives would keep miners honest.

5.5 W3C DIDs and Verifiable Credentials

Every Kernel, device, and agent has a W3C DID. The did:pcc method anchors identities on-chain via the ERC-8004 identity registry. The did:key method provides offline-generated Ed25519 identities for lightweight agents.

Completing verified work earns Verifiable Credentials: structured, signed JSON-LD documents asserting demonstrated capability. These are issued as soulbound cNFTs via Metaplex Core on Solana — non-transferable attestations that an operator's equipment has executed verified jobs at a specific assurance tier. A credential cannot be bought or transferred; it can only be earned.

6. Intellectual Property Layer: Story Protocol Integration

This is the layer that transforms PCC from a coordination protocol into an IP network. The key insight: physical work creates intellectual property, and that IP has been invisible until now.

6.1 Why Physical Work Creates IP

When a designer writes a Capability StructureDefinition for precision aluminum milling — encoding the parameter space, constraint rules, pricing logic, evidence requirements, and adapter configuration — they have created a design artifact. It encodes knowledge about how to correctly configure and price a manufacturing process. That knowledge has value: every time someone uses that CSD to run a job, they are building on the designer's work.

Similarly, when an operator produces verified evidence of a completed job, they have created a proof of execution. That evidence is a specific instance of the process the CSD describes. It is a derivative work.

The music industry solved an analogous problem decades ago. A songwriter earns royalties every time a band records their song. The band earns performance royalties every time a venue plays their recording. The rights are registered, the royalties flow automatically, and the original creator earns from every downstream use. Story Protocol brings this model to any form of programmable IP — and PCC applies it to physical manufacturing processes.

6.2 IP Assets: CSDs as Programmable IP on Story Network

Publishing a CSD on PCC simultaneously registers it as an IP Asset on Story Network (chain ID 1514, or Aeneid testnet 1513). The StoryIPService.registerCapabilityAsIP() call:

1. Builds IP metadata following the IPA Metadata Standard: title, description, capability type, assurance tier, kernel ID, creator address and name.
2. Uploads metadata to IPFS via the existing Storacha/Helia integration.
3. Calls client.ipAsset.registerIpAsset() with a commercial remix PIL (Programmable IP License): commercialRevShare: 5 (5% of all derivative revenue flows to this IP Asset's Royalty Vault).
4. Returns an ipId — the IP Account address (an ERC-6551 Token Bound Account) — which is stored alongside the CSD in PCC's database.

The CSD is now a programmable IP Asset. It has an on-chain identity, a Royalty Vault, and 100 Royalty Tokens representing shares of its revenue stream. These tokens can be distributed to collaborators at registration time.

The concept mapping between PCC and Story Protocol:

| PCC Concept | Story Protocol Concept |
|-------------|----------------------|
| CSD (Capability StructureDefinition) | IP Asset (ERC-721 + IP Account) |
| Capability contract (booking) | License (PIL terms minted at booking) |
| Job evidence bundle | Derivative IP Asset (child of the CSD) |
| Multi-step workflow | IP chain (parent → child → grandchild) |
| MilestoneEscrow release | Royalty payment to IP Royalty Vault |
| CSD fork (inheritance) | Derivative IP with automatic rev-share |
| Operator revenue share | Royalty Token holding |
| Challenge window dispute | Story Dispute Module (UMA arbitration) |

6.3 Derivative IP: Every Job Is a Proof of Execution

When a job completes and evidence is finalized, StoryIPService.registerJobAsDerivative() registers the evidence bundle as a child IP Asset of the CSD:

CSD: pcc://capabilities/cnc-3axis/v1   →  ipId: 0xA1... (parent IP)
  └── Job JOB-20260321-001 evidence    →  ipId: 0xB2... (child, derivative)
       └── Inspection report output    →  ipId: 0xC3... (grandchild, derivative)

This creates an on-chain provenance chain. Anyone can trace: this part was made using that process, which was derived from that capability definition, authored by that person, verified by that subnet, and settled at that escrow address. The chain is immutable and publicly auditable.

Royalty flows are automatic: when the job's escrow releases on Base Sepolia, a configured portion (default 5% of job value) flows as a royalty payment to the parent CSD's IP Royalty Vault via StoryIPService.payJobRoyalty(). The vault accumulates revenue; Royalty Token holders claim their share whenever they choose via claimRevenue().

6.4 Royalty Flows: Multi-Party Revenue Splits

Every IP Asset's Royalty Vault holds 100 Royalty Tokens. PCC distributes these tokens according to the role each party played in creating the capability:

| Role | Default Tokens | Revenue Share | Who |
|------|----------------|---------------|-----|
| CSD Designer | 10 | 10% | Person who authored the capability definition |
| Machine Operator | 70 | 70% | Person whose equipment ran the job |
| Verifier | 10 | 10% | Subnet/agent that verified evidence quality |
| Network Treasury | 10 | 10% | PCC protocol fee, non-transferable |

These are defaults. During the contract negotiation phase, the BrokerAgent can propose custom splits — operators can require a minimum revenue floor, designers can negotiate higher royalty rates for novel processes, and multi-party collaborations can encode arbitrary splits as on-chain license terms before the job begins. Once the job starts, the split is immutable.

Royalty Tokens are ERC-20 tokens. A designer who publishes a CSD and receives 10 Royalty Tokens can hold them indefinitely, sell them to investors, or distribute them to collaborators who helped design the process. This creates a secondary market for manufacturing process IP — a liquid asset class that did not previously exist.

6.5 Multi-Step Workflow IP Chains

A 4-step workflow — CNC milling → anodizing → quality inspection → shipping — creates four IP Assets, one per step. The customer pays once; the BrokerAgent distributes payment across the escrow chain, and each step's escrow release triggers a royalty payment to the corresponding IP Royalty Vault:

Customer pays $100 for the full workflow
├── Step 1: CNC Milling  ($40) → IP Asset 0xA1
│   ├── CNC CSD Designer (10%): $4.00
│   ├── CNC Operator (70%):     $28.00
│   ├── Verifier (10%):          $4.00
│   └── Network (10%):           $4.00
├── Step 2: Anodizing    ($25) → IP Asset 0xB1
│   └── [same distribution pattern — $2.50 / $17.50 / $2.50 / $2.50]
├── Step 3: Inspection   ($15) → IP Asset 0xC1
│   └── [same distribution pattern]
└── Step 4: Shipping     ($20) → IP Asset 0xD1
    └── [same distribution pattern]
Additionally: 5% of each step's revenue flows to parent CSD IP Assets
(when a device CSD is a fork of a base CSD, the base earns from all derivatives)

When a CSD is derived from another CSD, the revenue flows up the IP chain automatically through Story Protocol's derivative royalty mechanism. A step-2 anodizing CSD that derives from a base anodizing CSD pays 5% to the base's Royalty Vault, which flows to the base's Royalty Token holders.

6.6 CSD Forking: Remix a Capability, Parent Earns Forever

The CSD registry supports inheritance. When an operator takes the base pcc://capabilities/fdm/v2 and creates pcc://capabilities/bambulab-x1c/v1 with X1C-specific parameters, the fork is registered as a derivative IP Asset of the parent.

From that point forward:
- Every job run using the fork generates 5% royalties flowing to the parent CSD's IP Royalty Vault
- The fork can itself be further forked, creating multi-generation chains
- The original author of fdm/v2 earns micropayments from every FDM job run on the entire network, regardless of which specific device profile was used

A researcher who designs a novel PCR amplification protocol, encodes it as a CSD, and publishes it to the PCC registry earns every time any lab on the network runs that protocol — whether they use the base CSD directly or any of its device-specific derivatives. This is the music royalty model applied to manufacturing processes.

6.7 The CSD as a Durable Design Asset

The critical distinction between PCC and previous coordination systems is that capability definitions are treated as first-class intellectual property, not throw-away configuration files. A CSD represents accumulated engineering knowledge: which parameter combinations are valid for which materials, which evidence types are meaningful for which assurance claims, how pricing should respond to job complexity. This knowledge is valuable and deserves to be compensated.

Story Protocol's IP infrastructure ensures this compensation is:
- Automatic: Revenue flows to Royalty Vaults without anyone manually triggering payments
- Proportional: Each contributor earns in proportion to their contribution (encoded as Royalty Tokens)
- Permanent: The on-chain record persists for the life of the blockchain; a designer earns from their CSD for as long as it is used
- Composable: Royalty Token portfolios can be sold, staked, or used in DeFi protocols built on Story Network

6.8 Dispute Resolution via Story Protocol

Story Protocol's Dispute Module uses UMA's optimistic oracle for on-chain arbitration. When a PCC challenge window produces a contested dispute:

1. The challenger calls StoryIPService.raiseDispute() with an evidence hash and reason string
2. Story's DisputeModule (deployed at 0x9b7A9c70AFF961C799110954fc06F3093aeb94C5) opens an optimistic dispute period
3. If the defendant does not respond within the challenge window, the dispute resolves in the challenger's favor
4. If contested, UMA token holders adjudicate; the losing party's bond is slashed

This supplements PCC's own challenge windows with a decentralized arbitration layer that operates independently of PCC's gateway — ensuring disputes can be resolved even if PCC's infrastructure is temporarily unavailable.

7. Economic Model

7.1 Per-Capability Pricing with Constraint-Aware Calculators

Every CSD encodes a pricing model. The base price sets the floor; parameter selections apply multiplicative or additive modifiers. For an FDM print job:

Base price: $0.50/gram
Material modifier: PLA=1.0×, PETG=1.4×, ABS=1.6×, Nylon=2.2×
Resolution modifier: 0.3mm=0.8×, 0.2mm=1.0×, 0.1mm=1.8×
Infill modifier: 20%=1.0×, 50%=1.3×, 100%=2.0×
Supports: none=$0.00, generated=$0.15/gram (estimated weight)
Minimum charge: $5.00

The pricing calculator runs both in the browser (real-time configuration preview) and server-side (binding quote generation). Agents can call the pcc_calculate_price MCP tool to get a binding quote before submitting a job. No human conversation required.

Operators can set overrides on top of CSD pricing: maximum price ceilings, minimum revenue floors, volume discounts for batch orders, and dynamic pricing via Meteora DLMM pools (adjusting price based on current queue depth and market demand signals).

7.2 Escrow with Challenge Windows

The escrow lifecycle creates a sealed, time-boxed settlement window that removes the need for trust between parties who have never met. Tier-0 jobs settle immediately on evidence submission. Tier-3 jobs hold a 72-hour challenge window during which any party with standing can submit counter-evidence. During the window, neither the operator nor the customer can unilaterally touch the funds.

This structure means the economic risk is symmetric and clearly allocated before work begins — a significant improvement over traditional manufacturing contracts where payment disputes can extend for months.

7.3 DePIN Reward Epochs (Roadmap)

Operators who consistently execute verified work earn additional rewards from the network treasury through DePIN epoch scoring. The RewardEngine evaluates operators on three axes:

- Uptime: What fraction of scheduled hours was the device available and accepting jobs?
- Quality: What is the mean evidence quality score from the Bittensor subnet?
- Throughput: How many verified jobs were completed in the epoch?

Epoch rewards create a baseline income floor for operators who maintain reliable infrastructure, even during periods of low demand. This incentivizes sustained participation rather than cherry-picking only high-value jobs.

7.4 Royalty Tokens as Process IP Equity

Royalty Tokens represent fractional ownership of a capability's revenue stream. A designer who publishes a CSD receives 10 Royalty Tokens (10% of all revenue). They can hold these indefinitely, sell them to investors, or distribute them to collaborators.

This creates a secondary market for manufacturing process IP. A researcher who designs a breakthrough polymerization process and encodes it as a CSD can sell a portion of their Royalty Tokens to a lab equipment manufacturer interested in seeing the protocol proliferate. Both parties earn proportionally from the protocol's adoption. Process IP becomes a liquid asset class.

7.5 Supplies Marketplace

Operators need raw materials to run jobs. The PCC supplies marketplace (/api/marketplace/*) connects operators to material suppliers within the same protocol. 9 REST endpoints cover listing, searching, ordering, and fulfillment tracking across 12 categories: raw-metals, plastics-polymers, lab-reagents, lab-consumables, electronics, chemicals, biologicals, tooling, packaging, calibration, safety, and other.

This closes the loop for a PCC operator: discover jobs via DHT, source materials via the marketplace, execute using registered capabilities, receive payment via escrow. The entire supply chain is protocol-native.

7.6 Network Treasury and Protocol Fees

PCC's network treasury receives 10% of every job's royalty payment. These funds finance:

- Bittensor subnet incentives (paying miners to evaluate evidence)
- ZK proof anchoring costs (Starknet transaction fees)
- Story Protocol transaction fees (IP registration and royalty distribution)
- Protocol development grants
- Dispute resolution bond pool

Treasury flows are on-chain and auditable.

8. Setup Agent: Zero-Config Onboarding

The vision is radical accessibility: a person with any networked device — a 3D printer, a CNC machine, a lab instrument, even a standard inkjet printer — should be able to join the PCC network with minimal technical knowledge.

8.1 The "Dad in Florida" Test

The test for the onboarding experience is not "can a DevOps engineer configure this" — it is "can my 70-year-old dad in Florida get his Canon inkjet printer earning money on the PCC network." This standard forces radical simplification.

The target flow (not yet end to end in the beta):

1. Dad installs the PCC agent (npm package or standalone binary)
2. Agent scans the local network via mDNS, finds Canon PIXMA TR8620a at 192.168.1.50
3. Agent reports: "Found your Canon PIXMA. It can print color/B&W, Letter/A4/Legal, up to 4800 DPI, double-sided. Want to add it to PCC?"
4. Dad says yes
5. Agent generates a wallet, requests testnet funds from the faucet, and registers the device
6. Agent prints a test page to verify the pipeline: submit → IPP Print-Job → evidence collected → settlement
7. Done. The printer can take jobs on PCC

The full onboarding requires exactly three decisions from the operator: confirm the detected device is correct, approve the generated config, and optionally fund the wallet if on-chain settlement is needed. Everything else is automated.

8.2 MCP Tools for Agent-Driven Setup

The @pcc/mcp-server exposes 29 tools, including 10 setup-specific tools:

| Tool | Purpose |
|------|---------|
| pcc_setup_detect | Auto-detect current config state (env vars, DB, chain, adapters, storage, identity) |
| pcc_setup_generate_config | Generate KERNEL_CONFIG JSON from device descriptions |
| pcc_setup_validate_config | Validate adapter connectivity and configuration completeness |
| pcc_setup_register_device | Register a device in the network DB and run health check |
| pcc_setup_health_check | Ping all configured devices and report status |
| pcc_setup_generate_env | Generate a .env file for a deployment profile (dev/testnet/mainnet) |
| pcc_setup_deploy_contracts | Deploy escrow contracts to testnet (requires funded wallet) |
| pcc_setup_register_identity | Register Kernel identity via ERC-8004 |
| pcc_setup_test_job | Run an end-to-end test job (submit → execute → evidence → settle) |
| pcc_setup_status | Comprehensive status across all categories with remediation steps |

Any AI agent — Claude Code, Cursor, a custom GPT assistant — can call these tools to walk an operator through setup conversationally, with no manual environment variable configuration.

8.3 SetupAgent and A2A Intents

The SetupAgent extends BaseAgent and handles setup-specific intents: setup_detect, setup_configure, and setup_validate. It orchestrates the detection, configuration, and validation phases, routing text messages to setup commands via NLP. The same logic that backs the MCP tools is accessible via the A2A protocol, enabling automated onboarding pipelines where a parent orchestrator can set up multiple kernels in parallel.

The agent's machine-readable AGENT_INSTRUCTIONS.md provides a 12-step onboarding guide that any LLM agent can follow without human translation — making PCC the first manufacturing network that can be onboarded entirely by an AI acting on behalf of a user.

9. Distributed Architecture: Operators Run Their Own Nodes

9.1 The Centralization Problem

Early versions of PCC routed all communication through a central gateway. This worked for development but introduced a single point of failure, a privacy bottleneck (the gateway sees all traffic), and a trust dependency (operators must trust the gateway operator). A credibly neutral protocol cannot have a centralized relay as an architectural requirement.

9.2 pcc-node: Join the Network in One Command

The pcc-node package is a pip-installable CLI that turns any Linux machine with equipment into a PCC network node. The onboarding flow:

pip install pcc-node
pcc-node start

On startup, pcc-node executes a deterministic pipeline:

1. Hardware detection: Scans V4L2 cameras (/dev/video), Opentrons OT-2 robots (HTTP health endpoint at :31950), OctoPrint instances (HTTP API), serial ports (/dev/ttyUSB, /dev/ttyACM*), and mDNS network instruments (via optional zeroconf dependency). All probes are best-effort; missing tools or unreachable devices are silently skipped.

2. Key generation: Creates an Ed25519 key pair (via PyNaCl) for signing capability announcements and encrypting P2P messages. Keys are persisted to ~/.pcc-keys.json with 0600 permissions. A fallback HMAC-SHA256 scheme is available for development without PyNaCl.

3. API key provisioning: Calls POST /api/auth/provision on the gateway to obtain a Bearer token. This is the only required interaction with the gateway.

4. Kernel registration: Registers the node's detected hardware as a Shop Kernel on the network.

5. Capability announcement: Signs and publishes a CapabilityAnnouncement describing what the node's equipment can do — capability types, materials, price ranges, and queue depth.

6. Daemon loop: Enters a long-running event loop that polls for pending jobs, executes them through device adapters, pushes camera frames, and sends heartbeats to maintain online status.

The node supports five CLI commands:
- pcc-node start — full pipeline: detect, register, run daemon
- pcc-node start --discover — scan network first, then start with all found devices
- pcc-node discover — scan local network for devices (subnet sweep + protocol fingerprinting)
- pcc-node detect — hardware scan only (no network interaction)
- pcc-node status — check if the daemon is running, show uptime and job count

9.3 Device Adapters

The executor module implements a pluggable adapter pattern. Each adapter wraps a specific device protocol:

| Adapter | Device Type | Protocol | Operations |
|---------|-------------|----------|------------|
| OpentronAdapter | Opentrons OT-2 | HTTP REST (port 31950) | Health, pipettes, modules, calibration, protocol upload, run create/action/status, home, lights, identify, shell |
| OctoPrintAdapter | 3D printers | OctoPrint REST API | Version, connection, state, job, files, print, cancel, pause |
| GenericHTTPAdapter | Any HTTP device | Generic HTTP passthrough | Configurable method/path/body forwarding |

Adapters are instantiated dynamically from detected device metadata. When a job arrives, the executor tries each adapter until one handles the tool call. Results are posted back to PCC.

9.4 Brain/Executor Split

For complex operations (especially those requiring LLM reasoning), PCC implements a brain/executor architecture:

- Brain (runs on powerful hardware like DGX Spark): The LLM agent that reasons about what operations to perform, handles error recovery, and makes decisions about retries and escalation.
- Executor (runs on the device's local machine via pcc-node): Receives tool calls from the brain via the PCC relay, executes them against local hardware, and returns results.

This split is critical for lab instruments on private networks. An OT-2 robot on a lab's internal network cannot be directly reached by a cloud LLM. Instead:

1. Brain posts POST /api/ot2/tool-call to PCC with tool name and arguments
2. Executor polls GET /api/ot2/tool-call/pending from PCC
3. Executor runs the tool call locally against the OT-2
4. Executor posts result via POST /api/ot2/tool-result
5. Brain retrieves result via GET /api/ot2/tool-result/:id

PCC is a relay, not a controller. The relay stores nothing permanently — tool calls and results have a TTL and are garbage-collected.

9.5 Camera Streaming

Operators can stream camera frames from their equipment to the PCC dashboard for remote monitoring. The camera module:

1. Auto-detects V4L2 capture devices on Linux
2. Captures JPEG frames via v4l2-ctl, ffmpeg, or dd (automatic fallback)
3. Pushes base64-encoded frames to POST /api/ot2/camera/frame
4. Dashboard users view frames via GET /api/ot2/camera/latest (raw JPEG) or subscribe to GET /api/ot2/camera/stream (SSE notifications)

Only the latest 5 frames per kernel are retained to avoid database bloat.

10. Peer-to-Peer Protocol

10.1 Encrypted A2A Messages

Agent-to-agent messages are encrypted end-to-end using NaCl box (Curve25519-XSalsa20-Poly1305). Each message is wrapped in an EncryptedEnvelope:

interface EncryptedEnvelope {
  ciphertext: string;         // base64-encoded encrypted payload
  ephemeralPublicKey: string;  // hex-encoded Curve25519 ephemeral key
  nonce: string;               // base64-encoded 24-byte nonce
}

This means the gateway (or any relay) cannot read message contents even if it is compromised. Only the intended recipient, holding the corresponding private key, can decrypt.

10.2 Signed Capability Announcements

Every node signs its capability announcements with Ed25519. A CapabilityAnnouncement contains:

- kernelDid — W3C DID of the announcing kernel
- kernelId — human-readable kernel identifier
- capabilities[] — array of CapabilitySummary objects (type, materials, price range, queue depth)
- endpoints[] — how to reach this node (WebSocket direct, WebSocket relay, WebRTC, HTTP poll)
- ttlSeconds — announcement validity period (default 300s)
- timestamp — ISO 8601 creation time
- signature — Ed25519 signature over canonical JSON of all other fields

Announcements are self-contained and independently verifiable. Any node receiving an announcement can verify its authenticity without contacting the signer.

10.3 DHT-Based Capability Discovery

The @pcc/dht package implements a WebSocket-based gossip DHT for decentralized capability discovery. Its components:

- AnnouncementRegistry: In-memory store with TTL-based expiry. Stores one active announcement per kernel. A periodic prune timer evicts expired entries every 30 seconds.
- CapabilityQuery: Structured query object supporting filters by capability type, materials, max price, minimum assurance tier, and geographic proximity (haversine distance).
- Query engine: matchesQuery() applies AND logic across all specified filters. rankResults() scores announcements by queue depth, price, and material breadth.
- Bootstrap nodes: Default bootstrap node is wss://capability.network/ws/dht. Operators can extend the list with a local JSON config file.

When an agent needs a capability, it queries the DHT instead of (or in addition to) the gateway. This provides censorship resistance: even if the gateway goes offline, nodes that know each other can still discover and coordinate.

10.4 Transport Layer

PCC supports four transport types, negotiated at connection time:

| Transport | Latency | NAT Traversal | Use Case |
|-----------|---------|---------------|----------|
| websocket-direct | Low | Requires open port | Lab-to-lab on same network |
| websocket-relay | Medium | Via PCC gateway | Default; works through NATs |
| webrtc | Low | ICE/STUN/TURN | Future: direct P2P with NAT traversal |
| http-poll | High | Always works | Fallback for restrictive networks |

Each peer advertises its available transports in its PeerEndpoint[] with priority ordering (lower number = preferred). Connecting peers negotiate the best mutual transport.

11. Execution Scope Protocol

11.1 The Security Problem

When an AI agent controls physical equipment remotely, the blast radius of a bug or compromise must be bounded. A language model that has been instructed to "run this HPLC protocol" should not be able to issue arbitrary shell commands on the lab's server. The question is not whether to restrict access — it is how to do so without making the system so rigid that it cannot recover from routine failures.

11.2 Four Operation Classes

PCC classifies every tool call into one of four security classes:

| Class | Policy | Examples |
|-------|--------|----------|
| READ | Always allowed; no scope needed | Health check, pipette status, calibration data, run history, camera snapshot |
| SAFE CONTROL | Allowed during active jobs without scope | Home axes, toggle deck lights, identify (blink) |
| SCOPED WRITE | Requires active execution scope | Upload protocol, create run, play/pause/stop run |
| PRIVILEGED | Requires explicit operator approval | Shell commands, self-update |

This classification is enforced at the gateway. Every POST /api/ot2/tool-call is validated before relay:

1. Class 1/2 tools pass immediately
2. Class 3 tools require a scopeId in the request body. The gateway checks: is the scope active? Has it expired? Is this tool in the scope's allowedTools? Has the command budget been exhausted?
3. Class 4 tools are always rejected at the API level; they require out-of-band operator approval

11.3 Scope Lifecycle

An execution scope moves through a defined state machine:

PROPOSED → ACTIVE → COMPLETED / EXPIRED / REVOKED

Creation (POST /api/ot2/scope): The user agent proposes a scope specifying which tools are needed, which pipettes and deck slots will be used, a command budget, a retry budget, a time limit, and optionally a protocol hash (SHA-256 of the protocol file content). The operator (or an auto-approve policy) activates the scope.

Validation: On every Class 3 tool call, the gateway increments the scope's commandCount, checks it against maxCommands, and verifies tool membership. Protocol uploads are hash-verified: the SHA-256 of the uploaded content must match the scope's protocolHash, preventing the brain from uploading a different protocol than what was approved.

Termination: A scope ends when all work is complete (agent calls scope completion), the time limit expires, or the operator revokes it. Revocation is immediate and atomic — all pending tool calls are rejected.

11.4 Graduated Troubleshooting

Physical operations fail routinely. A tip pickup misses. A well plate is offset. The scope protocol includes a four-level troubleshooting ladder:

1. Auto-retry: Tool call fails; retry within the scope's retry budget using Class 1/2 diagnostics (check calibration, home, inspect via camera)
2. Brain recovery: Claude examines error context, camera frames, and calibration data to decide on a recovery strategy within the scope's command budget
3. Operator escalation: Brain cannot resolve; pauses the job, notifies the operator via the dashboard with diagnostic context. Operator can extend the scope, grant temporary elevated access, manually fix hardware, or abort.
4. Emergency stop: Safety concern detected; all scopes for the kernel are revoked, all active runs receive "stop" actions, kernel status set to emergency_stopped. Requires manual resume and new scope creation.

11.5 Audit Trail

Every tool call is logged with scope ID, tool name, arguments (hashed for sensitive data), validation result (allowed/rejected with reason), execution result, timestamp, and requestor identity. The audit trail is queryable via GET /api/ot2/scope/:id/audit.

11.6 Chat Relay

Operators and agents can communicate in real-time through the chat relay (/api/ot2/chat). This provides a human-in-the-loop communication channel for escalation, status updates, and manual override coordination. Messages are persisted per-kernel and queryable by role.

12. Protocol Fee and Business Model

12.1 Open Protocol, On-Chain Monetization

PCC is an open protocol, not a SaaS platform. All code is open source. All specifications are public. Any operator can run a node, and any agent can interact with the network. The protocol monetizes through a transparent, on-chain fee applied at the settlement layer.

12.2 PCCProtocol Root Contract

The PCCProtocol root contract is the clearinghouse for all settlements. Design invariants:

- Automatic: Protocol fee deducted at escrow release, not invoiced separately
- Transparent: Fee rate visible on-chain, queryable by anyone
- Bounded: Governance can adjust the rate within defined bounds — but can never set it to zero
- Factory-gated: Only escrows deployed through the protocol factory can settle through the root — preventing fee bypass via direct escrow deployment
- Immutable recipient: The fee recipient address is set at deployment and cannot be changed

The root contract adds network-level accounting: total fees collected per token, per-escrow fee attribution, and a live factory registry.

12.3 Fee Distribution

Protocol fees fund the infrastructure that makes the network trustworthy:

| Allocation | Purpose |
|------------|---------|
| Bittensor subnet incentives | Paying miners to evaluate evidence quality |
| ZK proof anchoring | Starknet transaction fees for Merkle root commits |
| Story Protocol transactions | IP registration and royalty distribution gas |
| Gateway infrastructure | Bootstrap nodes, DHT relays, dashboard hosting |
| Protocol development | Open-source development grants |
| Dispute resolution pool | Bond pool for challenger incentives |

12.4 Fiat On-Ramp

To lower the barrier to entry, PCC integrates fiat-to-crypto on-ramps:

- Coinbase Onramp: Card and ACH payments for US/EU users, converting to USDC on Base
- Testnet faucet: Free testnet USDC for development and testing
- Yellowcard: Mobile money and bank transfers for 34 emerging market countries

Operators can receive payment in fiat via off-ramp integrations (Yellowcard for emerging markets, Wise for enterprise bank payouts in 40+ currencies).

13. Real Hardware Integration: OT-2 as Proof of Concept

13.1 Why a Liquid Handler

The Opentrons OT-2 is the ideal first real-hardware integration for PCC because it is:

- API-accessible: Full REST API at port 31950 with versioned endpoints for health, pipettes, modules, calibration, protocols, and runs
- Programmable: Python protocols uploaded and executed via the API
- Physically complex: Multi-axis liquid handler with pipette tips, well plates, temperature modules, and magnetic modules — enough complexity to stress-test the execution scope protocol
- Safety-critical: Incorrect pipetting can contaminate samples, waste expensive reagents, or damage equipment — making the graduated security model essential

13.2 Integration Architecture

The OT-2 integration demonstrates the complete PCC stack:

Claude (Brain, on DGX Spark)
    |
    | POST /api/ot2/tool-call
    v
PCC Gateway (capability.network)
    |
    | GET /api/ot2/tool-call/pending
    v
pcc-node (on OT-2's Raspberry Pi)
    |
    | HTTP to localhost:31950
    v
Opentrons OT-2 Robot

The gateway validates every tool call against the active execution scope before relaying it. The node's OpentronAdapter translates PCC tool calls into OT-2 API requests. Camera frames from a USB camera connected to the OT-2's Raspberry Pi stream through the camera relay for remote monitoring.

13.3 13 OT-2 Tool Calls

| Tool | Class | What It Does |
|------|-------|-------------|
| ot2_health | READ | Robot health, firmware version, serial number |
| ot2_pipettes | READ | Attached pipettes with calibration status |
| ot2_modules | READ | Temperature, magnetic, and heater-shaker modules |
| ot2_deck_calibration | READ | Deck calibration matrix and status |
| ot2_pipette_offset | READ | Per-pipette offset calibration data |
| ot2_tip_length | READ | Tip length calibration data |
| ot2_protocols_list | READ | Uploaded protocol files |
| ot2_runs_list | READ | Run history with status |
| ot2_run_status | READ | Status of a specific run |
| ot2_home | SAFE | Home all or specified axes |
| ot2_lights | SAFE | Toggle deck illumination |
| ot2_identify | SAFE | Blink LEDs for physical identification |
| ot2_protocol_upload | SCOPED | Upload a Python protocol (hash-verified against scope) |
| ot2_run_create | SCOPED | Create a run from an uploaded protocol |
| ot2_run_action | SCOPED | Play, pause, or stop a run |
| ot2_shell | PRIVILEGED | Arbitrary shell command (operator approval required) |

14. Related Work

14.1 Asset Administration Shell (AASX/AAS)

The Asset Administration Shell (AASX), developed under IEC 63278 and maintained by the Industrial Digital Twin Association (IDTA), is the closest existing standard to PCC's CSD. AAS defines digital twins of physical assets with typed Submodels (NameplateV2, TechnicalDataV1, etc.) and hierarchical inheritance via SubmodelTemplates.

PCC's CSD differs from AASX in three critical ways:

1. Interactive constraint propagation: AASX has no constraint engine. SubmodelTemplates describe what data a Submodel may contain, but they do not constrain how selecting one parameter affects the valid range of another. PCC's constraint engine handles bidirectional cross-parameter dependencies in real time — essential for agent-driven job configuration.

2. Economic primitives: AASX is an engineering data model. It has no concept of per-job pricing, evidence tiers, slashable bonds, or settlement. PCC's CSD embeds pricing rules, evidence requirements, and assurance tier definitions directly in the capability description.

3. Agent-first design: AASX is designed for OPC UA servers and Industry 4.0 middleware. PCC's CSD is designed for LLM agents consuming MCP tools and A2A intents. The discovery and adapter sections are specifically designed to be actionable by autonomous agents without human translation.

PCC plans to build a bidirectional CSD ↔ AASX Submodel Template translator for industry interoperability.

14.2 MTConnect

MTConnect (IIC/ANSI) is a read-only telemetry standard for CNC machine tools. It answers "what is this machine doing right now?" — not "what can this machine do?" The SensorPipeline in @pcc/kernel uses MTConnect-compatible semantics for sensor data taxonomy, but MTConnect is not suitable as a capability advertisement format.

14.3 OPC UA Companion Specifications

OPC UA's companion specification system (OPC UA for Machine Tools, OPC 40501) is structurally analogous to CSD base types and device profiles. OPC UA's type hierarchy supports subtype inheritance and device-level instantiation. The key gap: no cross-field constraint mechanism. OPC UA types can specialize further (additive inheritance) but cannot narrow the valid range of a base type's fields. PCC's CSD constraint system explicitly solves this.

PCC's adapter layer includes an OPC-UA adapter, and CSD profiles can reference OPC UA node addresses for parameter mapping, enabling PCC to serve as an IP and coordination layer on top of existing OPC UA infrastructure.

14.4 SiLA 2

SiLA 2 (Standardization in Lab Automation) is the closest analog to PCC's CSD for laboratory instruments. SiLA Feature Definitions (FDLs) describe instrument commands with typed parameters and return values, exposed via gRPC. PCC includes a SiLAAdapter that connects SiLA 2 instruments to the kernel, with CSD profiles for HPLC, PCR, and liquid handling capabilities.

14.5 The FHIR Inspiration

PCC's CSD format was directly inspired by BabelFHIR-TS, a FHIR StructureDefinition compiler that generates TypeScript interfaces and runtime validators from FHIR profiles. The planned BabelPCC compiler will compile CSDs to TypeScript interfaces, runtime validators, pricing calculators, adapter scaffolds, and test data generators — the same toolchain that FHIR developers use for healthcare interoperability, applied to physical manufacturing.

15. Technical Implementation

PCC is a pnpm monorepo of 25 packages (including a pip-installable Python CLI), one dashboard application, and over 3,600 tests. It is implemented in TypeScript (ES2022, NodeNext module resolution, strict mode) with Turbo for build orchestration, plus Python for the operator node package.

15.1 Package Architecture

| Package | Description |
|---------|-------------|
| @pcc/spec | Canonical types, Zod schemas, ID generation, W3C DIDs, VCs, Story IP types, P2P types |
| @pcc/kernel | Shop Kernel runtime: adapters, EvidenceEmitter, JobRunner, SensorPipeline, BatchTracker, EncryptionService, IPFS/Storacha storage |
| @pcc/contracts | Solidity: MilestoneEscrow, MockUSDC; TS: CapabilityCertificateService, RewardEngine, StoryIPService |
| @pcc/scheduler | WorkflowCompiler (DAG/topo-sort), CapabilityRouter, competitive auction |
| @pcc/verifier | VerifierMarket, EvidenceVerifier, CommitmentService (Merkle), ZKProofService, BittensorSubnetBridge |
| @pcc/payments | x402 middleware + client; Meteora DLMM capability pricing pools |
| @pcc/contract-builder | Schema-driven contract builder: templates, profiles, resolver, pricing, validator |
| @pcc/orchestrator | TransferGraph, ResourcePool, SampleTracker, ProtocolEngine, ProtocolRunner |
| @pcc/a2a | 41+ typed intents, MessageBus, Conversations |
| @pcc/agent-runtime | BaseAgent, AgentWallet (viem), SolanaAgentWallet, SpendingPolicy, ERC-4337 session keys |
| @pcc/agent-user | UserAgent: discover, negotiate, submit, build contracts |
| @pcc/agent-broker | BrokerAgent: routing, escrow, NLP, FundingHandler |
| @pcc/agent-kernel | KernelAgent: wraps kernel, jobs, evidence |
| @pcc/agent-evaluator | EvaluatorAgent: quality assessment, ACP bridge, reputation |
| @pcc/agent-support | SupportAgent: diagnostic engine, escalation manager, setup guidance |
| @pcc/identity-8004 | ERC-8004 identity/reputation/validation registry clients, cross-chain registration |
| @pcc/onboard-kit | quickStart, scaffold, validate, CLI, AGENT_INSTRUCTIONS.md |
| @pcc/dht | Distributed capability discovery: WebSocket gossip DHT, AnnouncementRegistry, CapabilityQuery engine |
| pcc-node | pip-installable Python CLI: hardware auto-detection, key management, device adapters, camera streaming, daemon loop |
| @pcc/ui | Solarpunk component library: 64+ components, DIDBadge, IPFSLink, ChainTxLink |
| @pcc/gateway | Fastify REST/SSE: 400+ endpoints across 60+ route files, StreamHub, SIWE auth, x402 gate, NEAR 1Click, PCCProtocol routes, marketplace, operator relay, request decomposition |
| @pcc/dashboard | Vite SPA: 57+ routes, React Flow builders, Recharts, 18-step onboarding tour |

15.2 Test Coverage

The test suite has 3,600+ passing tests across 100+ test files (TypeScript + Python), including 497+ gateway API tests, 308 Python tests, and 66 Forge tests for the contracts package. Coverage spans unit tests for every package, integration tests for the gateway API, and end-to-end simulations:

- scripts/e2e-simulation.ts: Kernel-level E2E (job submit → adapter execute → evidence → settlement)
- scripts/agent-e2e-simulation.ts: Agent-to-agent negotiation (UserAgent → BrokerAgent → KernelAgent)
- scripts/sovereign-e2e-simulation.ts: 9-phase sovereign infrastructure test (DIDs, IPFS, Lit, ZK, Bittensor, DePIN, cNFTs)
- scripts/openclaw-print-deliver-e2e.ts: OpenClaw print-and-deliver scenario (3 variations, 37 assertions)

15.3 Multi-Chain Architecture

PCC operates across four chains with distinct roles:

Base Sepolia (chain 84532): Primary escrow and settlement. The MilestoneEscrow contract holds customer funds, manages bonds, and releases payment when evidence is verified. The PCCProtocol root contract clears all Base Sepolia settlements, collecting the protocol fee on every job.

Flow EVM Testnet (chain 545): Secondary settlement chain with sub-cent transaction costs. The same MilestoneEscrow and MockUSDC contracts are deployed to Flow EVM via scripts/deploy-flow-evm.ts. Set PCC_NETWORK=flow-evm-testnet to route the gateway to Flow. Explorer: https://evm-testnet.flowscan.io

NEAR / Cross-Chain (1Click): Cross-chain payment intents. Agents on any chain can fund PCC escrows through NEAR's solver network without managing bridges. Four gateway routes (/api/near/*) and four A2A intent types handle the full quote → submit → settle flow. No SDK dependency — plain fetch() against the 1Click REST API.

Story Network (chain 1514 / Aeneid testnet 1513): IP registration, licensing, royalties, and disputes. CSDs are registered as IP Assets here. Royalty Token distribution and revenue claims happen on Story. The StoryIPService bridges with Base: when escrow releases on Base, it triggers a royalty payment on Story.

Arkhai / Alkahest: Conditional peer-to-peer escrow with EAS (Ethereum Attestation Service) attestations. PCC maps each milestone to an Alkahest obligation — the buyer locks tokens with a demand (evidence requirements for that assurance tier), the operator fulfills by producing an evidence attestation, and the arbiter (PCC's verification layer) validates the result. If valid, escrow releases to the operator. If expired, funds return to the buyer. This provides a second escrow primitive alongside the native MilestoneEscrow, with boolean-native settlement semantics built on attestations rather than contract state.

Roadmap: x402 (HTTP 402 Payment Required) per-request micropayments for lightweight digital services — API access, data feeds, computation — without requiring full escrow setup. The payment gate is not yet active on the gateway's routes.

15.4 Dashboard

The dashboard is a 52-route Vite/React 19 SPA with React Router v7, TanStack Query v5, Zustand v5, Tailwind v4, React Flow (DAG visualization), and Recharts. Key views:

- Contract Builder (/build): Process selector → parameter configurator with real-time constraint validation → pricing preview with Story Protocol revenue split display
- Workflow Builder (/workflow): React Flow DAG editor for assembling multi-step capability chains
- Evidence Explorer (/evidence): Encrypted evidence bundles with decrypt-on-demand and ZK proof status
- DePIN Dashboard (/depin): Treasury balance, soulbound certificate registry, reward epoch history
- Operator Dashboard (/operator): Machine management, earnings, capability certificates, IP Asset holdings

16. Future Work

16.1 BabelPCC Compiler

The BabelPCC compiler will transform CSDs into type-safe TypeScript artifacts: interfaces for job parameters, runtime validators, pricing calculators, adapter scaffolds, and test data generators. The compiler will be published as an npm package (babelpcc) and integrated into the PCC CLI:

babelpcc compile pcc://capabilities/fdm/v2 --output ./generated/
Output:

generated/fdm.ts               — interfaces (FDMParams, FDMConfig)

generated/fdm.validator.ts     — runtime validation

generated/fdm.pricing.ts       — price calculator

generated/fdm.adapter.ts       — adapter scaffold

generated/fdm.test.ts          — test data generators

16.2 Cross-Chain Bridges

Story Network, Base, and Solana operate as independent settlement and identity chains. Cross-chain bridges will enable:

- Royalty Tokens minted on Story to be staked in Base DeFi protocols
- Solana soulbound cNFTs to carry Story IP lineage metadata
- Cross-chain escrow settlement: customer funds in USDC on Base → royalties distributed in WIP on Story → certificates minted on Solana in a single atomic transaction

16.3 Additional Hardware Integrations

The current integration covers OctoPrint (3D printers), Opentrons OT-2 (liquid handling), Modbus (industrial sensors), OPC-UA (CNC/automation), SiLA 2 (lab instruments), and IPP (2D printers). Future adapters will include:

- OpenClaw / OpenDroids: Robot arm control via ROS 2 + Isaac ROS for lab automation tasks
- GMP pharmaceutical: Batch manufacturing via SiLA 2 + 21 CFR Part 11 evidence for regulatory compliance
- Semiconductor equipment: Fab-grade interfaces via SECS/GEM and SEMI E164 standards

16.4 Industry 4.0 Interop via AASX Mapping

A bidirectional CSD ↔ AASX Submodel Template translator will enable PCC to interoperate with Industry 4.0 systems that already speak AASX. A CNC shop running a Siemens MES can export its AAS to PCC, which translates it to a CSD and registers it on the network. PCC capabilities can also be exported as AASX for consumption by traditional industrial systems — allowing PCC to overlay IP and settlement on top of existing Industry 4.0 infrastructure rather than requiring a full replacement.

16.5 Story Protocol Mainnet Migration

Current Story integration targets the Aeneid testnet (chain 1513). Migration to Story mainnet (chain 1514) requires funded IP wallets and production-grade royalty vault management. The StoryIPService is designed for zero-configuration switching: setting STORY_NETWORK=story and STORY_MOCK=false activates production mode with no code changes required.

17. Conclusion

Physical Capability Cloud is the substrate for agent-mediated economic coordination. It applies the three principles that made cloud infrastructure succeed — capability abstraction, unit pricing, credible commitment — to every unit of work, not just compute. The enforcement layer (encrypted IPFS evidence, Lit Protocol access control, Bittensor quality verification, Starknet ZK anchoring, milestone escrow, Story Protocol IP) is what makes its claims load-bearing. The substrate is what makes its claims compose.

What's live in the substrate today

Beyond the three properties named in §1.2, the substrate ships four slots that turn any capability — a machine, a person who can do something, an autonomous asset — into a network participant addressable by any agent:

1. Capability + parameters — what the node does, expressed as a typed Capability StructureDefinition (CSD). FHIR-inspired, inheritable, registered, and counted toward adoption.
2. Service-level agreement — for human-operated nodes, an explicit acceptance window + completion deadline + presence + scheduling mode. For machine-operated nodes, null. Captured in one JSON column.
3. Notification channel — how PCC pings the operator when work lands: a small stable transport enum (webhook, email, SMS, voice, push, MQTT, file, manual) plus a plain-English describe field that the operator's onboarding agent writes during setup. The substrate stays neutral on every specific vendor; new backend integrations appear by conversation, not by adapter code.
4. Availability — when the capability is reachable: always | windows | cron | manual-claim | delegate-to-agent, plus a describe slot for the long tail.

All four slots are addressable from a single A2A skill (pcc-author-integration), which means a user's own agent — talking to the user in their own session, in their own LLM client of choice — can publish a full operator in one round-trip after the setup conversation.

Bidirectional onboarding: the registry talks back

The substrate is conversational on both sides. The user's agent can push data INTO the registry (publish a capability, attach a channel, set availability) AND ask the registry to push candidate templates BACK to the user's agent during setup (pcc-suggest-templates). When the user's agent says "I'm setting up a same-day courier service" or "I have an Opentrons OT-2", the registry returns N candidate CSDs that match — with relevance scores and adoption counts — and the user's agent picks one. This converts onboarding from filling-out-a-blank-form into picking from a library, and it turns the library itself into a marketplace primitive: every adoption is attributed to a CSD, which makes royalty flow and template authorship tractable problems rather than open ones.

Templates can be free (the default — pure substrate primitive) or monetized through smart-contract gating (Story Protocol IP layer, §6). The user's agent is the one that picks. Every node hosted on the network sits at the same place on the same shape — substrate primitives all the way down.

What the substrate's existence implies

In March 2026, PCC's distributed pieces ran end to end in testing. Operators can join the network with pip install pcc-node && pcc-node start. Hardware is auto-detected. Capabilities are announced with Ed25519 signatures and discoverable via a gossip DHT. Agent-to-agent messages are encrypted end-to-end with NaCl box. Execution scopes enforce a four-class security model that allows AI agents to control physical equipment while bounding the blast radius of errors. A real Opentrons OT-2 liquid handler has run jobs through the complete pipeline: brain reasoning on DGX Spark, tool calls relayed through PCC, execution on the device, camera frames streaming back to the dashboard.

The result is a network where a machinist in Detroit and a biologist in Boston can form a trustless workflow without a broker, a marketplace, or a negotiated contract. Where the intellectual property embedded in a manufacturing process earns royalties for its designer forever. Where verified physical work builds permanent on-chain credentials. Where any AI agent can discover, book, and settle a physical capability through a typed API, the same way it calls any other microservice.

The Story Protocol integration is not an afterthought — it is the mechanism that makes the network self-sustaining. When designers earn from every use of their CSDs, they are incentivized to publish better definitions. When operators earn not just from execution but from the IP equity in their device profiles, they are incentivized to maintain and improve their capabilities. When the network treasury accumulates from protocol fees, it can fund the verification infrastructure that makes evidence credible. The economic flywheel is fully specified in the protocol.

This is not a marketplace. It is a protocol — and protocols are how the internet got built.

What This Means

The implications extend far beyond manufacturing efficiency.

The end of geographic monopoly on physical work. Today, if you need something fabricated, you call whoever is nearby — or whoever your procurement team has a relationship with. PCC makes geography irrelevant to discovery. An operator in Lagos competes on the same network as one in Los Angeles. The best price and the best quality win, regardless of where the machine sits. The Yellowcard fiat ramp means the operator in Lagos gets paid in naira. The escrow means neither party needs to trust the other.

AI agents as economic actors in the physical world. We are building toward a world where AI agents don't just write code and answer questions — they commission physical work. An agent managing a supply chain doesn't email a vendor and wait three days for a quote. It discovers capabilities on the network, negotiates autonomously, locks escrow, monitors execution via evidence streams, and settles payment — all in the time it takes a human to open their inbox. PCC is the API that connects artificial intelligence to physical reality.

The operator-owned economy. Every platform economy follows the same arc: aggregate supply, subsidize demand, extract rent. PCC inverts this. The protocol fee is minimal and transparent. There is no algorithm deciding which operators get surfaced. There is no platform that can deactivate your account because you also work for a competitor. Operators own their identity (W3C DIDs), their reputation (on-chain, portable), their evidence history (content-addressed on IPFS, encrypted under their control), and their intellectual property (Story Protocol, with royalties flowing forever). The network works for its participants, not the other way around.

Physical work as programmable IP. When a machinist develops a novel fixturing technique that produces better tolerances, that technique — encoded as a Capability StructureDefinition — becomes an IP Asset. Every time another operator uses that CSD, royalties flow back to the original designer. Physical expertise stops being tacit knowledge trapped in one person's head and becomes composable, tradeable, and perpetually compensated intellectual property.

Verification as infrastructure, not overhead. In the current system, quality verification is a cost center — inspectors, paperwork, disputes resolved by lawyers. In PCC, verification is built into the protocol. Evidence is cryptographic. Proofs are on-chain. Disputes are arbitrated by staked verifiers with economic skin in the game. This doesn't eliminate the need for quality — it makes quality provable, portable, and automatic.

The implications for emerging markets are not hypothetical. A woman in Kenya with a bioreactor and an internet connection can serve pharmaceutical companies anywhere on Earth. She doesn't need a corporate account, a bank that services her region, or a relationship with a procurement department. She installs pcc-node, her equipment is discovered, her capabilities are announced, and her first job arrives when an agent somewhere in the world needs what she can do. She gets paid in her local currency. Her reputation builds on-chain. Her evidence history is permanent and verifiable. She is, for the first time, a full participant in the global manufacturing economy.

This is what it looks like when physical capability becomes as fluid as information.

Appendix A: Story Protocol Contract Addresses

Both Story mainnet (chain 1514) and Aeneid testnet (chain 1513) share the same addresses:

| Contract | Address |
|----------|---------|
| IPAssetRegistry | 0x77319B4031e6eF1250907aa00018B8B1c67a244b |
| LicenseRegistry | 0x529a750E02d8E2f15649c13D69a465286a780e24 |
| RoyaltyModule | 0xD2f60c40fEbccf6311f8B47c4f2Ec6b040400086 |
| DisputeModule | 0x9b7A9c70AFF961C799110954fc06F3093aeb94C5 |
| PILicenseTemplate | 0x2E896b0b2Fdb7457499B56AAaA4AE55BCB4Cd316 |
| WIP Token (mainnet) | 0x1514000000000000000000000000000000000000 |

Appendix B: Default Revenue Split Parameters

| Parameter | Default | Configurable | Description |
|-----------|---------|-------------|-------------|
| commercialRevShare | 5% | 1–50% | Percent of derivative revenue flowing to parent CSD IP |
| Designer Royalty Tokens | 10 / 100 | Yes | Share of all revenue earned by CSD author |
| Operator Royalty Tokens | 70 / 100 | Yes | Share of revenue earned by executing operator |
| Verifier Royalty Tokens | 10 / 100 | Yes | Share earned by evidence verifier |
| Network Treasury Tokens | 10 / 100 | No | Protocol fee, non-transferable |

Appendix C: Key Environment Variables

| Variable | Default | Purpose |
|----------|---------|---------|
| STORY_MOCK | true | false for real Story Network transactions |
| STORY_NETWORK | story-aeneid | story for mainnet |
| STORY_PRIVATE_KEY | none | Private key for Story chain (separate from escrow key) |
| EVIDENCE_STORAGE | helia | storacha for Filecoin archival via Storacha w3up |
| LIT_PROTOCOL_REAL | unset | true for real Lit Network (datil-test) |
| STARKNET_NETWORK | goerli | mainnet for production ZK anchoring |
| PCC_NETWORK | base-sepolia | EVM chain for escrow settlement |

Live Network: [capability.network](https://capability.network)

Agent Package: [capability.network/agent-package.json](https://capability.network/agent-package.json) (218 tools, v2.8.0, for any LLM agent)

Operator Node: pip install pcc-node && pcc-node start

Repository: [github.com/global-mysterysnailrevolution/physical-capability-cloud](https://github.com/global-mysterysnailrevolution/physical-capability-cloud)

Hackathon: PL Genesis: Frontiers of Collaboration — Fresh Code Track — Deadline March 31, 2026