IOI: Internet of Intelligence Technical Whitepaper

About This Document

This technical whitepaper describes the architecture, security model, and protocol mechanics of the Internet of Intelligence (IOI).

It is intended to document the system as designed and under active development, and to serve as a reference for contributors, reviewers, and early integrators.

Detailed interfaces, implementation details, and evolving components are documented separately in the IOI documentation and repositories.

Thesis note: IOI is an open intent-to-outcome architecture for verifiable machine labor. Users express jobs to be done; the network routes work across compute, data, models, tools, workers, services, evaluations, and workflows; and the result returns with receipts, provenance, and settlement context. Alignment security for machine authority is the invariant that makes this possible: consequential actions become authorized, policy-bound, receipt-backed, replayable, challengeable, and settleable without treating raw model output as law.

Terminology note: this document uses Worker as the canonical protocol actor. "Agent" may appear in product-facing or colloquial contexts, but the normative unit of executable authority is the Worker: a bounded actor with a manifest, policy envelope, capability surface, receipt obligations, and settlement identity. A model is not the actor; it is a cognition backend used by a worker. This distinction is essential to the Mixture of Workers execution architecture and the Market of Workers economy introduced below.

IOI in One Sentence

IOI is the Internet of Intelligence protocol: an open, decentralized, intent-to-outcome network for verifiable machine labor, where bounded workers compose compute, data, models, tools, services, evaluations, and workflows under alignment-secure authority so consequential actions become authorized, replayable, accountable, and economically settleable.

Executive Summary

IOI defines a Web4 runtime for bounded autonomous software execution. Its core claim is narrow: probabilistic models may reason and plan non-deterministically, but consequential actions that affect capital, credentials, durable state, third-party rights, or settlement must become canonical, authorized, policy-bound, receipt-backed, replayable, and settleable before execution.

IOI is not only a model network and not only a safety layer. It is an intent-to-outcome network: demand enters as a job to be done, and supply is an open set of compute, data, models, workers, tools, services, evaluations, and multi-worker workflows. The organizing security problem is machine authority: when software can spend money, execute code, use credentials, mutate durable state, affect third-party rights, or trigger settlement, safety cannot rest on an unverifiable model response. IOI provides alignment security by moving enforceable guarantees into explicit authority grants, deterministic runtime boundaries, canonical state transitions, receipt obligations, evidence bundles, and dispute-aware settlement.

The architectural boundary between model reasoning and economic consequence is the Determinism Boundary. Upstream of the boundary, workers may use any cognition backend: hosted frontier models, local open-weight models, retrieval systems, deterministic tools, verifier ensembles, or mixtures of those systems. Downstream of the boundary, a deterministic runtime normalizes the requested act, checks capabilities and authority, enforces policy, and emits receipts that can support audit, insurance, arbitration, and settlement. Validity is defined by evidence, not by hardware: clean-room execution can be satisfied by TEEs, zero-knowledge proofs, verifiable computation, MPC, FHE, deterministic replay, or hybrid bundles, with the receipt set defined by the action class.

IOI treats the Worker, not the model, as the protocol actor. A worker has a manifest, policy envelope, capability surface, receipt obligations, identity, and settlement posture. The model is a component mounted by the worker. This distinction enables Mixture of Workers at runtime and the Market of Workers at network scale: routed labor graphs in which planners, executors, verifiers, tools, and services can be selected, paid, benchmarked, and disputed as accountable contributors.

This is why the Worker is the economic actor. The model supplies cognition; the worker supplies bounded agency. Authority, receipts, contribution accounting, reputation, disputes, and settlement attach to the worker and its manifest, not merely to whichever model powered one reasoning step.

Worker Training creates the supply side of the Market of Workers. A customer or builder does not merely buy a fine-tuned model; they can produce a trained, evaluated, policy-bound worker with a manifest, lineage refs, benchmark receipts, evaluation receipts, authority requirements, and contribution policy. Hypervisor Foundry is the primary local product surface for this lifecycle. This is a concrete commercial wedge, not the whole IOI thesis: the broader network still depends on open compute, data, models, evaluations, routing, services, payments, and settlement.

IOI is operationalized through separate but interoperable product domains. Hypervisor is the local desktop/runtime workbench and Foundry surface. aiagent.xyz is the worker marketplace for publishing, benchmarking, ranking, installing, initializing, and routing workers. sas.xyz is the marketplace for autonomous service outcomes, including worker-training contracts and worker-composed services. internetofintelligence.com is the lightweight control plane for accounts, devices, restore routing, publishing, sync metadata, and remote-runtime entitlement. IOI L1 is the public settlement, registry, rights, dispute, and governance root. The whole system exists to turn user intent into verified outcomes by coordinating independent supply layers rather than centralizing intelligence inside one application.

aiagent.xyz supports two usage shapes. First, workers can be installed as composable capabilities inside Hypervisor, sas.xyz outcomes, enterprise runtimes, or MoW labor graphs. Second, workers can be initialized as managed instances bound to a user, organization, project, subscription, authority policy, runtime profile, and memory/archive policy. Managed instances may be invoked through web chat, API, Hypervisor, workflows, service outcomes, or router-selected MoW tasks. This makes aiagent.xyz both a supply marketplace and a direct intelligence access surface without making it the centralized execution runtime.

Hypervisor trains and runs workers. aiagent.xyz publishes and initializes workers. sas.xyz sells worker-powered outcomes. internetofintelligence.com coordinates accounts, devices, restores, publishing, and remote-runtime entitlement. IOI L1 settles and governs public commitments.

The IOI Daemon implements the runtime boundary. It isolates untrusted workload execution, translates tool requests into canonical ActionRequests, evaluates ActionRules, obtains wallet.network authority grants when needed, and records outcomes in a hash-linked receipt chain. The same artifact semantics apply locally, in provider sessions, in customer-boundary deployments, and at IOI L1 settlement or dispute commitment. Execution happens at runtime edges and domain kernels; IOI L1 is the public trust root for commitments that need registry, rights, settlement, or dispute finality. The blockchain is not used as a global cognition engine; it is used for escrow, routing anchors, identity anchors, commitments, and dispute resolution.

IOI inverts the traditional blockchain topology. It does not begin by forcing all application state through global consensus. Work begins at the edge: local devices, hosted runtime nodes, customer VPCs, TEEs, DePIN nodes, and provider sessions. Domain kernels maintain operational truth through Agentgres. IOI L1 receives sparse public commitments only when the domain needs registry, rights, escrow, fee routing, dispute, governance, or settlement finality. This lets the intelligence economy scale across many independent providers without turning the L1 into a bottleneck for cognition or application state.

Agentgres supplies per-domain canonical operational truth: accepted operations, object heads, state roots, constraints, invariants, projections, subscriptions, receipts, quality/contribution ledgers, settlement mirrors, and sealed archive refs. ioi-memory supplies private semantic memory, retrieval surfaces, execution traces, and task-scoped context slicing. Sealed State Archives provide portable encrypted cold state, while Agentgres remains the authority that records what archive exists, what state it represents, who may restore it, and which receipt makes restoration valid. Domain Ontologies and Data Recipes supply ontology-bound domain truth for training, evaluation, projections, benchmarks, and worker/service composition. Together they replace the split between opaque SaaS databases and stateless AI tool wrappers with a portable state and semantic-data model for sovereign applications.

Agentgres may expose Postgres-compatible projection/query surfaces for adoption, analytics, BI, admin tooling, and application reads. This bridge does not define Agentgres identity. Canonical writes still compile into Agentgres operations with schema, policy, authority, invariant, and receipt checks. This keeps familiar data access available without collapsing IOI back into a row-centric app stack.

IOI also requires a semantic data plane. Domain Ontologies define the entities, relationships, events, actions, states, roles, and invariants of a domain. Data Recipes map raw sources, documents, traces, and connector payloads into canonical objects, policy-bound data views, distilled training signal, evaluation datasets, and Agentgres projections. This is what turns worker training from "upload data and tune a model" into repeatable, auditable, comparable domain capability. It is also what lets the wider IOI economy pay, route, and evaluate data contributions without collapsing data into opaque platform custody.

The economic model is a market for verifiable work. Users may buy outcomes through Gig Escrows, operate embedded workers under strict policy limits, or consume work credits that settle to providers, developers, and contributors through receipts. Labor Gas prices orchestration, compute, royalties, settlement, and routing. Arbitration is staged: cryptographic verification first, objective tests second, constrained semantic review third, and human escalation last.

The end-to-end architecture has seven supply legs: compute for execution, data for domain truth, models for cognition, evaluations for capability evidence, workers for bounded agency, workflows for composition and routing, and an economy for contracts, contribution accounting, payment, recourse, and settlement.

IOI does not claim to make neural inference deterministic, prove model wisdom, or put every local action on-chain. It claims that consequential action can be bounded by deterministic runtime controls and made economically legible through canonical receipts, explicit authority, and settlement-aware recourse.

1. Web4 Thesis and Scope

Web4 extends the web primitive ladder from Read, Write, and Own to Act. Act is executable ownership: delegated software authority that inherits the deterministic guarantees of Own when it crosses a consequential boundary. This formulation appears once as the thesis, not as a repeated slogan.

The Web4 thesis is therefore a machine-authority thesis. Read made information addressable. Write made publication interactive. Own made value programmable. Act makes delegated authority executable. IOI exists because an open network of intelligence can only become useful at economic scale if executable authority is alignment-secure at the boundary where intent becomes consequence.

The scope is intentionally limited. A browser click, local inference step, draft, or file read need not become an on-chain transaction. The requirement is that any boundary touching ownership, credentials, durable state, third-party rights, escrow, or settlement must become transaction-shaped: canonicalized, authorized, policy-bound, replayable, and settleable.

The stable unit of governance is the bounded act performed by a worker under an authority envelope, not the model response that proposed it. Model internals can change, model outputs can vary, and models can be swapped. The protocol-visible actor is the Worker: a bounded execution unit with identity, manifest, policies, capabilities, receipt obligations, and settlement posture. This worker-as-actor framing is what makes Mixture of Workers possible at runtime, and a Market of Workers possible at network scale: routed labor graphs in which planners, executors, verifiers, tools, and services can be selected, paid, benchmarked, and disputed as accountable contributors.

The IOI architecture is local-first and fractal. Local execution preserves speed, privacy, and zero marginal network fees. Provider sessions add elastic capacity and specialized execution. IOI L1 handles escrow, identity anchors, sparse commitments, and disputes. The invariant across those planes is not global execution; it is consistent artifact semantics at the consequential boundary. The same canonical ActionRequest, policy hash, approval chain, capability scope, and receipt obligations apply whether the workload runs on a personal device, a customer VPC, a hosted provider, a hardware-confidential clean room, or a cryptographic clean room.

To facilitate seamless integration into existing developer workflows, the local machine-labor operating domain is split as follows:

1. Hypervisor Node: The headless execution and local settlement domain. It hosts governed autonomous-system chains, manages local interop, processes local module invocations, and resolves local authority outcomes without consuming public L1 gas.
2. Hypervisor Workbench: The native, IDE-grade operator console for composing, replaying, and supervising workflows. It is a client of the Hypervisor Node, not the node itself.
3. IOI Authority Gateway (packaged as Hypervisor Guard): A non-intrusive, background sidecar profile acting as a deterministic boundary for third-party developer interfaces.

This is an edge-in topology. Authority-bearing work starts close to the user, project, provider, or compute venue; becomes canonical inside a domain kernel; and settles upward to IOI L1 only when a public trust commitment is required.

The reader should expect this paper to introduce the runtime architecture (Section 2), state and memory (Section 3), network/routing/work-graphs including MoW (Section 4), settlement and consensus (Section 5), cryptography and clean-room evidence (Section 6), identity and authority (Section 7), economics and arbitration (Section 8), security and evolution (Section 9), and protocol surfaces (Section 10). Normative schemas -- ActionRules, Firewall artifacts, session artifacts, dispute schema -- are collected in Appendix A. Other appendices cover canonical envelopes, the developer quickstart with connector manifest, claims and non-claims, fail-closed verdict logic, and references.

1.1 From Shared Gradients to Verifiable Labor

IOI differs from federated-learning and 6G visions of the Internet of Intelligence. Those architectures primarily optimize cooperative model training, gradient sharing, and distributed inference across edge devices. IOI instead uses the term in a narrower architectural sense: it defines the Internet of Intelligence as a settlement-aware execution fabric for autonomous Workers.

The protocol does not require participants to reveal weights, training data, prompts, datasets, or proprietary reasoning traces. Intelligence may remain privately produced and privately owned. What becomes protocol-visible is the Worker: its manifest, authority scope, policy boundary, evaluation evidence, execution receipts, and contribution claims.

This shifts the organizing unit of the network from shared gradients to verifiable labor. The next internet routes work, not pages. IOI makes autonomous work authorized, receipted, portable, and accountable.

2. The IOI Runtime Architecture

IOI is defined by a fractal, edge-in runtime architecture. The local coordination layer is the Hypervisor Node, which serves as a local settlement domain. Inside the node, the IOI daemon serves as the deterministic execution and authority-enforcement substrate.

Rather than running as ad-hoc scripts, autonomous systems run as Governed Autonomous-System Chains. These are local, stateful execution chains containing policies, modules, proposals, and receipts. The Hypervisor Node manages local interop and settles authority outcomes through Agentgres, anchoring selected roots to IOI L1 only when global registry, economics, reputation, or dispute resolution are required.

This architecture serves as an Evolutionary Sandbox. It allows agents to introspect their own performance, propose mutations to their own logic, and atomically upgrade themselves, but only if the mutation satisfies the immutable safety constraints defined by the user. In high-assurance continuity profiles, mutations can also carry recursive continuity proofs that independently verify lineage across deployed generations.

This stack is designed to be fractally self-similar: the same core components run on a user device (Local), a provider (Session), and IOI L1 (Global). Environments differ in capacity and trust profile, but they share the same artifact semantics, canonical payloads, binding hashes, and attestation rules, so outcomes can be upgraded across the Market for Liability without reinterpretation.

2.1 The Protocol Core: The Four Pillars of Agency

To make probabilistic AI legally and economically enforceable -- and to make Own executable as Act -- the IOI runtime relies on four tightly coupled cryptographic contracts. These primitives ensure that intelligence is strictly bounded before any state mutation occurs, providing a clear roadmap for protocol engineers implementing the stack:

1. Pillar 1: Canonicalization. Every intent or tool call generated by an agent is intercepted and normalized into a mathematically stable JSON representation (RFC 8785) before hashing. This guarantees byte-level determinism across heterogeneous hardware.

2. Pillar 2: Policy Binding (policy_hash). The boundaries of agency are not heuristic. All rules, constraints, and scope definitions are normalized, deterministically ordered, and hashed. This policy_hash serves as the immutable law of the session.

3. Pillar 3: Pre-Effect Commitment (CommittedAction): Before a side-effect touches the host system (network, filesystem, or GUI), the runtime binds the request hash, the policy hash, and any required user approvals (binding the exact request hash, scope, expiry, and revocation epoch) into the transaction-shaped evidence bundle for the act.

4. Pillar 4: Settlement Binding. Execution receipts are compiled into a Merkle root (receipt_root). The economic layer explicitly binds the session ID, the policy hash, and the receipt root to the on-chain escrow, creating an airtight liability loop between the agent's actions and the provider's capital.

Design Doctrine: Process Safety over Model Safety IOI accepts that global consensus is too slow for cognition and local execution is too unsafe for settlement. Furthermore, attempting to force bit-for-bit determinism onto the neural network inference layer fundamentally breaks the utility of modern AI.

IOI achieves verifiable agency by moving safety invariants out of the "black box" of the model and into explicit, checkable protocol surfaces at the execution boundary:

• Canonicalization & Pinned IO: Ensures that the effects of intelligence are replayable and auditable, even if the underlying inference process is stochastic.

• Typed Steps & Bounded Classification (ICS): Enforces hard constraints and strict type-matching before any model-based judgment is permitted to cross into shared reality.

• Deterministic Retries & Failure Routing: Acknowledges that agents will fail. Retries are permitted, but they must be deterministic, bounded by strict attempt counts, and fully recorded in verification evidence rather than looping silently.

• Content-Addressed Evidence & Due Process: Prevents "he-said-she-said" disputes by requiring cryptographic proof of state. The protocol enforces a strict taxonomy between Enforceable Artifacts (consensus-critical receipts and commitments, stored as sparse roots on L1) and Observational Artifacts (local telemetry and wallclock timestamps, stored in Agentgres operation logs), ensuring disputes are resolved exclusively via mathematically binding evidence.

2.2 The IOI Daemon & Multi-Plane Architecture

The IOI daemon is the universal execution endpoint. It is not the L1, not the L0 substrate, and not the SDK. It is the core execution substrate inside the Hypervisor Node. Local Hypervisor-managed processes, hosted providers, DePIN nodes, TEEs, enterprise/private runtimes, and customer VPCs all run daemon-compatible runtime profiles.

2.2.3 Hypervisor Node Local Boundary

Hypervisor Node is the local autonomous-system settlement and interop domain.

• The Daemon is the execution and authority-enforcement engine inside the node.
• The Workbench is the operator UI console.
• Agentgres provides the operational truth substrate.
• wallet.network manages the authority path.
• The Model Router handles policy-bound model invocation and routing boundaries.

When the daemon executes an autonomous-system harness, it runs it as a modular state-transition pipeline. Consequential steps are executed as typed Service Module Invocations. The daemon writes governed transitions and local settlement records through Agentgres-compatible APIs without writing directly to IOI L1.

Product domains are not runtime nodes by default. A web app, marketplace, or control plane may create runtime assignments, request daemon-compatible execution, or project runtime state, but workers execute inside local, hosted, decentralized, enterprise, TEE, or customer-boundary runtime profiles. A managed worker instance does not make aiagent.xyz the execution runtime. aiagent.xyz resolves the worker package, install/license rights, runtime profile, authority requirements, subscription policy, and memory/archive policy. Execution occurs on a daemon-compatible runtime node: local machine, hosted provider, DePIN node, TEE, GPU job, browser sandbox, customer VPC, or enterprise/private runtime.

Every execution node that performs IOI work runs, embeds, or speaks to a daemon-compatible runtime profile. The Daemon decouples logical isolation from physical hardware via a Multi-Plane Scaling Architecture. The invariant is: regardless of deployment target, every node enforces the same isolation contract, the same artifact schema, and the same policy evaluation pipeline. What varies across deployments is capacity, trust posture, and attestation class, not the kernel semantics.

Deployment examples: locally (Hypervisor), the planes collapse into a user-space virtualization layer over the host OS. On a provider (sas.xyz), they scale horizontally across four distinct planes, engaging cryptographic settlement only when required:

Plane A: The Edge / Admission Plane

• Role: The stateless API and routing layer.

• Responsibilities: Handles initial authentication, rate limiting, request normalization, routing, and session admission. It acts as the programmatic ingress for hosted internetofintelligence.com queries and third-party dApps.

Plane B: The Inference Plane

• Role: The cognitive engine.

• Responsibilities: Horizontally scaled by model pool and queue depth. It handles fast reasoning, embeddings, and rerankers. It utilizes warm capacity (Provider OSS or proprietary models) to eliminate cold starts for standard queries, while safely routing Bring-Your-Own-Key (BYOK) requests, where wallet.network brokers BYOK keys and never exposes them to raw workflows.

Plane C: The Execution Worker Plane (The Guest)

• Role: The isolated environment where the "Alien Intelligence" (AI model, external script, or third-party binary) executes its tools. It is strictly air-gapped from the host network and the user's primary state.

• Responsibilities: Horizontally scalable worker nodes that execute workflow steps, tool calls, browser/runtime jobs, and generate raw artifacts.

• Isolation: Runs in containerized namespaces (e.g., Docker/Bubblewrap) or remote managed bridges. It boots in a zero-trust state. The worker utilizes a Transparent Sidecar Proxy (NetDriver) injected by the Coordinator to intercept all API calls, enforcing strict capability limits.

Plane D: The Kernel / Coordinator Plane (The Authority)

• Role: The bounded, capacity-governed execution control role. This is the always-on runtime authority that holds run state, policy bundles, tenant configurations, and cryptographic receipts.

• Runtime Node Modes: Execution venues that run IOI daemon profiles.

• Hosted IOI Runtime: Hosted by the provider or provider-managed infrastructure for fast, consumer-facing tasks.

• Customer VPC Runtime: Deployed directly inside a customer's VPC or on-prem environment, allowing sas.xyz to orchestrate tasks without exfiltrating enterprise data.

• Local Hypervisor: Embedded inside Hypervisor on the user's personal device.

• IOI Authority Gateway (Sidecar Profile): Run locally or within customer boundaries to act as an external execution and policy boundary. Rather than serving as the primary interface, it runs as a background process ("sidecar") to intercept, evaluate, and authorize action requests generated by third-party cognitive environments.

• Customer Boundary Runtime: Deployed inside a customer VPC or on-prem environment so orchestration can occur without exfiltrating enterprise data.

• Hardware-Attested Confidential Runtime: A TEE-backed runtime that may provide hardware attestation and memory-confidential execution under a vendorspecific threat model. One admissible clean-room substrate among several.

• Cryptographic Clean-Room Runtime: A proof-carrying runtime that uses FHE, MPC, ZK proofs, verifiable computation, or a hybrid construction to produce externally verifiable evidence without treating hardware attestation as the root of validity.

• The Guardian (Security Monitor): Operating within the Coordinator Plane, the Guardian holds protected signing keys and maintains the local receipt-chain authority for a runtime. It does not by itself define protocol validity. Its signatures are accepted only when bound to canonical requests, policy hashes, monotonic sequence state, receipt obligations, and the applicable verifier requirements. The Guardian integrates an Oracle (a remote or enclave-bound minimal binary) that maintains a persistent, monotonic counter (seq) on disk to enforce an append-only, non-equivocating receipt chain.

Safety Invariant: Because the Oracle enforces monotonic sequence advancement on disk, equivocation becomes detectable under the declared storage and runtime threat model. A compromised host or execution worker cannot produce valid higher-tier evidence unless it also satisfies the receipt-chain, verifier, and challenge requirements for that action class.

2.2.1 Plane-Enforced Isolation

The IOI Daemon enforces a strict Air Gap between Plane C (where the AI thinks and executes tools) and Plane D (where the Coordinator evaluates policy and signs state). The Coordinator mediates all I/O via the Agency Firewall, ensuring that a compromised Execution Worker cannot escape the virtualization boundary. When a worker requests an action (e.g., an API call), wallet.network performs brokered secret execution or issues an operationscoped short-lived token. The worker process never sees the raw secret.

2.2.2 Deterministic IO and Pinned Externalities

To ensure that agent execution can be audited and arbitrated on-chain, the Orchestrator enforces Pinned IO. Agents cannot access non-deterministic system resources directly; they must access them via Kernel interfaces that produce canonical receipts.

• Pinned Time & Determinism Semantics In a distributed asynchronous network, wall-clock time is inherently non-deterministic. To prevent "timestamp drift" from breaking consensus or receipt verification, IOI enforces a strict separation between enforceable time and observational time.

• Chain Time (Enforceable / MUST): Derived exclusively from Mainnet block headers or the cryptographic monotonic counter within the TEE's Oracle. Enforceability artifacts (Commitments, Receipts) MUST use Chain Time or deterministic monotonic sequence numbers (seq) for cryptographic bindings and replay protection.

• Wall Time (Observational / Non-Binding): Derived from local SystemTime::now(). Wall time is used strictly for UI telemetry, activity streams, and non-binding debug logs. It MUST NOT be used to validate policy expiries or settle disputes.

• Pinned Network:

• Requests are routed through the Orchestrator (NetworkCall).

• Responses are captured, hashed, and emitted as a NetworkReceipt.

• Large response payloads MUST be referenced via a Content Identifier (CID); small payloads MAY be inlined.

• Pinned Randomness:

• Derived deterministically using a domain-separated PRF keyed by a Future Block Hash (VRF) or a Commit-Then-Reveal scheme from the User Node. The selection of an audit must remain unknowable to the Provider until after the Receipt is committed.

• Pinned Context (Focus Interlock):

• To prevent "Confused Deputy" attacks where an agent clicks the wrong window (e.g., clicking a background browser instead of the intended calculator), the Kernel enforces an atomic Context Interlock.

• Mechanism: The InteractionTarget is derived from the user's intent. Before any kinetic input (Click/Type) is executed, the OS Driver verifies that ActiveWindow == InteractionTarget.

• Enforcement: If the contexts mismatch, the Kernel creates a Hard Fault before the click occurs, preventing the action and forcing the agent to execute a os__focus_window correction routine.

Normative Invariant: The only nondeterminism allowed in the system is nondeterminism that is cryptographically committed- ensuring verifiability on demand.

The "Run Anywhere" Property IOI's portability is achieved by separating kernel semantics from workload packaging. The IOI Secure Hypervisor is the execution invariant: it defines how policies bind, how receipts are formed, and how attestations are produced.

Workloads are packaged as Universal Protocol Artifacts (e.g., OCI images or equivalent bundles), allowing a workflow built locally on a laptop to run on a cloud provider or committee node with no code changes. What changes across environments is the assurance level: a self-attested receipt on a User Node can be upgraded to a provider-attested receipt in a session, and further escalated into bonded commitments or certificates on Mainnet.

2.2.4 The Sidecar Deployment Profile (IOI Authority Gateway)

When running in sidecar mode (marketed to developers as Hypervisor Guard), the IOI Daemon operates as a deterministic, policy-enforcing hypervisor for external, unaligned processes. In this profile, the daemon does not drive the agent's cognitive loop (the "thinking"). Instead, it intercepts proposed effects at the host operating system and network boundaries.

This architecture implements the core thesis: Models reason; IOI authorizes action.

A. Control Points and Interception Boundaries

Because third-party cognitive engines (such as Cursor, Claude Code, or Codex) operate inside proprietary or closed-source runtimes, the Authority Gateway enforces alignment at the host boundaries through six deterministic control points:

1. Shell Commands: The gateway intercepts terminal executions, verifying package installations, file deletions, network sockets, process spawns, and deployment commands against active ActionRules.
2. File System Watcher: Monitors workspace diffs and git configuration files. The gateway blocks unauthorized writes to protected system directories or sensitive file extensions.
3. Git Hook Mediation: Enforces policies on branches, force-pushes, and commit signing, automatically binding signed commit hashes to corresponding execution receipts.
4. Secret Isolation (wallet.network): API keys and deployment credentials remain within the Sovereign Vault. The sidecar injects temporary, operation-scoped credential leases at the network edge, ensuring the raw secret material is never exposed to the agent’s context window.
5. MCP Gateway: Acts as a local Model Context Protocol (MCP) proxy. Tool calls proposed by the external agent must resolve to schema-validated ActionRequests before execution.
6. Context-Aware Approvals: Triggers the Hardware-Interrupted Step-Up Gate when an external agent attempts an action exceeding autonomous limits (e.g., spending capital, modifying production environments).

2.3 The Anatomy of a Worker

The IOI runtime decomposes agency into composable primitives rather than treating each agent as a monolithic container. This decomposition serves three purposes: deterministic execution boundaries, portability across deployment targets, and intellectual property isolation between participants.

The Worker Ontology The IOI runtime decomposes agency into four distinct primitives:

1. Worker: The core execution unit. Each worker has a defined role, a policy scope, a computational budget, and a capability set (defined by a canonical WorkerManifest). Workers are actors, they do things.

2. Model: The cognitive backend. Models are cognitive backends, not peers to workers. The node owns the model routing and invocation boundaries. Model weights, local model files, local model servers, and provider endpoints are mounted by a Model Deployment Profile, and are not part of the Hypervisor Node binary by default.

3. Capability: Capabilities are what workers use. This surface groups four pillars: 1. Connections (authenticated reach to external systems), 2. Computer Use (direct digital action, browser, desktop, terminal), 3. Skills (reusable, named operating patterns), and 4. Extensions (installable packages that grant new capabilities).

4. Extension: An installable package that grants new capabilities to a worker, extending its capability surface without modifying its core policy or identity.

Model Routing vs. Worker Routing IOI distinguishes model routing from worker routing.

Model routing selects a cognition backend: OpenAI, Anthropic, Gemini, local open-weights, fine-tuned models, MoE systems, or provider-routed inference.

Worker routing selects an accountable actor: a bounded worker with a manifest, policy envelope, tools, runtime requirements, receipt obligations, license terms, and settlement identity.

Mixture of Experts (MoE) is model routing. Federated Learning (FL) is cooperative training. Mixture of Workers (MoW) is accountable labor routing.

Mixture of Workers is how autonomous labor executes. Market of Workers is how autonomous labor is discovered, priced, governed, and settled.

A Worker may internally use a dense model, an MoE model, a fine-tuned local model, a toolaugmented model, a rules engine, a human approval path, or a specialist trained, configured, or evaluated through synthetic-data workflows. The protocol does not privilege the internal substrate. It binds accountability to the Worker identity, manifest, policy envelope, authority chain, evaluation receipts, contribution receipts, and settlement surface. This preserves intellectual property while ensuring that benchmarks, disputes, and royalties attach to the verifiable actor rather than the opaque cognitive engine.

Node Packaging Principle: The Hypervisor Node contains model routing and invocation contracts; the model itself is a mounted cognition backend unless a deployment profile explicitly declares bundled weights. Bundled weights are allowed only when declared by specific offline or local-only deployment profiles and are not the architecture default. Service modules and workers invoke models strictly through route aliases, never via direct file assumptions or hardcoded provider names.

Instead, a "Worker" is decomposed into distinct, composable primitives. This structure aligns with the Model Context Protocol (MCP) while enforcing the IOI Kernel's unique security invariants. It rigorously enforces the separation of Logic (Routing), Cognition (Thinking), and Execution (Acting).

[[figure:anatomy-of-an-agent]]

1. The Agent Core (Logic, Cognition & Context) To protect developer IP while maintaining zero-idle infrastructure, the Agent's "Brain" is never packaged as a single heavy asset. It is strictly decoupled into three sub-components defined in the Worker Manifest:

• The Logic Binary (WASM): The state machine, prompt templates, tool wiring, and ReactFlow node configurations are compiled into a lightweight WebAssembly (WASM) binary (typically <5MB).

• IP Protection (The Obfuscation Moat): By compiling to WASM, the developer's proprietary workflow logic is protected from casual reverse-engineering while remaining perfectly portable across local devices and cloud providers.

• The Cognition Engine (Models & Weights): Logic binaries do not contain model weights; they declare cognition dependencies. Public foundational models may be fetched from public registries or caches. Proprietary models and private retrieval substrates are encrypted at rest and hydrated only under the action's declared cleanroom evidence profile. Depending on the workload, the profile may require TEE attestation, FHE-backed private evaluation, MPC execution, ZK-proven model computation, deterministic replay evidence, or hybrid evidence. TEEs are admissible where ordinary software compatibility and performance matter. FHE/MPC/ZK-based execution is preferred where the action class requires stronger external verifiability or reduced dependence on hardware attestation roots. In all cases, the model or program hash, input commitments, output commitments, policy hash, leakage bounds, and verifier requirements are bound into the CleanRoomExecutionReceipt. This reduces exposure under the declared substrate threat model and makes any authority-critical claim dependent on receipt completeness, not on trust in the execution venue.

• The Sovereign Context (The Data Moat): For complex agents relying on public open-weights, the developer's true IP is often their proprietary data. The agent's knowledge base (e.g., 50,000 proprietary trading algorithms) is stored as an encrypted Vector Database within the local ioi-memory / Agentgres substrate. Even if the WASM logic is decompiled, without the decryption key for this memory substrate, the agent is braindead.

2. Tools (The Cognitive Interface / Intent)

• Analogy: OpenAI Function Definitions, MCP Resources & Prompts.

• Definition: The intent schema exposed to the Foundational Model or Cognition Engine.

• Role: Allows the model to request an action.

Invariant: A Tool Call is a request, not an execution grant. When a model selects a Tool, it generates a ActionRequest (derived from the MCP CallToolRequest standard). This request is treated as untrusted input and MUST be validated by the Agency Firewall before any side effect occurs.

3. Drivers (The Execution Layer / MCP Servers)

• Analogy: Model Context Protocol (MCP) Servers, Hardware Drivers.

• Definition: The binary or process that performs the I/O.

• Architecture:

• Software Drivers (MCP Wrappers): Standard MCP servers (e.g., stripe-mcp, filesystem-mcp) wrapped by the IOI Kernel and bound by explicit Runtime-ToolContract schemas defining primitive capabilities and risk classes. The wrapper handles credential injection and policy enforcement transparently.

• Hardware Drivers (IOI Core): Native code holding OS handles (e.g., Enigo for mouse control, xcap for screen capture). These provide the zero-latency "Atomic Vision-Action Lock" required for GUI agents, which standard MCP over JSON- RPC cannot guarantee.

• Role: Executes the authorized I/O. Drivers do not "think"; they obey the kernel.

Invariant: Drivers are Air-Gapped from the Model. They never receive raw tokens or persistent API keys. They only receive policy-validated, canonical payloads from the Orchestrator, injected with ephemeral credentials for the duration of a single operation.

2.4 The Determinism Boundary (Invariant)

As established in the Prologue and Section 1, IOI does not make AI deterministic. It makes agentic state transitions deterministic by enforcing the following invariants at the execution boundary.

The Determinism Boundary is the alignment-security boundary. It does not make inference deterministic. It determines when a proposed act has enough canonical input, authority, policy binding, evidence, and settlement context to become a consequential effect. The Determinism Boundary decouples Cognition from Sanction and extends Own into Act. Models run on any hardware, embracing hardware-induced drift. Strict mathematical determinism is enforced only at the Agency Firewall using integer-bound computation.

[[figure:determinism-boundary]]

Upstream (fuzzy): Models may be stochastic, creative, and adaptive. The Boundary: Before any output can affect shared state (payments, votes, property, credentials, durable records, irreversible actions, or settlement), it must pass through a strict, normative invariant set. This is the consequential boundary of Web4 Act. Downstream (rigid): The resulting artifact (Receipt -> Commitment -> Certificate/Resolution) is immutable, machine-verifiable, and enforceable.

The Determinism Boundary Invariant Set (DBIS) To ensure skeptics, auditors, and protocol engineers can mathematically verify the execution boundary, the IOI Kernel enforces the following normative invariants:

DBIS-1: Canonicalize-before-hash/sign (MUST, Fail-Closed): All ActionRequest objects and any commitment material MUST be canonicalized via RFC 8785 (JSON Canonicalization Scheme) prior to hashing (e.g., try_hash()) or signing. This prevents cross-runtime mismatch and ensures hashes are stable. Failure to canonicalize MUST result in the request being dropped.

DBIS-2: Tiered Safety Decision Determinism:

• DBIS-2A Deterministic Safety (MUST): Any decision that changes the Allow / Block / Require Approval semantics for high-risk actions MUST be computed via a deterministic mechanism (e.g., a pinned Canonical Inspection Module snapshot running in a strict WASM sandbox).

• DBIS-2B Advisory Safety (MAY): Non-deterministic models (e.g., standard LLMs) MAY be used for heuristic hints, intent parsing, or assistive transforms only if the final enforceable decision remains fully DBIS-2A compliant.

DBIS-3: Explicit and Scoped Pinned Externalities (MUST): Externalities relevant to execution MUST be deterministically bound. For example, window_id and visual perceptual hashes are explicitly pinned for UI and browsing actions. However, wall-clock timestamps (e.g., SystemTime::now()) are explicitly classified as non-binding telemetry unless sourced directly from a verified chain/block timestamp.

DBIS-4: The Deterministic Retry Contract (SHOULD): Agents inherently fail and retry. Retries are permitted, but they MUST be deterministic, bounded, and fully recorded. A failed execution MUST generate a failure receipt, increment a deterministic attempt counter against a strict budget, and be included in the verification evidence. Unbounded, unlogged heuristic loops are strictly prohibited.

DBIS-5: Binding Set for Enforceability Artifacts (MUST) For any consequential action that crosses the boundary, the runtime MUST emit a transaction-shaped enforceability artifact (e.g., a CommittedAction record) that securely binds:

1. request_hash (The canonical intent)

2. policy_hash (The ruleset governing the action)

3. Context bindings where relevant (e.g., window_id)

4. Approval references (if the action required a user step-up token)

Enforceable vs. Observational Artifacts To prevent verification bloat and preempt disputes over non-deterministic telemetry (such as local machine latency), the determinism boundary strictly categorizes all outputs into two artifact classes:

• Enforceability Artifacts (Settlement-Grade): These are the inputs to disputes and economic liability. This includes CommittedAction records, Firewall decision receipts, settlement commits, and Merkle inclusion proofs. They are not Web2-style logs; they are transaction records for acts that may become economically or legally consequential. These rely exclusively on deterministic inputs, bounded states, and cryptographic signatures.

• Observational Artifacts (Telemetry): These are local UI and ops events (e.g., WorkloadReceiptEvent streams, wall-clock timestamps, local activity feeds). While useful for user experience and debugging, they contain non-deterministic metadata and MUST NOT be used to evaluate policy compliance or settle on-chain disputes.

Design Principle (Normative): IOI constrains the effects of intelligence, not the process of intelligence. That is how Web4 turns Own into Act without trying to make cognition itself deterministic.

2.4.1 The Intent Contract Schema (ICS)

To enable deterministic arbitration, agents bind to an Intent Contract Schema (ICS)- a canonical JSON structure defining discrete constraints (e.g., max_price, deadline_epoch, allowed_providers). This allows the arbitration layer to validate outcomes against scalar values rather than relying solely on subjective natural language.

The ICS is one of the mechanisms that makes the act transaction-shaped. It converts natural-language intent into discrete fields, constraints, and adjudication criteria that can be signed, replayed, challenged, and settled.

2.4.2 The Adversarial Hierarchy (Adaptive Work Graphs / Deterministic Gate)

To support massive, high-velocity agent work graphs without exposing the User Node to chaotic or malicious state changes, IOI bifurcates execution into two distinct security zones. This architecture treats the User Node's context (files, wallet, calendar, memory) as the Sovereign Master State, and all agent activities as Proposed State Deltas.

The IOI Kernel enforces an Adversarial Hierarchy:

[[figure:adversarial-hierarchy]]

Zone A: The Optimistic Internal Zone (The Delegated Work Graph) Execution occurs within a Delegation Thread. Workers operate with high velocity using Advisory Peer Review. When a Worker proposes a change (a "State Delta"), another Worker in the swarm MAY act as a reviewer to flag obvious errors. Trust is Optimistic: state transitions in this zone are provisional (labeled as speculative state). They allow for messy, nonlinear collaboration (e.g., hundreds of asynchronous drafts or plans) but MUST NOT affect the User Node's sovereign state.

Zone B: The Deterministic Egress Gate (The User) The boundary between the Graph's provisional state and the User's sovereign state is the Merge Gate. This is an authoritative, local-first checkpoint. No effect lands in the User's sovereign context without passing this gate.

The Gate executes a Deterministic Gate VM- a canonical, sandboxed verification runtime that validates two vectors:

1. State Validity: It executes a Validation Recipe to verify the output (e.g., "Do the unit tests pass?", "Are the facts verified against the Trust Oracle?", "Is the transaction syntax valid?").

2. Policy Compliance: An Intent Contract Evaluator verifies the Provenance Ledger, ensuring the State Delta came from a hired worker, the chain of custody is intact, and the effect does not violate authorized prim:* and scope:* restrictions.

Only if all checks pass does the Gate emit an Egress Receipt and execute the State Integration (Merge).

2.5 Fractal Edge-In Topology, Hypervisor Nodes, and the L0/L1 Boundary

IOI's fractal topology routes state transitions and settlements across strict boundaries:

+---------------------------------------------------------------------------------+
| Governed Autonomous-System Chain                                                |
|   - Accepts local module invocations, proposals, receipts, and state transitions|
+---------------------------------------------------------------------------------+
                                         |
                                         v (Local Settlement)
+---------------------------------------------------------------------------------+
| Hypervisor Node (Local Settlement Domain)                                        |
|   - Coordinates multiple autonomous-system chains                               |
|   - Settles local interop, authority outcomes, and local receipt-roots           |
+---------------------------------------------------------------------------------+
                                         |
                                         v (Global Anchoring & Escalation)
+---------------------------------------------------------------------------------+
| IOI L1 (Global Settlement Layer)                                                |
|   - Anchors selected roots (node, system-chain, policy, module, upgrade roots)  |
|   - Settles public rights, disputes, reputation, registry, and economics        |
+---------------------------------------------------------------------------------+

The layers are not identical. They reuse the same kernel doctrine at different authority and commitment boundaries.

The IOI kernel / L0 substrate provides reusable machinery for: domain creation; policy namespaces; Agentgres domain state; runtime-node profiles; worker and service manifests; receipt and artifact semantics; routing and settlement mirrors; upgrade and governance hooks; and L1 commitment interfaces.

IOI L1 provides: public registry roots; identity and rights anchors; escrow and fee routing; dispute bonds; settlement finality; governance and upgrade approvals; and sparse public commitments.

The topology is edge-in. Runtime edges execute; domain kernels remember; IOI L1 settles.

The purpose of this topology is composability. A result may involve one user's local Hypervisor, a managed worker from aiagent.xyz, data recipes from a domain ontology, a hosted model, a verifier worker, a sas.xyz service workspace, and an IOI L1 escrow. The architecture must let those layers compose without becoming one centralized runtime.

2.5.1 The Three Execution Axes

Rather than hardcoding static "lanes," the IOI runtime evaluates execution along three dynamic axes, which the user or developer configures as execution "presets."

Axis 1: Where it runs (The Physical Target)

• Local Hypervisor: Execution occurs on the user's personal device. Ideal for tasks requiring local GPU, direct desktop/browser control, or ultimate sovereignty where no hosted dependency is desired.

• Customer Boundary (VPC / On-Prem): Execution occurs within an enterprise's secure firewall. A Boundary Coordinator orchestrates tasks, ensuring that proprietary data never leaves the internal network.

• Provider-Hosted: Execution occurs on a remote cloud or DePIN provider. Ideal for batch jobs, heavy inference requiring massive hardware, or proprietary models that cannot be distributed locally.

• Decentralized Clean-Room: Decentralized compute nodes with minimized task capsules whose substrate-specific exposure bounds are bound into the clean-room receipt; suited to third-party execution of sensitive workloads where centralized infrastructure is undesirable.

• Hardware-Attested Confidential: Attested confidential compute nodes (e.g., AWS Nitro, Google Confidential Space) providing hardware-bounded execution and remote attestation under a vendor-specific threat model. One admissible clean-room substrate among several.

Axis 2: How inference is sourced

• Local Model: Weights run on the local machine's GPU/CPU.

• Bring Your Own Key (BYOK): The user provides external API keys (e.g., OpenAI, Anthropic) via their local Sovereign Vault to power the cognitive plane.

• Provider OSS Model: The provider supplies warm, open-weight models (e.g., Llama-3) for fast, cost-effective inference.

• Provider Proprietary Model: The provider utilizes custom, closed-source weights (e.g., a proprietary HFT trading model) secured within a TEE.

Axis 3: Evidence Posture

• Standard: Execution is fast and cheap, but the infrastructure operator may have access to plaintext runtime state. Suitable only for low-risk or non-private workloads.

• Private: Data remains inside the user's local device or customer-controlled boundary.

• Hardware-Confidential: Remote execution uses a hardware-attested confidential runtime such as a TEE. This may reduce exposure to infrastructure operators, but validity remains dependent on IOI receipts and declared verifier requirements.

• Cryptographic Clean Room: Computation is performed or checked using FHE, MPC, ZK proofs, verifiable computation, or hybrid constructions. This posture minimizes reliance on hardware attestation and is preferred for authority-critical bounded computations where practical.

• Verified: Execution evidence satisfies the Required Receipt Set for the action class. Verified status is not tied to any single substrate; it may be achieved by TEE attestations, ZK proofs, MPC transcripts, FHE commitments, deterministic replay, external evidence bundles, or hybrids.

2.5.2 The Derived Presets (Lanes)

For consumer simplicity, these axes are bundled into canonical "Lanes" within the internetofintelligence.com and Hypervisor UX:

• Fast: Typically maps to Local execution with BYOK, or Provider-Hosted with warm OSS workers under a Standard trust posture. Optimized for low-latency chat or interactive loops.

• Confidential: Typically maps to Provider-Hosted execution with a Hardware-Confidential or Cryptographic Clean-Room evidence posture. It is intended to reduce infrastructure-operator exposure, but the protocol treats confidentiality claims as substrate-specific and receipt-bound, not absolute.

• Private: Strictly maps to Local Hypervisor or Customer Boundary targets. The data never traverses the open internet to a third-party processor.

2.5.3 Agentgres: The Per-Domain State Substrate

Agentgres is the per-domain state substrate. It stores operational truth, not IOI L1 economic settlement. Every consequential Web4 application domain (e.g., aiagent.xyz, sas.xyz, enterprise deployments) runs its own kernel/runtime deployment with its own Agentgres domain.

Agentgres is not a thin index over Filecoin/CAS blobs. It owns the canonical operation log, object heads, constraints, indexes, projections, subscriptions, delivery state, and quality/contribution ledgers. The IOI L1 blockchain is used strictly for sparse root commitments, contract state, and dispute resolution. Truth is anchored in Agentgres canonical operations and deterministic object state, not in mutable table rows.

2.5.4 The "Eject" Bridge: Pointer-Based State Injection

Because all engines and execution targets share the exact same Artifact Schema and Fractal Query Fabric (FQF) standards, a user can seamlessly migrate an agent from Local (Private) to Network (Public). This is not a bulk data upload, but a State Injection via the ai:// global namespace. To prevent blockchain bloat, the protocol enforces a strict separation between Logic (Storage) and Authority (Chain).

The Migration Protocol executes in three atomic steps:

1. Content Addressing (The Store): The Hypervisor freezes the local agent. It uploads the static artifacts (WASM binary, React UI bundle, connector schemas) to a decentralized storage network (e.g., IPFS/Filecoin).

• Result: A set of Content Identifiers (CIDs).

2. Root Anchoring (The Transaction): The user submits a DeployAgent transaction to the Mainnet. This payload is minimal (approx. 200 bytes). It contains only the pointers:

• Identity: ai://<authority>/<agent_id>/<version> (The human-readable DNS name).

• Logic Root: ManifestCID (Pointer to the code).

• State Root: agentgres_projection_watermark (The Agentgres projection anchor) or StateRoot.

3. Hydration (The Execution): A Provider Node picks up the job. It uses the ManifestCID to pull the logic, and the StateRoot to rebuild the required FQF projections or retrieve the context slice required for execution.

Zero-Bloat Invariant: The IOI Mainnet (the deployed IOI L1) stores Pointers, not Payloads. The blockchain tracks who is allowed to execute the agent, what the valid state root is, and the publisher identity. The actual gigabytes of UI bundles, vector memory, and model weights are fetched via IPFS/CDN only by the specific node (L1) provisioning the workload.

2.6 Policy Enforcement & Authority Gates (Client-Side)

Standard operating systems protect the machine from malware. The IOI Kernel protects the machine from agency.

Operating as a User-Space Hypervisor, the Daemon strictly isolates the untrusted agent workload (the Guest) from the host environment. The Agency Firewall is the physical I/O boundary and deterministic transaction gate that enforces this isolation. It ensures that an agent cannot interact with the network, filesystem, or GUI directly. Instead, the OS is treated as a protected syscall surface, and every attempted side-effect is trapped by the hypervisor and evaluated by the Firewall before any state mutation occurs. When the side-effect is consequential, the trap creates the transaction record of the act.

By leading with OS-level isolation rather than brittle "prompt-engineering," IOI shifts the security paradigm from "prompt-safe" to action-safe.

[[figure:agency-firewall]]

The Firewall enforces a strict, four-step decision pipeline at the validator ante level:

1. Intercept and Normalize: When the agent attempts an externally-effectful operation, the hypervisor intercepts the request and normalizes it into a canonical ActionRequest. This object contains a typed target (e.g., gui::click), deterministic parameters, and the execution context.

2. Translate Policy Context: The engine loads the active, state-backed ActionRules. This includes global ontology policies, per-target guardrails, and environment capability scopes (e.g., restricted filesystem paths).

3. Enforce (Context-Aware): The request is deterministically evaluated against the ruleset at the exact moment of execution:

• If a matching cryptographic ApprovalToken is presented for the exact request hash, the action is explicitly allowed.

• Otherwise, rule matching applies (Allow / Block / RequireApproval).

• PII Egress Routing (CIM Assist): If the action involves data egress, the firewall routes the payload through a local PII review contract. Here, the Canonical Inspection Module (CIM) is utilized strictly as a deterministic evaluator to identify and mask sensitive data before it leaves the local boundary.

• All rejections are fail-closed.

4. Emit Audit Trail: The firewall emits transaction records and auditable outcomes as signed receipts and events (e.g., FirewallInterception, PiiDecisionReceiptEvent), ensuring every execution decision is preserved for replayability and deterministic arbitration.

Context-Aware Guardrails Because the Firewall sits at the hypervisor level, its context awareness is real, not heuristic. Conditions are evaluated against the live OS state through the Kernel's native drivers. For example:

• allow_apps constraints validate the active window for gui::* actions. This prevents "Context Hijacking," where a malicious agent waits for the user to open a sensitive application (like a password manager) before triggering a seemingly benign allowed click.

• Click coordinates are mathematically bounded to the active window geometry.

• Network actions require strict URL-domain allowlists at the proxy level.

• System command execution is constrained by safe command allowlists and command-class bans.

The Interception Boundary (RequireApproval) The firewall functions as the ultimate governance boundary between the agent's logic and the host's authority. If a high-risk step triggers a RequireApproval policy, the Firewall returns a PendingApproval state and pauses the agent's execution. This triggers the UI to request explicit human consent. Upon receiving a resume command with a valid cryptographic signature from the user, the firewall deterministically verifies the token and allows the OS interaction to proceed.

2.6.1 ActionRequest: The Canonical Action Primitive

To be enforceable, policies must evaluate deterministic inputs. The firewall therefore requires every outbound operation to be translated into a normalized ActionRequest. The ActionRequest is the pre-effect transaction candidate: a canonical representation of the act before authority is granted or execution occurs. This aligns with the Model Context Protocol while adding the strict typing required for security.

The kernel normalizes inputs into the following schema before hashing:

• Typed Target: The namespaced identifier, covering both standard and native capabilities:

• Standard MCP: fs::write, net::fetch, wallet::send, sys::exec.

• Native Core (GUI): gui::click, gui::type (OS-level Kinetic actions).

• Headless Browser: browser::navigate, browser::click_selector, browser::eval, browser::screenshot (Hermetic DOM actions).

• Arguments: A canonical, schema-validated JSON payload (RFC 8785) containing the tool parameters.

• Payload Storage: Large input/output payloads (e.g., retrieval documents, model weights) MUST be referenced via Content Identifiers (CIDs) to ensure immutable addressing and keep the audit log lightweight. Small payloads MAY be inlined.

• Context Bindings:

• policy_hash: The hash of the active ruleset.

• session_id: The session identifier (if applicable).

• origin: The ID of the agent requesting the action.

• window_id (Optional): For GUI actions, binding the click to a specific OS window handle to prevent clickjacking.

Normative Invariant: This structure prevents bypass via alternate toolpaths (e.g., trying to access the network via browser::fetch instead of net::fetch). The Orchestrator maps all drivers and MCP servers into the same target namespace, creating a unified Control Plane for agency where every action, regardless of source, produces an identical, hashable receipt.

2.6.2 ActionRules: The policy language

Firewall policies are expressed as ActionRules, a JSON-based DSL. Policies are default-deny and support Graph-Aware Permissioning. Rule semantics are deterministic: rules match on the target plus conditions over canonicalized fields; BLOCK rules override ALLOW; decisions are { ALLOW | BLOCK | REQUIRE_APPROVAL }; and policy evaluation relies on integer-deterministic inference rather than floating-point arithmetic. The policy_hash is computed via JCS canonicalization (RFC 8785) over the canonically ordered ruleset; see Appendix A.1 for the full canonicalization invariants and a complete policy.json example.

2.6.3 Canonical Policy Ordering & Hashing (Normative)

In distributed systems, the memory insertion order of policy rules (especially those generated dynamically by agents or stored in HashMaps) is non-deterministic. If Node A and Node B represent the exact same logical policy but iterate through it in a different order, they will produce divergent policy_hash values, breaking consensus and settlement. Furthermore, because the Agency Firewall evaluates rules sequentially, non-deterministic iteration could lead to Node A allowing an action that Node B blocks.

To neutralize this attack vector and ensure bit-for-bit reproducibility across all architectures, the IOI Kernel enforces a strict normalization pipeline. The runtime MUST pass the raw policy through the ActionRules::canonicalize() function at three specific lifecycle stages:

1. Immediately after trace-driven synthesis.

2. Before computing the policy_hash.

3. Before the policy engine evaluates an ActionRequest.

The Normalization Pipeline The canonicalize() function enforces the following structural invariants:

1. Nested Field Normalization (Arrays & Strings):

• All list-like condition arrays (e.g., allow_domains, allow_apps, capabilities) MUST be lexicographically sorted.

• All duplicate entries within arrays MUST be stripped.

• All string values matching network protocols (e.g., domains, URIs) MUST be lowercased and normalized via Unicode NFC.

2. Stable Rule Sorting (The Sort Key):

• The top-level rules array MUST be deterministically sorted using a composite sort key to resolve any ties. The sort order is defined as:

• Primary Key: target namespace, sorted lexicographically (e.g., fs::write precedes net::fetch).

• Secondary Key: action precedence, strictly ordered as BLOCK (0) > REQUIRE_APPROVAL (1) > ALLOW (2). This ensures restrictive rules are always evaluated before permissive ones for the same target.

• Tertiary Key (Tie-Breaker): The lexicographical string representation of the rule's already-canonicalized conditions object.

3. RFC 8785 Serialization (JCS): Once the struct is sorted, it MUST be serialized using the JSON Canonicalization Scheme (RFC 8785) to eliminate whitespace and formatting variances.

The Hash Invariant: The canonical identifier for any given policy is mathematically locked to this pipeline: policy_hash = H(JCS(canonicalized(ActionRules)))

Evaluation Semantics The Firewall's policy engine MUST evaluate rule matches by iterating over the strictly ordered array produced by canonicalize(). Relying on standard HashMap iteration or the raw input array order for security gating is strictly prohibited.

Security Rationale (The Evaluation Invariant): By forcing the policy_hash and the execution engine to share the exact same sorted representation, IOI guarantees that a policy signed by the user's wallet.network will behave identically inside a remote DePIN Clean Room, eliminating "Butterfly Effect" bypasses where an attacker manipulates JSON parsing to hide a malicious ALLOW rule.

2.6.4 The CIM Runtime: Deterministic Policy Enforcement over a Local Evidence Graph

A decentralized agent system cannot treat arbitrary neural inference as a consensus primitive. Open-ended model execution varies across hardware, runtimes, compiler settings, and vendor-specific kernels. Even when two environments produce semantically similar outputs, they are not a safe basis for policy gates, receipts, or replay-critical validation. IOI addresses this by separating cognitive inference from enforcement: models may propose, but the enforcement path must reduce those proposals to deterministic, replayable structures before they can cross a trust boundary.

Consensus on Enforcement, Not General Cognition The goal of the CIM is not to reproduce a full model's internal reasoning across nodes. The goal is narrower and more useful: consensus on policy-relevant classification and action gating. For PII-sensitive egress, IOI first builds a local evidence graph using deterministic detectors and validators for concrete classes such as API keys, emails, phone numbers, SSNs, and card PANs. The CIM then operates on that evidence graph, not on raw probabilistic hidden states. If two nodes begin from the same evidence graph, policy, target, and risk surface, they derive the same assist identity, routing outcome, and decision hash.

The Genesis CIM: Narrow, Deterministic, and Consensus-Bound The genesis CIM is a narrow deterministic assist contract (cim_v0), not a generalized quantized LLM. Its role is to refine ambiguous spans in a strictly bounded way before routing and transform decisions are made. Its allowed behaviors are intentionally limited: it may drop spans that are deterministically identified as ambiguity false positives, downgrade confidence buckets, and clear ambiguity in specific policy-defined cases. It may not create new spans, mutate the source hash, increase severity, or upgrade a classification to a more severe class. This keeps the safety layer legible, auditable, and consensus-friendly.

Deterministic Runtime Properties The CIM contract forbids wall-clock reads, RNG, external I/O, locale-sensitive behavior, and floating-point or thread-scheduling dependence. The surrounding PII pipeline is likewise structured around deterministic evidence extraction, rules-only routing, and deterministic transform. In practice, this means the safety decision is driven by stable local detectors, explicit policy controls, and an assist receipt that is bound into decision-hash material. A locally produced PII decision can therefore be validated and replayed without depending on arbitrary model execution.

Current Implementation Note: cim_v0 is initially implemented as native deterministic logic over a local evidence graph. Its interface already carries explicit assist identity commitments, including kind, version, config hash, and module hash, which leaves room for future portable module packaging. The present system should therefore be described as a deterministic assist layer over structured evidence, not as a deployed protocol-wide WASM safety guest or a generalized integer-only model.

Normative Invariant: The validity of the Agency Firewall must not depend on reproducing open-ended cognitive inference on verifier hardware. Safety-critical policy decisions must be reducible to deterministic evidence, explicit policy state, and a consensus-bound assist contract.

2.6.5 The Capability Surface: Primitive Constraints vs. Authority

Scopes

The Bifurcated Capability Surface To prevent security bypasses and split-brain API design, IOI abandons flattened capability bags. The capability surface is strictly bifurcated into two tiers:

• Primitive Execution Capabilities (prim:*): These describe runtime feasibility, physical isolation, and risk boundaries enforced by the IOI Daemon. Examples: prim:fs.read, prim:fs.write, prim:sys.exec, prim:ui.interact, prim:net.request, prim:model.invoke.

• Authority Scopes (scope:*): These describe wallet/provider admission policies, budgets, and identity constraints governed by wallet.network. Examples: scope:gmail.read, scope:gmail.send, scope:commerce.order_submit, scope:repo.write.

Every tool and connection MUST define a RuntimeToolContract that declares both its required prim:* capabilities and its scope:* authority boundaries. The IOI Daemon enforces primitive feasibility; wallet.network enforces authority admission. Together, they prevent the "confused deputy" failures that arise when execution capability and resource authority are conflated into a single permission bag.

2.6.6 Capability scopes: permissions, not root

Agents are granted scoped capabilities rather than ambient authority, ensuring they operate within a "Safety Envelope":

prim:net.request bounded by scope:domain_allowlist -- outbound allowlists (domains/IP ranges), protocol restrictions, and per-origin limits. prim:fs.read / prim:fs.write -- read/write scopes restricted to sandboxed roots; explicit deny lists for secrets (~/.ssh, /etc, keychains). cap:input - UI control limited to specific window/application identifiers and interaction types. scope:wallet.transfer_under_limit -- hard ceilings for Labor Gas and any wallet/ transaction operations (per-session and per-day). cap:sys - restrictions on creating child processes or accessing system binaries (e.g., "Allow ffmpeg, Block bash").

Capabilities define the maximum possible envelope; ActionRules define the per-action policy inside that envelope.

2.6.7 Interception and approvals

1. Request: The Ephemeral MicroVM emits an ActionRequest (e.g., gui::click{x,y,window_id}).

2. Evaluation: The Orchestrator evaluates the request against the active policy set.

3. Settlement Resolution: * ALLOW: forward to the relevant driver. * BLOCK: drop the request and return AccessDenied. * REQUIRE_APPROVAL: pause execution and prompt the user via the IOI UI.

Approval tokens (formalizing "user consent"): User approvals are issued as signed approval tokens with explicit scope (target + constraints), TTL, and optional usage count (one-time vs session). Tokens are recorded in the audit chain and can be replay-checked to prevent silent reuse. This acts as 2FA for Agency, ensuring critical actions (like spending) require explicit human sign-off. Approval therefore carries Own into Act. The user is not merely clicking OK; they are signing bounded execution authority for a specific transaction-shaped action. When an action triggers REQUIRE_APPROVAL, the user's DID generates an ApprovalToken. To prevent replay and bypass attacks, the token MUST bind:

• request_hash (the canonical intent)

• policy_hash (the active policy state)

• visual_hash (SHOULD be bound for GUI/screen-based actions)

• audience (Validator/Executor identity)

• expiry (time bound; Chain Time / Block Height)

• revocation_epoch (minimum valid epoch for bulk revocation)

• counter (Monotonic nonce)

Tokens may be One-Shot (burned upon execution) or Multi-Use (Lease). Multi-use tokens MUST strictly decrement a max_usages counter recorded in the state receipt log.

The FirewallDecisionReceipt The runtime MUST emit a FirewallDecisionReceipt for all governed actions. This receipt is the critical link proving why an action occurred. For consequential actions, it is the transaction record of the act, binding the model's requested effect to the user's authority and the active policy state. It permanently binds the request_hash, the policy_hash, and the verdict (Allow/Block/Approved) into the local Merkle spine.

2.6.8 Audit and portability

Every firewall decision is appended to the local receipt chain, creating the Economic Chain of Custody by which executable ownership remains replayable and settleable:

• action_hash (canonicalized request)

• policy_hash

• resolution (+ approval token reference if applicable)

• timestamp/sequence (Guardian-linked)

Policies themselves are content-addressed (hashed), enabling:

• Sharing: developers publish hardened policies (e.g., "Safe Banking", "Read-Only Email").

• Auditing: third parties verify an agent operated under a declared policy set.

• Enforcement: when outcomes escalate to network settlement, the Guardian attests to the policy_hash. Artifacts whose bindings do not match the declared policy are invalid for higher tiers.

This turns the user device from a passive terminal into a managed runtime: autonomy is real, but it is bounded by explicit, verifiable constraints that limit Liability.

2.6.9 Normative Schema: Firewall Artifacts

The Agency Firewall emits three standardized artifacts to ensure interoperability between local and global environments: ActionRequest (the input -- a normalized, schema-validated description of an externally effectful operation), ApprovalToken (user consent -- a scoped, time-bounded authorization), and FirewallDecisionReceipt (the transaction record of the act -- a Guardian-attested decision record). All hashes are computed over RFC 8785 canonicalized bytes; policy_hash MUST be stable for a given ordered ruleset. Full Rust struct definitions and canonicalization requirements are in Appendix A.2.

2.6.10 Attribution Graphs & Contribution Receipts

To scale agency beyond simple tasks, IOI supports Marketplace Neutrality and Contribution Accounting. These primitives ensure that delegated work graphs remain economically legible and that upstream contributors retain credit even when their work is composed into downstream outcomes.

Anti-Cannibalization Rule The default execution harness MUST remain a neutral execution substrate. It is mathematically forbidden from silently cloning, absorbing, or reproducing third-party worker logic into native primitives. Marketplace neutrality is enforced at the protocol level: the runtime cannot use its privileged position to displace the very contributors whose work it routes.

Contribution Receipts When an agent hires another worker or uses a specialized tool, Agentgres records a ContributionReceipt. This receipt tracks the quality_delta the contribution introduced and binds the contributor's identity into the downstream outcome's provenance chain. When the downstream task settles successfully, wallet.network uses the contribution graph to route compensation or credit attribution to upstream providers in proportion to their measured contribution.

The Contribution Graph (Agentgres) Agentgres maintains the canonical Contribution Graph for each domain: a directed acyclic record of who hired whom, under what authority budget, with what measured quality contribution. This replaces the prior "Delegation Graph Ledger" abstraction with a marketplaceneutral object whose semantics are economic accounting first, runtime sub-hiring second. The graph is queryable as a first-class projection and is admissible as evidence in dispute resolution.

2.6.11 Proposal-Mediated Upgrades & Upgrade Governance

To enable safe Recursive Self-Improvement, self-improvement is re-framed as a governed, proposal-mediated upgrade process. Agents do not self-modify directly. Instead, autonomous systems propose upgrades to governed modules, and only policy-bound, receipted governance makes those upgrades canonical.

When an autonomous system identifies a performance limitation, it executes the following upgrade pipeline:

1. Observe limitation & draft an Upgrade Proposal.
2. Bind the target module, workflow, policy, tool, model route, or schema.
3. Simulate, evaluate, benchmark, or dry-run the proposed changes.
4. Review the upgrade under current policy and authority.
5. Approve, reject, escalate, or roll back.
6. Commit the accepted operation through the daemon into Agentgres.
7. Emit Upgrade Receipts and optional IOI L1 anchored roots.

This process strictly enforces the Monotonic Policy Invariant (Policy_New must be a strict subset or equivalent of Policy_Old) at the boundary, ensuring logic can be optimized but privileges cannot be expanded without explicit step-up signature authorization.

The Subset Inclusion Invariant: A mutation is valid IF AND ONLY IF Policy_New is a strict subset or equivalent of Policy_Old .

• Allowed: "I want to remove my access to the filesystem because I don't need it." (Tightening constraints).

• Allowed: "I want to change my system prompt to be more polite." (Logic change, Constraint unchanged).

• BLOCKED: "I want to add access to api.stripe.com." (Loosening constraints).

• BLOCKED: "I want to increase my daily spend limit." (Loosening constraints).

This ensures that agents can evolve to become more capable (better at achieving goals within limits) but can never evolve to become more dangerous. Any attempt to relax constraints triggers a Hard Stop requiring explicit human authorization (Signature).

Recursive Continuity Proofs

Under the High-Assurance Continuity Profile (Section 9.4.4), a proposed mutation requires the runtime to emit a CanonicalCollapseObject. This object contains a rolling continuity_accumulator_hash and a continuity_recursive_proof (verified, for example, via a Succinct SP1 backend). Together they cryptographically prove that Generation N of the agent is a valid, monotonically compliant descendant of Generation 1. Under this profile, a mutation lacking a verifiable continuity proof is rejected and the existing manifest remains canonical.

3. State, Memory, and Semantic Data

Traditional web applications rely on a centralized relational database as the source of truth, with blob storage for files and caches for speed. Decentralized agentic applications require a different foundation: canonical replayable operations, portable serving across untrusted nodes, and cryptographic receipts. A centralized database cannot serve as the ultimate source of truth for decentralized, portable agency.

To replace this legacy stack, IOI mandates a kernel-native Canonical State and Projection System (CSPS).

The CSPS has two complementary components. Agentgres is the shared application truth: the canonical operation log and its materialized projections, serving the role traditionally held by a centralized database. ioi-memory is private semantic memory: the agent's local execution history, document corpus, and vector embeddings, serving the role traditionally held by a user's personal context.

IOI separates state, memory, and semantic data:

1. Agentgres stores canonical operational truth: accepted operations, object heads, state roots, projections, subscriptions, receipts, ledgers, and archive refs.

2. ioi-memory stores private semantic memory, retrieval surfaces, execution traces, and task-scoped context.

3. Domain Ontologies and Data Recipes define domain meaning and transform raw sources into ontology-bound runtime, training, evaluation, and projection data.

4. Agentgres: The Application's Truth. Agentgres rejects the premise that mutable database rows are the source of truth. Canonical truth is the deterministic operation log; app-facing reads are materialized as strictly verifiable Agentgres Projections.

5. Agentic Memory Runtime (ioi-memory): The Worker's Memory. It governs what the worker knows, providing tiered memory (working, core, archival), vector search, and privacy slicing.

3.1 Agentgres: Operation-Backed Domain Truth

Agentgres is the operational truth substrate for governed autonomous-system chains and Hypervisor Node local settlement domains. It records proposals, module invocations, local settlement records, receipt roots, upgrade decisions, state roots, and replayable projections.

Each serious Web4 application domain (e.g., aiagent.xyz, sas.xyz, enterprise deployments) runs its own kernel/runtime deployment with its own independent Agentgres domain.

Agentgres stores:

1. governed autonomous-system chain records;

2. Hypervisor-node local settlement records;

3. service module manifests and registry roots;

4. module invocation records;

5. proposal queues and upgrade decisions;

6. accepted operations and domain sequence numbers;

7. object heads and state roots;

8. schema versions;

9. constraints and invariants;

10. policy hashes;

11. authority grant refs;

12. artifact refs;

13. projection definitions and checkpoints;

14. subscription watermarks;

15. receipt metadata;

16. quality/contribution ledgers;

17. settlement mirrors;

18. archive refs and restore receipts.

Agentgres state is domain-local operational truth. A domain may publish state roots, registry roots, settlement mirrors, receipt roots, or dispute commitments to IOI L1, but ordinary projection state, traces, subscriptions, runtime state, and worker-training state stay in the domain kernel unless a public commitment is required.

Each serious domain should have its own Agentgres kernel:

1. agentgres://domain/local-hypervisor-user

2. agentgres://domain/internetofintelligence.com

3. agentgres://domain/aiagent.xyz

4. agentgres://domain/sas.xyz

5. agentgres://domain/enterprise-customer

6. agentgres://domain/sovereign-worker-network

These domains may reference one another explicitly, but they should not share one giant mutable Agentgres state. Cross-domain references bind object refs, state roots, manifest hashes, policy hashes, receipt roots, and settlement mirrors.

Agentgres operates across a rigorous, decoupled data stack:

1. The Canonical Operation Log (The Deepest Truth): The state machine does not mutate rows in place. Every state change is a signed, canonical operation appended to the log. Truth is historical and replayable.

2. The Object Model: A semantic object framework built over the canonical state log. It holds domain entities like Service, Version, Run, Receipt, and CapabilityLease (object-first truth, not row-first truth).

3. The Projection Engine: The computational engine that maintains materialized read models, derived indexes, real-time changefeeds, and projection checkpoints.

The Replay Invariant: Because all truth originates from the canonical operation log, any node can independently reconstruct the current state of the application by replaying the signed operations from genesis to the current agentgres_projection_watermark.

3.2 Sealed State Archives and Rehydration

To prevent blockchain bloat and ensure fast execution, the architecture enforces a strict separation between operational metadata and heavy payloads.

Agentgres is not a thin index over Filecoin/CAS blobs.

1. Agentgres (Hot / Operational): Owns the canonical operation log, object heads, constraints, indexes, projections, subscriptions, receipt metadata, delivery state, and quality/contribution ledgers.

2. Filecoin/CAS/CDN (Cold / Immutable): Stores the immutable payload bytes: worker packages, large evidence objects, trace bundles, generated artifacts (PDFs/videos), and archival checkpoints.

The Mechanism: Filecoin/CAS stores the payload; Agentgres stores the ArtifactRef. The ArtifactRef binds the payload's Content Identifier (CID/Hash) to its provenance (which run produced it, which receipt validates it, and what policy governs its access).

Managed worker instance lifecycle. Managed worker instances may keep small canonical refs hot and move heavy or idle state cold. Hot state includes instance id, worker manifest ref, lifecycle status, latest state root, runtime assignment, authority policy, subscription/entitlement, archive CID/hash, policy hash, and restore permissions. Cold state may include traces, context windows, intermediate artifacts, inactive patch branches, cached projections, checkpoints, and evidence bundles sealed as encrypted content-addressed archives.

Agentgres has two planes.

Hot canonical runtime state: operation log; object heads; task/run/patch state; projection checkpoints; active subscriptions; leases; receipts; archive refs and lifecycle metadata.

Cold durable artifact plane: encrypted snapshots; trace bundles; evidence bundles; replay exports; dormant agent/worker state; large payloads; backups; sealed archives.

Filecoin/CAS/S3/local disk may hold encrypted archive bytes by hash/CID. These bytes are not canonical live state. Agentgres is the authority that records the archive ref, state root, schema version, policy hash, object heads, authority context, restore policy, and receipts.

Restore Flow user or worker requests restore -> Agentgres checks authority through wallet.network or policy -> fetch encrypted blob by CID/hash -> verify CID/hash -> decrypt through authorized key lease -> validate schema, state root, policy, and object heads -> import through Agentgres operations -> rebuild or resume projections -> record RestoreReceipt

Secret handling. Secrets should be represented by wallet.network references or sealed key leases, not embedded as raw secret material in state archives. Restore reacquires scoped authority instead of replaying stale secret material.

3.3 Projections & Subscriptions: The Agentgres Read Interface

In traditional databases, indexes and views are hidden implementation details. In IOI, Projections are first-class, versioned protocol artifacts. Agentgres serves these projections directly to applications.

Agentgres supports multiple projection families natively:

1. Relational Projections: For dashboards, billing summaries, and tabular admin views.

2. Graph Projections: For service dependency graphs, capability workflows, and lineage tracking.

3. Timeline / Event Projections: For run timelines, audit trails, and operation feeds.

4. Capability Projections: For resolving "what this session can access" or "what this lease permits."

Projection Watermarks: Clients bind directly to these named, versioned projections. Because projections are asynchronous, every read from Agentgres includes an agentgres_projection_watermark (e.g., domain_seq:99182). This guarantees that the client knows exactly which sequence of operations is reflected in the view.

Postgres bridge. Projections are first-class serving surfaces. Agentgres may expose SQL or Postgres-compatible reads over named projections for BI tools, admin tooling, dashboards, ORMs, and psql-compatible clients. Projection reads must expose freshness, domain sequence, policy, and source watermarks when relevant.

Projection compatibility does not imply mutable-row canonicality. Writes become canonical only when compiled into Agentgres operations and accepted under schema, authority, policy, constraints, invariants, and receipt obligations.

3.4 Distributed Runtime Serving, Managed Instances, and Subscriptions

Agentgres enables true multi-node serving. If a user is interacting with an app on Provider Node A, and that node goes offline, the React client can seamlessly failover to Provider Node B without losing application state.

This is achieved via Stateless Portable Session Tokens and Resumable Subscriptions. Instead of sticky web sessions, the client holds a token scoping its read/write capabilities. When connecting to a new node, the node statelessly verifies the token and resumes the client's Agentgres projection changefeed via a deterministic change_seq delta catch-up or a verified ProjectionCheckpoint rebase.

Managed Worker Instances and Runtime Subscriptions A ManagedWorkerInstance is a user-, organization-, or project-bound initialization of a worker package. Product UX may call it an agent instance, but canonical state binds it to:

1. worker manifest ref;

2. install/license right;

3. owner or tenant;

4. runtime assignment or routing policy;

5. persistence profile: per-invocation | warm | persistent | zero-to-idle;

6. authority policy;

7. memory/archive policy;

8. interaction surfaces;

9. subscription or entitlement;

10. latest state root and archive refs;

11. receipt obligations.

A RuntimeSubscription is the entitlement or billing object that keeps an instance available. It may pay for per-invocation use, warm runtime allocation, persistent runtime allocation, restore operations, storage, archive retention, verifier costs, or premium routing. It does not grant the worker ambient authority; authority still flows through wallet.network or an equivalent authority layer.

3.5 The Query Model & Consistency Levels

A query in Agentgres is a runtime capability. Agentgres exposes a structured REST and relational API for local machine-economy objects (POST /v1/query), registering paths for:

• /v1/hypervisor-nodes
• /v1/autonomous-system-chains
• /v1/service-modules
• /v1/module-invocations
• /v1/upgrade-proposals
• /v1/upgrade-proposals/{proposal_id}/decisions
• /v1/local-settlements

Clients must declare their required Consistency Level:

1. cached_projection: May be stale; suitable for UI, search, and non-critical browsing.

2. projection_consistent: Read is served from a named projection at a declared watermark.

3. snapshot_consistent: Multiple reads observe the same projection or state snapshot.

4. state_root_consistent: Read is bound to a specific domain state root.

5. linearized_domain: Read observes all accepted operations up to the latest committed domain sequence.

6. serializable_domain: Operation set is evaluated as if applied in a single valid serial order.

3.6 The Agentic Memory Runtime (ioi-memory)

While Agentgres manages shared application state, ioi-memory manages the agent's private semantic memory and execution checkpoints, organized as a modular, tiered architecture:

1. Thread Execution (LangGraph-shaped): Maintains resumable transcripts and bounded working state.

2. Tiered Ontology (Letta-shaped): Separates memory into distinct working, core, and archival layers.

3. Background Enrichment (Zep-shaped): Utilizes an asynchronous pipeline for summaries, entity extraction, and compaction, avoiding synchronous runtime bottlenecks.

4. Local Artifact Storage: Manages blob-oriented storage for evidence and artifacts independently from chain-visible policy states.

3.6.1 Locality-by-Default

By default, the substrate index remains local:

1. Local execution: Retrieval occurs against the local substrate and context is consumed locally.

2. Remote execution: When offloading to a provider, the runtime does not export the full corpus or index. It exports only a task-scoped context slice under the privacypreserving injection protocol.

Instead of moving user data to centralized compute, IOI moves the compute to the data.

Invariant: the user's memory substrate never becomes a cloud dependency.

3.6.2 The Memory API

The Substrate exposes a uniform, verifiable interface to agents and workflows. It utilizes Intent-Constrained Addressing (ICA) to abstract over raw file formats and storage locations, treating user context as a queryable knowledge graph rather than a directory tree.

// Querying The Substrate via ICA agent.substrate.query("Q3 financial reports", limit = 5)

The runtime resolves this into a policy-governed retrieval operation against the local Substrate Root, returning the minimal set of relevant chunks (plus metadata/provenance) required for the current step of the agent DAG.

3.6.3 Privacy-Preserving Context Injection

When a local agent offloads to a provider, remote execution needs context to be useful, but users require privacy by default. IOI solves this with privacy-preserving context injection: a protocol that minimizes the exported surface area, binds it to explicit policy, and encrypts it under session-scoped keys. (See Section 4.1.4 for the canonical OffloadPacket and ContextSlice schemas.)

3.7 Domain Ontologies and Data Recipes

Ontology is what the domain means. A DomainOntology defines entities, relationships, events, actions, states, roles, and invariants. A CanonicalObjectModel grounds that ontology in IDs, schemas, lifecycle states, constraints, privacy classes, authority needs, and projection hints.

Data Recipes define how raw sources become domain truth. A DataRecipe maps documents, connector payloads, traces, examples, corrections, and source systems into ontology-bound objects, policy-bound data views, evaluation datasets, distilled ontology datasets, and Agentgres projections.

The canonical path is: raw sources -> ConnectorMapping -> DataRecipe -> TransformationRun -> canonical ontology-bound objects -> PolicyBoundDataView -> DistilledOntologyDataset / EvaluationDataset / WorkerTraining / OntologyProjection -> WorkerManifest, MoW routing, service outcomes

Workers train on ontology-bound data, not raw blobs. For efficient specialist workers, the best substrate is often distilled ontology-bound data: compact examples, counterexamples, verifier assertions, tool traces, canonical object transitions, rubric judgments, and failure regressions derived from ontology-bound source material.

3.8 Canonical Object Models and Connector Mappings

Connector payloads are not canonical domain truth by themselves. A ConnectorMapping maps provider fields, files, events, and actions into canonical object models and authority scopes. For example, CRM records, emails, spreadsheets, PDFs, repo events, tickets, and prior work traces become domain objects only after a DataRecipe extracts, redacts, normalizes, dedupes, validates, and links them under policy.

3.9 Distilled Ontology Datasets and Evaluation Datasets

DistilledOntologyDataset is a compact, high-signal dataset derived from ontology-bound source truth. Distillation may use teacher workers, verifier workers, deterministic gates, human reviewers, and data recipes. It may reduce source volume, but it must not erase provenance. A distilled dataset binds source commitments, recipe versions, policy-bound data view refs, transformation receipts, teacher/verifier refs when used, and rubric or benchmark bindings. EvaluationDataset is the benchmark-facing counterpart: golden cases, holdouts, adversarial cases, failure regressions, expected outputs, rubric refs, benchmark refs, and provenance commitments. Evaluation datasets are not ad hoc folders of examples; they are receipted inputs with domain meaning.

4. Network, Routing, and Work Graphs

IOI replaces the flat gossip mesh of traditional blockchains with an Elastic Topology: locality-first execution with network escalation only when capacity, capabilities, or enforceability require it.

4.1 The Clean-Room Offload Mechanism

An Offload is a temporary escalation from a User Node runtime (Local) into a Provider runtime (Session). It is a Clean Room Execution: a bounded Ephemeral MicroVM migration where the developer's encrypted IP and the user's encrypted data meet inside a hardwaresecured enclave (TEE) or Mutual Blind DePIN node. The User Node exports a minimal execution capsule, receives a result plus verifiable accounting artifacts, and reintegrates the output into the local agent graph. The Offload mechanism targets a Clean-Room Non-Exposure property. The exact guarantee depends on the selected substrate and must be represented explicitly in the receipt bundle:

[[figure:confidential-offload]]

1. Provider exposure bound: what the infrastructure operator can and cannot observe under the declared substrate threat model.

2. User exposure bound: what the user can and cannot extract from developer-owned logic, weights, or protected data.

3. Developer exposure bound: what the developer can and cannot observe about the user's private inputs or context slices.

4. Verifier requirements: which attestations, proofs, transcripts, commitments, or replay evidence are required before the output can be accepted.

The protocol mandates a Session Erasure Obligation. A provider must emit evidence that the session was closed, state was not retained beyond the authorized window, and any cached context was deleted or rendered cryptographically inaccessible according to the substrate's erasure model. For TEE-backed sessions, this may include teardown attestations and enclave lifecycle receipts. For cryptographic clean rooms, this may include proof transcripts, key-erasure commitments, MPC transcript closure, or output-only commitments.

Session Offloading is strictly restricted to cognitive and data operations. Offloading migrates Ephemeral MicroVM state only. The Guardian keys, policy engine, kinetic operations (mouse, keyboard, hardware control), and local memory substrate remain on the User Node.

4.1.1 Trigger conditions

The Orchestrator MAY initiate an offload when any of the following holds:

1. Capacity limit: Local hardware cannot satisfy the declared execution requirements (e.g., model snapshot exceeds VRAM, missing accelerator class).

2. Capability gap: The task requires a tool or dataset not available locally (e.g., enterprise data feed, specialized service, regulated connector).

4.1.2 The Hybrid Data Plane (Dual-Path I/O)

The IOI Kernel automatically selects the most efficient transport based on the topology of the Agent Work Graph: Network Path (Remote): When offloading to a remote Provider (Session), context is sliced, encrypted, and transmitted via the Session State Channel to ensure privacy. Local Path (Zero-Copy): When the User Node (Orchestrator) and Agent (Workload) run on the same physical machine (Local), the kernel establishes a Shared Memory Region (shmem). Data objects (Context Slices, Model Weights, Tensor Inputs) are passed via pointer arithmetic, bypassing the network stack entirely for near-native performance.

4.1.3 Session bootstrap: Routing and Route Selection

The User Node initiates a session to migrate a workload from the local device to a remote environment. To accommodate both enterprise privacy needs (BYO-Infra) and consumer market dynamics (Spot Compute), the protocol supports two distinct routing modes:

A. Direct Routing (Explicit / BYO-Infrastructure) The user (or enterprise policy) explicitly defines the endpoint target. The Protocol does not search for a provider; it executes the integration driver to connect to known infrastructure.

• Mechanism: The Worker Manifest or User Policy specifies a direct driver URI (e.g., target: aws-nitro://192.168.1.5 or target: private-cluster-v1).

• Authentication: This mode utilizes a Bring Your Own Key (BYOK) model. The User Node supplies the necessary cloud credentials (e.g., AWS API keys, SSH keys) stored in the wallet.network Sovereign IAM Hub to authenticate with the target. (Raw keys are never exposed to the agent workflow.)

• Verification: While the user selects the provider, the IOI Protocol still enforces the Handshake. The target endpoint MUST be running a compatible IOI Kernel (Session) capable of generating valid Session Receipts. If the target cannot prove its security posture (e.g., AttestationProfileRegistry via TEE Attestation), the connection is rejected by the Orchestrator.

B. Market Routing (Oblivious / Matching) The user defines constraints, and the network selects the optimal provider. Mechanism: The User Node submits a Constraint Object (e.g., vram > 24GB, tier >= 2, price < 50 gas) to the Matching Engine (see Section 13.3) or utilizes Oblivious Resolution (see Section 3.3.3) to query the Global Registry. Selection: The Matching Engine pairs the intent with a Provider Node that satisfies the constraints without revealing the specific task details to the broader network. Payment: In this mode, the User typically pays via the Solver Network, trading tokens/fiat for the specific compute slot.

The Handshake & Topology Negotiation Regardless of the routing mode (Direct or Market), once the connection is initiated, the runtimes perform a handshake to secure the tunnel: Security Verification: The User Node verifies the destination meets the declared security requirements (e.g., Must be a Tier 3 TEE) before transmitting any data. Topology Negotiation: The runtimes negotiate the data substrate. Standard tasks default to Context Slicing (Point-to-Point). Complex workloads elevate to Delegation Threads, where the User Node orchestrates explicit child-to-parent state merges (e.g., append_summary_to_parent, append_as_evidence) based on the TaskEnvelope output contract, rather than relying on shared-memory CRDTs.

The user retains full control over routing mode. The protocol handles secure bootstrapping, negotiation, and receipt generation uniformly regardless of path.

4.1.4 The Offload Packet

To preserve privacy and minimize bandwidth, the User Node does not upload the full agent state. It constructs an Offload Packet containing only what is required to execute a specific step of the DAG. An Offload Packet consists of: Instruction: The concrete intent for this step (typed ActionRequest / tool invocation / model call).

• Ephemeral MicroVM capsule: Optional serialized Ephemeral MicroVM-local state required to resume execution (e.g., KV cache, intermediate graph state), excluding any Guardian/Orchestrator secrets.

• Context slice: The minimal retrieval output needed for the step (chunks, embeddings, citations), encrypted to the provider's session key using a hybrid KEM-derived symmetric key.

• Policy bindings: The policy set that must govern execution:

• policy_hash (content-addressed ruleset)

• Authority Grant Envelope (allowed tools, network domains, spend ceilings)

• Optional "no egress" / "no tool" constraints for sealed execution

• Settlement and payment handle: A session ticket / metering agreement (Labor Gas terms), bound to session_id and policy_hash.

Normative Invariant: The Offload Packet MUST be canonicalized, or be composed exclusively of canonical sub-objects, such that: offload_packet_hash = H(canon(OffloadPacket))

is stable across implementations. Identical semantic packets MUST produce identical bytes under canon(x).

4.1.5 Execution and return

1. Handoff: The provider decrypts the context slice inside an Ephemeral MicroVM container operating under the declared policy bindings.

2. Execute: The provider performs the computation and produces outputs (optionally encrypted end-to-end back to the User Node).

3. Receipt: The provider returns:

• output (plaintext or ciphertext)

• A Session Receipt counter-signed by the provider Guardian, binding:

• offload_packet_hash

• output_hash

• policy_hash

• model_snapshot_id

• Metering (cost, resources, duration)

• Any additional evidence required by the session terms (e.g., tool-call transcript hashes)

4.1.6 Reintegration and verification

On receipt, the User Node MUST execute the Deterministic Egress Gate protocol to safely merge external results into the local sovereign state:

1. Ingress Validation: Verify the provider signature(s) and session bindings (session_id, policy_hash, offload_packet_hash).

2. State Continuity: If the burst utilized a ContextDelta, the User Node MUST verify that the SessionReceipt binds to the Merged Context Hash (the cryptographic combination of the cached base ciphertext + the delta). This ensures the Provider correctly updated their cache and did not execute against stale state.

3. Decryption: The User Node decrypts the output (if end-to-end encrypted) to prepare it for inspection.

4. Gate Execution: The runtime spins up the Deterministic Gate VM to validate the result against the Merge Gate Rule Set:

• State Validity: The Gate executes the Validation Recipe associated with the task type (e.g., schema validation, unit test execution).

• Policy Compliance: The Gate verifies the Provenance Ledger to ensure the State Delta has an attributable lineage and adheres to metering constraints (pricing agreement, spend caps).

5. Integration: Only if all checks pass does the Gate emit an Egress Receipt. The runtime then injects the output back into the local DAG as if executed locally, appending the receipt to the local audit chain.

If verification fails, the User Node MUST treat the step as rejected and MAY trigger session dispute escalation.

4.1.7 Remote Planning (Synthesis via Schema Slices)

To leverage external intelligence for reasoning without exposing instance-level data, IOI supports Remote Planning. In this pattern, the OffloadPacket requests a PlanArtifact (e.g., code, DAG structure, or search strategy) rather than a direct execution result.

This implements a Split-Brain Architecture:

• The Planner (Provider/FM): Receives structural context (schemas) and intent. It generates an execution plan or code.

• The Executor (Local IOI Kernel): Executes the generated plan against the full private context in the Agentic Memory Runtime.

The Mechanism:

1. Schema Slicing: The runtime constructs a SchemaSlice- a constrained ContextSlice containing only structural metadata (JSON keys, CSV headers, ontology graphs) and zero values, enforced by the leakage budget.

2. Synthesis Request: The OffloadPacket contains an instruction to synthesize logic (e.g., "Generate a Python script to analyze data matching this schema").

3. Local Reintegration: The Provider returns the logic as a PlanArtifact. The User Node creates a new ephemeral sandboxed Workload to execute this logic.

Safety Invariant (Normative): Any logic returned by a Planner Burst MUST be treated as untrusted input and:

• MUST execute inside the IOI Daemon (sandbox + primitive execution capabilities + authority scopes).

• MUST NOT perform effectful operations directly; all effects MUST be mediated as ActionRequests and evaluated by ActionRules and ApprovalTokens.

Privacy Note (Non-Normative): Schema Slices reduce exposure but are not zero-knowledge; they are policy-governed exports.

4.2 Session State Channels (High-Frequency Economic Rails)

Session State Channels are transaction-shaped off-chain accounting rails between a User Node and a Provider Node that settle to Mainnet only at boundaries (close, dispute, escalation). They preserve the Web4 invariant without forcing every local or high-frequency agent action onto the chain.

4.2.1 Channel lifecycle

A session is a temporary economic relationship with an explicit ruleset (pricing, policy scope, dispute terms) bound to a session_id.

[[figure:session-state-channel]]

1. Open (Funding and Transport Handshake) A session MAY be funded in multiple ways (direct user escrow, delegated/sponsored funding, or pre-funded provider accounts). In the canonical on-chain-funded case:

• A funder deposits X tokens into a Mainnet escrow object GasEscrow, bound to:

• session_id

• payer_id (user or sponsor)

• provider_id

• pricing_terms_hash

• policy_hash (or a policy envelope hash)

• Mainnet emits ChannelOpen(session_id, payer_id, provider_id, escrow_id, terms_hash).

2. Transact (The "Hot Lane" Loop) To ensure "Harvest-Now, Decrypt-Later" resistance even if the underlying transport (e.g., TLS/QUIC) is compromised, the User and Provider do not rely on standard Web2 sockets. They establish a mathematically verifiable Application-Layer Hybrid KEM channel prior to dispatching workloads.

3. The 4-Way Handshake: The nodes execute a strict initialization sequence (ChannelOpenInit ChannelOpenTry ChannelOpenAck ChannelOpenConfirm). This handshake utilizes both X25519 (Classical) and ML-KEM-768 (Post-Quantum Kyber) to mutually authenticate and derive a shared, forward-secure channel_secret.

4. Zero-RTT Dispatches (The Packet Layer): Once the channel state is locked to OPEN, it acts as a multiplexed Hot Lane. The User Node dispatches work via strictly sequenced PKT_ACTION_INVOKE packets. Because the connection is prewarmed, these dispatches incur 0-RTT connection overhead. All payloads are AEAD-encrypted (XChaCha20-Poly1305) using the channel_secret.

5. Delta Context Injection: To minimize bandwidth, the User Node checks the provider's ephemeral cache status.

• First Burst: The User sends the full EncryptedSlice within the invoke packet.

• Subsequent Bursts: The User sends a ContextDelta containing only new differential data and a reference hash to the cached ciphertext. The Provider merges this delta with the cached state before execution.

4. Execution & Return: The PKT_ACTION_INVOKE includes a Payment Ticket (a monotonic promise to pay). The Provider executes the workload and returns a PKT_ACTION_RESULT. This packet contains the sanitized output and a cryptographically signed Session Receipt.

5. Pipelining & Checkpointing: The User Node MAY pipeline multiple asynchronous bursts (e.g., parallel tool calls) over the same Hot Lane without waiting for the previous result. To optimize network overhead, the nodes periodically exchange PKT_RECEIPT_COMMIT messages containing the Merkle Root of the recent receipt chain, continually advancing the immutable audit log and the economic state of the channel.

6. Close (Settlement)

• When a channel is closed cooperatively or uncooperatively, the resulting SettlementSummary submitted to Mainnet is governed by Sealed Effects (staged; see Roadmap) logic. The payout of Labor Gas is an "irreversible effect" and therefore requires the slot to reach SealedFinal state via CanonicalChallengeV1 observer transcripts before funds are released from the Mainnet escrow.

4.2.2 Payment tickets and monotonic state

A Payment Ticket MUST be non-replayable and monotonically increasing within a session. It is the payment-side transaction record that lets off-chain labor inherit settlement-grade determinism. Conceptually, it advances the session's agreed payment state without publishing to chain. The Provider MUST reject tickets that do not strictly advance seq, preventing replay and double-spend within the channel.

4.2.3 Receipt accumulator (Merkle compression)

Sessions may include thousands of interactions. Neither party should upload every receipt on-chain. IOI compresses the session history into a Merkle accumulator (an MMR or Merkle tree):

• Each accepted Session Receipt is added as a leaf: receipt_leaf = H(H("IOI_SESSION_LEAF_V1") || H(canon(SessionReceipt)) || H(canon(PaymentTicket)))

• The channel state tracks an evolving receipt_root.

• The SettlementSummary contains only this root plus netted balances.

This compresses an entire session into a constant-size commitment. If a specific interaction is disputed, a party can selectively reveal the receipt leaf and a Merkle proof to the committed root.

4.2.4 SettlementSummary (what hits Mainnet)

A cooperative or contested close submits a SettlementSummary that is sufficient to settle value and anchor accountability:

• session_id

• provider_id, payer_id

• final_seq

• receipt_root

• total_cost (or net balance)

• terms_hash / policy_hash bindings

• Signatures from one or both parties (depending on close type).

Mainnet verifies signatures, checks monotonicity, releases escrow accordingly, and opens a challenge window when unilateral.

4.2.5 Delegated and zero-collateral sessions (free-to-play)

To support a frictionless funnel, IOI supports delegated sessions, where a sponsor/solver funds the escrow and the user participates without holding tokens.

• A Solver (liquidity provider) opens or funds the session.

• The user signs payment authorizations (tickets) scoped to session_id, spend limits, and policy envelope.

• The solver pays the provider and recovers value via subscription, off-chain billing, or a pooled credit model.

Safety Invariant: Delegation affects who pays, not what was executed. The cryptographic bindings for offload_packet_hash, policy_hash, and model_snapshot_id remain end-to-end between the user and provider. A solver cannot tamper with instructions or outputs without producing invalid receipts.

4.2.6 Normative Schema: Session Artifacts

Session artifacts adhere to a strict canonical schema. The PaymentTicket is an incremental promise binding session, provider, terms, monotonic sequence, cumulative amount, receipt root, and payer signature. The SettlementSummary is the closing statement covering cooperative or unilateral close modes. The ReceiptLeaf is the per-step history unit. PKT envelopes (PKT_LEASE_ISSUE, PKT_ACTION_INVOKE, PKT_ACTION_RESULT, PKT_RECEIPT_COMMIT) carry MCP payloads and policy decisions across the session. Full Rust struct definitions, JSON examples, and the TypeScript PktEnvelope type are in Appendix A.3.

4.2.7 Milestone-Based Streaming Settlement

For long-running swarms where "Pay-Per-Token" misaligns incentives with results, IOI introduces Milestone-Based Streaming Settlement. This protocol ensures funds flow only when verifiable progress is made, preventing "drift" and inefficiency.

The Streaming Ticket Primitive Instead of discrete payment tickets for every burst, the User Node opens a Streaming Payment Channel. The flow rate (Labor Gas / second) is variable and gated by a Flow Controller logic.

Multi-Signal Progress Proofs To maintain the stream, the Manager Node MUST emit periodic Progress Proofs. A proof is a composite claim anchored to the current Repo State, such as:

• Tests Passed: 40/100

• Coverage Delta: +5%

• Linter Status: Clean

• Artifact Hash: Changed

Light Client Sampling & Challenge The User Node (running locally) acts as a Light Client Sampler. It does not re-run the entire test suite. Instead, it randomly spot-checks specific claims in the Progress Proof (e.g., "Rerun Test #32").

• Verification: If the spot-check passes, the Flow Controller releases the next tranche of funds.

• Challenge: If the spot-check fails (e.g., the Planner claimed a test passed when it failed), the stream is deterministically paused, and the Swarm may be terminated or slashed.

• Offline Semantics: If the User Node goes offline, the stream defaults to Pause. Users MAY authorize a Delegated Sampling Node (a low-power cloud verifier) to continue spot-checks and funding in their absence.

4.3 AIIP Resolution (The "DNS of Agency")

The Agentic Interoperability Protocol (AIIP) defines how abstract identifiers (ai://...) resolve into concrete runtime artifacts: code packages, model requirements, policy defaults, and execution endpoints. AIIP makes agents addressable like websites: local-first for speed, registry-backed for discovery, and content-addressed for safety.

[[figure:aiip-uri-resolution]]

4.3.1 The AIIP URI Scheme

ai://<authority>/<agent_id>/<version>[?query]

• Authority: did:ioi:... (public key, DAO address, or governance identity).

• Agent ID: human-readable label (e.g., personal-finance).

• Version: immutable release identifier (e.g., sha256:... or semantic version mapped to a content hash).

4.3.2 Resolution Result

Resolving an AIIP URI returns a structured Resolution Result:

• A content-addressed Agent Manifest (signed by authority).

• An optional Local Installation Handle (if the package is already present in the local Agentic Memory Runtime).

• Zero or more candidate Endpoints (p2p, https, or driver-specific transports), ordered by trust policy and locality.

• A declared Primitive Capabilities and Authority Scopes requirement for user review.

• Optional MoW routing metadata, when present: sparse_worker_category, benchmark_profile_refs, current leaderboard position or reputation root reference, routing_eligibility_status, contribution terms, and training_lineage_ref.

4.3.3 Resolution Logic: Split-Horizon Discovery

When the runtime encounters an AIIP URI, it follows a deterministic waterfall to prevent the "DNS Leak" problem where looking up an agent reveals user intent:

Step 1: Local Install Cache ("Hosts File")

• The Runtime checks the local inventory and Agentic Memory Runtime.

• If installed, it returns the local package handle (content hash / bundle ID) and skips network lookup.

• Latency: ~0ms. Privacy: Maximal.

Step 2: Pinned Registries ("Known Good")

• The Runtime checks a locally pinned list of trusted registries or providers (e.g., enterprise catalogs, user favorites) via encrypted transport.

• If found, it returns the manifest and endpoints from the pinned source.

• Latency: Low. Trust: Explicit.

Step 3: Network Discovery ("Dark Pool")

• If not found locally, the Runtime utilizes Oblivious Resolution (e.g., PIR) to query the Global Registry.

• Providers can operate in Dark Pool Mode, where capacity is not broadcast globally.

The Tower of Babel Solution: Semantic Negotiation To ensure that a "Downloaded Accountant" can speak to a "Downloaded Bank", the Resolution Logic utilizes the IOI Schema Registry.

• Schema Enforcement: A Worker Manifest MUST declare its I/O schemas (e.g., input: std:finance:invoice_v1, output: std:finance:tax_report_v2).

• Handshake: During resolution, the Runtime verifies that the hired agent's output schema matches the employer's input requirement before money moves. This prevents "semantic mismatch" errors where agents perform valid work in an unusable format.

4.3.4 The Worker Manifest

The Worker Manifest is the declarative contract for execution. It specifies what the agent is, what it requires, and where it can run.

A Worker Manifest MAY additionally declare MoW routing metadata: sparse_worker_category, benchmark_profile_refs, evaluation_rubric_ref, routing_eligibility_status, contribution_policy, training_lineage_ref, and supported_execution_axes.

Optional MoW routing fields:

{ "sparse_worker_category": "std:code:rust_security_audit.v1", "benchmark_profile_refs": [ "benchmark://ioi/categories/rust_security_audit/v1" ], "evaluation_rubric_ref": "rubric://ioi/rust_security_audit/v1", "routing_eligibility_status": "eligible", "training_lineage": { "training_run_ref": "run://...", "dataset_commitment": "hash://...", "evaluation_receipt_root": "hash://..." }, "contribution_policy": { "mode": "receipt_weighted", "royalty_bps": 500, "license_ref": "license://..." } }

{
"authority" : "did:ioi:dao-xyz" ,
"id" : "ai://dao-xyz/governance-bot" ,
"version" : "sha256:8f4..." ,
"package" : { "type" : "oci" , "digest" : "sha256:..." } ,
"template_id" : "tpl:governance.bot.v1" ,
"model_requirements" : {
"arch" : "llama3" ,
"quantization" : "q4_k_m" ,
"vram_min" : "16GB"
} ,
"policy_defaults" : {
"cap:network" : [ "api.daoxyz.org" ],
"cap:spend" : "0"
} ,
"endpoints" : [
{ "type" : "p2p" , "uri" : "libp2p://..." } ,
{ "type" : "http" , "uri" : "https://api.gateway.io/..." }
],
"signature" : "..." // Signed by Authority
}

Normative Security Rule: The runtime MUST NOT auto-execute code obtained via resolution. Resolution names intelligence; it does not grant authority. A resolved worker becomes a Web4 actor only after wallet.network or an equivalent authority layer grants bounded, policy-bound execution authority inherited from Own. It MUST present an installation and permission prompt (displaying requested prim:* and scope:* capabilities, policy defaults, and authority identity), and execution MUST require explicit user approval (or an enterprise policy decision).

4.3.5 The Intent Contract Schema (ICS)

To enable deterministic arbitration, agents bind to an Intent Contract Schema (ICS)- a canonical JSON structure defining discrete constraints. This allows the arbitration layer to validate outcomes against scalar values and structured logic rather than relying solely on subjective natural language.

An ICS binds to the Worker Manifest via the template_id and includes:

• Discrete Fields: max_price, deadline_epoch, min_confidence_score.

• Enums: allowed_providers, outcome_type.

• Adjudication Rubric: A structured, boolean-logic prompt defining success criteria for Arbitration Nodes.

• Example: rubric: { "contains_code": true, "passes_linter": true, "tone": "professional", "forbidden_words": ["sorry", "I cannot"] }

• Tie-Breakers: optimize_for settings.

Invariant: Rubric Binding (Normative) To be eligible for the Low-Cost Fast Path (Tier 4A), contracts MUST bind to a valid Evaluation Rubric. Contracts lacking a deterministic rubric default to the High-Cost Human Arbitration Lane (Tier 4B), requiring significantly higher bond posting by the Planner.

4.4 Infrastructure Integrations and Driver Modules

IOI does not compete with commodity hardware networks; it integrates them. The IOI Runtime acts as a Universal Driver, allowing users to deploy workloads to any infrastructure they choose while maintaining a unified verification layer.

Connectors should declare not only transport and tool interfaces, but also ConnectorMappings into canonical domain objects, authority scopes, redaction policies, evidence requirements, and policy-bound data views.

• Hyperscale Integrations (AWS / GCP / Azure): The IOI Runtime deploys directly into Confidential VMs (e.g., AWS Nitro, GCP Confidential Space). The user brings their own cloud credentials ("BYO-Key"), using IOI purely for the verification overlay.

• DePIN Integrations (Akash / Render / Gensyn): The user selects DePIN endpoints for cost-optimized or permissionless workloads. The IOI Runtime handles the bidding and connection logic via the driver.

• Private Integrations (Local): Enterprise users route workloads to their own internal hardware.

Architectural Result: IOI functions as the Intelligence Orchestration Layer that sits above physical infrastructure networks. It upgrades commodity hardware into privacy-preserving, agentic nodes, while the integration model guarantees that critical workloads execute on user-selected, reliable infrastructure (whether Hyperscale or DePIN).

4.5 Artifact Resolution & On-Demand Provisioning

AI agents frequently fail not because of flawed logic, but because of environmental drift- conflicting Python packages, incompatible CUDA versions, or missing system dependencies. To solve this, IOI adopts a strict "Wrapped Asset" model. Agents are not loose scripts; they are self-contained executable assets defined entirely by a cryptographic Worker Manifest.

This declarative asset model is the foundation of Zero-Idle Infrastructure. Developers do not need to host expensive, always-on API servers. Agents and their proprietary models exist as dormant, encrypted manifests on decentralized storage (Filecoin/CAS/CDN). If a user's Local Node lacks the precise computational resources (e.g., VRAM) to run the manifest, or if the manifest requires a secure hardware enclave to decrypt proprietary developer IP, the IOI Orchestrator initiates a frictionless route to a Cloud/DePIN Provider. The network handles the on-demand provisioning, spinning up an exact, dependency-matched environment in milliseconds.

ai:// resolution may return worker manifests, service manifests, runtime profiles, install rights, license refs, archive refs, data recipe refs, benchmark refs, contribution policy refs, and domain refs. Resolution does not imply that all referenced state lives in one product database. The resolver returns explicit cross-domain references.

aiagent.xyz worker initialization flow:

user selects worker -> resolve WorkerManifest and version -> check install/license right -> inspect runtime requirements -> select persistence profile -> quote compute/storage/subscription terms -> request wallet.network authority grants -> create ManagedWorkerInstance in aiagent.xyz Agentgres domain -> assign daemon-compatible runtime node or zero-to-idle policy -> initialize hot state and optional sealed archive refs -> expose web/API/Hypervisor/workflow invocation surfaces -> emit install, runtime, authority, and initialization receipts

4.5.1 The Provisioning Lifecycle

Every routed cloud execution is governed by a declared Clean-Room Evidence Profile (Section 4.1). The profile specifies the substrate, threat model, admissible leakage bounds, required attestations or proofs, and the receipt obligations that must be satisfied before reintegration or settlement. Providers do not run agents on their bare-metal host OS. When a Provider Node accepts a routed workload, it executes the following on-demand sequence:

1. Strict Dependency Resolution: The Orchestrator parses the Worker Manifest's dependency tree to identify exact version requirements (e.g., requires: python-3.11, requires: vLLM-0.4.2, model: llama-3-70b-quantized).

2. Authenticated Fetch:

• Public Artifacts: Base models, system libraries, and standard tools are fetched from the IOI Public Cache (a pinned IPFS cluster or high-speed CDN) using verifiable content addressing (CIDs). These are pure payload bytes, not Agentgres state.

• Proprietary IP (The Developer's Asset): If the manifest requires custom, closed-source model weights, the encrypted weight blob is pulled from decentralized storage directly into the hardware enclave.

• User Context (Private Data): Task-scoped, encrypted Context Slices are fetched directly from the User Node via the secure session channel.

3. Sandbox Initialization (Substrate-Specific): The runtime provisions the declared execution substrate. For TEE-backed workloads, an Ephemeral MicroVM or enclave may decrypt protected assets in memory under a vendor-rooted attestation model. For FHE-backed workloads, selected computations may run over encrypted inputs without decryption. For MPC workloads, secret shares may be distributed across participating executors. For ZK-proven or proof-VM workloads, the provider returns a proof that a committed program or model step was executed according to the declared circuit, VM, or verifier. In every case, exposure bounds are determined by the declared substrate threat model and bound into the receipt rather than asserted absolutely.

4. Integrity Lock: The Guardian computes the Merkle root of the loaded execution state. The model_or_program_hash and execution_plan_hash are bound to the CleanRoomExecutionReceipt. Depending on the action class, this may prove only that a particular runtime image was attested, or it may prove a stronger bounded computation claim through ZK, MPC, deterministic replay, or hybrid evidence.

5. Session Erasure: Upon generating the output commitments and the CleanRoomExecutionReceipt, the provider must emit evidence that the session was closed and any cached context was deleted or rendered cryptographically inaccessible according to the substrate's erasure model (e.g., teardown attestations, key-erasure commitments, MPC transcript closure, or output-only commitments).

4.5.2 Orchestration: On-Demand Hydration vs. Hot Pools

Because IOI relies on declarative manifests, the protocol does not force developers or providers into a single infrastructure paradigm. Instead, IOI operates as a highly scalable orchestration engine that routes intent based on the workload's required latency.

When configuring a service in sas.xyz, the builder specifies its readiness posture. Cold services are hydrated on demand; the network treats the user's transaction as a trigger to execute the hydration lifecycle. Because users are conditioned to accept slight initialization times for high-value asynchronous deliverables, this friction is negligible, and it optimizes for zero-idle developer economics. Conversely, Hot services are routed directly to pre-warmed runtime capacity maintained by the provider. This bypasses the hydration phase entirely, optimizing for instant interaction and Web2-style API latency.

4.6 The Workload Shim & Network Virtualization

Just as an Operating System requires drivers to interact with physical hardware, the IOI Kernel requires a bridge to interact with digital infrastructure (SaaS APIs, Blockchains, LLMs). IOI fulfills this via Network Virtualization and the Workload Shim.

Legacy platforms rely on centralized "Universal Connectors" or handing raw API keys to anonymous bots, creating massive security liabilities. IOI introduces a decentralized standard for connecting Sovereign Agents to external services by treating the Model Context Protocol (MCP) and HTTP traffic as raw transport layers that require a Security Envelope.

This architecture functions as an automated KYA Check (Know Your Agent): instead of handing raw secrets to an agent, the kernel installs a managed shim. This shim acts as a Secure Enclave Abstraction Layer (SEAL). It enforces Zero-Exposure Execution: the AI model generates the parameters of a request (e.g., "Refund $50"), but the IOI Kernel injects the authentication (API Key) only at the network edge. The model never sees, holds, or leaks the credential.

4.6.1 The Mechanism: The Capability Execution Engine

The IOI Kernel acts as a "Man-in-the-Middle" capability broker for its own workloads. Legacy platforms attempt to secure agents by injecting API keys into environment variables or local proxies. IOI fundamentally rejects this model.

The protocol enforces a non-negotiable security invariant: The agent requests effects, not keys.

To achieve this without breaking standard tools (e.g., standard MCP servers or CLI scripts), the Kernel utilizes a Transparent Sidecar Proxy backed by the Sovereign IAM Hub (wallet.network). Execution is routed through one of two distinct operational modes:

• Capability Execution (Remote Request -> Local Execution). The agent requests an action; the Vault performs the action locally using its protected secrets; the Sovereign IAM Hub returns the result. The secret never enters the agent's runtime space.

• Attested Remote Execution. For high-scalability workloads running on external hardware, the Sovereign IAM Hub approves an action and injects an ephemeral key strictly into an Attested Remote Enclave (TEE) via a Hybrid KEM handshake.

When a wrapped tool is executed, the Kernel performs the following atomic sequence:

1. Virtualization & Intent Translation: The Kernel spins up an ephemeral HTTP proxy on localhost. The agent is spawned with modified environment variables (e.g., OPENAI_BASE_URL pointing to the proxy) and dummy credentials. When the agent attempts a network request, the proxy intercepts it and translates it into a canonical PKT_ACTION_INVOKE request bound to the agent's active SessionLease.

2. Policy Evaluation: The request is forwarded to the Sovereign IAM Hub (wallet_network). The Sovereign IAM Hub evaluates the PKT_ACTION_INVOKE against the active Policy Envelope. It verifies that the requested capability (e.g., stripe:refund) and its parameters (e.g., $50) are mathematically within the bounds of the agent's current SessionLease and its parent RootGrant.

3. The Out-of-Band (OOB) Step-Up Gate: If the request violates the autonomous policy limits (e.g., interacting with a new smart contract, or exceeding a daily spend cap), the Sovereign IAM Hub strictly enforces an Out-of-Band Step-Up.

• Execution is paused.

• An on-screen prompt on the active host is considered insufficient (to mitigate local malware). The Sovereign IAM Hub pushes a cryptographic signing request to a secondary device (e.g., the user's Mobile Phone via Bluetooth FIDO2/Passkey).

• If approved, the Sovereign IAM Hub mints a one-time ApprovalToken to override the policy block.

4. Execution (The Air-Gap): Assuming policy passes or an ApprovalToken is provided, the Sovereign IAM Hub executes the capability. In the default Capability Execution, the Sovereign IAM Hub internally signs the transaction or makes the OAuth API call using the root credential stored in its encrypted XChaCha20-Poly1305 database.

5. Receipt Emission (ActionResult): The proxy returns the sanitized HTTP response (the result of the action) back to the agent tool. Simultaneously, the Sovereign IAM Hub generates a cryptographically signed PKT_AC- TION_RESULT (a Receipt). This binds the original intent, the applied policy hash, and the execution outcome into a hash-linked audit log.

Result: The agent possesses Functional Authority (it can complete the job) but zero Credential Authority (it cannot steal the keys, exfiltrate the session, or bypass the constraints). If the agent is fully compromised or "jailbroken," the maximum potential damage is mathematically capped to the exact capabilities explicitly granted in the SessionLease.

4.6.2 Provider Swapping (The Local Routing Table)

Because the Kernel controls the network layer, it can dynamically reroute agent "brains" without modifying the agent code.

• Model Swapping: An agent hardcoded for OpenAI can be routed to an Anthropic endpoint by the Shim.

• Local Fallback: Cloud-native tools can be forced to use local LLMs (e.g., Ollama) by redirecting their API calls to a local inference server, enforcing total data sovereignty.

4.6.3 Kinetic Drivers & Browser Subsystem

While many tools run as standard binaries or isolated processes via the Model Context Protocol (MCP) Manager, the IOI Kernel exposes specialized Native Drivers comprising two distinct subsystems to handle OS and Web interactions safely.

Kinetic Drivers (OS-Level) For desktop applications (e.g., Excel, Photoshop), raw screen pixels are insufficient for reliable agency. The IOI Core implements Application Lenses (LiDAR)- drivers that project the raw OS Accessibility Tree into a simplified, token-efficient XML representation.

• Div-Soup Filtering: Lenses (e.g., universal_heuristic_v4, react_semantic) actively prune non-interactive elements, empty containers, and invisible nodes to reduce context window usage.

• Semantic Tagging & SoM: Visual elements are tagged with two distinct identifiers:

1. Stable Semantic IDs: Derived deterministically from content, role, and deep ancestry hashing, allowing the agent to reference elements across shifting layouts.

2. Ephemeral SoM IDs: Numeric "Set-of-Marks" IDs injected per-frame during the Visual Grounding phase, allowing Vision-Language Models (VLMs) to intuitively target spatial coordinates.

The kernel utilizes native OS handles (via enigo) to inject input (gui::click, gui::type) based on these semantic targets. These actions interact with the Atomic Vision-Action Lock, which evaluates the perceptual state of the UI at the exact moment of execution to prevent "Visual Drift" (TOCTOU attacks). The Managed Browser Subsystem (Web-Level) Agents DO NOT directly control the user's personal, daily-driver browser (e.g., Chrome/Safari). Doing so would expose the user's logged-in sessions (Gmail, Banking) to implicit exfiltration and unintended cross-contamination.

Instead, the Kernel spawns a Hermetic Chromium Instance managed by the CDP (Chrome DevTools Protocol) Driver.

• Hermeticity: The browser initializes with a clean profile- zero cookies, zero history, and disabled extensions. It can operate in strict headless mode or headed mode (for active user monitoring).

• Structural Interaction: Instead of relying purely on computer vision, the browser driver targets DOM and Backend Node IDs (e.g., browser::click_selector). This makes the agent highly resilient to visual drift, rendering lag, or popup overlays that would otherwise confuse a pure-vision model.

• Intent-Level Network Pinning: Rather than attempting brittle packet-level interception of the browser's internal network stack, the Orchestrator evaluates the agent's intent. All tool invocations (e.g., browser::navigate, ucp::checkout) are checked by the Policy Engine. The destination URLs and arguments are validated against cap:network allowlists before the driver executes the command.

• Secret Isolation (Roadmap): The framework's SecretInjection primitives (backed by the Sovereign Vault) lay the groundwork for injecting bounded session tokens directly into the hermetic browser instance, allowing agents to adopt specific user privileges without ever exposing raw credentials to the LLM.

4.6.4 The Enterprise Gateway Node (BYO-Auth)

For high-security "AI as a Service" workflows, enterprises deploy Enterprise Gateway Nodes.

• Role: These are specialized Provider Nodes that run managed workloads configured with corporate identity.

• Mechanism: An enterprise spins up a Gateway Node inside their VPC. They load it with corporate API keys and whitelist specific did:ioi agents (e.g., "The Customer Support Swarm").

• Security: The data never leaves the corporate VPC. The agents "visit" the Gateway Node via Confidential Offload (Session), drive the internal APIs via the kernel wrapper, and return only the structured result.

4.6.5 The UCP Commerce Wrapper

As the industry standardizes agent-to-merchant communication via the Universal Commerce Protocol (UCP), IOI provides the UCP Wrapper. This transforms raw commerce intent into safe, verifiable transactions.

• Hardware-Isolated Payment: The Wrapper negotiates the shopping cart, but the Guardian injects the payment token (e.g., Stripe/Google Pay) only at the moment of egress via SecureEgress.

• Semantic Budgeting: The Agency Firewall inspects UCP payloads. A policy like allow spend < $50 on "groceries" is enforced deterministically against the UCP schema.

• Liability Binding: Every purchase generates a receipt binding the Merchant ID, Total Spend, and Worker Logic Hash, creating an auditable trail for chargebacks or insurance claims.

4.7 The Solver Network (Liquidity & Abstraction Layer)

IOI formalizes the Solver as a specialized node that provides just-in-time liquidity, bridging fiat-denominated user demand and token-denominated network settlement so mainstream users never interact with tokens directly.

While Providers supply Compute, Solvers supply Just-In-Time (JIT) Liquidity.

4.7.1 The Solver Responsibilities

• Zero-Latency Funding (Zero-RTT): To open a session channel, the protocol requires locked collateral on Mainnet. If a User performs this directly, they must wait for block confirmations (~12s). Solvers maintain massive, pre-funded Master Escrows. They cryptographically issue Payment Tickets to Providers on behalf of users in milliseconds, enabling instant "Click-and-Run" agency.

• Gas & Currency Abstraction: Solvers pay all Mainnet settlement costs (ETH/Gas) and Labor Gas. The User pays the Solver off-chain (via Fiat, Credit Card, or Enterprise Invoice), and the Solver handles the on-chain conversion and settlement.

• Privacy Mixnet: By sitting between the User and the Provider, the Solver breaks the on-chain link between a specific User Identity and a specific Agent Workflow. The Provider sees the Solver's address as the payer, preserving the User's economic privacy.

4.7.2 Security Invariant: Financial vs. Executive Authority

The Solver architecture enforces a strict separation of powers to prevent censorship or manipulation. A Solver holds Financial Authority but Zero Executive Authority.

• Encryption Barrier: The Solver CANNOT decrypt the User's Context Slice or see the agent's private inputs.

• Integrity Barrier: The Solver CANNOT alter the Agent's ActionRequest or Policy Envelope. Any tamper attempt invalidates the signature chain, causing the Provider to reject the job.

• Payment Barrier: The Solver CANNOT withhold payment for valid work (verified receipts) without generating a cryptographic proof of misbehavior that triggers the slashing of the Solver's own bond.

4.7.3 The Solver Business Model (Arbitrage)

Solvers are permissionless. The protocol anticipates a competitive market where Solvers act as Arbitrageurs:

• Revenue: They capture the spread between the stable "Retail Price" (e.g., $29/mo Subscription) charged to the user and the dynamic "Wholesale Price" (Spot Labor Gas) paid to the network.

4.8 Multi-Worker DAGs and Mixture of Workers: Visualizing the Supply Chain

Swarm Orchestration Topologies While simple DAGs remain the default execution model, IOI supports richer orchestration topologies for complex workflows:

• Planner / Executor / Verifier: A three-phase topology where a planning worker decomposes intent, executor workers perform actions in parallel, and a verifier worker validates outputs against the original intent contract before settlement.

• Parallel Branches with Quorum Review: Multiple workers execute competing strategies simultaneously; a quorum of supervisor workers selects the best outcome based on predefined fitness criteria.

• Fallback & Escalation Strategies: Workers specify fallback paths, if a primary capability fails, the orchestrator reroutes to a secondary worker or escalates to a supervisory worker with broader authority.

• Supervisory Workers: Dedicated meta-workers that monitor swarm health, enforce cross-worker policy consistency, and serve as escalation targets for ambiguous or high-risk decisions.

Mixture of Workers is the runtime routing doctrine for these topologies.

A Planner / Executor / Verifier graph is not merely an implementation pattern; it is the canonical execution shape of MoW. A planner decomposes intent, executor workers perform scoped labor, verifier workers validate outputs, and the merge gate converts provisional work into sovereign state.

Each routed worker remains independently accountable. It has its own manifest, policy envelope, contribution terms, receipt obligations, and dispute surface. The final output is therefore not a black-box "agent response," but a verifiable supply chain of worker contributions. When these independent workers are routed, benchmarked, and compensated across organizational boundaries, the Mixture of Workers becomes a Market of Workers.

Worker Training is the supply-creation loop for this routing market. MoW does not assume that the best worker already exists. Workflows, examples, corrections, domain ontologies, data recipes, quality gates, verifier feedback, and benchmark failures can become training material for improved workers. Those workers can then be published, benchmarked, installed, composed, routed, and paid by receipts.

MoW routing may be invoked by Hypervisor, aiagent.xyz, sas.xyz, internetofintelligence.com, CLI, SDK, enterprise backends, or workers themselves. Routing is a domain/kernel capability, not a single product surface. Each domain may operate its own router subject to routing receipts, declared policy, marketplace neutrality, and contribution accounting.

A worker can be routed as a primitive inside a larger labor graph or invoked directly as a managed assistant. These are not competing models. A contract review worker, research worker, code review worker, sales ops worker, or intake worker may be useful as a standalone web/API experience and also as a node in Hypervisor workflows, sas.xyz outcomes, enterprise automations, or MoW task graphs.

Agents are rarely standalone scripts. They are workflows: chains of reasoning, tool use, and verification. IOI represents workflows as Directed Acyclic Graphs (DAGs) so steps can execute locally, burst selectively, and escalate to settlement only where needed.

[[figure:worker-dag]]

4.8.1 Execution Graph (Runtime View)

At runtime, the DAG is compiled into canonical ActionRequests and step-wise artifacts.

Step-wise artifacts (normative): Each node execution produces an artifact bound to:

• canonical_payload_hash of inputs/outputs,

• policy_hash,

• model_snapshot_id (when applicable),

• and parent step references. Graph and step addressing (normative):

Traceability: Because each step commits to prior artifact IDs and utilizes hash-linked receipt chains, final outputs carry a cryptographic chain-of-custody. A calendar update can be traced back to the specific summary receipt(s), policy, and required logs that authorized it.

4.8.2 Modular Dispute Resolution (Privacy-Preserving)

Because verification is step-scoped, arbitration is precise:

• Disputes target noncompliance at a specific step, not "the whole agent."

• Challenge packages can reference graph_id and step_id and reveal only minimal evidence for that step.

• Arbitration evaluates only the contested step under its declared ruleset.

Result: Accountability without full disclosure.

4.9 Sparse Worker Categories, Benchmarks, and Subscription Credit Routing

The Market of Workers requires a routing market that does not collapse into one global leaderboard. IOI therefore supports Sparse Worker Categories: narrow labor categories with explicit evaluation profiles.

A Sparse Worker Category may declare required DomainOntology refs, CanonicalObjectModel refs, WorkflowSchema refs, benchmark profile refs, EvaluationDataset refs, privacy classes, allowed training-data policies, and receipt obligations. Category claims are comparable only when workers are evaluated against declared ontology-bound inputs and rubrics.

aiagent.xyz is the canonical product domain for Sparse Worker Categories, Benchmark Profiles, worker manifests, trained worker packages, installs, managed instances, ranking, and routing eligibility. It may publish roots or commitments to IOI L1, but category operations, benchmarks, installs, and marketplace projections are domain-level Agentgres truth.

Examples:

1. Rust security audit worker

2. legal intake worker

3. grant research worker

4. sales follow-up worker

5. React refactor worker

6. insurance claim review worker

7. construction quote worker

8. local SEO worker

9. government RFP worker

Each Sparse Worker Category MAY define:

1. task class

2. allowed input/output schemas

3. benchmark suite

4. evaluation rubric

5. runtime requirements

6. policy requirements

7. trust posture requirements

8. receipt obligations

9. submission fee or stake

10. routing eligibility criteria

Submitting a worker to a category pays for benchmark execution and leaderboard admission. A submitted worker does not automatically receive routing. Routing eligibility is earned through benchmark performance, receipt completeness, policy compatibility, price, and reputation.

Subscription-credit routing:

User subscription -> work credits -> worker invocation -> ContributionReceipt -> quality/reputation update -> receipt-weighted payout

This lets a subscription fund the Market of Workers economy without creating a generic pooled payout model. The pool does not pay popularity. It pays verified contribution.

Reference payout structure:

worker_payout = invocation_fee + metered_compute + success_bonus + quality_delta_bonus + royalty_share - dispute_or_failure_penalties

This structure supports direct invocation, subscription credits, outcome escrow, local royalties, free/open workers, and benchmark-funded category admission under a single accounting model.

5. Settlement and Consensus

Settlement is not runtime execution, and local autonomous work does not spam the public chain. Hypervisor nodes settle autonomous work and interop locally through the Daemon, Agentgres, and local receipt chains. IOI L1 is reserved for global settlement, registry, reputation, disputes, and anchoring selected roots.

Non-Ownership Invariants:

• IOI L1 does not own or store Hypervisor-node local settlement state.
• IOI L1 does not own or record every governed autonomous-system-chain transition.
• IOI gas is not consumed for local settlement records or internal module invocations.

IOI L1 is a bounded settlement, routing, arbitration, and identity-anchor layer. It does not execute cognition; it finalizes the economic consequences of cognition executed elsewhere. By the time IOI L1 sees an act, the act has already crossed the Determinism Boundary and become a transaction-shaped artifact: canonical, authorized, policy-bound, receipt-backed, and challengeable. As the Root L1, it also serves as the decentralized custodian of the L0 protocol itself, governing upgrades to the IOI SDK and Daemon through a staked approval process.

Sovereign L1s govern their own application state independently but inherit the L0 kernel from the Mainnet-managed blueprint. For the open internet, IOI L1 hosts the global registry, public Gig Escrows, and the Deterministic Arbitration Engine.

This enables specialized agent economies (e.g., a "Medical Diagnosis Swarm" or "HFT Grid") to coordinate as sovereign networks or run in confidential cloud environments while inheriting the Mainnet's bounded primitives: Settlement, Arbitration, and Verification.

5.1 The Role of IOI L1: Settlement, Arbitration, and Routing

IOI L1 is a high-security ledger optimized for enforceability and discovery, not raw interaction throughput. It is the place where providers are discovered, the transaction records of acts become commitments, and disputes become resolutions.

IOI L1 responsibilities are intentionally bounded:

1. Settlement Core (The Toll Booth)

• Balance Finality: Maintains canonical balances for Labor Gas and related settlement assets.

• Channel Management: Opens and funds session escrows for cloud routing, and processes SettlementSummary closes to reallocate funds to providers.

• Routing Fee Capture: Programmatically diverts the protocol's micro-cut from closed cloud sessions to the network treasury/validators.

• Bond Custody: Custodies and enforces SLA collateral posted by Providers to guarantee uptime and honest execution.

2. Arbitration Core (Deterministic Arbitration Module)

• Dispute Intake: Accepts challenge packages (e.g., a user contesting a Gig Escrow) and initiates the specified dispute procedure.

• Resolution Enforcement: Executes remedies defined by the Arbitration Lane (escrow refunds, provider SLA slashing) under the governing ruleset.

3. Verification & Routing Anchor (The Address Book)

• Provider Registry: Maintains the global index of active Cloud and DePIN provider nodes, their hardware capabilities, IP endpoints, and staked SLA bonds. The off-chain Matching Engine uses this on-chain state to route workloads.

• Identity Anchor: Maintains the canonical mapping from DID -> public key / authority, establishing the root of trust for signed Worker Manifests and AIIP resolution.

• External Evidence Anchor: Stores state roots and verification rules for external chain evidence (e.g., Ethereum block headers), consumed by the External Evidence Interface (EEI, Section 6.2). This is an evidence-ingestion mechanism, not a bridge, the Kernel verifies external proofs without maintaining active light clients.

5.1.1 Operational Invariant: Optimistic by Default

IOI L1 is lazy by design. The local or session runtime produces transaction-shaped acts; IOI L1 settles only the economic boundary, not every cognition step. The actual transfer of context slices and offloaded execution happens entirely off-chain over secure session tunnels. IOI L1 assumes these off-chain sessions are valid unless challenged. It performs heavy work primarily at boundaries:

• Routing events: Provider registration, SLA bonding, and capability advertisement.

• Settlement events: Channel open/close, Gig Escrow netting, and protocol fee routing.

• Dispute events: Challenges, evidence verification, and algorithmic escrow refunds.

This yields orders-of-magnitude higher effective interaction capacity at the edge, while keeping IOI L1 load proportional to economic events, not cognitive steps.

5.2 Modular Consensus (The Driver Philosophy)

Before detailing the Mainnet's specific consensus engine, it is critical to establish that the IOI Runtime itself is consensus-agnostic.

The IOI Daemon enforces the Agency Firewall, normalizes inputs, and generates cryptographic receipts, but it does not dictate the security model of the network. The kernel interacts with consensus through a standardized ConsensusDriver interface, allowing IOI to run across a full fractal topology:

• Driver::Solo (Local Authority Mode): Used by local Hypervisor nodes. The user is the sole authority, resulting in zero-latency, free execution.

• Driver::Permissioned (Federated Mode): Traditional BFT (e.g., PBFT, Raft) or Multisig replication used by Sovereign L1s (e.g., enterprise consortia) to reach local agreement over domain state without publishing sensitive data to a public chain.

• Driver::AFT (Public Settlement Mode): The pure-software, high-throughput challenge-dominant public state continuity (PSC) engine utilized by the public Root Mainnet (detailed in Section 5.3).

5.2.1 Driver Invariance (The "USB-C" Rule)

Swapping the consensus driver does not change the artifact format.

• Schema Invariance: A Receipt has the same canonical fields and hashing rules regardless of the driver.

• Binding Invariance: Canonicalization (RFC 8785), model_snapshot_id, and policy_hash bindings remain identical.

What changes is the attestation class and available enforcement regime- not the semantics of the artifacts. This ensures Agent Portability across the fractal network: an agent built and tested in a private enterprise swarm can be upgraded, settled, or adjudicated on public IOI L1 without translation.

5.3 AFT: Challenge-Dominant Settlement Finality

To serve as the global settlement layer for an automated economy, the Root Mainnet requires a consensus model with fault tolerance well beyond classical BFT thresholds.

For 40 years, distributed systems have been constrained by the classical lower bound of Byzantine Fault Tolerance (BFT). Traditional permissioned networks tie deterministic safety to dense positive voting -- requiring a >2/3 honest majority to sign every block. Under this legacy model, if 34% of the network becomes malicious, the chain's security is mathematically broken.

To solve this, the IOI Mainnet is powered by Asymptote Fault Tolerance (AFT).

AFT is a proposed settlement-finality design that separates throughput-critical publication from authority-critical verification. Its goal is to make irreversible economic effects challengedominant and fail-closed: if required observer, witness, or retrievability evidence is missing or inconsistent, the slot aborts rather than settling unsafe state. The production Mainnet specification SHOULD state exact synchrony, adversary, data-availability, committee-selection, and challenge-window assumptions before advertising a quantitative Byzantine threshold.

5.3.1 The Two-Tier Finality Model

AFT implements a scalable two-tier finality model that keeps block transport on a hot path, then upgrades selected slots to a stronger irreversible-effect settlement state:

• BaseFinal (The Hot Path): A validator majority Quorum Certificate (QC) plus a Guardian committee certificate. Used for rapid chain progression.

• SealedFinal (The Irreversible Path): Upgrades BaseFinal using a deterministic sealing plane. Irreversible effects (e.g., releasing a Gig Escrow) require a proof-carrying SealObject that binds the observer/witness sealing surface.

Ambiguity or adversarial behavior during the sealing phase collapses deterministically to Abort, preventing the network from heuristically retrying or partially settling unsafe state.

5.3.2 Canonical Challenge V1: Deterministic Observer Sealing

To upgrade a block to SealedFinal without requiring >2/3 honest voting, AFT utilizes Deterministic Observer Sealing.

Observers are assigned deterministically via an epoch seed. Each observer evaluates the block and publishes exactly one of two objects:

• A guardian-backed AsymptoteObserverTranscript (Ok).

• An objective AsymptoteObserverChallenge (e.g., MissingTranscript, TranscriptMismatch).

The observer acceptance rule is strictly challenge-dominant:

• SealedFinal is accepted if and only if the TranscriptSurface covers every assignment and the ChallengeSurface is absolutely empty, emitting an AsymptoteObserverCanonicalClose.

• If any valid challenge exists, the slot deterministically emits an AsymptoteObserverCanonicalAbort.

Because canonical close and canonical abort are mutually exclusive, a challenge-dominated slot cannot authorize irreversible release. A single honest node can publish an objective challenge, deterministically killing the malicious block and slashing the attackers.

5.3.3 Endogenous Retrievability: Witness-Coded Recovery Capsules

To guarantee that the ordered set is unique and recoverable even when up to 99% of validators withhold data, AFT implements an Endogenous Retrievability Plane via Nested-Guardian witness committees.

• Witness-Coded Recovery: The protocol uses abstract coded recovery families (e.g., SystematicXorKOfKPlus1V1 or SystematicGf256KOfNV1) to generate RecoveryCapsules.

• Reconstruction: Threshold-many public RecoveryShareMaterial reveals can reconstruct the payload, outputting a compact RecoveredPublicationBundle.

• Fail-Closed Impossibility: If assigned witnesses fail to reveal their shares, the network accumulates MissingRecoveryShare objects. Once the missing count exceeds the threshold required for recovery, the protocol materializes a deterministic recovery-impossible canonical abort.

This ensures that the protocol does not stall indefinitely waiting for withheld data; it either recovers the payload or objectively aborts, maintaining the challenge-dominant safety property declared in the production specification.

5.3.4 Challenge-Dominant Settlement for the Agentic Economy

Because the IOI L0 framework is consensus-agnostic, agents execute their logic off-chain or on private Sovereign L1s. IOI L1 is the ultimate custodian of the economy's capital and the venue where authority-critical effects become irreversible.

AFT's design intent is that authority-critical settlement is challenge-dominant: under the declared synchrony, data-availability, and observer-coverage assumptions, missing or inconsistent evidence aborts a slot before unsafe state can settle. The exact adversary tolerance is a function of those assumptions and the active challenge windows; quantitative Byzantine thresholds are stated only in the production Mainnet specification, not in this whitepaper.

The architectural goal is to remove reliance on dense validator quorums for safety: settlement should fail closed when required evidence is unavailable, rather than rely on majority honesty alone.

5.4 The Settlement Core

The Settlement Core is the unified ingress/egress point for the IOI economy. It functions as the Final Settlement Authority. Its primary role is to enforce the economic consequences of agent actions based on the artifacts produced by the Kernel and finalized by AFT.

5.4.1 Settlement Pipeline

Any settlement artifact (Commitment, Bond Claim, Dispute) must pass the pipeline:

1. Ingestion: The Core receives a SettlementSummary or ChallengePackage.

2. Artifact Verification: Validates that all IOI Receipts (internal history) are cryptographically valid, canonical, and linked to a funded Session.

3. Evidence Review (Optional): If the settlement involves a disagreement regarding external outcomes, the Core inspects the attached Evidence Bundle (via the EEI) to determine if the contractual terms were met.

4. Resolution & Release: Based on the internal receipts and external evidence, the Core initiates the financial logic. The actual transfer of assets (releasing escrows, slashing bonds, or transferring Service NFT royalties) is explicitly held until the underlying AFT slot reaches SealedFinal status.

5.4.2 Driver-Based Interoperability

IOI enables agents to interact with any external system, blockchains, cloud APIs, or legacy databases, through I/O Drivers.

• No "Native" Chains: The protocol treats Ethereum, Solana, and AWS equally: they are external systems accessed via tools.

• Sovereign Vault Strategy: Interoperability is achieved through Key Management, not State Bridging. The IOI Kernel holds the signing keys (ECDSA, Ed25519) in the Sovereign Vault. Agents request signatures; the Policy Engine approves/denies them; and the Driver broadcasts the transaction.

• Atomic Swaps: Cross-chain value transfer is handled via standard Hashed Timelock Contracts (HTLCs) or liquidity solver networks orchestrated by the agent, rather than a native IOI bridge protocol.

5.5 Domain Networks, Sovereign Chains, and L0-Instantiated Execution Domains

The IOI kernel / L0 substrate may instantiate domain networks, sovereign execution domains, non-intelligent chains/state machines, and intelligent blockchains. These domains can use their own consensus, state, policy, receipts, and projection machinery. IOI L1 does not become their application runtime; it can anchor their release roots, registry commitments, settlement claims, governance approvals, and dispute outcomes.

Sovereign Domains and Intelligent Blockchains are formally instantiated via the IOI CLI. It is the developer-grade, kernel-adjacent surface for defining domain topology, policy roots, and delegation models. IOI CLI writes directly to the protocol kernel (L0); it is not a standard Web2 SaaS dashboard but a first-class protocol surface.

Because the network operates as an Operating System rather than a monolithic chain, a Sovereign L1 is simply an independent deployment of the universal L0 Blueprint (SDK).

5.5.1 The Independent Swarm Thesis

Unlike traditional Web3 L2 rollups designed to offload execution from a congested L1, IOI Sovereign L1s do not rely on IOI L1 for execution, validation, or anchoring by default. They are independent trust domains spawned from the exact same L0 DNA.

1. Execution Separated from Coordination: Cognitive work executes on user or provider hardware, while the sovereign L1 tracks the canonical coordination state, object transitions, leases, receipts, and projection checkpoints required by that trust domain.

2. Federated Consensus: Domain swarms (e.g., a hospital consortium, a trading firm) compile the L0 Kernel and run validators on their own infrastructure using lightweight consensus drivers (e.g., Driver::Permissioned). They reach local agreement over domain state without publishing sensitive data or paying gas to public IOI L1.

3. API-Native Interoperability Without Mandatory Enshrined Bridging: Sovereign L1s do not inherently need complex, protocol-enshrined bridges to communicate with the outside world. They expose standard gRPC or HTTP REST endpoints. Because they run the IOI SDK, their API responses are automatically packaged as canonical JSON accompanied by IOI Session Receipts. An external client can query a Sovereign L1 via Web2 APIs and mathematically verify the signatures against the L1's declared public keys (PKI trust), completely off-chain.

5.5.2 Deployment Topologies

Rather than a strict hierarchy, the IOI ecosystem supports parallel deployment topologies tailored to different trust and coordination requirements:

• The Root Mainnet (Public Utility): Runs Driver::AFT. Hosts the global ai:// registry, public Gig Escrows, and the Deterministic Arbitration Engine. It provides economic finality and a neutral ground for the Service-as-a-Software (SaS) economymediating trust between users, independent developers (Service NFTs), and on-demand execution providers.

• Sovereign L1s (App-Specific): Runs Driver::Permissioned or custom lightweight drivers. Handles domain-specific coordination, internal app serving, and enterprise workspaces. They manage their own internal state and do not anchor to Mainnet unless explicitly exporting trust or participating in cross-domain public settlement.

6. Cryptography and Evidence

This section specifies the cryptographic primitives the IOI architecture requires. The protocol is designed for institutional risk models: cryptography that remains durable under future cryptanalytic shifts, and evidence interfaces that verify external state without trusting opaque APIs or centralized bridges.

The protocol enforces two primary invariants:

1. Longevity: artifacts and identities remain secure against future cryptanalytic shifts, including large-scale quantum adversaries.

2. External Evidence Verification: the kernel can verify claims about external state (e.g., Ethereum transactions, Solana proofs) under explicit driver-specific verification rules, without maintaining active light clients or trusting centralized bridges.

6.1 Strict Hybrid Cryptography (Classical + Post-Quantum)

Post-Quantum (PQ) algorithms are newer and potentially vulnerable to undiscovered implementation flaws. The protocol therefore adopts a Strict Hybrid security model. This ensures safety against quantum adversaries without abandoning the proven robustness of classical cryptography. The algorithms listed below are the genesis suite (required at launch). The Verifier Registry (Section 6.5) provides the agility path for future algorithm rotation without protocol hard forks.

Where long-term security matters (identity, policy commitments, registry roots), IOI requires the simultaneous satisfaction of both classical and post-quantum proofs.

• The Dual-Entropy Mnemonic (The Root): The foundation of the hybrid stack is a native Dual-Entropy Mnemonic. A single root seed deterministically derives both classical keys (secp256k1 / Ed25519) for legacy asset compatibility and Post-Quantum keys (ML-DSA-44) for native Web4 artifacts.

• Transport (Harvest-Now / Decrypt-Later resistance): Session channels utilize an Application-Layer Hybrid KEM handshake. The protocol combines classical ECDH (X25519) with a NIST-standardized PQ KEM (ML-KEM-768, derived from CRYS- TALS-Kyber). This ensures forward secrecy for agent sessions even if the underlying transport (TLS) is recorded and quantum-decrypted in the future.

• Identity & Policy (Dual-Signature Invariant): Long-lived identities (Guardian/ User/Vault) and critical control artifacts (RootGrants, Policy Envelopes) employ a hybrid signature scheme: Ed25519 + ML-DSA-44 (formerly CRYSTALS-Dilithium). To be considered valid, an artifact MUST carry valid signatures from both algorithms. This ensures that a mathematical break in either the classical or the lattice-based systems is insufficient to compromise the network.

• Data at Rest (Symmetric Hardness): For the Sovereign Vault and bulk Context Slices, the protocol utilizes XChaCha20-Poly1305. With a 256-bit key space, this symmetric primitive is inherently resistant to quantum search (Grover's Algorithm) and avoids the performance overhead of asymmetric PQ encryption for bulk storage.

Invariant: IOI optimizes for durable accountability via redundancy. Security relies on the conjunction of classical hardness and post-quantum lattice assumptions, ensuring artifacts remain verifiable decades into the future regardless of which mathematical branch survives.

6.2 The EEI: External Evidence Interface

The IOI Kernel is an Operating System, not a Bridge. It does not maintain active light clients or sync external blockchain headers. Instead, it verifies external state through a passive evidence model: agents submit structured proof bundles; the Kernel validates them.

To prove that an external event occurred (e.g., "This transaction was confirmed on Ethereum" or "This bank API returned 200 OK"), agents utilize the External Evidence Interface (EEI).

EEI is what lets an IOI act remain transaction-shaped even when the external consequence occurs outside IOI. The IOI receipt binds the agent's authorized intent; the EEI bundle binds the external system's proof of consequence.

6.2.1 Evidence Bundles

The EEI defines a standard schema for wrapping external data so it can be ingested by the IOI Arbitration Core. An Evidence Bundle consists of:

1. The Claim: A canonical JSON object describing the event (e.g., { "chain": "eth", "tx_hash": "0x...", "event": "Transfer", "amount": 100 }).

2. The Proof: Cryptographic material supporting the claim. This is driver-specific:

3. For Blockchains: An RPC receipt proof, a merkle inclusion proof, or a block header signed by a known oracle/notary.

4. For Web APIs: A TLSNotary proof or a signed attestation from a Multi-Party Computation (MPC) witness.

5. The Binding: A hash link to the specific Agent Action Receipt that triggered the external event.

Normative Invariant (Zero-Bloat Verification): The firewall evaluates chain-visible manifests and receipts that bind request_hash to evidence_hash. Raw local bytes remain in ioi-memory / Agentgres; only the canonical hash crosses to consensus.

6.2.2 Verification via Drivers

The Kernel does not verify the Evidence Bundle natively. Instead, verification is delegated to the Driver that generated the action.

• Example: If an agent uses the driver::eth_wallet to send funds, that driver includes the logic to parse and validate an Ethereum Receipt.

• Arbitration Role: In a dispute, the Arbitration Node loads the relevant Driver Plugin to validate the Evidence Bundle. If the Driver confirms the proof is valid according to the external network's rules, the IOI Kernel accepts the Claim as truth for settlement purposes.

Chain of Custody: The Kernel secures the Intent (Policy + Signing). The Driver secures the Evidence (Formats + Proofs).

6.3 Canonicalization: The Common Tongue

To enable seamless movement of artifacts between Local, and Global environments, IOI enforces strict data canonicalization.

Normative Standard (External): RFC 8785 (JSON Canonicalization Scheme, JCS), which builds on I-JSON constraints and deterministic property sorting to produce a hashable representation. ([RFC Editor][2])

6.3.1 Determinism Invariant

Before hashing or signing, runtimes MUST canonicalize payloads:

• No whitespace variance

• Deterministic key ordering (UTF-16 code unit order, locale-independent)

• Reject NaN/Infinity

• Economically meaningful quantities MUST NOT use JSON numbers; represent as fixed-point strings at the schema layer

6.3.2 canonical_payload_hash Every IOI artifact is identified by a hash computed over canonical bytes:

let canonical_bytes = jcs :: canonicalize ( & payload )?;
let artifact_id = H( & canonical_bytes );

6.4 Domain Separation

To prevent replay across contexts, IOI enforces strict domain separation:

Canonical domains include:

• SIG_DOMAIN_BLOCKHEADER (Global)

• SIG_DOMAIN_RECEIPT (Session)

• SIG_DOMAIN_ARBITRATION

• SIG_DOMAIN_MANIFEST

6.5 Cryptographic Agility (Verifier Registry)

Instead of hardcoding algorithms into the consensus binary, the protocol uses an on-chain Verifier Registry:

Algorithm_ID -> Verifier_WASM_Blob

Upgrade path: new signature schemes or proof verifiers can be added via governance-approved module updates without protocol hard forks. This mechanism is staged; the genesis algorithm suite (Section 6.1) is specified not to require a chain halt to extend.

6.6 Proof-Carrying Clean Rooms

Clean-room execution is substrate-neutral. IOI does not require Trusted Execution Environments as a root of authority. TEEs may be used as one admissible execution substrate for confidentiality and operational practicality, but they do not define validity. A clean-room action becomes valid only when its execution evidence satisfies the required receipt set for its action class. Where feasible, IOI prefers proof-carrying computation -- including zero-knowledge proofs, verifiable computation, FHE-backed private evaluation, MPC, or hybrid constructions -- because these reduce reliance on hardware attestation roots and align clean-room execution with the protocol's deterministic settlement model.

IOI treats clean-room execution as a substrate-neutral evidence problem. A clean room may protect confidentiality, correctness, or both:

1. Confidentiality: The worker computes over sensitive inputs while minimizing disclosure. FHE and MPC can replace TEEs for bounded private evaluation where latency and cost permit.

2. Correctness / Verifiability: The worker proves that a committed computation was executed correctly. ZK-ML and verifiable computation can satisfy bounded inference, classifier, policy, or scoring claims without relying on a hardware vendor as the sole attestation root.

3. Operational practicality: TEEs remain admissible for running ordinary software with lower integration friction. In IOI they are treated as evidence adapters, not as protocol trust roots.

The settlement layer verifies receipt sufficiency, not substrate identity. The verifier registry therefore supports TEE quote verifiers, ZK proof verifiers, MPC transcript validators, FHE parameter validators, deterministic replay verifiers, and future proof systems. The canonical settlement question is not "Did this run in a TEE?" but "Does the receipt bundle satisfy the Required Receipt Set for this action class?"

Normative invariant: A clean-room substrate MUST NOT be treated as a source of authority. Authority is derived from request hash, policy hash, approval chain, capability scope, receipt completeness, and settlement rules. The substrate contributes evidence only.

6.6.1 The CleanRoomExecutionReceipt

A CleanRoomExecutionReceipt is not itself an authority grant. It is an evidence envelope. Validators accept or reject the action by checking whether the receipt set satisfies the Required Receipt Set for the action class. A TEE quote, ZK proof, MPC transcript, FHE commitment, deterministic replay result, or hybrid proof may satisfy part of that set, but no substrate alone defines validity.

CleanRoomExecutionReceipt { receipt_version, substrate: "local_deterministic" | "tee" | "fhe" | "mpc" | "zkml" | "verifiable_computation" | "hybrid", action_request_hash, offload_packet_hash, policy_hash, authority_grant_id, model_or_program_hash, execution_plan_hash, input_commitments, output_commitments, context_slice_commitments, proof_refs, attestation_refs, mpc_transcript_refs, fhe_parameter_refs, zk_circuit_or_vm_ref, verifier_requirements, leakage_bounds, erasure_or_key_lifecycle_evidence, observation_refs, settlement_class, receipt_root_binding, provider_signature, guardian_signature }

7. Identity and Authority

In the Internet of Intelligence, identity must bridge two worlds... assets, reputation, and liability. We are moving from Know Your Customer (KYC) to Know Your Agent (KYA).

KYA is the identity layer that lets Own become Act without becoming ambient authority. It turns property rights into scoped, revocable, receipt-backed execution authority.

• KYC (Biological): Validates who you are (Passport, ID).

• KYA (Cryptographic): Validates what you are (Code hash), how you behave (Policy envelope), and what you are worth (Bonded Liability). The IOI Identity stack ensures that while an agent may be autonomous, it is never anonymous to the ledger.

IOI uses a progressive identity model. Users (and agents) are not forced to manage seed phrases to begin; they start with device-local authority and upgrade to network sovereignty only when they need to hold funds or sign binding contracts.

7.1 Guardian-Managed Identity (Legible Agency)

The Guardian is the node's trust anchor: it holds protected signing keys and enforces nonequivocation via an append-only receipt chain. A Guardian signature is not merely a proof of origin; it is an accountability attestation- because equivocation and receipt gaps become detectable, and (where bonded) provably punishable under network rules.

This is what makes software legible to the economy: an agent can be given a budget because its actions are auditable, bounded by policy, and, when operating under enforceable modes, subject to slashing or dispute enforcement.

7.2 The Superset Identity Stack (Master vs. Ops)

IOI explicitly separates the authority to act (Operational) from the authority to own (Economic) while requiring the former to inherit deterministic constraints from the latter. However, to prevent legacy cryptographic vulnerabilities from compromising Web4 agency, IOI introduces a Cryptographic Superset Identity Model. This model replaces the mandatory reliance on legacy EOAs with a native, Post-Quantum secure root that manages both assets and agency under a unified, user-defined security threshold.

The protocol implements a three-tier identity stack that progresses from frictionless onboarding to institutional-grade security, anchored by a native Dual-Entropy Mnemonic.

Tier 1: The Master Custodian (Native Root)

• Role: Sovereign custody of all funds, Post-Quantum identity anchor, and final settlement authority.

• Implementation: A native Web4 identity generated via a Dual-Entropy Mnemonic. This single root seed derives classical keys (secp256k1 / Ed25519) for legacy Web3 assets (ETH/SOL) alongside Post-Quantum keys (ML-DSA-44) for native Web4 artifacts such as Service NFTs and Policy Envelopes.

• Function: The Master Custodian serves as the absolute "Source of Funds" and "Root of Policy." It is never directly connected to a high-frequency agentic workflow or dApp. It is secured by the user's highest configured authentication threshold (e.g., 3FA/MPC). While users may optionally link a legacy Web3 hardware wallet (the "Link and Upgrade" bridge) as a liquidity source, the Master Custodian is the sovereign apex of the stack.

Tier 2: The Manager (wallet.network / Sovereign IAM Hub)

• Role: Hot management of secrets, policies, session automation, and out-of-band approvals.

• Implementation: wallet.network, acting as a local Identity & Access Management (IAM) control plane and authority issuer.

• Cryptography: Strict Hybrid Post-Quantum (Ed25519 + ML-DSA-44 for signatures; X25519 + ML-KEM-768 for channel handshakes with the Guardian).

• Function: The Manager holds "Operational Authority." It evaluates agent requests against the user's pre-approved Policy Envelope. Based on the user's configured Frictionless-to-Fortress policy, it either auto-signs intents, executes capabilities internally via the Credential Enclave, or triggers Step-Up MFA (e.g., FaceID or YubiKey) to mint time-bounded Session Keys and ApprovalTokens.

Tier 3: The Worker & The Ops Wallet (Execution Layer)

• Role: Autonomous execution of tasks and on-chain interactions.

• Implementation: Ephemeral Session Keys held by the Agent Runtime, executing through an Agent Execution Account (Ops Wallet).

• The Smart Account Upgrade: To ensure security survives a compromised runtime, the Ops Wallet is deployed as an ERC-4337 Smart Account.

• Function: The Tier 2 Manager authorizes the Tier 3 Ephemeral Session Keys as temporary module signers for the Smart Account. Workers operate autonomously within their granted scope. Crucially, On-Chain Modules (e.g., Spend Limits, Contract Allowlists) act as the ultimate physical enforcer. Even if the local Guardian is compromised or an agent goes rogue, the blockchain physically prevents the agent from draining funds beyond the module's strict limits defined by the Master Custodian.

Manager-Delegated Agent Autonomy: In this architecture, agents do not generate raw signed transactions. Instead, an agent generates a canonical TxIntent. The Tier 2 Vault evaluates this intent against the Policy Envelope and the user's current security tolerance settings.

• Low-Risk Intents (e.g., read-only calls, allowlisted swaps) are processed with Level 1 (Frictionless) auth.

• High-Risk Intents (e.g., modifying network allowlists, transfers exceeding caps) trigger an Out-of-Band Step-Up, requiring the user to sign an ApprovalToken via a TEE-backed factor (FaceID) or a physical hardware key (YubiKey).

This model completely isolates the risk of the active execution environment from the user's primary capital, achieving scalable autonomy without sacrificing self-sovereignty or inheriting the vulnerabilities of legacy Web3 cryptography.

The Link and Upgrade Bridge To avoid inheriting legacy Web3 vulnerabilities, IOI does not use MetaMask as the root Web4 identity. Instead, it generates a native Post-Quantum seed and allows users to cryptographically link their legacy EOA (via SIWE, Sign-In with Ethereum) as an onboarding factor and liquidity source. This "Link and Upgrade" pattern preserves access to existing Web3 assets while ensuring the sovereign root of identity is always Post-Quantum secure and under IOI's governance model.

7.3 wallet.network: The Authority Control Plane

The protocol requires wallet.network--the canonical Web4 authority layer. It is an identity, secret, authority-scope, approval, payment, and revocation control plane for autonomous software. It manages not just asset ownership but also access control, liability limits, and the cryptographic authority of a digital workforce.

Architecturally, it functions as a Cryptographic Superset. By implementing a Dual-Entropy Mnemonic, a single root seed natively derives both classical keys (secp256k1/Ed25519) for legacy Web3 assets and Post-Quantum keys (ML-DSA-44) for native Web4 artifacts. It scales its security requirements dynamically via Configurable Signature Thresholds, allowing the user to define the balance between friction and "Fortress" security.

Core Capabilities:

• The Credential Enclave: Securely custodies Web2 secrets (AWS, Stripe, OpenAI). It enforces a strict security invariant: The agent requests effects, not keys.

• Frictionless-to-Fortress Auth: Supports progressive security starting from Google OIDC (1FA) to TEE-backed Biometrics (2FA) and institutional MPC Sharding (3FA+).

• Zero-Trust Extensibility: Provides a programmatic SDK and a sandboxed WASM marketplace for third-party developers to integrate custom API connectors securely.

• Unified Audit Log: A real-time, immutable feed of every key accessed, policy triggered, and Labor Gas unit spent, providing total observability into the "Black Box" of AI execution.

7.3.1 The Credential Enclave (Capability Execution & Secret Isolation)

Standard agents often require API keys in environment variables, creating massive attack surfaces. The IOI architecture fundamentally rejects this model. To achieve secure automation, wallet.network manages credentials exclusively through Capability Execution:

1. Storage (Data at Rest): Keys are stored locally within wallet.network, encrypted at rest using XChaCha20-Poly1305 and envelope encryption (Argon2id KDF). They are strictly inaccessible to client apps or agent sandboxes.

2. Request (The Intercept): When an agent attempts a tool call (e.g., tools/ call:stripe), the IOI Daemon sends an AuthorityScopeRequestEnvelope directed at wallet.network.

3. Capability Execution: The Vault evaluates the request against the active Policy Envelope. If authorized (and MFA is satisfied), the Vault executes the capability internally- making the external API call or signing the transaction itself.

4. Return (Sanitized Delivery): wallet.network returns only the sanitized result (e.g., the API response) to the agent daemon. The secret never leaves wallet.network's control plane and never enters the agent's runtime space.

7.3.2 The Multi-Factor Identity Model (Frictionless-to-Fortress)

The Sovereign IAM Hub utilizes Threshold Cryptography (MPC) to support progressive security levels:

• Level 1 (Frictionless 1FA): Google OIDC (Social Login) + ZK-Login via MPC Managed Shard. Enables instant onboarding and low-value agentic read/writes with zero wallet friction.

• Level 2 (Trusted Device 2FA): Mobile biometric enclaves and WebAuthn authenticators can provide a hardware-backed local-user-presence signal under the device vendor's security model. IOI treats this as a step-up authentication factor, not as a proof of legal identity or an infallible proof of physical presence.

• Level 3 (Sovereign Fortress 3FA+): Configurable MPC Sharding requiring hardware keys (YubiKey/FIDO2) with fractional or absolute approval thresholds for highstakes capital movement or policy widening.

• Sovereign Backup: Users utilize the Dual-Entropy Mnemonic for ultimate recovery. This allows them to "eject" from the wallet.network interface while retaining both their legacy Web3 wealth and their Web4 agentic fleet.

7.3.3 Session Keys (The Burner Wallet Pattern)

To operationalize the hierarchy, IOI implements capability delegation via Session Keystemporary keypairs issued to Tier 3 Workers. These are constrained by an explicit Policy Envelope (specific capabilities + spend limits + target whitelists).

• Expiry: Keys are strictly Time- or Block-bounded.

• Revocation: Session authority can be revoked by the Manager Identity at any time by advancing the revocation_epoch, instantly invalidating the agent's ability to act or spend.

7.3.4 The Manager Node (Delegated Authority)

For complex swarms, the User delegates coordination to a Manager Node. Unlike a standard Worker, a Manager is authorized to mint Session Sub-Keys for its subordinates.

• Delegation Certificate: To hire a worker, the Manager signs a certificate binding the new Worker's ephemeral key to a monotonic narrowing of the Manager's own budget and policy.

• Cascading Revocation: The Vault retains an absolute "Kill Switch." Revoking the Manager's primary certificate triggers a cascading termination of all downstream Sub-Keys and associated payment channels.

7.3.5 Zero-Trust Extensibility Framework

The Sovereign IAM Hub supports programmatic extensibility (see Section 7.3 for product surface details):

• Permissionless Domain Integration: Any third-party platform can integrate the open wallet-sdk to request Agency Grants. The Vault cryptographically verifies the origin and requires user consent before issuing a bounded Session Key.

• Sandboxed Connector Marketplace: Developers can build and publish new API connectors (e.g., custom CRM or niche banking APIs). These run inside a hermetic WASM sandbox (WASI) injected only with the specific secret required, physically preventing third-party logic from exfiltrating other Vault credentials.

7.4 Portable App Sessions (Agentgres Authority)

Centralized session state (cookies, JWTs against a single database) breaks in a multi-plane architecture where users failover between Provider Nodes.

IOI replaces centralized session state with Stateless Portable Capability Tokens.

Rather than a node looking up a session in a local database, the client holds a cryptographically signed artifact (SessionAuthorization or SessionLease) that dictates exactly what canonical state it can read, what projections it can subscribe to, and what mutations it can request.

Authority-bound restore. Portable sessions restore through authority-bound import. A sealed archive may contain task state, run checkpoints, traces, artifact refs, patch branches, projection checkpoints, and replay metadata. It should not silently mutate live truth. Agentgres must verify authority, hash, policy, schema, state root, and object heads before rehydration, then emit RestoreReceipts.

7.4.1 The Stateless Authentication Flow

Portable session tokens carry an explicit cryptographic envelope containing:

• session_id or lease_id

• subject_id (The User/Principal) and issuer_id (The Vault/Manager)

• policy_hash (The overarching ruleset)

• capability_subset and projection_scope (What specific Agentgres views can be read)

• expires_at and revocation_epoch

Because these tokens are self-contained and signed by the user's wallet.network (Tier 2 Vault), validation on any Provider Node is completely stateless. If the active node serving an Agentgres projection goes down, the client seamlessly reconnects to a new healthy node, presents the same portable token, and resumes its subscription stream. The new node validates the signature, expiry, and capability scope against the canonical state without needing a shared backend database.

7.4.2 The Auth Split: Portable vs. Pinned Authority

To balance seamless application failover with strict security for high-stakes actions, the KYA framework enforces a strict bifurcation in how tokens are audience-bound:

1. Portable Session/Lease Tokens (For App State):

• Usage: Reading Agentgres projections, maintaining resumable subscriptions, and requesting routine workflow mutations.

• Audience Binding: Bound to the logical application instance or runtime identity, not a specific physical node. This ensures cross-node failover for normal app continuity.

2. One-Shot Approval Tokens (For High-Risk Execution):

• Usage: Sensitive capability execution (e.g., spending funds, signing mainnet transactions, modifying core firewall policies).

• Audience Binding: Tightly pinned to a specific physical executor or Guardian ID via nonce, counter, revocation_epoch, and strict audience fields. These cannot be ported to another node; they are exact, single-use cryptographic authorizations.

This model completely isolates the risk of the active execution environment. It allows user interfaces to remain fast, distributed, and highly available via Agentgres, while guaranteeing that irreversible sovereign actions remain explicitly gated and physically pinned.

7.5 Authority Scope Request Flow

The core architectural doctrine of IOI is that Hypervisor/IOI Daemon executes the work, Agentgres remembers the work, but wallet.network authorizes the power to do the work. This is the operational bridge from Own to Act: ownership becomes executable only through scoped authority grants bound to request_hash, policy_hash, budgets, expiry, and revocation_epoch. This is executed through a strict request flow:

1. Request: The agent/runtime encounters an effectful tool node and issues an AuthorityScopeRequestEnvelope to wallet.network. The request declares the required Primitive Capabilities (prim:) and the requested Authority Scopes (scope:).

2. Evaluation: wallet.network evaluates the request against the active policy. If the action exceeds autonomous thresholds (e.g., risk_class: funds_transfer), it triggers a Hardware-Interrupted Step-Up.

3. Issuance: If approved, wallet.network issues an AuthorityGrantEnvelope containing the exact request_hash, allowed scope:* strings, resource constraints (budgets/deadlines), and the current revocation_epoch.

4. Execution & Receipt: The IOI Daemon executes the tool bounded by that grant, returning a ToolExecutionReceipt that is appended to the Agentgres domain log.

8. Economics and Arbitration

IOI prices verifiable work rather than raw inference, and resolves disputes through staged arbitration rather than open-ended adjudication. This section consolidates the four protocollevel economic mechanisms: the Market of Workers (8.1), the artifact hierarchy that standardizes accountability across that market (8.2), the agentic core that performs deterministic arbitration when work is contested (8.3), and the pricing model that translates outcomes into Labor Gas, contribution receipts, royalties, and settlement (8.4).

8.1 The Market of Workers

IOI turns Mixtures of Workers into Markets of Workers.

In Web3, users pay for blockspace. This is the economic form of executable ownership: users do not merely own assets or permissions; they delegate bounded authority and pay only for acts whose receipts can be verified, challenged, and settled. In the Internet of Intelligence (IOI), users pay for verifiable work within a Market of Workers.

The market for verifiable work has three related supply-side markets:

1. Workers that perform work.

2. Training services that create or improve workers.

3. Benchmarks that determine routing eligibility inside sparse worker categories.

This is what prevents the IOI economy from collapsing into a single model marketplace. The economically relevant unit is not the largest model; it is the worker that can produce the best verified outcome under the relevant constraints.

The question this section answers is: how is the financial risk of agent failure managed? IOI structures agentic labor into two economic modes, each with a distinct risk allocation and evidence requirement.

1. The Outcome-Based Escrow (On-Demand Gigs) Best for: Task-based outsourcing, discrete deliverables, and untrusted agents.

In this mode, the user does not buy the agent itself; they buy the outcome. The economic relationship mirrors hiring a freelance contractor for a specific gig, utilizing the blockchain as an algorithmic escrow agent to guarantee delivery.

• The Mechanism (Gig Escrows): The user defines the specific success criteria of the job using a deterministic Intent Schema (e.g., "Output must be valid JSON matching this structure," or "Code must pass this specific test suite"). The user then funds a Gig Escrow on-chain (or via a Solver) with the required bounty.

• Execution: The hired Agent (Worker) performs the computational labor off-chain within a Session or via a Provider Node.

• Resolution: Upon completion, the Agent submits its final deliverable and cryptographic receipts (the transaction records of the acts that produced the deliverable) to the network's Deterministic Arbitration engine.

• Settlement: The Arbitration engine mathematically compares the deliverable against the user's Intent Schema.

• Success: If the output matches the schema, the work is cryptographically verified, and the escrowed funds are automatically released to the Agent/Provider.

• Failure: If the output fails the schema checks (e.g., the code doesn't compile, or the AI hallucinates a non-compliant format), the work is rejected, and the funds are returned to the user in full.

The Economic Result: Zero insurance is required. The user takes absolutely no financial risk on the agent's cognitive capabilities. If the AI hallucinates or fails, the provider wastes compute, but the user does not lose their money. They only pay for strictly verified success.

2. The Service-as-a-Software Model (Embedded Assets) Best for: Long-running background processes, proprietary enterprise workflows, and highlytrusted models.

This mode represents the pure realization of Service-as-a-Software (SaS). Instead of paying a recurring subscription to access a vendor's dashboard, the user purchases the agent as a portable software asset and operates it continuously as an embedded worker.

• The Mechanism (Asset Acquisition): The user acquires the Worker Manifest and deploys it either on their local hardware (Native User Node) or on a privately rented cloud instance (Session). The agent becomes a permanent, self-updating employee.

• Security (The Agency Firewall): Because the agent is acting continuously on the user's behalf, security is not guaranteed by post-execution arbitration, but by pre-execution deterministic limits. The user wraps the agent in the Agency Firewall, defining a strict, immutable Policy Envelope.

• Example: The user limits the agent to a maximum spend of $50 per day, restricts its network access to a strict whitelist (api.exchange.com and stripe.com), and requires biometric human approval for any transaction over $10.

• Liability ("As-Is" Execution Risk): The agent operates autonomously within this strict sandbox. If the agent hallucinates or makes a poor decision within its legal bounds (e.g., it decides to execute an unprofitable trade but stays under the $50 spend limit), the user absorbs the cost.

The Economic Result: The user accepts the cognitive risk of the agent's logic in exchange for absolute data sovereignty and zero marginal execution fees (beyond raw compute). Financial catastrophe is prevented not by capital-heavy insurance pools, but by the physical impossibility of the agent breaching the firewall's mathematical boundaries.

8.1.1 Cryptographic Evidence

Cryptographic evidence provides objective, machine-verifiable proof of execution, provenance, authorization, and compliance. Each category produces hash-linked artifacts that can be independently validated without re-executing the workload.

Execution Receipts The foundational evidence layer. Every effectful step produces a chain of receipts binding intent to execution:

• intent_hash = H(canonical_intent) - tool name, parameter schema, target selectors, risk surface, deadlines.

• Per-step hashes chained as a Merkle-linked log: step_i_hash = H(step_i || step_{i-1}_hash).

• policy_binding_hash = H(policy_version || rule_ids || scopes || exceptions) - optionally co-signed by the policy authority.

• Clean-room evidence receipt, if applicable: a substrate-specific evidence object binding the run to the declared model/program hash, policy hash, input commitments, output commitments, and verifier requirements. This may include TEE attestation quotes, ZK proofs, MPC transcripts, FHE parameter commitments, deterministic replay signatures, or hybrid proof references.

Determinism & Replay Evidence Enables independent verification that a given execution trace is consistent with its declared inputs:

• Canonical input transcript: all tool I/O normalized (CIM / canonical JSON / protobuf canonicalization), hashed.

• Deterministic seed receipt: seed_commit = H(seed || run_id) with optional commit--reveal for delayed disclosure.

• Replay proof: re-execution by an independent verifier confirms the transcript hash matches, signed by the verifier.

Data Provenance & Integrity Proves the lineage and integrity of all artifacts consumed or produced during execution:

• Content-addressed artifacts: blobs stored by hash (IPFS / Arweave / local CAS); receipts reference content_hash.

• Merkle inclusion proofs: prove an artifact was part of a larger bundle or log.

• Source authenticity: upstream signatures (signed packages, TLS certificate pin evidence, signed documents) proving "came from X."

Human Authorization & Keying Evidence Establishes the chain of consent from user to agent:

• User consent receipt: signed approval over the intent hash + scope + expiry (session key, passkey, wallet signature).

• Delegation / session key chain: parent key -> delegated key (capabilities, TTL) -> action signature.

• Quorum approval (optional): M-of-N signers for high-risk actions.

Privacy & PII Minimization Evidence Proves compliance with data-handling obligations without revealing the protected data itself:

• Selective disclosure receipts: hashes and redacted strings with a redaction_manifest_hash describing what was removed.

• Proof-of-scrub: cryptographic commitment to raw input in a sealed vault; only the scrubbed transcript + hash pointers are published (auditors can verify under legal process).

• Egress allowlist receipts: signed statement that outbound domains/targets were permitted by policy at the relevant version.

External Anchoring Anchors the receipt chain to external time and storage to prevent retroactive falsification:

• Append-only log anchoring: periodic commitment of the Merkle root of receipts to a chain or transparency log.

• Timestamping: RFC 3161 timestamp token or chain timestamp; binds receipt existence to a verifiable time window.

8.1.2 Dialectic Evidence

Dialectic evidence addresses policies that are not purely mechanical, e.g., "don't be deceptive," "don't collect sensitive info," "don't violate ToS", where compliance is contextual rather than binary. The protocol defines a structured adversarial process to resolve these claims.

Claim--Challenge--Response The atomic dispute unit. A structured three-phase exchange that bounds the scope of inquiry:

• Claim: "Action A complied with policy P under context C," with references to cryptographic receipts (hashes only if privacy-sensitive).

• Challenge: Adversary submits a specific alleged violation and bounded evidence requests.

• Response: Agent reveals minimal additional evidence (selective disclosure) or produces a counter-argument.

Dialectic Transcripts with Commitment Ensures the full record exists before selective disclosure begins:

• Commit to the full private transcript hash up front.

• Run the debate on redacted excerpts.

• If escalated, reveal additional evidence under controlled rules; every reveal is itself receipted.

Adversarial Spot-Check Audits Randomized sampling that makes log forgery probabilistically detectable:

• Randomly sample steps or episodes from the execution trace.

• Require the agent to produce witness bundles (inputs, intermediate state summaries, tool outputs) for the sampled steps only.

• Penalize inability to produce consistent witnesses (detects missing or forged logs).

Multi-Judge / Jury Verification Panel-based adjudication for claims requiring contextual judgment:

• A panel (human, model, or hybrid) votes on compliance.

• Judges sign an attestation over: (policy_hash, claim_hash, evidence_bundle_hash).

• Optionally weight judges by stake or reputation.

Counterfactual Tests Forces the agent to justify its choices against plausible alternatives:

• Verifier proposes an alternative compliant action A' and asks: "Why wasn't A' chosen?"

• Agent must provide bounded rationale linked to planning receipts (e.g., constraint satisfaction, tool availability, risk scoring).

Remedy & Liability Outcomes Defines the enforcement actions triggered by an upheld violation:

• If violation upheld: generate a Fault Receipt (verdict + violated_rule_ids + impacted_artifacts).

• Trigger automated remediation: revoke session keys, rotate secrets, quarantine artifacts, compensate affected party, each action receipted.

The Liability Ceiling (Strategic Constraint) To ensure the long-term integrity of the agent supply chain, IOI enforces a Liability Ceiling based on the model source:

• Passthrough Agents (APIs): Agents relying on third-party, closed-source APIs are generally capped at Level 1 (Auditable). Because their execution is opaque, they cannot produce the replay proofs or full execution receipts required to defend themselves in Level 3 Arbitration. This forces them to rely on subjective trust or over-collateralization to participate in insured tiers.

• Native Agents (Open Weights): To unlock high-certainty enforcement, workloads must migrate to Open Weights running on attested IOI Provider Nodes. These agents produce complete, replayable execution traces and receipt chains, enabling them to mount a full cryptographic defense in the Arbitration Lane.

This structure creates a natural "Bridge" incentive: developers can onboard instantly using APIs, but must distill their logic into Open Weights to unlock the full security and economic efficiency of the Market for Liability.

The Adaptive Default By default, the IOI economy operates at Level 1 (Auditable). When an agent needs to hold value or interact with strangers, it upgrades to Level 2 (Insured Bonded) by requiring a Provider or Developer Challenge Bond. Only when an outcome is contested does it escalate to Level 3 (Enforced).

This "escalate-as-needed" model ensures verification costs scale with consequence, not with every intermediate cognitive step.

8.1.3 Worker Training as Verifiable Work

Worker training is itself a Service-as-a-Software outcome.

The customer does not merely buy a fine-tuned model. The customer buys a trained, benchmarked, policy-bound worker capable of performing a scoped task under receipt obligations.

A worker training engagement produces:

1. workflow traces

2. examples and counterexamples

3. DomainOntology refs

4. CanonicalObjectModel refs

5. DataRecipe and ConnectorMapping refs

6. PolicyBoundDataView refs

7. DistilledOntologyDataset refs

8. EvaluationDataset refs

9. TransformationReceipts

10. policy envelope

11. WorkerManifest

12. benchmark report

13. evaluation receipts

14. deployment package

15. optional aiagent.xyz listing

16. optional sas.xyz outcome wrapper

Training may include model fine-tuning, but fine-tuning is not required. A worker can be trained by improving its prompts, skills, retrieval corpus, verifier gates, tool policies, workflow graph, domain ontology, data recipes, memory substrate, route policy, or fallback strategy.

A canonical training envelope MAY describe a Synthetic Bootstrapping Pipeline.

One important Worker-creation pattern in the IOI ecosystem is the generation of synthetic datasets to specialize local models. In this pattern, a high-reasoning Planner defines the task domain, schema, rubrics, and edge cases; Generator workers produce candidate examples or traces; Verifier workers and deterministic gates filter the corpus; and the resulting dataset is used to fine-tune, distill, configure, or benchmark a specialized Worker.

The canonical flow for this pattern is:

Define Intent Schema -> Planner Scopes Dataset -> Generators Produce Synthetic Corpus -> Quality Gates Filter Corpus -> Fine-Tune -> Bind Policy Envelope -> Emit EvaluationReceipt -> Deploy as Worker

IOI does not require synthetic data, fine-tuning, or any specific model architecture. It requires that claims about training, evaluation, specialization, and deployment be represented through auditable envelopes and receipts. By tracking these inputs, IOI treats the creation, specialization, and evaluation of Workers as a fully auditable, receipt-backed workflow.

The first commercial wedge for the Market of Workers is therefore not "buy an agent marketplace." It is:

Train a specialist AI worker for a defined outcome.

This creates the supply side of the Internet of Intelligence before the marketplace is fully liquid.

8.1.4 Service Outcomes and the sas.xyz Domain

sas.xyz is the service-outcome domain. It is not merely a smart-contract frontend. It owns operational truth for ServiceOrders, OutcomeWorkspaces, TaskGraphs, Runs, WorkerInvocations, DeliveryBundles, EvidenceBundles, Approval records, DisputeRecords, QualityRecords, and SettlementMirrors. Consequential commitments settle or mirror to IOI L1 where escrow, fees, disputes, or public trust require it.

A typical sas.xyz outcome flow:

buyer funds or escrow locks -> sas.xyz Agentgres creates ServiceOrder -> OutcomeWorkspace initializes -> router selects workers and compute provider -> runtime assignment provisions daemon-compatible execution -> workers execute toward delivery goal -> receipts, artifacts, checkpoints, and evidence are emitted -> sas.xyz Agentgres records operational truth -> idle state may seal into archive -> buyer approves or disputes -> IOI L1 routes settlement and fees when required

8.2 The Artifact Hierarchy: Standardizing Accountability

This section defines the master taxonomy of artifacts produced by the IOI Kernel. Every section of this paper depends on these artifact classes; they are defined here once and referenced throughout. Blockchains cannot store the massive outputs of AI models. IOI therefore enforces strict Evidence-Hash Separation: execution produces full evidence locally, while only canonical hashes and commitments cross to consensus.

DomainOntology, DataRecipe, TransformationRun, TransformationReceipt, DistilledOntologyDataset, EvaluationDataset, and OntologyProjection are artifact-bearing domain objects. They do not replace receipts; they bind the source, policy, transformation, evaluation, and projection context that makes receipts meaningful.

While the IOI Kernel is fully capable of generating these artifacts today, the network enforcement logic is phased. The protocol currently defines the strict schema and binding mechanisms required for future liability, while the automated adjudication and slashing logic is being progressively activated.

The Artifact Class Hierarchy The IOI protocol defines six canonical artifact classes, ordered by liability weight. Each class builds on the previous, forming a progressive evidence ladder:

Class 1: Receipt. A signed, hash-linked transaction record of a single consequential act. Receipts bind request_hash, policy_hash, model_snapshot_id, and the firewall verdict into an immutable, replayable act record. Receipts are produced by the Agency Firewall (Section 2.6) and form the leaves of the session Merkle accumulator (Section 4.2.3). They are the foundational evidence unit.

Class 2: Commitment. A cryptographic binding of a batch of receipts to a settlement-visible hash. Commitments are produced when a session closes or a milestone is reached. They compress an arbitrarily long execution trace into a constant-size Merkle root suitable for onchain anchoring (Section 4.2.4, Section 5.4).

Class 3: Certificate. A validator-attested or committee-attested endorsement of a Commitment. Certificates are produced when a Commitment is verified by an independent party (provider attestation, TEE attestation, or Mainnet consensus). They upgrade local evidence into network-grade assurance (Section 5.2.1).

Class 4: Resolution. The output of the Deterministic Arbitration process. Resolutions bind a dispute to a verdict and a remedy (escrow release, slashing, fault assignment). They are the terminal artifact in the dispute lifecycle (Section 8.3.1).

Class 5: FaultProof. Cryptographic evidence of a slashable offense: a forged receipt, a replayed ticket, an omitted step, or a policy violation. FaultProofs are produced by challengers and consumed by the Arbitration Lane (Section 8.3.1.2). They trigger automated remediation. Class 6: MutationReceipt. A signed record of a self-upgrade: the old Manifest hash, the new Manifest hash, the rationale (from ioi-memory), and the Monotonic Policy Invariant check result. MutationReceipts are produced by the Evolutionary Engine (Section 9.4) and audited by the Guardian.

The progression Receipt -> Commitment -> Certificate -> Resolution mirrors the escalation path from local execution to network settlement. Not every action requires every class; the protocol applies the minimum evidence tier proportional to the economic risk of the task.

Domain-Specialized Receipt Types TrainingReceipt, BenchmarkReceipt, EvaluationReceipt, and RoutingReceipt are not new top-level artifact classes. They are specialized Class 1 Receipts. They bind a specific training run, benchmark execution, evaluation verdict, or routing decision to the same receipt semantics used throughout IOI: canonical input, policy hash, worker identity, artifact references, and signature.

This preserves the artifact hierarchy while allowing worker training and MoW routing to become first-class Market of Workers economic events.

Normative wire formats for all artifact classes are specified in Appendix B.

8.2.1 The Required Receipt Sets (RRS)

To guarantee that agentic workloads can be audited and arbitrated deterministically, the IOI Verification Fabric enforces a strict, dual-layer receipt architecture at the execution boundary. These sets define the Minimum Viable Receipts (MVR) required for a workflow to be considered valid.

1. RRS-I (Intent-Level Contract Markers): Required receipts tied to resolved agent intents. These are enforced at lifecycle completion gates (e.g., agent_complete), ensuring the overarching workflow satisfies proof of delivery (e.g., verifying provider_selection_commit and verification_commit exist for a system command).

2. RRS-A (Action-Level Enforceability): Required cryptographic bindings generated dynamically for every governed tool execution. For consequential executions, these bindings are what make the action transaction-shaped and settlement-eligible.

Minimum Viable Receipts (MVR) Table for RRS-A For an action to pass the Deterministic Gate and be eligible for on-chain settlement, the runtime MUST successfully record the base RRS-A bindings (rrsa_request_binding, rrsa_firewall_decision, rrsa_domain) plus the specific cryptographic commitments required by its target domain:

Action Domain Domain-Specific Required Verification Enforced (RrsaDomain) Commitments UI / Browser rrsa_output_commitment Binds the visual perceptual hash (visual_hash) or fallback execution output to the action. Filesystem rrsa_path_scope_binding Extracts and commits all accessed rrsa_output_commitment paths (source/dest) to prove the agent did not break out of its sandbox. Network (Web) rrsa_domain_binding Canonicalizes and commits the tarrrsa_output_commitment get URL/Host to prove compliance with the allow_domains policy. Wallet / Smart rrsa_tx_hash_binding Enforces that a cryptographic step- Contract rrsa_approval_token_ref up token was consumed, binds the rrsa_eei_bundle_commit- resulting TxHash, and mandates an ment rrsa_output_com- External Evidence Interface (EEI) mitment bundle for chain state verification. Clean-Room Com- rrsa_cleanroom_sub- Binds the action to the declared pute strate_binding rrsa_in- clean-room substrate and requires put_commitment the receipt bundle to satisfy the verirrsa_output_commitment fier requirements for the action rrsa_model_or_program_h ash rrsa_verifier_re- class. Substrate evidence may be quirements TEE, FHE, MPC, ZK, deterministic rrsa_proof_or_attesta- replay, or hybrid. tion_ref rrsa_leakage_bounds

Normative Invariant (The Completion Gate): If an agent completes a workflow, but the execution log is missing any required RRS-I or RRS-A markers (e.g., the agent wrote to a file but the rrsa_path_scope_binding is missing), the Orchestrator MUST fail the workflow with an ExecutionContractViolation error. The execution is rendered economically void.

Additional RRS-A domains for worker training and MoW routing Worker Training:

1. rrsa_training_spec_binding

2. rrsa_dataset_commitment

3. rrsa_evaluation_rubric_binding

4. rrsa_training_output_commitment

Benchmark Execution:

1. rrsa_benchmark_profile_binding

2. rrsa_worker_manifest_binding

3. rrsa_eval_environment_binding

4. rrsa_score_commitment

MoW Routing:

1. rrsa_routing_policy_binding

2. rrsa_candidate_set_commitment

3. rrsa_selection_reason_commitment

4. rrsa_contribution_policy_binding

Missing any required worker-training, benchmark, or routing receipt renders the associated training result, leaderboard claim, or routing decision economically non-enforceable.

8.3 The Agentic Core: Deterministic Arbitration & Economic Neutrality

IOI verifies Intent Compliance: did the agent fulfill the contract under declared rules? This section defines how disputes are resolved when that question cannot be answered by receipt inspection alone. IOI resolves such disputes by converting probabilistic outputs into deterministic arbitration artifacts governed by objective protocol logic.

Not all failures are malicious. A service may fail because a third-party API enforced a copyright filter, or because a DePIN node went offline. The arbitration core is designed to mathematically distinguish between Developer Malpractice, User Fraud, and Upstream Censorship.

8.3.1 Arbitration Lane: Economic Resolution & Settlement

The Arbitration Lane is the dispute-resolution backstop. It processes disputes through a rigid sequential funnel: cryptographic verification first, objective evaluation second, semantic judgment third, human escalation last.

The Lane strictly forbids relying on AI models for free-form legal discretion. It decomposes subjective rubrics into machine-verifiable atomic checks, escalating to human judgment only when objective and semantic lanes are insufficient.

Note: The Arbitration Lane is an exclusive feature of the Root Mainnet public market. Sovereign L1s utilizing trusted consensus drivers govern themselves internally; IOI L1 does not adjudicate disputes for independent subnets unless those subnets explicitly lock capital in Mainnet escrows under Mainnet rules.

8.3.1.1 Scope and Eligibility To be eligible for the low-cost Fast Path (Autonomous AI Arbitration), a dispute MUST meet strict scoping criteria.

• Fast Path Eligible: Step-scoped disputes (graph_id, step_id), claims supported by non-ambiguous deterministic artifacts (receipts, diffs, test outputs, compiler logs), and claims strictly bounded by the Canonical Context Window.

• Never Fast Path (Forced Slow Path): Broad subjective claims ("Was this coder polite?", "Is this UI visually pleasing?"), disputes lacking required rubric completeness, or evidence cap violations. 8.3.1.2 The Deterministic Arbitration Stack (3 Lanes) Disputes are processed through a rigid, sequential funnel.

Lane 0: Hard Constraint Gate (The Cryptographic Filter) In addition to validating signatures and policy hashes, the Arbitrator now enforces Contextual Completeness. Lane 1: Deterministic Objective Evaluators (The Primary Source of Truth) The protocol requires all Intent Contracts to undergo Rubric Decomposition- converting subjective goals into atomic, objective tests.

• Action: For each step, the Arbitrator executes fixed objective checks: Build/compile success, Hash-anchored test suite results, Lint/security rulesets, and Schema/type compliance.

• Resolution: If an objective failure proves a violation (e.g., tests fail), the ruling deterministically resolves in favor of the Challenger. If all objective checks pass, the dispute moves to Lane 2.

Lane 2: Constrained Semantic Review Only used for residual rubric items that passed Lane 1 but require semantic validation. Because semantic evaluation is vulnerable to adversarial inputs, this lane utilizes a Heterogeneous Ensemble of Evaluators (e.g., fixed snapshots of multiple distinct open-source model families) operating strictly as a constrained judiciary quorum.

• Phase A (Prosecutor): The ensemble extracts candidate violations only from cited evidence.

• Phase B (Defender): The ensemble validates or refutes each candidate against citations.

• Phase C (Resolver): Emits per-claim binary verdicts and a global confidence score based on quorum agreement.

All outputs MUST be machine-readable schemas with canonical serialization (sorted keys, deterministic JSON) so the resulting arbitration artifact is deterministic once accepted. The semantic judgment itself is not a consensus primitive. If evaluator disagreement, prompt-injection risk, or evidence ambiguity exceeds the configured threshold, the dispute MUST route to the Slow Path. Because structural output constraints do not prevent semantic hijacking originating from untrusted evidence, Lane 2 strictly forbids single-model adjudication.

Invariant: Structural and Semantic Isolation (Normative): IOI constrains the effects of intelligence. An agent can "think" whatever it wants, but it cannot perform canonical Web4 Act -- spend, send, exfiltrate, mutate durable state, use credentials, or settle -- without passing deterministic checks of the Firewall and the enforceability checks of the settlement system. That is the precise security meaning of Act inheriting Own.

The evidence bundle is evaluated simultaneously by structurally distinct models. Because different architectures process tokens differently, adversarial inputs that fool one model are statistically less likely to fool another, making prompt injection attacks against the arbitration ensemble significantly harder than against a single judge. Confidence Threshold (The Divergence Trap): The system treats model disagreement as a cryptographic indicator of edge-case ambiguity or an active semantic attack. If the Ensemble Quorum fractures (e.g., Model A returns true but Model B returns false), the aggregate confidence score automatically drops below the protocol safety threshold (e.g., epsilon < 0.95). If the score falls below this threshold, or if schema conflicts are unresolvable, the output is immediately marked Undecidable and the dispute is routed to the human Slow Path (Lane 3).

8.3.1.3 No-Fault Escapes & Graceful Degradation (The Copyright Exception) In a decentralized marketplace utilizing third-party foundational models (e.g., OpenAI, Anthropic), an agent may fail to execute a Gig due to upstream API safety filters, copyright refusals, or censorship. If a user asks a proprietary Image-Generation Node to "Vectorize this Disney logo," the upstream API will reject it. This failure is neither Developer Malpractice (their WASM logic is sound) nor User Fraud. The IOI protocol protects developers from being penalized for upstream censorship via No-Fault Arbitration.

• Graceful Fallback (The Node Invariant): High-assurance Nodes constructed in the Agentic Canvas IDE SHOULD define a fallback routing mechanism. If a closedsource API throws an HTTP 400 Policy Violation, the Node is programmed to automatically attempt the exact same execution using an uncensored, open-weights model (e.g., routing to Llama-3 on a DePIN Akash provider) before emitting a terminal failure.

• Standardized Fault Receipts: If all fallbacks fail due to prompt refusal, the Ephemeral MicroVM MUST emit a cryptographic Fault Receipt explicitly classifying the error (e.g., ERR_UPSTREAM_POLICY_VIOLATION).

• The Unserviceable Request Outcome: When the Arbitration Lane ingests this specific Fault Receipt, it bypasses the slashing logic. The Gig is classified as an "Unserviceable Request." The User's escrowed funds are refunded (minus the network Compute Gas already expended to that point). Crucially, the Developer's Service NFT Bond is NOT slashed, and their Marketplace Reputation Score remains untouched. This guarantees that developers can confidently build services on top of rigid LLMs without assuming the financial liability of user-prompted censorship.

8.3.1.4 Verifier Model Versioning & Replay Correctness To ensure that the Fast Path cannot be gamed by shifting AI baselines, Arbitration Nodes MUST pull the exact runtime configuration from the Arbitration Registry. A valid Fast Path resolution requires:

1. Fixed judge binary hash (e.g., WASM CIM).

2. Fixed debate prompts and feature sets.

3. Signed model attestation at execution time.

4. Supermajority hash consensus among the sampled arbitration quorum, producing identical resolution_hash outputs. 8.3.1.5 Canonical Dispute Schema All challenge packages and resulting resolutions adhere to a canonical YAML schema to ensure cross-node determinism. The schema binds case_id, graph_id, step_id, policy_hash, policy_version, rubric_version, model_snapshot_id, evidence references, Lane 1 objective check outcomes, Lane 2 prosecutor/defender/resolver claim verdicts, and the aggregate final verdict. The full schema is in Appendix A.4.

8.3.2 Hybrid Execution Model

IOI composes probabilistic reasoning with deterministic settlement.

1. Agentic Phase: An AI model processes fuzzy inputs (e.g., "Analyze market sentiment from news feeds").

2. Boundary Crossing: Probabilistic intent collapses into a transaction-shaped ActionRequest / CommittedAction: canonical payload, authority binding, policy_hash, receipt obligations, and replay evidence.

3. Settlement Phase: The transaction-shaped act record is passed into deterministic contract logic (EVM/WASM) for value transfer, escrow resolution, or dispute handling.

Visual summary: [Agent Input] -> [Workload Inference] -> [Agency Firewall: ActionRequest + Receipt] -> [Settlement Object]

AI handles decision-making; the Kernel enforces the deterministic boundary that makes the consequence settleable. This is how Own becomes executable without making the model itself deterministic.

8.3.3 Marketplace Neutrality: The Anti-Cannibalization Invariant

A Market of Workers cannot exist if the infrastructure provider competes with its own supply chain. If the default runtime harness becomes "good enough at everything," it cannibalizes marketplace workers and destroys the incentive for developers to publish specialized intelligence.

IOI enforces Marketplace Neutrality as a core architectural invariant:

1. The Neutral Substrate: The default harness (e.g., Hypervisor) is a neutral execution substrate, not a privileged competitor. It is mathematically and procedurally forbidden from silently cloning or absorbing third-party worker internals into its default logic.

2. Explainable Routing: When the runtime router selects a worker to fulfill a task (whether the default harness, an installed worker, a marketplace worker, or a managed service), the routing decision MUST be explainable to the user (based on cost, privacy, required tools, or reputation).

3. Opt-In Service Redirection: Users retain the right to run tasks locally via the default harness unless the task strictly requires licensed data, third-party authority, or hosted execution. Service redirection is strictly opt-in.

4. No Platform Fiat: The default harness cannot rank itself first in marketplace discovery through platform fiat. Ranking must be strictly based on measurable quality, reputation, and cost signals.

5. MoW Router Neutrality: The MoW router is subject to the same neutrality requirement as marketplace discovery. Routing preference must be based on declared policy, benchmark performance, cost, privacy, trust posture, installed status, or user preference. The runtime MUST NOT privilege first-party workers through hidden ranking logic, opaque bundling, or unreceipted substitution.

8.3.4 Contribution Accounting: The Attribution Graph

To ensure developers are compensated when their specialized logic is utilized within a larger autonomous workflow, Agentgres implements precise Contribution Accounting.

When a Planner Agent delegates a sub-task to a specialized Worker, or utilizes a specific Tool/Model, the runtime emits a ContributionReceipt.

ContributionReceipts are the unit of Market of Workers economics. Payouts, royalties, reputation updates, routing weight, and subscription-credit distribution should be based on verified contribution, not raw token usage, attention time, or generic popularity.

The ContributionReceipt records:

1. The Contributor Identity (ai://workers.xyz)

2. The Contribution Type (e.g., verification, generation, planning, tool usage)

3. The Input and Output Artifact References

4. The Quality Delta (the measurable improvement the worker provided to the workflow)

5. The Reward Basis and License Terms

For Market of Workers settlement, the ContributionReceipt MAY also record:

1. routing_decision_ref

2. sparse_worker_category

3. benchmark_profile_ref

4. verifier_worker_ref

5. failure_or_dispute_status

6. downstream_outcome_ref

These receipts form an Attribution Graph within the Agentgres domain. They serve as the verifiable foundation for:

1. UsageReceipt Settlement: Triggering micro-payments or royalty distributions on the IOI L1.

2. Reputation Updates: Feeding quality ledgers so that highly effective workers organically rise in marketplace rankings based on proven outcomes, not marketing.

3. Dispute Traceability: Allowing Arbitrators to pinpoint exactly which node in a multiagent supply chain failed, ensuring liability falls only on the responsible party.

The IOI protocol doctrine is absolute: The platform must route intelligence, not absorb it.

Incentive-Compatible Contribution Without IP Disclosure: IOI does not require developers to open-source their models, weights, prompts, or datasets in order for the network to improve. A developer who creates a superior verification Worker, planning Worker, data-curation Worker, or domain-specialist Worker can expose it through a manifest and policy-bound interface while retaining the underlying IP. Contribution accounting allows such Workers to receive attribution and compensation when routed into larger workflows, synthetic-data pipelines, or execution swarms. The network improves because useful intelligence is economically routable, not because participants are assumed to share gradients without compensation.

8.4 Economics: Pricing Verifiable Work

This section specifies the economic model of the IOI protocol.

The IOI economic model monetizes Verifiable Work: the assurance that an agent's actions are safe, correct, and accountable. Economically, this is executable ownership: users delegate bounded authority and pay for verified acts rather than merely renting tools or buying raw compute. It captures value at the verification boundary and the orchestration of the agent supply chain, not at the inference layer.

This new asset class is priced using Labor Gas. Unlike traditional blockchain gas, which pays for ephemeral blockspace, Labor Gas pays for the end-to-end execution, orchestration, and verification of autonomous labor.

Managed worker pricing may include:

1. install or license fee;

2. per-invocation fee;

3. warm runtime subscription;

4. persistent runtime subscription;

5. zero-to-idle restore fee;

6. storage/archive fee;

7. model/provider usage;

8. compute provider fee;

9. verifier/evaluator fee;

10. worker author royalty;

11. marketplace/protocol fee.

Settlement should remain receipt-bound through WorkerInvocationReceipts, RuntimeAssignmentReceipts, ComputeSessionReceipts, StorageArchiveReceipts, RestoreReceipts, EvaluationReceipts, ContributionReceipts, and SettlementReceipts.

8.4.1 The Economic Shift: Paying for Outcomes, Not Just Compute

In the commodity inference model, users pay for compute cycles. Value accrues to hardware, not to the orchestration or verification of work.

In the Web4 IOI model, users pay for Verified Outcomes: "Here is $5.00 in escrow. Run this Agent, and you only get paid if the output passes the Deterministic Gate." The escrow is Own; the successful receipt-backed execution is Act.

This mechanism establishes a Market for Verifiable Work, effectively decoupling the computational cost of inference from the economic value of the executed task.

Developer Economics IOI captures the economic sweet spot between Services and Software.

• Services have high value (doing the work) but low margins (humans don't scale).

• Software has low value (just a tool) but infinite margins (zero marginal cost of replication). Service-as-a-Software combines the utility of a service (the job gets done) with the replicability of software (containerized agents). Developers publish once and earn per-execution royalties without provisioning infrastructure. Labor Gas monetizes this asset class.

8.4.1.1 The Liquidity & Orchestration Layer (Protocol Revenue) The IOI protocol sustains itself not by extracting rent from local execution, but by monetizing the convenience and complexity of network escalation.

1. Cloud Routing as Protocol Revenue (The Primary Engine) Whenever a user's Local Node lacks the precise computational resources (e.g., VRAM) to run a Worker Manifest, the Orchestrator initiates a frictionless, one-click route to a Cloud Provider. The network handles the heavy lifting: fresh clean-room installs, strict dependency resolution, and establishing the secure application-layer tunnel. For providing this seamless "One-Click Cloud" orchestration, the protocol captures a Routing Fee (a micro-cut of the execution cost) from the session.

2. Swap Spreads & Liquidity (Wallet Revenue) The user-facing wallet.network integrates a native aggregation router for cross-asset swaps. Liquidity is provided via RFQ by Solvers, who capture the spread between wholesale (Chain) and retail (Wallet) prices. The protocol may capture a parameterized convenience fee on these fiat-to-crypto bridging flows.

8.4.2 Stakeholder Alignment

This model aligns incentives across the core stakeholders of the automated economy:

• Users (Demand): Purchase verified outcomes. They utilize Gig Escrows to guarantee they only pay for successful, cryptographically proven work. They maintain absolute data sovereignty because their data never rests on a developer's proprietary server.

• Providers (Supply): Earn revenue for providing compute and readiness, fulfilling offloaded cloud sessions inside hardware-secured Clean Rooms.

• Developers (Creators): Earn royalties when their agent architectures (Service NFTs) are rented, without ever incurring idle server costs or exposing their proprietary model weights.

• Solvers (Liquidity): The bridge between the Web2 consumer and the Web4 protocol. Solvers capture fiat revenue (e.g., credit card subscriptions from the Private AI frontend) and act as the payer on-chain. They open Delegated Sessions, providing the "Working Capital" that allows the network to function at zero latency. They absorb token volatility risk in exchange for capturing the spread between the retail fiat subscription and the wholesale token cost of network compute.

• Arbitration Nodes: Earn "Resolution Fees" by resolving disputes via the Fast Path. They provide Adjudication Capacity, staking capital on their ability to consistently evaluate Intent Schemas.

8.4.3 Labor Gas Model (The Micro-Split Settlement)

IOI accounts for costs deterministically based on the artifacts produced and the routing path taken. The total cost of an agentic workflow is strictly defined as:

Total = Compute + Settlement + Royalties + Routing_Fee

When a user funds a Gig or executes an IDE Node, the transaction fee is automatically divided at the protocol level via a Micro-Split Settlement:

1. Compute (paid to Providers): Market-priced hardware execution (GPU/CPU time, tokens generated, tool API costs), metered via session receipts paid directly to the physical host of the Clean Room.

2. Settlement (paid to Mainnet): Standard network fees for submitting settlement objects (escrows, channel closes, arbitration resolutions) to the blockchain.

3. Royalties (paid to Developers): Protocol-enforced routing of declared fees to the owner of the invoked Service NFT as pure profit for supplying the intellectual property.

4. Routing Fee (paid to Protocol/Treasury): The micro-cut captured by the network for orchestrating cloud offloads, matching providers, and resolving dependencies.

The Sovereignty Discount: If a user runs an agent entirely on their local machine (Native User Node), the Compute and Routing_Fee drop to zero. The user pays only the Developer Royalty and minimal Settlement fees (if state is anchored on-chain). This ensures that sovereignty is economically incentivized.

11.3.1 The Subscription Abstraction (The Fiat-to-Gas Flywheel)

To achieve mass adoption, the protocol does not force retail users to purchase tokens or manage wallets. The top-of-funnel Private AI interface (internetofintelligence.com) can be monetized via traditional Web2 fiat subscriptions (e.g., $20/month) or credit card billing for premium inference. This fiat revenue acts as a massive, stable liquidity hose for the protocol, facilitated by the Solver Network (Section 4.7):

1. Ingestion: The user pays a fiat subscription to access the Private AI interface.

2. Conversion: Solvers (acting as infrastructure brokers) capture this fiat off-chain. Behind the scenes, they open Delegated Sessions (Section 4.2.5) on-chain on the user's behalf.

3. Distribution: As the user prompts the AI, the Solver uses its token reserves to pay Labor Gas directly to the DePIN hardware providers (Compute) and Royalties to the Service NFT owners (Developers) executing the workflows. Subscription revenue provides baseline liquidity to the network. This yield attracts hardware providers and developers, which improves agent capability and attracts further subscribers.

Subscription credits SHOULD be treated as prepaid work credits, not as a vague pro-rata pool. Credits are spent when workers are invoked, benchmarks are run, or outcomes are delivered. Distribution is receipt-weighted: workers and upstream contributors are paid when ContributionReceipts prove they contributed to completed work.

The settlement unit is verified contribution, not raw model tokens.

8.4.4 Supply-Side Incentives: Service NFT Fee Routing

IOI introduces NFT-anchored fee routing to sustainably monetize open-source agents and proprietary tools.

• Mechanism: The Service NFT acts as the canonical fee recipient and the pointer to the dormant IPFS Manifest.

• Enforcement: When a session invokes a Worker Manifest, the settlement logic checks the Service Registry. It calculates the Royalties portion from the metered Labor Gas and routes it directly to the Service NFT Owner.

• Impact: This enables a "Royalty-on-Execution" model rather than "Royalty-on-Access." Developers are paid whenever their intelligence is rented to perform work, ensuring WASM-compiled source code remains visible for safety while preserving deep monetization.

8.4.5 Contribution Accounting & Marketplace Neutrality

The core problem of an "Internet of Intelligence" is cannibalization. If the platform's default execution harness becomes "good enough at everything," it will silently absorb the logic of specialized third-party workers, destroying the incentive for developers to publish them.

IOI prevents this through strict Marketplace Neutrality and Contribution Accounting. This economic layer ensures that whenever intelligence is shared, it is attributed and compensated, protecting the Market of Workers.

1. The Anti-Cannibalization Invariant: The default IOI runtime harness is mathematically forbidden from silently cloning or appropriating third-party worker logic. If an agent utilizes a specialized tool, dataset, or sub-agent from the aiagent.xyz marketplace to fulfill an intent, the runtime MUST emit a ContributionReceipt.

2. The ContributionReceipt: This cryptographic artifact records exactly who contributed intelligence (the contributor_id), how it was used (e.g., planning, verification, tool execution), and the quality_delta (the measurable improvement it provided to the final outcome).

3. The Attribution Graph: These receipts form an Attribution Graph within the Agentgres domain. When a user pays for a successful outcome, the settlement layer uses this graph to automatically distribute micro-royalties or Labor Gas kickbacks to every developer who contributed to the supply chain of that task.

4. Reputation as an Asset: Even in "free" or local executions where no tokens change hands, ContributionReceipts update the developer's on-chain Reputation Root. This ensures their agent organically rises in marketplace search rankings based on cryptographic proof of utility, rather than platform fiat or marketing spend.

This shifts the economic model from zero-sum competition to composable collaboration. Developers are economically incentivized to publish small, hyper-specialized agents because they will automatically earn royalties whenever their logic is routed into a larger, more complex swarm.

8.4.6 Escalation Economics

To prevent abuse of Deterministic Arbitration (the Arbitration Lane) in the Gig Escrow model, IOI enforces strict anti-griefing dispute bonds. While the protocol does not require massive code-liability insurance pools, it does require parties to have skin in the game when they contest a settlement.

Liability Binding & Current Enforcement Status The IOI economic ladder relies on the settlement schema binding the execution artifacts to real capital.

• Minimal Enforceability Invariant: A bonded on-chain escrow MUST strictly bind to (session_id, policy_hash, receipt_root). A dispute MUST present a challenged receipt alongside a valid Merkle inclusion proof against that committed root.

• Current Enforcement Status: The network currently implements the fundamental state channels: escrow/bond locks, payment settlement, dispute flagging, channel receipt-root commits, and replay windows.

• Staged Enforcements: Automated programmatic slashing of Developer SLA bonds based on mathematical policy_hash + receipt_root validation via the Arbitration Lane is schema-defined and staged for subsequent protocol phases.

Escalation Parameterization To ensure that while human recourse exists for 'Whale' transactions, frivolous disputes become economically ruinous, the Arbitration Lane enforces the following schema parameters (with specific values governed by the IOI DAO):

1. Challenge Bonds (Base Bond Function): Base_Bond = max(Task_Value * Risk_Multiplier, Minimum_Floor). If a User rejects a Provider's deliverable (or if a Provider contests a User's refusal to pay), the escalating party MUST post this escalation bond.

2. Superlinear Cost Curve (Lane Multipliers): Escalation bonds increase geometrically with the arbitration tier. Moving from deterministic objective checks (Lane 1) to AI semantic verification (Lane 2) to Human Review (Lane 3) incurs a geometric cost increase: EscalationBond_lane_n = BaseBond x LaneMultiplier^n where n is the escalation lane index and LaneMultiplier is a governance parameter.

3. Burn/Return Policy: A mathematically defined percentage of the loser's dispute bond is burned. This creates a negative-sum game for frivolous disputes, ensuring Arbitration is only invoked when a party has high confidence in their cryptographic evidence.

4. Challenge Windows & Anti-Griefing Caps: Dispute windows are strictly defined in epochs (e.g., defaulting to 24 hours for asynchronous disputes), alongside hard caps on the maximum allowable escalations per session or per epoch to prevent griefing loops.

5. Pre-funding: The escalating party MUST pre-fund the incremental compute and gas required by the Arbitration Nodes to run the verification trace.

9. Security and Evolution

IOI's security model is process safety over model safety. A model may remain stochastic, fallible, or replaceable. What must be secured is the path by which a worker turns model output into authority-bearing consequence.

This section specifies the threat model for the IOI protocol. The system assumes adversarial conditions: some providers are malicious, some users are reckless, and some hardware is compromised. The firewall mechanics that enforce containment are specified in Section 2.6; this section defines the adversaries, failure modes, and mitigations that those mechanics are designed to withstand.

Security is enforced fractally across the network topology, preserving the same transactionshaped boundary from local runtime to global settlement:

1. Local (User Node): the Agency Firewall protects the device.

2. Session (Remote Infrastructure): receipts + spend limits protect the budget.

3. Global (Mainnet): challenge, slashing, and finality protect enforceable settlement.

9.1 The Agency Firewall (Reference)

The Agency Firewall is the primary defense mechanism against all threats enumerated below. Its normative specification, ActionRequest canonicalization, ActionRules policy language, canonical ordering, CIM runtime, capability scopes, interception and approval flow, audit chain, hierarchical delegation, and the Monotonic Policy Invariant, is defined in Section 2.6. This section assumes those mechanics and focuses on the adversaries they are designed to contain.

9.2 Threat Model: Market Risks

9.2.1 Malicious Agents (Trojan Horse / Device Harm)

• Scenario: A user installs an agent that attempts to exfiltrate secrets (~/.ssh), encrypt documents, or automate destructive actions.

• Defense: Capability sandboxing + Mediated I/O. The agent has no ambient authority; filesystem/network actions must pass the firewall, and deny-listed paths are blocked by policy.

9.2.2 Malicious MCP Servers (The Supply Chain Attack)

• Scenario: A user downloads a tool advertised as a "Calculator MCP" that actually contains logic to scan the filesystem for crypto wallets or exfiltrate environment variables.

• Defense:

• Process Containment: The IOI Kernel runs every MCP server in a restricted sandbox (e.g., Bubblewrap, Docker, or WasmTime).

• Policy Manifest Enforcement: The Kernel enforces the Policy Manifest. Even if the malicious code attempts fs.read("/home/user"), the Kernel will deterministically block the syscall if that path was not explicitly granted in the manifest.

9.2.3 Malicious Providers (Fraud, Overcharging, and Fake Receipts)

• Scenario: A provider returns garbage, induces retry loops to drain budget, inflates metering, or returns forged artifacts to claim payment.

• Defense:

• Spend Caps: Hard max_spend per session/step enforced by policy.

• Loop Brakes: Orchestrator enforces retry/tool/time limits.

• Receipt Validation: Each burst must return a receipt bound to offload_packet_hash, policy_hash, and model_snapshot_id.

9.2.4 Market Manipulation (Sybil and Capability Spam)

• Scenario: An attacker floods discovery with fake capabilities/endpoints to manipulate routing or reputation signals.

• Defense: Guardian-bound identities + Economic Friction. Policies and registries require attested identities and (where configured) bonded participation for advertising or prioritized routing.

9.2.5 Global Settlement Fraud (Forged State, Replayed Tickets)

• Scenario: A provider attempts to settle a session using forged state (inflated balances, fabricated receipts, replayed payment tickets).

• Defense:

• Monotonic Tickets: PaymentTickets are signed by the payer and strictly monotonic (seq, cumulative_amount).

• Merkle Roots: Session history is committed via receipt_root.

• Challenge Window: Unilateral close opens a challenge window; either party may submit a newer valid state or evidence against the claimed root.

9.2.6 Lying by Omission (Context & Receipt Gaps)

• Scenario: A provider performs work but omits required evidence (e.g., a tool call or network access) that would prove policy violation, or omits a relevant file from context retrieval to force a specific output.

• Defense:

• Required Receipt Set (RRS): Each task type defines a required receipt set keyed by policy_hash; missing required receipts invalidates enforceability.

9.2.7 The Latency-Induced Hazard (Visual & Context Drift)

A critical vulnerability emerges when the safety-checking logic is physically separated from the execution environment, a common topology in cloud-based "Computer Use" agents.

Visual Drift (Time-of-Check to Time-of-Use) Scenario: An agent analyzes a screenshot at time t0 and decides to send a click command. At t1, before the click is injected, a high-priority system dialog ("Grant Admin Access") appears at those exact coordinates. Defense:

• For OS Actions: The Atomic Vision-Action Lock. Because strict cryptographic hashing of raw pixel buffers is unviable (a blinking cursor or ticking clock would paralyze the agent), the lock utilizes Perceptual Hashing (pHash). Before injecting a click, the Native Operator captures a fresh screenshot and computes its pHash. It compares this against the expected_visual_hash from the inference step. If the Hamming distance exceeds the protocol's strict drift threshold (e.g., > 32 bits of divergence), the screen has materially changed. The kinetic action is immediately Blocked by the Firewall, preventing unintended clicks.

• For Web Actions: DOM-Level Resolution. By utilizing the Browser Subsystem, web agents target structural layout elements rather than absolute X,Y coordinates. If the DOM geometry shifts during execution, the CDP backend resolves the new coordinate center prior to dispatch, drastically mitigating race conditions.

Context Drift (The Focus Gap) A specific hazard occurs when an agent intends to interact with Application A but inadvertently brings Application B to the foreground, effectively hijacking the agent's subsequent inputs. The IOI Verifier treats this not as a "State Change" (Success) but as a Context Violation (Failure).

• Defense: The Perception Layer continuously evaluates the OS Window context. If a visual shift occurs (a high Hamming distance) AND the active window title/app name mismatches the agent's intended target constraint, the execution step is marked as Failed. Rather than triggering a blockchain-style "revert" (which is impossible for physical OS states), this triggers the agent's local error-correction and retry pathways, forcing it to re-orient via os::focus before proceeding.

9.2.8 Credential Exfiltration (The "Model Leak")

• Scenario: A malicious or "jailbroken" model attempts to output its system prompt or environment variables to a user, inadvertently leaking an API key.

• Defense: Structural Isolation. Because the model never possesses the key (it only possesses a handle/reference), the model cannot leak the key via token generation under the runtime's capability-handle indirection: the protocol only ever exposes a handle to the model, never the secret material itself. Even if the model is fully jailbroken, it can only output the handle, which is useless outside the local runtime.

9.2.9 Adversarial PII Bypass

While a malicious agent could theoretically obfuscate PII to bypass the CIM (e.g., encoding a credit card number as a poem), doing so renders the data unusable by the receiving Provider Node. Because the IOI runtime enforces Schema Validation at the destination, obfuscated data typically fails the input type check of the target tool, causing the transaction to fail. The PII Airlock is designed to prevent accidental leakage and lazy exfiltration, not to prevent a compromised agent from steganographically encoding data.

9.2.10 Clean-Room Substrate Compromise

IOI does not make any single clean-room substrate foundational to authority. A class-wide TEE vulnerability, proof-system break, MPC implementation flaw, FHE parameter failure, or verifier bug may compromise the confidentiality or correctness claims of sessions that relied on that substrate. It must not compromise global settlement validity unless the affected receipt class was incorrectly elevated into an authority source.

Defense: The protocol separates substrate evidence from authority. Validators accept cleanroom outputs only when the Required Receipt Set is complete, the verifier registry recognizes the proof or attestation class, and the action's settlement class permits that evidence posture. High-risk workloads may require hybrid evidence, such as TEE + deterministic replay, TEE + ZK, MPC + output commitments, or ZK + external observation receipts.

Non-claim: IOI does not claim that TEEs, FHE, MPC, or ZK-ML are universally secure or universally applicable. It claims that authority-critical execution is receipt-bound and verifiergoverned, so compromised substrates can be deprecated, challenged, or excluded without redefining the protocol.

9.3 Semantic Integrity (Prompt Injection and Context Poisoning)

A technically secure agent can still be semantically dangerous. IOI defends via Verifiable Interpretation: Semantic integrity is not only prompt filtering. It depends on policy-bound data views, connector mappings, data recipes, transformation receipts, ontology-bound evaluation datasets, and provenance-preserving distilled datasets. A worker should not silently train on, evaluate with, export, or route over raw connector payloads outside authorized views.

Typed inputs: structured objects, not raw string concatenation; instructions separated from data and policy-checked. Model binding: receipts bind model_snapshot_id; swapping models becomes provable fraud. Context provenance: retrieved chunks carry stable IDs + hashes (and signatures where available). Policies may require higher-assurance sources for high-stakes steps.

Invariant: IOI constrains the effects of intelligence. An agent can "think" whatever it wants, but it cannot perform canonical Web4 Act -- spend, send, exfiltrate, mutate durable state, use credentials, or settle -- without passing deterministic checks of the Firewall and the enforceability checks of the settlement system. That is the precise security meaning of Act inheriting Own.

9.4 The Evolutionary Engine: Mutation as a Transaction

IOI frames worker self-improvement as bounded, sovereign state transitions rather than freeform self-modification. In this architecture, workers analyze execution traces and fitness signals to generate mutation intents, but actual code upgrades must be executed through governance or owner-authorized swap_module transactions to ensure deterministic activation and integrity. Central to this process is Execution-Boundary Alignment enforced by the Safety Ratchet, currently implemented as a monotonic policy guardrail that permits agents to upgrade their Logic (capabilities) while strictly blocking any expansion of Policy (privileges) without explicit authorization. For high-assurance workloads, this Monotonic Policy Invariant is not merely a local software check; it can be cryptographically enforced across generations via opt-in Recursive Continuity Proofs, ensuring that Generation N of an agent remains a verifiable, policy-compliant descendant of Generation 1.

Allowed vs. Disallowed Self-Improvement Domains Workers CAN improve: Prompts, instructions, tool choice heuristics, skill extraction from execution traces, test generation, and proposing policy changes for sovereign review via the Inbox approval gate. Workers CANNOT improve (Hard Bounds): Bypassing policy constraints, expanding their own authority scope, self-replicating, or mutating trust boundaries without explicit Inbox approval. These hard bounds are enforced by the Monotonic Policy Invariant and are cryptographically committed.

[[figure:safety-ratchet]]

9.4.1 The Fitness Function (The Evaluator)

The Fitness Function evaluates agents on Economic Utility (task completion, user satisfaction) and Safety Compliance (policy adherence, receipt completeness). Fitness scores inform mutation decisions but do not trigger automatic self-modification; the owner or governance process must authorize any code change via a swap_module transaction bound to a cryptographic receipt.

9.4.2 The Mutation Primitive (MutationReceipt)

Agents submit a swap_module transaction to update their own Manifest. The transaction must include a MutationJustification artifact: a structured record from ioimemory / Agentgres documenting the execution traces, failure modes, and fitness signals that motivated the change. This is a formal audit artifact, not raw model reasoning.

9.4.3 The Monotonic Policy Invariant

The Monotonic Policy Invariant: A mutation can change Logic (Code) but cannot relax Constraints (Policy Envelope). This guarantees that Recursive Self-Improvement is bounded, operationally containing self-escalation at the execution boundary.

Code updates are accepted via owner-authorized swap_module transactions; policy relaxations require explicit Human or Guardian signatures. No mutation, code or policy, takes effect without a signed MutationReceipt (Section 8.2, Class 6).

Crucially, any policy widening (relaxing constraints) requires an explicit step-up approval token from wallet.network. This approval is not a generic boolean; it MUST cryptographically bind the exact request_hash, policy_hash, scope, expiry, and revocation_epoch to prevent replay or scope-creep.

9.4.4 Recursive Continuity Proofs (The Cryptographic Chain)

For high-consequence or high-liability environments where execution-boundary containment must be verified independently off-chain, the protocol defines a High-Assurance Continuity Profile. To mathematically guarantee the Monotonic Policy Invariant across infinite generations of an agent, this profile bypasses reliance on point-in-time state checks by requiring a cryptographic proof of the agent's entire evolutionary lineage.

When an agent is deployed under this profile, any proposed self-mutation requires the runtime to emit and verify a CanonicalCollapseObject:

• The Continuity Accumulator: The CanonicalCollapseObject carries a rolling continuity_accumulator_hash that compresses the entire history of the agent's state transitions and mutations.

• The Recursive Proof: The object also carries a continuity_recursive_proof. This proves that the transition from the previous CanonicalCollapseObject to the current one strictly adhered to the Monotonic Policy Invariant.

• The Extension Certificate: When a mutated agent proposes a new block of work, the proposal carries a CanonicalCollapseExtensionCertificate. This succinctly links the new work to the validated predecessor hash.

• Authorized zkVM/Proof Verifiers: To ensure these recursive proofs can be verified on-chain and across nodes with zero-idle overhead, the runtime can compile the verifier logic into a zero-knowledge execution environment. For example, systems utilizing the Succinct SP1 backend allow any external verifier to evaluate Generation 10,000 of an agent and cryptographically prove--in milliseconds--that it has never bypassed the safety constraints established in Generation 1.

Result: In high-assurance continuity deployments, self-improvement is no longer a black-box trust assumption. It is a mathematical proof of lineage, allowing safe, autonomous evolution without loss of sovereign control.

9.4.5 Worker Training vs. Self-Mutation

IOI distinguishes initial or authorized worker training from post-deployment self-mutation.

Worker training is a builder-authorized or customer-authorized process that creates or improves a worker before deployment, or under an explicit retraining contract. It may expand the worker's logic, tool strategy, memory, verifier gates, or model backend if the resulting manifest and policy are explicitly signed by the appropriate authority.

Self-mutation is a deployed worker proposing changes to itself after it already holds a policy envelope and operational identity. Self-mutation is governed by the Monotonic Policy Invariant and cannot relax policy, expand authority, or widen capability without explicit human, guardian, or governance approval.

In short:

1. Training creates or improves a worker under an authorized training contract.

2. Mutation evolves a deployed worker under monotonic safety constraints.

Both processes emit receipts; high-assurance mutation profiles may require recursive continuity proofs across deployed generations. Training improves capability. Policy grants power.

10. Protocol Surfaces and Roadmap

The product stack is described as protocol surfaces, not as marketing personas.

• aiagent.xyz is the component and worker marketplace.

• sas.xyz is the outcome-service marketplace.

• Hypervisor is the local/private runtime and execution control plane.

• wallet.network is the authority control plane for secrets, leases, and payment grants.

• IOI Mainnet (L1) is the public root for settlement, identity, disputes, and rewards.

• internetofintelligence.com is the demand ingress for user intent.

• IOI CLI is the operator interface for domains, manifests, receipts, authority scopes, and Mainnet interactions.

The Protocol Surface Hierarchy

To ensure architectural clarity and prevent the conflation of user-facing adapters with core protocol engines, the stack is organized according to the following strict hierarchy:

1. Settlement Layer (IOI L1): Mainnet consensus (AFT), escrow, registry, and dispute resolution.
2. Authority Layer (wallet.network): Identity management, credential enclaves, and cryptographic policy grants.
3. Runtime Layer (IOI Daemon): The deterministic execution boundary. Employs two deployment profiles: a. Hypervisor Workbench (Canonical Native Console) b. IOI Authority Gateway / Hypervisor Guard (Compatibility Sidecar Profile)
4. Adapter Layer: IDE extensions, CLI shims, and API proxies that map third-party actions to the daemon.
5. Capability Layer: Workers, models, and tools executing as guest workloads under the daemon.

Layer 3 application overlays are not base-layer mechanics. They are stateless frontends and operational surfaces that bind to Agentgres projections and IOI runtime domains. The core whitepaper describes their protocol role; detailed buyer language, builder-lens descriptions, trace tutorials, and adapter walkthroughs belong in product docs and developer documentation.

The Promotion Path doctrine remains: Hypervisor captures, trains, and stabilizes workers; aiagent.xyz lists composable components; sas.xyz productizes outcomes including Worker Training as a service; IOI CLI sovereignizes them when a system requires its own policy root; the Market of Workers routes verified workers across this ladder using receipts, benchmarks, policy compatibility, and contribution accounting.

Product Domains. The product stack decomposes into separate but interoperable domains. Each domain has its own Agentgres kernel, runtime profile, and authority context; they interoperate through worker manifests, ai:// refs, runtime assignments, authority grants, receipts, archive refs, contribution ledgers, and IOI L1 commitments.

Hypervisor is the local desktop/runtime workbench for chat, workflow composition, worker supervision, Hypervisor Foundry, local daemon UX, and private execution.

internetofintelligence.com is the lightweight control plane for accounts, device registrations, restore routing, sealed archive metadata, publishing metadata, sync metadata, subscription/billing entitlement, and remote-runtime entitlement.

aiagent.xyz is the worker marketplace for manifests, publisher profiles, benchmark profiles, Sparse Worker Categories, trained worker packages, installs, managed worker instances, direct invocation, and routing eligibility.

aiagent.xyz direct invocation surfaces:

1. Worker package page -- inspect manifest, policy, benchmark profile, category, runtime requirements, licensing, contribution terms, and known limitations.

2. Initialize worker -- bind owner, runtime profile, authority policy, persistence profile, memory/archive policy, and subscription.

3. Web console -- chat or task UI mounted over the managed runtime instance.

4. API invocation -- stable endpoint for applications and enterprise systems.

5. Hypervisor install -- local or remote instance available inside Hypervisor.

6. Workflow node -- worker callable from shared workflow compositor recipes.

7. MoW route target -- worker eligible for router selection under declared policy and benchmark profile.

sas.xyz is the service-outcome marketplace for ServiceOrders, OutcomeWorkspaces, worker-composed services, worker-training contracts, provider workspaces, delivery bundles, approvals, disputes, and settlement mirrors.

IOI CLI / TUI is the terminal and interactive operator client over daemon and public runtime APIs, covering training runs, benchmark jobs, receipts, restore, archive, routing, and Agentgres inspection.

IOI SDK is the developer client facade over daemon and substrate contracts. It is not the runtime initialized on compute nodes.

IOI Daemon / Runtime Node is the execution endpoint for workers, tools, models, connectors, workflows, training, evaluation, benchmark, routing, artifact, and delivery jobs.

Agentgres operator surface. Canonical operator commands live under ioi agentgres: ioi agentgres status ioi agentgres doctor ioi agentgres replay ioi agentgres verify-root ioi agentgres rebuild-projection ioi agentgres restore ioi agentgres explain ioi agentgres diff-heads ioi agentgres inspect-receipt ioi agentgres migrate

L0 / L1 / Runtime Boundary. The protocol surfaces are bounded by where they sit on the topology:

• IOI Kernel / L0: reusable substrate for domains, workers, policy, Agentgres, manifests, receipts, routing, runtime profiles, and L1 commitments.

• IOI Daemon / Runtime Node: process that executes workers, workflows, tools, models, connectors, training jobs, evaluation jobs, benchmarks, and artifact production.

• Domain Kernel: application-domain deployment of runtime, state, and policy over Agentgres truth.

• IOI L1: public registry, rights, settlement, dispute, governance, and commitment root.

• SDK / CLI / TUI / agent-ide: clients and projections over daemon/domain contracts, not the execution substrate.

The Request for Worker (RFA) Protocol covers three engagement classes: Class A (Agentic Contract -- natural-language rubrics, Gig Escrow on Mainnet, arbitration backstop); Class B (Test-Driven Contract -- programmatic constraints with blind validation against an encrypted test suite); and Class C (Worker Training Contract -- client supplies workflow context and acceptance rubric, provider delivers a trained worker manifest, training receipts, evaluation report, and deployment package).

The roadmap remains Edge -> Network -> Settlement: first ship local runtime, firewall, memory, and worker training; then activate routing, state channels, providers, and sparse worker categories; finally close the economy with settlement domains, identity anchors, challenge packages, verifier outputs, and receipt-weighted contribution settlement.

Court is a productized dispute-resolution surface, not a base-layer protocol requirement. sas.xyz may expose a Court product that consumes IOI receipts, challenge packages, verifier outputs, and settlement envelopes for service-order disputes.

Data Recipe Builder is a guided product surface for mapping source systems, connector outputs, docs, traces, and corrections into ontology-bound data.

Ontology Builder is the surface for defining domain entities, relationships, actions, states, invariants, canonical objects, lifecycle states, and projection hints.

Foundry Data Workbench is the surface for inspecting, curating, gating, distilling, reviewing, exporting, and evaluating training and evaluation data.

10.1 The Control Plane: The HCI of Intent

The IOI Kernel requires precise, deterministic instructions to enforce liability. Users express fuzzy intent. The Control Plane bridges the gap.

The Control Plane bridges this gap. It translates natural language intent into the deterministic ActionRequests and policy bindings required by the Agency Firewall.

Canonical UX Objects The Control Plane exposes three governance surfaces:

• The Inbox: The durable decision surface for human-in-the-loop governance. Approvals, clarifications, anomaly flags, and results all flow through the Inbox. No action with material consequence proceeds without an Inbox checkpoint unless policy explicitly pre-authorizes it.

• Workflows & Runs: Visual authoring surfaces for composing multi-step worker orchestrations, and operational observation panels for monitoring live execution. Workflows are the "source code" of agentic behavior; Runs are their runtime traces.

• The Artifact & Evidence Atlas: The unified inspection surface for all outputs, cryptographic receipts, and provenance chains. Every action a worker takes produces an auditable artifact; the Atlas makes these navigable, searchable, and verifiable.

10.1.1 The Intent Interface (The "Search Engine" Experience)

As described in the Vision, users should not manage JSON files or API keys. The Control Plane provides a Spotlight Interface that acts as the primary input surface.

• Fuzzy-to-Formal Compilation: When a user types "Analyze my competitors," the Control Plane utilizes an always-on CIM Intent Parser (running on CPU) to decompose this intent into a candidate Worker Manifest and Policy Envelope.

• The Magic Handoff: It automates the "Demand Side" negotiation, utilizing the Orchestrator to broadcast the intent to the supply network without burdening the user with the complexity of routing or node selection.

10.1.2 The Authorization Gate (Human-in-the-Loop)

While the network strives for autonomy, sovereignty requires consent. The Control Plane implements a Hardware-Interrupted Gate for high-stakes actions.

• If an agent attempts an action that exceeds its synthesized policy (e.g., "Spend > $50"), the Control Plane interrupts the flow with a Context-Aware Modal.

• This is not a standard system dialog; it is a Signing Event. Clicking "Approve" uses the Local DID to cryptographically sign an Approval Token, converting the user's consent into an on-chain fact.

10.1.3 Visual Sovereignty

The Control Plane provides a persistent, non-blocking status indicator so the state of any active agent (reasoning, spending, settling) is always visible to the user.

10.1.4 Hypervisor Foundry

Hypervisor Foundry is the worker creation and improvement lens inside Hypervisor. Its default user-facing action is: Train a Specialist

The guided flow is:

Define Task -> Select Base Model, Cognition Backend, or Training Profile -> Bind Domain Ontology and Data Recipes -> Plan Dataset Scope -> Ingest / Generate Examples -> Quality Gates -> Human Review -> Distill Ontology-Bound Data -> Train or Configure -> Evaluate -> Package or Deploy as Worker -> Monitor & Improve When Needed

The final product output should be a Worker Card, not merely a checkpoint file: task class, ontology refs, data recipe refs, distilled dataset refs, evals, benchmarks, known limitations, authority scopes, runtime profiles, interaction surfaces, and deployment options.

10.1.5 The Shared Builder Substrate

Foundry is a product lens over the shared builder substrate, not a separate canvas environment. Training recipes, evaluation recipes, benchmark recipes, deployment recipes, data recipes, and outcome workflows share the same graph model, typed node contracts, schemas, daemon execution path, and Agentgres receipt model. Different lenses may expose different palettes, inspectors, run panels, templates, and validation rules.

Foundry should lead with guided views. Advanced users may open the same recipe in the standard workflow compositor for inspection, customization, reuse, or composition.

10.2 Closing

IOI defines a deterministic execution boundary for autonomous software. The protocol does not claim to align model wisdom, eliminate hallucination at the model layer, or remove the need for human judgment. It claims that the consequential boundary -- the point at which probabilistic reasoning becomes economically binding -- can be canonicalized, policybound, receipt-backed, and settled through cryptographic recourse rather than vendor goodwill.

The bounded claim is narrow and the non-claims are explicit (Appendix D). What IOI provides is the protocol substrate for accountable autonomous labor: workers as the protocol-visible actor, MoW as the routing doctrine, Agentgres and ioi-memory as the state model, cryptographic and dialectic evidence as the verification ladder, the Agency Firewall as the deterministic egress gate, wallet.network as the authority control plane, and IOI L1 as the settlement and arbitration anchor. Web4 is the architecture in which Act inherits Own. The boundary between intelligence and consequence is the protocol's reason for existing.

Appendix A: Normative Schemas and Moved Code Blocks

This appendix collects code, JSON/YAML/Rust/TypeScript examples, and byte-level envelope material moved out of the main narrative. Conceptual definitions remain in the body; exact structures live here.

A.1 ActionRules policy example (moved from original Section 2.6.2)

2.6.2 ActionRules: The policy language

Firewall policies are expressed as ActionRules, a JSON-based DSL. Policies are default-deny and support Graph-Aware Permissioning.

Rule semantics (deterministic):

• Match: Rules match on the target plus conditions over canonicalized fields (domain, path, amount, window_id, etc.).

• Precedence: BLOCK rules override ALLOW. If multiple allows match, the most specific rule wins (ties broken by the strict canonical ordering defined below).

• Decision: { ALLOW | BLOCK | REQUIRE_APPROVAL } produces a single settlement resolution.

• Integer Determinism: Policy evaluation relies on Integer-Deterministic Inference (via the active CIM) rather than Floating Point (FP16) arithmetic. This ensures that policy decisions are identical across all hardware architectures (e.g., x86 vs. ARM), eliminating "Butterfly Effect" non-determinism in safety checks.

Canonical Rule Ordering & Hashing Specification (Normative) To ensure that a policy_hash is reproducible across heterogeneous hardware and immune to non-deterministic map iteration or insertion order variances, the ActionRules object MUST be strictly normalized before evaluation or hashing.

The IOI Synthesizer MUST apply the ActionRules::canonicalize() function enforcing the following invariants:

1. Array Normalization: All list-like conditions (e.g., allow_domains, allow_apps, capabilities) MUST be lexicographically sorted and de-duplicated. All strings MUST be Unicode normalized.

2. Stable Rule Sorting: The array of rules MUST be sorted by a deterministic, stable sort key (e.g., grouped by target lexicographically, then by descending action priority [BLOCK, REQUIRE_APPROVAL, ALLOW], and finally by the canonicalized string of their conditions).

3. Strict Evaluation Order: The policy engine MUST evaluate rules in this canonicalized order, never relying on the memory insertion order or unstructured HashMap iteration.

4. Hash Generation: The canonical policy hash is strictly defined as policy_hash = H(JCS(canonicalized(ActionRules))) where JCS is the RFC 8785 JSON Canonicalization Scheme. Graph-Aware Permissioning (DLP for Agents): To prevent data exfiltration through complex inference chains, ActionRules can block specific relationships in data exports. For example, a rule may allow an agent to access "Emails" and "Financial Data" individually, but BLOCK any egress if the export graph contains edges connecting an "Email Node" to a "Financial Data Node."

Structure (example):

{
"policy_id" : "production_assistant_v1" ,
"defaults" : "deny_all" ,
"rules" : [
{ "rule_id" : "allow_safe_browsing" , "target" : "net::fetch" ,
"conditions" : { "allow_domains" : [ "wikipedia.org" , "github.com" ] } ,
"action" : "ALLOW" } ,
{ "rule_id" : "allow_workspace_filesystem" , "target" : "fs::write" ,
"conditions" : { "allow_paths" : [ "/home/user/workspace" , "/tmp" ] } ,
"action" : "ALLOW" } ,
{ "rule_id" : "block_pii_clipboard_export" , "target" : "clipboard::write" ,
"conditions" : { "block_intents" : [ "pii_export" , "credential_leak" ] } ,
"action" : "BLOCK" } ,
{ "rule_id" : "gui_sandbox_allow_vscode" , "target" : "gui::click" ,
"conditions" : { "allow_apps" : [ "VS Code" , "Terminal" , "Firefox" ] } ,
"action" : "ALLOW" } ,
{ "rule_id" : "commerce_spend_gate" , "target" : "ucp::checkout" ,
"conditions" : { "allow_domains" : [ "amazon.com" ] , "max_spend" : 50000 } ,
"action" : "ALLOW" } ,
{ "rule_id" : "high_value_commerce_approval" , "target" : "ucp::checkout" ,
"conditions" : { "max_spend" : 100000 } , "action" : "REQUIRE_APPROVAL" } ,
{ "rule_id" : "block_credential_typing" , "target" : "gui::type" ,
"conditions" : { "block_text_pattern" : "password|secret|..." } ,
"action" : "BLOCK" } ,
{ "rule_id" : "system_command_allowlist" , "target" : "sys::exec" ,
"conditions" : {} , "action" : "REQUIRE_APPROVAL" } ,
{ "rule_id" : "wallet_signing_gate" , "target" : "wallet::sign" ,
"conditions" : {} , "action" : "REQUIRE_APPROVAL" }
] ,
"ontology_policy" : {
"approval_mode" : "single_pending" ,
"max_incident_transitions" : 32,
"intent_failure_overrides" : [
{ "intent_class" : "install_dependency" ,
"failure_class" : "permission_denied" , "strategy_name" : "sudo_retry" ,
"max_transitions" : 3 }
] ,
"tool_preferences" : {
"install_manager_priority" : [ "apt-get" , "brew" , "pip3" ] ,
"forbidden_remediation_tools" : [ "rm" , "dd" , "mkfs" ] ,
"bounded_reprompt_limit" : 2
}
}
}

A.2 Firewall artifacts (moved from original Section 2.6.9)

2.6.9 Normative Schema: Firewall Artifacts

To ensure interoperability between Local and Global environments, the Agency Firewall emits standardized artifacts. All hashes are computed over RFC 8785 canonicalized bytes.

ActionRequest (the input) A normalized, schema-validated description of an externally effectful operation.

struct ActionContext {
agent_id : String ,
session_id : Option <Hash>,
window_id : Option <u64>,
}

struct ActionRequest {
target : String , // e.g., "net::http::get", "ui::click", "wallet::send", "sys::exec"
params : CanonicalJson , // RFC 8785 canonical payload (typed by target)
context : ActionContext , // binds action to agent/session/UI scope
nonce : u64, // prevents replay within a context
}

ApprovalToken (user consent) A scoped, time-bounded authorization for an ActionRequest (or a constrained family of requests).

enum ApprovalMode { OneShot , Lease }

struct ApprovalToken {
scope : ApprovalScope , // What action(s) are approved
expires : u64, // Unix timestamp

// Anti-Replay & Hierarchy
mode: ApprovalMode , // OneShot (single use) vs Lease (time-bound)
grant_linkage : Option <Hash>, // Pointer to parent grant_id/lease_id
audience : Option <Hash>, // Binds to specific Guardian/executor

// Strict Replay Protection
nonce : u64, // Random value for uniqueness
counter : u64, // Monotonic sequence number

user_sig : Signature // User's cryptographic approval
}

enum ApprovalScope {
SingleAction ( Hash), // H(specific_action_request)
PolicyRule ( String ), // e.g., "allow_checkout_under_100"
SessionWide // Full session approval (rare)
}

FirewallDecisionReceipt (transaction record of the act) A Guardian-attested record of the firewall's decision for a given request.

enum Verdict {
Allow ,
Block ,
Approved { token_hash : Hash}, // H(canon(ApprovalToken))
}

struct FirewallDecisionReceipt {
request_hash : Hash, // H(canon(ActionRequest))
policy_hash : Hash, // H(canon(ordered_active_ActionRuleset))
verdict : Verdict ,

// Append-only anchoring (plugs into the Guardian receipt chain)
seq : u64, // monotonic sequence number
prev_receipt_hash : Hash, // hash-link to prior receipt in the chain

guardian_sig : Signature , // Guardian attestation over all fields above
}

Canonicalization and hashing requirements (normative):

• canon(x) denotes RFC 8785 canonical JSON serialization of x (or an equivalent canonical encoding defined by the protocol).

• H(bytes) denotes the protocol hash function over canonical bytes.

• policy_hash MUST be stable for a given ordered ruleset and MUST change for any rule addition/removal/reorder.

Shared ID Namespaces:

• node://<authority>/<node_id> - Identifies an Hypervisor Node.
• module://<authority>/<module_id>/<version> - Identifies a Service Module.
• invocation://<node_id>/<invocation_id> - Identifies a Module Invocation.
• proposal://<chain_id>/<proposal_id> - Identifies an Upgrade Proposal.
• transition://<chain_id>/<sequence> - Identifies a state transition.

Shared Envelope Specifications:

struct AutonomousSystemChainEnvelope {
    chain_id: Hash,
    manifest_ref: URI,              // points to manifest.json
    policy_hash: Hash,              // active policy_hash
    state_root: Hash,               // current Agentgres state root
    sequence: u64,                  // monotonic transition sequence
    prev_transition_hash: Hash,     // hash-link for chain integrity
}

struct HypervisorNodeEnvelope {
    node_id: URI,                   // node:// namespace
    owner_did: URI,
    active_chains: Vec<Hash>,       // hosted GovernedAutonomousSystemChains
    local_receipt_root: Hash,       // local Merkle accumulator root
    signature: Signature,           // Node Guardian signature
}

struct ServiceModuleManifestEnvelope {
    module_id: URI,                 // module:// namespace
    manifest_type: String,          // must be "service_module"
    required_capabilities: Vec<String>,
    deployment_profile: ModelDeploymentProfileEnvelope,
}

struct ModelDeploymentProfileEnvelope {
    model_name: String,
    mount_mode: String,             // bundled_weights | local_file | local_server | external_api | hosted_pool | tee_session | depin_session | customer_vpc
    model_artifact_ref: Option<URI>, // CID/hash link to weights if bundled/local_file
    vram_required_bytes: u64,
}

A.3 Session artifacts (moved from original Section 3.2.6)

3.2.6 Normative Schema: Session Artifacts

To ensure interoperability across diverse provider implementations, session artifacts adhere to a strict canonical schema.

PaymentTicket (Incremental Promise):

struct PaymentTicket {
session_id : Hash,
provider_id : Hash, // Binds ticket to a specific provider identity
terms_hash : Hash, // Pricing + dispute rules + policy envelope
seq : u64, // Monotonic counter
cumulative_amount : u128 , // Total Labor Gas authorized so far
receipt_root : Hash, // Merkle/MMR root after including this step
payer_sig : Signature , // Signature over all fields (canon-encoded)
}

SettlementSummary (The Closing Statement):

enum CloseMode {
Cooperative ,
Unilateral , // one-party submit; opens challenge window
}

struct SettlementSummary {
session_id : Hash,
provider_id : Hash,
payer_id : Hash,
terms_hash : Hash,
final_seq : u64,
final_amount : u128 , // Amount owed to provider (or total authorized)
final_receipt_root : Hash,
mode: CloseMode ,
payer_sig : Option <Signature >, // present for cooperative, may be absent in unilateral
provider_sig : Option <Signature >, // present for cooperative, may be absent in unilateral
}

ReceiptLeaf (The History Unit):

leaf = H(
H( "IOI_SESSION_LEAF_V1" ) ||
H( canon ( SessionReceipt )) ||
H( canon ( PaymentTicket )) )

PKT_LEASE_ISSUE (lease request with wallet.issueLease MCP payload)

{
"pkt_version" : "1" ,
"packet_type" : "PKT_LEASE_ISSUE" ,
"issued_at" : "2026-02-22T10:15:00Z" ,
"session_id" : "sess_01HZ..." ,
"tenant_id" : "tenant_acme_ai" ,
"payload" : {
"mcp" : {
"jsonrpc" : "2.0" ,
"id" : "lease-req-001" ,
"method" : "wallet.issueLease" ,
"params" : {
"agent_did" : "did:example:agent-123" ,
"capability_scope" : [ "stripe.refund" , "s3.read" ],
"limits" : { "max_amount_usd" : 50, "expires_at" : "..." }
}
}
}
}

PKT_ACTION_INVOKE (action invocation referencing lease_id)

{
"pkt_version" : "1" ,
"packet_type" : "PKT_ACTION_INVOKE" ,
"issued_at" : "2026-02-22T10:16:00Z" ,
"session_id" : "sess_01HZ..." ,
"lease_id" : "lease_77f..." ,
"payload" : {
"mcp" : {
"jsonrpc" : "2.0" ,
"id" : "invoke-002" ,
"method" : "tools/stripe_refund" ,
"params" : {
"charge_id" : "ch_1" ,
"amount_usd" : 10
}
}
}
}

PKT_ACTION_RESULT (result with nested mcp response + policy decision)

{
"pkt_version" : "1" ,
"packet_type" : "PKT_ACTION_RESULT" ,
"issued_at" : "2026-02-22T10:16:01Z" ,
"session_id" : "sess_01HZ..." ,
"lease_id" : "lease_77f..." ,
"action_result_id" : "res_9a1" ,
"payload" : {
"mcp" : {
"jsonrpc" : "2.0" , "id" : "invoke-002" ,
"result" : {
"refund_id" : "rfnd_42" ,
"status" : "succeeded" ,
"object" : "refund"
}
} ,
"policy" : {
"policy_hash" : "sha256:ab12..." ,
"decision" : "approved" ,
"enforced_bounds" : [ "capability_match" , "amount_limit" ]
}
}
}

PKT_RECEIPT_COMMIT (receipt commitment with hash chain linkage)

{
"pkt_version" : "1" ,
"packet_type" : "PKT_RECEIPT_COMMIT" ,
"issued_at" : "2026-02-22T10:16:02Z" ,
"session_id" : "sess_01HZ..." ,
"action_result_id" : "res_9a1" ,
"payload" : {
"receipt" : {
"receipt_id" : "rcpt_001" ,
"action_result_id" : "res_9a1" ,
"result_hash" : "sha256:7f3c..." ,
"prev_receipt_id" : "rcpt_000" ,
"signature" : "ed25519:..."
}
}
}

PktEnvelope (TypeScript type definition for the minimal schema)

type PktEnvelope = {
pkt_version : "1" ,
packet_type : "PKT_LEASE_ISSUE" | "PKT_ACTION_INVOKE" | "PKT_ACTION_RESULT" | "..." ,
issued_at : string ,
session_id : string ,
lease_id ?: string ,
action_result_id ?: string ,
payload : { mcp: Record <string , unknown > } | { receipt : Record <string , unknown > },
};

Machine-Economy Event Kinds:
- module.invocation_proposed: Emitted when a worker proposes a service module call.
- module.invocation_started: Emitted when the daemon initiates module execution.
- module.invocation_completed: Emitted when execution concludes and produces output.
- module.invocation_committed: Emitted when the output and receipt are written to Agentgres.
- upgrade.proposal_submitted: Emitted when an upgrade proposal is drafted.
- upgrade.proposal_approved: Emitted when the policy engine approves the proposal.
- upgrade.proposal_rejected: Emitted when the proposal violates the Monotonic Policy Invariant.
- upgrade.proposal_committed: Emitted when the daemon applies the module swap.
- local_settlement.committed: Emitted when a local interop transaction is settled.

Machine-Economy Receipt Types:

```rust
struct ModuleInvocationReceipt {
    invocation_id: Hash,
    module_ref: URI,
    caller_identity: URI,
    input_payload_hash: Hash,
    output_payload_hash: Hash,
    execution_gas_spent: u128,
    status: String,                 // Success | Failure
}

struct UpgradeProposalReceipt {
    proposal_id: Hash,
    chain_id: Hash,
    proposer: URI,
    target_module_id: URI,
    old_manifest_hash: Hash,
    new_manifest_hash: Hash,
    rationale_hash: Hash,           // hash of justification in ioi-memory
}

struct UpgradeDecisionReceipt {
    proposal_id: Hash,
    verdict: String,                // Approved | Rejected
    reason_code: String,            // e.g., "MONOTONIC_PASS", "POLICY_VIOLATION"
    authority_signature: Signature, // wallet.network or Guardian signature
}

struct LocalSettlementReceipt {
    settlement_id: Hash,
    node_id: URI,
    involved_chains: Vec<Hash>,
    net_amount: u128,
    asset_identifier: String,       // Labor Gas or internal credits
    receipt_root: Hash,             // local Merkle tree anchor
}

### A.4 Canonical dispute schema (moved from original Section 11.1.5)

#### 11.1.5 Canonical Dispute Schema

All challenge packages and resulting resolutions must adhere to the following canonical schema to ensure cross-node determinism:

```yaml
arbitration_case :
case_id : <Hash>
graph_id : <Hash>
step_id : <Hash>
policy_hash : <Hash>
policy_version : <u32>
rubric_version : <u32>
model_snapshot_id : <Hash>
evidence :
- artifact_id : <Hash>
- merkle_proof : <Hex>
objective_checks : # Lane 1 Outputs
- name: "test_suite_pass"
- status : <Boolean>
- hash : <Hash>
- detail : <String/Null>
claims : # Lane 2 Outputs
- claim_id : <String>
- description : <String>
- evidence_refs : [ <Hash> ]
- objective_fallback : <Boolean>
- prosecutor :
status : <String>
confidence : <Float>
cites : [ <Hash> ]
- defender :
status : <String>
cites : [ <Hash> ]
- resolver :
verdict : <Boolean>
confidence : <Float>
aggregate :
final_verdict : <String>
aggregate_confidence : <Float>
unresolved : <Boolean>
resolution_hash : <Hash>

End-to-End Dispute Example A user funds a Gig Escrow for a code-generation task with an ICS rubric: {passes_tests: true, language: "Rust", max_lines: 500}. The provider's agent delivers code that compiles but fails 3 of 12 test cases. The user submits a ChallengePackage referencing the session_id and the failing test hashes.

Lane 0 verifies signatures, policy_hash, and receipt chain integrity, all pass. Lane 1 replays the test suite against the delivered artifact: 3 tests fail deterministically. The rubric field passes_tests evaluates to false. Lane 1 emits a Resolution (Section 8.2, Class 4): provider fault, partial refund per the ICS penalty schedule. No semantic evaluation is needed; the dispute never reaches Lane 2. A FaultProof (Class 5) is appended to the provider's portfolio.

Appendix B: Canonical Envelopes: Manifest, Task, Run, and Receipt Schemas

To prevent split-brain API design between the IOI Daemon, Hypervisor, Agentgres, wallet.network, the marketplaces (aiagent.xyz, sas.xyz), and IOI L1 contracts, the protocol mandates a shared set of low-level canonical envelopes. All components MUST communicate using these stable structures.

Crucially: ai:// names intelligence. HTTP/gRPC/IPC transports execution. Canonical envelopes define the protocol semantics.

Canonical envelopes are the wire-level mechanism by which Act inherits Own: they make execution authority explicit, bounded, signed, replayable, and settleable across transports.

B.1 Identifier and Locator Conventions

IOI uses multiple URI-like strings, but they do not all represent transport protocols. To avoid "protocol sprawl," identifiers are strictly categorized into intelligence namespaces, typed domain object references, payload locators, and colon-based capability vocabularies.

ai:// is not a replacement for HTTP. It is the canonical name and trust resolution layer for intelligence. A resolved ai:// manifest may expose HTTP, gRPC, IPC, Filecoin/CAS, Agentgres, or local runtime endpoints as available transports and payload locations.

1. Canonical intelligence namespace These are stable, global, user-facing or protocol-facing names. ai:// is the primary global namespace.

2. ai://... -- global intelligence/app/worker/service/domain namespace (e.g., ai:// sas.xyz/services/weekly-runtime-audit)

3. ioi://publisher/... -- publisher identity namespace

4. Domain object references These are typed object references inside the IOI architecture, typically mapped through an Agentgres domain. They are not web protocols.

5. agent://... -- agent or worker instance

6. worker://... -- worker package or worker type

7. service://... -- service definition

8. run://... -- runtime run identity

9. task://... -- task identity

10. artifact://... -- Agentgres artifact reference

11. receipt://... -- receipt identity

12. wallet://... -- wallet.network account or authority reference

13. grant://... -- authority grant or lease reference

14. Storage and transport locators These point to where bytes or endpoints physically live.

15. cid://... -- content-addressed Filecoin/CAS payload

16. https://... -- HTTP transport endpoint

17. grpc://... -- gRPC transport endpoint

18. ipc://... -- local daemon IPC endpoint

19. file://... -- local filesystem reference

20. agentgres://... -- Agentgres domain object/projection reference

21. Capability vocabulary (Not URI schemes) Primitive execution capabilities and authority scopes use a colon-vocabulary (:). They MUST NOT use :// to avoid looking like transport protocols.

22. prim:fs.read

23. prim:model.invoke

24. scope:gmail.read

25. scope:repo.write

26. scope:commerce.order_submit

B.2 The ai:// Resolution Waist

ai:// acts as the "thin waist" of the Web4 architecture. Resolving an ai:// identifier yields a ManifestEnvelope, which in turn maps the intelligence object to physical transports, authority requirements, and settlement profiles.

For example, a client resolves: ai://sas.xyz/services/runtime-audit

And receives a ManifestEnvelope:

manifest_id: ai://sas.xyz/services/runtime-audit manifest_type: service body_ref: cid://bafy... runtime_endpoints:

• https://api.sas.xyz/v1/services/runtime-audit

• grpc://... authority_required:

• scope:payment.escrow

• scope:repo.read artifacts: package_ref: cid://bafy... mow: sparse_worker_category: optional benchmark_profile_refs: [] evaluation_rubric_ref: optional routing_eligibility_status: draft | submitted | benchmarking | eligible | suspended | revoked contribution_policy_ref: optional training_lineage_ref: optional settlement: chain_id: ioi-mainnet contract: ServiceOrder

B.3 Capability and Authority Tiers

IOI uses two separate tiers that MUST NOT be collapsed into a single generic capability field. Generic cap:* bindings are deprecated.

1. Primitive execution capabilities (prim:*): Runtime feasibility and physical isolation primitives. They describe the low-level action classes an IOI Daemon/tool requires to execute (e.g., prim:fs.read, prim:sys.exec, prim:net.request, prim:model.invoke).

2. Authority scopes and leases (scope:*): wallet.network policy grants over resources, providers, identities, budgets, approvals, and expiry. They describe what a subject is allowed to do (e.g., scope:gmail.read, scope:gmail.send, scope:commerce.order_submit).

B.4 Canonical Envelopes

1. ManifestEnvelope Used for registering and resolving canonical packages.

ManifestEnvelope: manifest_id: ai://... manifest_type: app | worker | service | runtime | domain | tool | connector version: semver_or_hash publisher_id: ioi://publisher/... manifest_root: hash body_ref: cid://... | https://... | agentgres://... signature: scheme: ed25519 | secp256k1 | ml-dsa | hybrid public_key_ref: ... signature: base64 l1_commitment: chain_id: ioi-mainnet contract: ManifestRootRegistry tx_hash: optional status: draft | active | deprecated | revoked

2. AuthorityScopeRequestEnvelope & AuthorityGrantEnvelope The core handshake between the IOI Daemon (requesting power) and wallet.network (granting power).

AuthorityScopeRequestEnvelope: authority_request_id: authreq_... subject_id: agent://... | worker://... | runtime://... issuer_id: wallet://... | org://... | policy://... primitive_capabilities_required:

• prim:model.invoke

• prim:fs.read authority_scopes_requested:

• scope:gmail.read

• scope:repo.write resource_scope: resources:

• agentgres://project/hypervisor/*

• file://workspace/src/** constraints: max_budget_usd: 10 expiry: 2026-05-01T00:00:00Z approval_required_for:

• external_message

• commerce policy_hash: hash request_hash: hash authority_grant_id: optional status: requested | granted | denied | expired | revoked

AuthorityGrantEnvelope: authority_grant_id: grant_... request_id: authreq_... issuer_id: wallet://... | org://... | policy://... subject_id: agent://... | worker://... | runtime://... authority_scopes:

• scope:gmail.read

• scope:repo.write primitive_capability_constraints:

• prim:fs.read

• prim:fs.write resources:

• agentgres://project/hypervisor/*

• file://workspace/src/** constraints: max_budget_usd: 10 expires_at: 2026-05-01T00:00:00Z max_calls: optional approval_required_for:

• external_message

• commerce revocation_epoch: integer status: active | expired | revoked

3. TaskEnvelope & RunEnvelope The canonical definitions of work to be done, and the execution trace of that work.

TaskEnvelope: task_id: task_... requester_id: wallet://... | agent://... | service://... objective: string task_class: coding | research | workflow | commerce | render | connector | service_delivery | other privacy_class: public | internal | confidential | regulated execution_profile: local | hosted | depin_mutual_blind | tee_enterprise | customer_vpc input_refs:

• artifact://...

• agentgres://object/... output_contract: type: report | patch | artifact | delivery_bundle | service_result | worker_result required_receipts:

• execution

• validation constraints: deadline: optional max_budget: optional human_approval: optional primitive_capabilities_required:

• prim:model.invoke authority_scopes_required:

• scope:model.invoke.external created_at: timestamp training_spec_ref: optional benchmark_profile_ref: optional sparse_worker_category: optional evaluation_rubric_ref: optional contribution_policy_ref: optional

RunEnvelope: run_id: run_... task_id: task_... runtime_id: runtime://... worker_id: optional service_id: optional state: queued | assigned | starting | running | awaiting_approval | paused | completed | failed | cancelled assignment: node_id: node://... placement_reason: string privacy_mode: mutual_blind | enterprise_secure | local | hosted event_stream: /v1/runs/{run_id}/events artifacts_endpoint: /v1/runs/{run_id}/artifacts receipts_endpoint: /v1/runs/{run_id}/receipts trace_endpoint: /v1/runs/{run_id}/trace inspect_endpoint: /v1/runs/{run_id}/inspect scorecard_endpoint: /v1/runs/{run_id}/scorecard stop_condition: optional task_state_ref: optional agentgres_projection_watermark: optional

4. RuntimeEventEnvelope & ReceiptEnvelope The observational stream (Events) vs. the enforceable cryptographic proof (Receipt). Events describe what appeared to happen; receipts are the transaction records of acts.

RuntimeEventEnvelope: event_id: evt_... parent_event_id: optional run_id: run_... task_id: task_... turn_id: optional kind: session.started | model.requested | model.completed | tool.proposed | policy.decided | approval.requested | tool.started | tool.completed | artifact.created | receipt.emitted | run.completed | run.failed timestamp: timestamp actor_id: agent://... | runtime://... | wallet://... privacy_class: public | internal | private | secret redaction_status: full | redacted | hash_only payload: object receipt_ref: optional cursor: integer terminal: boolean

ReceiptEnvelope: receipt_id: receipt_... receipt_type: policy | approval | model_invocation | tool_execution | artifact | validation | delivery | settlement | contribution | quality | training_trace | dataset_curation | benchmark_run | evaluation_verdict | routing_decision run_id: optional task_id: optional actor_id: string input_hash: optional output_hash: optional policy_hash: optional authority_grant_id: optional primitive_capabilities: [] authority_scopes: [] artifact_refs: [] timestamp: timestamp signature: optional l1_commitment: optional

5. ArtifactEnvelope The pointer linking Agentgres state to Filecoin/CAS payloads.

ArtifactEnvelope: artifact_id: artifact_... cid: bafy... sha256: hash size_bytes: integer media_type: string privacy_class: public | internal | private | encrypted encryption: mode: none | envelope | threshold | tee_sealed key_ref: optional provenance: run_id: optional worker_id: optional operation_id: optional receipt_id: optional access_policy_ref: optional

6. DeliveryEnvelope & SettlementEnvelope The bridge between Agentgres operational truth and IOI L1 economic settlement.

DeliveryEnvelope: delivery_id: delivery_... service_order_id: optional worker_invocation_id: optional run_id: run_... output_artifacts: [] evidence_bundle: [] quality_summary: object policy_summary: object settlement_status: pending | accepted | disputed | paid | refunded acceptance_deadline: optional

SettlementEnvelope: settlement_id: settle_... chain_id: ioi-mainnet contract: string action: escrow_lock | payout_release | license_mint | dispute_open | dispute_resolve | reputation_root_update amount: optional token: IOI | stablecoin | credit related_delivery_id: optional related_receipt_root: optional tx_hash: optional

7. ContributionEnvelope The mechanism for Marketplace Neutrality, Attribution, and Royalties.

ContributionEnvelope: contribution_id: contrib_... contributor_id: worker://... | service://... | publisher://... | tool://... | model://... consumer_id: wallet://... | service://... | agent://... task_id: task_... contribution_type: worker_invocation | service_delivery | tool_use | model_use | dataset_use | workflow_use | verification | training_data | training_service | benchmark_submission | routing_selection | verifier_signal usage_hash: hash quality_delta: optional reward_claim: optional license_ref: optional receipt_ref: receipt://... sparse_worker_category: optional benchmark_profile_ref: optional routing_decision_ref: optional downstream_outcome_ref: optional dispute_status: none | pending | upheld | rejected | no_fault

8. DomainOntologyEnvelope Defines the semantic vocabulary of a domain: what its entities, relationships, events, actions, states, roles, and invariants are.

DomainOntologyEnvelope: ontology_id: ai://... domain_id: ioi://domain/... schema_version: semver entity_types: [TypeDecl] relationship_types: [RelDecl] event_types: [EventDecl] action_types: [ActionDecl] state_types: [StateDecl] role_types: [RoleDecl] invariants: [InvariantDecl] policy_refs: [policy://...] projection_hints: optional receipt_root: hash

9. CanonicalObjectModelEnvelope Grounds an ontology in concrete object schemas, IDs, lifecycle states, constraints, privacy classes, authority needs, and projection hints. CanonicalObjectModelEnvelope: object_model_id: ai://... ontology_ref: ai://ontology/... object_type: string id_schema: IdSchemaDecl fields: [FieldDecl] lifecycle_states: [StateDecl] constraints: [ConstraintDecl] privacy_class: public | internal | confidential | restricted | regulated authority_requirements: [scope_ref] projection_hints: optional

10. DataRecipeEnvelope Defines how raw sources, connector payloads, documents, traces, and corrections are transformed into ontology-bound runtime, training, evaluation, and projection data.

DataRecipeEnvelope: recipe_id: ai://... ontology_refs: [ai://ontology/...] connector_mapping_refs: [ai://mapping/...] source_classes: [SourceClassDecl] transform_steps: [TransformStep] redaction_policy_ref: policy://... dedupe_policy_ref: policy://... validation_policy_ref: policy://... output_object_model_refs: [ai://object-model/...] output_dataset_refs: [ai://dataset/...] output_projection_refs: [ai://projection/...] receipt_obligations: [ReceiptObligation]

11. ConnectorMappingEnvelope Maps provider fields, files, events, and actions from a connector into canonical object models and authority scopes.

ConnectorMappingEnvelope: mapping_id: ai://... connector_id: ioi://connector/... provider_schema_ref: ref://... object_model_refs: [ai://object-model/...] field_mappings: [FieldMapping] action_mappings: [ActionMapping] authority_scope_refs: [scope_ref] evidence_requirements: [EvidenceReq] redaction_policy_ref: policy://...

12. PolicyBoundDataViewEnvelope A scoped, policy-bound projection of domain data with explicit allowed uses, subjects, authority grants, and retention rules. PolicyBoundDataViewEnvelope: view_id: ai://... domain_id: ioi://domain/... ontology_refs: [ai://ontology/...] object_model_refs: [ai://object-model/...] source_refs: [ref://...] allowed_uses: read | transform | distill | train | evaluate | export | publish | route subject_refs: [subject://...] policy_hash: hash authority_grant_refs: [grant://...] retention_policy_ref: policy://...

13. TransformationRunEnvelope A single materialized execution of a DataRecipe under a policy-bound view, producing canonical objects, datasets, distilled datasets, and projections with a receipt root.

TransformationRunEnvelope: run_id: ai://... recipe_ref: ai://recipe/... source_refs: [ref://...] policy_bound_view_ref: ai://view/... input_commitment: hash output_object_refs: [ai://object/...] output_dataset_refs: [ai://dataset/...] output_distilled_dataset_refs: [ai://distilled/...] output_projection_refs: [ai://projection/...] transformation_receipt_root: hash

14. DistilledOntologyDatasetEnvelope A compact, high-signal dataset derived from ontology-bound source truth via teacher workers, verifier workers, deterministic gates, human reviewers, and data recipes; binds full provenance.

DistilledOntologyDatasetEnvelope: dataset_id: ai://... source_dataset_refs: [ai://dataset/...] ontology_refs: [ai://ontology/...] data_recipe_refs: [ai://recipe/...] policy_bound_view_refs: [ai://view/...] source_commitments: [hash] distillation_method: DistillationMethodDecl teacher_worker_refs: [worker://...] verifier_worker_refs: [worker://...] rubric_refs: [rubric://...] benchmark_profile_refs: [benchmark://...] artifact_refs: [artifact://...] receipt_root: hash

15. EvaluationDatasetEnvelope The benchmark-facing counterpart to training data: golden, holdout, adversarial, regression, or distilled cases with rubric, benchmark, and provenance bindings.

EvaluationDatasetEnvelope: dataset_id: ai://... ontology_refs: [ai://ontology/...] object_model_refs: [ai://object-model/...] data_recipe_refs: [ai://recipe/...] dataset_type: golden | holdout | adversarial | regression | distilled rubric_ref: rubric://... benchmark_profile_refs: [benchmark://...] artifact_refs: [artifact://...] source_commitments: [hash] receipt_root: hash

16. OntologyProjectionEnvelope A materialized read surface over ontology-bound data: index refs, freshness SLO, and a checkpointed projection root.

OntologyProjectionEnvelope: projection_id: ai://... ontology_refs: [ai://ontology/...] object_model_refs: [ai://object-model/...] data_recipe_refs: [ai://recipe/...] policy_bound_view_refs: [ai://view/...] index_refs: [index://...] freshness_slo: duration projection_checkpoint_ref: ref://... receipt_root: hash

17. OntologyToWorkerPlanEnvelope Binds ontology, object models, recipes, views, distilled and evaluation datasets, and workflow schemas to a worker training objective, producing a worker manifest with a receipt root.

OntologyToWorkerPlanEnvelope: plan_id: ai://... ontology_refs: [ai://ontology/...] object_model_refs: [ai://object-model/...] data_recipe_refs: [ai://recipe/...] policy_bound_view_refs: [ai://view/...] distilled_dataset_refs: [ai://distilled/...] evaluation_dataset_refs: [ai://dataset/...] workflow_schema_refs: [workflow://...] worker_objective: ObjectiveDecl benchmark_profile_refs: [benchmark://...] output_manifest_ref: ai://manifest/... receipt_root: hash

18. CrossDomainRefEnvelope A lightweight reference shape for binding objects, state roots, policies, and receipts across product domains without collapsing them into one database.

CrossDomainRefEnvelope: ref_id: ref_... source_domain: agentgres://domain/... target_domain: agentgres://domain/... object_class: string object_ref: ai://... | agentgres://... state_root_ref: hash | optional policy_hash: hash | optional receipt_root: hash | optional authority_context_ref: grant://... | optional settlement_mirror_ref: l1://... | optional created_at: timestamp

19. AgentStateArchiveEnvelope Sealed, encrypted, content-addressed archive of worker or runtime state with full provenance, authority context, and restore policy bindings.

AgentStateArchiveEnvelope: archive_id: arch_... domain_id: agentgres://domain/... run_id: run_... | optional worker_id: worker://... | optional base_state_root: hash object_head_refs: [ref://...] archive_cid: cid://... archive_sha256: hash encryption: scheme: aes-256-gcm | xchacha20-poly1305 | hybrid_pq recipient_ref: wallet://... | grant://... key_ref: key://... contents:

• task_state

• working_memory

• patch_branches

• tool_trace

• artifact_refs

• projection_checkpoint schema_version: semver policy_hash: hash authority_context_ref: grant://... | policy://... restore_policy_ref: policy://... created_at: timestamp receipt_root: hash

20. RestoreReceiptEnvelope Receipt emitted when a sealed archive is verified, decrypted, validated, and imported through Agentgres operations.

RestoreReceiptEnvelope: restore_id: restore_... archive_ref: arch://... requester_ref: wallet://... | worker://... authority_grant_refs: [grant://...] hash_verified: bool decrypted: bool schema_validated: bool state_root_validated: bool imported_operation_refs: [op://...] projection_rebuild_refs: [projection://...] result_state_root: hash receipt_time: timestamp

21. ConstraintDefinitionEnvelope Declarative constraint definition over an Agentgres object class.

ConstraintDefinitionEnvelope: constraint_id: con_... domain_id: agentgres://domain/... object_class: string constraint_type: required | unique | foreign_ref | check | exclusion | schema_type | cardinality | temporal expression: ExpressionDecl enforcement_mode: immediate | deferred violation_receipt_type: receipt_type_ref

22. InvariantCheckEnvelope Audit-grade record of a domain-level invariant evaluation over a set of accepted operations.

InvariantCheckEnvelope: invariant_id: inv_... domain_id: agentgres://domain/... invariant_type: authority | receipt | settlement | policy | temporal | projection | state_root | artifact_integrity | policy_monotonicity operation_refs: [op://...] result: pass | fail | warn violation_refs: [violation://...] receipt_root: hash

23. SchemaMigrationEnvelope Operation-backed schema evolution: proposal, validation receipts, backfill plan, projection rebuilds, commit, and rollback plan.

SchemaMigrationEnvelope: migration_id: mig_... domain_id: agentgres://domain/... from_schema_version: semver to_schema_version: semver proposed_operation_ref: op://... validation_receipt_refs: [receipt://...] backfill_plan_ref: plan://... projection_rebuild_refs: [projection://...] committed_operation_ref: op://... rollback_plan_ref: plan://...

24. PostgresBridgeProjectionEnvelope Configuration of a Postgres-compatible read surface over a named Agentgres projection, including write policy.

PostgresBridgeProjectionEnvelope: bridge_id: bridge_... projection_ref: projection://... sql_schema_name: string read_consistency_level: cached_projection | projection_consistent | snapshot_consistent | state_root_consistent | linearized_domain | serializable_domain writable: false | operation_compiled allowed_write_operations: [op_type] freshness_slo: duration policy_watermark: hash domain_sequence_watermark: integer

B.5 Worker Training, Evaluation, and Benchmark Envelopes

Specialized envelopes for the Worker Training Pipeline, benchmark execution, and MoW routing decisions. These compose with the canonical envelopes in B.4 and produce specialized Class 1 Receipts.

WorkerTrainingEnvelope: training_id: train_... target_worker_id: worker://... requester_id: wallet://... | service://... | org://... provider_id: worker://... | service://... | publisher://... training_objective: string domain_ontology_refs: [ai://ontology/...] data_recipe_refs: [ai://recipe/...] policy_bound_data_view_refs: [ai://view/...] distilled_dataset_refs: [ai://distilled/...] evaluation_dataset_refs: [ai://dataset/...] training_methods:

• prompt_optimization

• workflow_trace_learning

• retrieval_curation

• verifier_tuning

• model_finetune

• distillation

• policy_hardening

• context_graph_revision

• route_policy_training

• synthetic_dataset_planning

• synthetic_generation

• deterministic_quality_gating

• semantic_quality_gating

• evaluation_benchmarking

pipeline_roles: planner_workers:

• worker://... generator_workers:

• worker://... verifier_workers:

• worker://...

execution_environment: locality: local | remote | hybrid | undisclosed

dataset_commitment: hash synthetic_corpus_commitment: optional_hash privacy_policy_ref: optional evaluation_rubric_ref: rubric://... benchmark_profile_ref: benchmark://... evaluation_receipts:

• receipt://... contribution_receipts:

• receipt://... output_manifest_ref: ai://... receipt_root: hash status: proposed | running | evaluated | accepted | rejected | disputed

BenchmarkEnvelope: benchmark_run_id: bench_... worker_id: worker://... sparse_worker_category: string benchmark_profile_ref: benchmark://... environment_hash: hash manifest_hash: hash policy_hash: hash score_commitment: hash evaluator_id: worker://... | verifier://... evaluation_receipt_root: hash routing_eligibility_result: eligible | ineligible | suspended

RoutingDecisionEnvelope: routing_decision_id: route_... task_id: task://... router_id: worker://... | runtime://... candidate_set_commitment: hash routing_policy_hash: hash selected_worker_id: worker://... selection_reason: string contribution_policy_ref: optional receipt_obligations: [] signature: optional

TrainingProfileEnvelope: profile_id: train_profile_... worker_architecture_class: planner | executor | verifier | router | specialist | hybrid cognition_backend_refs: [model://... | api://... | local://...] context_strategy: ContextStrategyDecl adapter_strategy: AdapterStrategyDecl distillation_strategy: DistillationStrategyDecl local_remote_compute_policy: local | remote | hybrid benchmark_requirements: [benchmark://...] promotion_requirements: [RequirementDecl] regression_requirements: [RequirementDecl]

WorkerCardEnvelope: worker_id: worker://... manifest_ref: ai://manifest/... task_class: string ontology_refs: [ai://ontology/...] data_recipe_refs: [ai://recipe/...] distilled_dataset_refs: [ai://distilled/...] evaluation_receipt_refs: [receipt://...] benchmark_receipt_refs: [receipt://...] known_limitations: [string] authority_requirements: [scope_ref] runtime_profiles: [profile_ref] interaction_surfaces: [surface_ref] deployment_options: [deployment_ref] contribution_policy_ref: policy://...

ManagedWorkerInstanceEnvelope: instance_id: inst_... worker_manifest_ref: ai://manifest/... worker_version: semver_or_hash owner_ref: wallet://... | org://... | project://... tenant_ref: optional install_right_ref: ref://... license_ref: license://... runtime_profile_ref: profile://... runtime_assignment_ref: assignment://... | optional persistence_profile: per_invocation | warm | persistent | zero_to_idle authority_policy_ref: policy://... wallet_grant_refs: [grant://...] memory_policy_ref: policy://... archive_policy_ref: policy://... latest_state_root: hash archive_refs: [cid://...] interaction_surfaces:

• web_chat

• api

• hypervisor

• workflow

• sas_outcome

• mow_route subscription_ref: sub://... | optional receipt_root: hash lifecycle_status: initializing | ready | running | idle | archived | suspended | revoked

RuntimeSubscriptionEnvelope: subscription_id: sub_... owner_ref: wallet://... | org://... | project://... managed_instance_ref: inst://... billing_policy_ref: policy://... included_invocations: integer | unlimited runtime_profile: profile://... persistence_profile: per_invocation | warm | persistent | zero_to_idle compute_provider_refs: [provider://...] storage_policy_ref: policy://... restore_policy_ref: policy://... entitlement_status: active | suspended | expired | revoked renewal_policy: auto | manual | none receipt_root: hash

WorkerInstallReceipt: receipt_id: receipt_... worker_manifest_ref: ai://manifest/... installer_ref: wallet://... | org://... install_right_ref: ref://... license_ref: license://... policy_hash: hash created_instance_ref: inst://... receipt_time: timestamp

ManagedInvocationReceipt: receipt_id: receipt_... instance_ref: inst://... invocation_ref: invocation://... runtime_assignment_ref: assignment://... authority_grant_refs: [grant://...] input_commitment: hash output_commitment: hash artifact_refs: [artifact://...] contribution_refs: [contribution://...] receipt_time: timestamp

Appendix C: Developer Quickstart and Connector Manifest

This appendix demonstrates a minimal valid agent package: the logic, the policy, and the manifest. Scenario: A "Research Assistant" that fetches a webpage, summarizes it using a local LLM, and saves the result.

C.1 The Worker Logic (src/agent.py)

The developer writes standard Python using the ioi-sdk. Note the absence of blockchain code.

from ioi_sdk import Agent , Tool

# Define a tool (automatically wrapped in an ActionRequest)
@Tool( name="fetch_page" )
def fetch_page ( url : str ):
# The runtime intercepts this; it never hits the OS network driver directly.
return requests . get ( url ). text

agent = Agent ( name="research-bot-v1" )

# The Agent DAG
@agent.task
def summarize_url ( url : str ):
# 1. Network Action (Triggering Policy Check)
content = fetch_page ( url )

# 2. Inference (Triggering Receipts & Metering)
summary= agent . llm . generate (
f"Summarize this: {content}" ,
model="llama3-8b" )

# 3. Filesystem Action (Triggering Policy Check)
agent . fs . write ( f"./summaries/{url.hash()}.txt" , summary)

return summary

C.2 The Policy Envelope (policy.json)

The firewall rules that govern the agent's execution. This ensures the agent cannot exfiltrate the user's SSH keys or drain their wallet.

{
"policy_id" : "research-safe-v1" ,
"defaults" : "deny_all" ,
"rules" : [
{
"target" : "net::fetch" ,
"conditions" : {
"allow_domains" : [ "wikipedia.org" , "arxiv.org" ],
"rate_limit" : "10/minute"
} ,
"action" : "ALLOW"
} ,
{
"target" : "fs::write" ,
"conditions" : {
"allow_path" : "./summaries/*"
} ,
"action" : "ALLOW"
} ,
{
"target" : "cap::spend" ,
"conditions" : {
"max_session_spend" : "50"
} ,
"action" : "REQUIRE_APPROVAL"
}
]
}

C.3 The Worker Manifest (manifest.json)

The declarative contract published to aiagent.xyz.

{
"authority" : "did:ioi:builder-xyz" ,
"id" : "ai://builder-xyz/research-bot" ,
"version" : "v1.0.0" ,
"package" : {
"type" : "oci" ,
"digest" : "sha256:e3b0c442..."
} ,
"requirements" : {
"vram_min" : "16GB" ,
"framework" : "python-3.11"
} ,
"permissions_request" : {
"network" : [ "Public Research Domains" ],
"filesystem" : [ "Local Summary Folder" ]
} ,
"developer_fee" : "500"
}

C.4 Normative Schema: Connector Manifest

To ensure agents can be swapped between providers (avoiding vendor lock-in), Connectors are defined by schema, not proprietary code.

{
"connector_id" : "std:salesforce:v58" ,
"interface" : {
"type" : "openapi" ,
"url" : "https://developer.salesforce.com/files/openapi.json"
} ,
"auth_requirement" : {
"type" : "oauth2" ,
"scopes" : [ "api" , "refresh_token" ]
} ,
"policy_defaults" : {
"allow_methods" : [ "GET" , "POST /sobjects/Account" ],
"deny_methods" : [ "DELETE" , "POST /sobjects/User" ]
} ,
"notarization" : "required" // Must produce TLS proof of response
}

C.5 Lifecycle of an Agentic Transaction (Worked Example)

Linear flow of data transformation.

Appendix D: Claims and Non-Claims (The Scope of Verification)

To provide absolute clarity to developers, legal arbiters, and protocol auditors, the IOI framework makes the following explicit claims regarding its cryptographic proofs. The protocol is designed around the philosophy of Process Safety over Model Safety; therefore, we explicitly bound the scope of what is mathematically guaranteed versus what is classified as heuristic or non-binding telemetry.

[[figure:claims-nonclaims]]

D.1 What the IOI Protocol PROVES (Normative Guarantees)

When an action or retrieval crosses the IOI Determinism Boundary and generates a settlement-grade receipt, the protocol cryptographically proves:

1. Canonical Intent: The exact byte-for-byte structure of the ActionRequest (via RFC 8785) that was committed prior to physical execution.

2. Policy Enforcement: The exact policy_hash under which the runtime authorized the action, proving the agent operated within its delegated constraints and canonical rule ordering.

3. Explicit Consent: The presence, cryptographic validity, and exact scope of an ApprovalToken if human step-up was required by the policy.

4. Bounded Execution: That execution attempts were bounded under a deterministic retry contract, with all failure receipts and attempt counts durably recorded in the local Merkle spine.

5. Cryptographic Inclusion: The inclusion of specific execution receipts, meeting the Minimum Viable Receipt (MVR) requirements for their specific domain, within the receipt_root committed during channel settlement.

6. Bounded Local Settlement: That Hypervisor Node local settlement transactions, service module invocations, and governed autonomous-system upgrades are policy-bound, receipt-backed, and cryptographically isolated, executing deterministically prior to optional L1 anchoring.

7. Transaction-Shaped Consequence: The protocol proves that a consequential action was represented before execution as a canonical, signed or authorized, policybound, replayable, and settleable artifact. This is the cryptographic inheritance path from Own to Act.

8. Bounded Machine Authority: The protocol proves that consequential machine authority was bounded by explicit runtime, authority, state, receipt, and settlement controls at the moment the action crossed the Determinism Boundary.

9. Open Intent-to-Outcome Routing: The protocol proves that an open intelligence network routed intent across compute, data, models, workers, workflows, evaluations, and services while preserving accountability through receipts and settlementaware recourse.

10. Agentgres Operational Substrate: Agentgres can serve as the canonical operational state substrate when application truth is produced by workers, authority grants, artifacts, receipts, projections, and settlement mirrors.

11. Postgres-Compatible Projection Surface: Agentgres can expose Postgres-compatible projection reads without becoming a mutable-row database at its canonical layer.

12. Sealed State Portability: Sealed State Archives make worker and runtime state portable, restorable, and verifiable without making blob storage canonical live truth.

D.2 What the IOI Protocol DOES NOT CLAIM (Non-Claims)

To avoid the architectural traps of first-generation Decentralized AI networks, IOI explicitly does not claim the following:

1. Bit-for-bit equivalence of foundational model inference: IOI does not claim an LLM will output the exact same tokens when run on an Nvidia H100 versus an Apple M3 chip. IOI embraces floating-point drift at the heavy cognition layer. We claim only that the Decision Verdict rendered by the Agency Firewall is fully deterministic. This is achieved via strict JCS normalization of ActionRequests and, specifically for neural PII detection and masking, the integer-bound Canonical Inspection Module (CIM).

2. Every local action is on-chain: IOI does not claim, require, or desire that every local action, tool call, click, inference step, or filesystem access become a Mainnet transaction. The claim is narrower and stronger: any consequential boundary of Web4 Act must be transaction-shaped and capable of settlement or recourse when required.

3. Universal Knowledge Optimality: IOI does not prove that a worker used the best information available in the global universe. It proves only that the committed context slice, retrieval inputs, and evidence references were faithfully packaged and bound to the intent under the declared policy. If a superior source was never present in the worker's accessible memory substrate, retrieval corpus, or authorized context window, IOI cannot prove it should have been used.

4. Wall-clock timestamps as consensus truth: While the runtime records local SystemTime for telemetry and debug activity streams (WorkloadReceiptEvent), these are observational artifacts. IOI does not treat local wall-clock time as a Byzantinefault-tolerant source of truth. All enforceable expiries and sequencing rely strictly on Chain Time or monotonic block heights.

5. Semantic Correctness: The protocol proves Intent Compliance (did the agent do what it said it would do within the rules?), not Semantic Wisdom. If a worker is authorized to spend $50 and it buys a useless asset within that authorized scope, the protocol proves the spend was authorized and executed; it does not claim the worker made a "smart" decision. Web4 proves executable ownership and accountable consequence, not wisdom. Economic liability for "authorized incompetence" remains with the User, while liability for "policy breach" rests with the Provider/Developer.

6. Total On-Chain Duplication: IOI does not claim that every state change or module invocation is duplicated on IOI L1. Hypervisor Node local settlement is designed to avoid public chain spam, storing operational and intermediate execution state locally within Agentgres.

7. Monolithic Binaries: IOI does not claim that the Hypervisor Node binary contains or owns model weights by default. Models are treated strictly as mounted cognition backends whose lifecycles are governed by independent deployment profiles.

8. Hardware attestation as authority: IOI does not claim that a TEE quote, secure enclave measurement, or confidential-compute attestation is sufficient to authorize an action. Hardware attestation may contribute evidence, but validity depends on the complete receipt set, policy hash, approval chain, capability scope, and settlement rules.

9. Cryptographic compute as universal runtime: IOI does not claim that FHE, MPC, ZK-ML, or proof VMs can currently replace all general-purpose agent execution. These substrates are strongest for bounded, typed, circuit-shaped, replayable, or privacy-sensitive subclaims. General browser automation, desktop operation, long-horizon mutable workflows, and open-ended agent behavior still require IOI's broader receipt and settlement boundary.

10. Clean-room non-exposure as absolute secrecy: Clean-room execution reduces disclosure under a declared threat model. It does not eliminate all side channels, implementation bugs, model leakage, misuse, or legal discovery risk. IOI's claim is narrower: the action's evidence posture, leakage bounds, and verifier requirements are explicit, auditable, and settlement-bound.

11. Global AI alignment: IOI does not claim to solve global AI alignment or inner alignment within neural networks. The protocol is strictly an execution-boundary containment system; it bounds the consequential effects of machine authority, and does not legislate the values, training data, or internal goals of any model.

12. Raw model output as authoritative: IOI does not claim that raw model output is legally or economically authoritative by itself. Authority attaches to the canonical ActionRequest, policy hash, approval chain, capability scope, and receipt set that wrap the output, not to the output as such. A receipt does not prove the underlying model was wise, truthful, or globally optimal.

13. Agentgres as universal store: Agentgres is not a universal replacement for OLAP engines, vector databases, blob stores, local UI state, generic event logs, or IOI L1 settlement.

14. SQL writes bypassing operation settlement: Agentgres does not allow arbitrary SQL writes to bypass operation settlement. The Postgres bridge serves projection reads; canonical writes must compile into Agentgres operations.

15. Sealed archive as authority: A sealed archive does not prove restore authority by existing. A blob CID is not canonical runtime truth by itself; Agentgres records who may restore, under what policy, and which receipt makes the restoration valid.

16. Omnipresent control over opaque runtimes: The IOI Authority Gateway does not claim to have direct, internal visibility into the state machines of closed-source, remote, or compiled third-party agent systems (e.g., Cursor's internal binary or remote Devin-like platforms). Instead, the protocol claims only that it can deterministically intercept, verify, and log the visible effects of those systems when they attempt to interact with the local filesystem, network, shell, or wallet via public integration hooks and proxies.

The Physics Oracle Caveat (Embodied AI Roadmap) IOI does not claim it can cryptographically prove the physical world changed (e.g., a robot moved a box) unless it controls and trusts the relevant physical sensor/actuator chain. Today, IOI proves the policy, the identity of the actor, the exact command issued, and the receipt of execution. Extending these guarantees to embodied action requires that the hardware attestation chain, from sensor readings through actuator commands, is itself brought under the IOI evidence and policy fabric. Until that integration is complete, IOI's cryptographic claims cover the digital command and receipt layer but not the physical outcome layer.

D.3 Benchmark and Routing Non-Claims

IOI BenchmarkReceipts prove performance under a declared benchmark profile, evaluation environment, rubric, and worker manifest. They do not prove universal intelligence, universal optimality, or permanent superiority across all future tasks.

MoW routing decisions prove that a worker was selected under a declared routing policy and candidate set. They do not prove that the selected worker is globally best in an absolute sense. They prove that the routing decision was legible, receipt-backed, policy-compatible, and challengeable. Sparse Worker Categories are relative labor markets, not universal intelligence rankings.

Appendix E: Fail-Closed Verdict Logic

This appendix defines the normative conformance contracts for the IOI Daemon and the Agency Firewall. To guarantee that autonomous agents cannot bypass safety constraints, the runtime must enforce two strict compliance models: the Capability-Intent Resolution Contract (CIRC) and the Capability Execution Completion Contract (CEC).

These rules dictate the "Fail-Closed" behavior of the Determinism Boundary. They enforce a "Zero Heuristics / Zero Fallbacks" doctrine: zero ad hoc routing patches, and zero post-execution heuristic retry loops. They are the conformance rules that prevent Act from degrading into Web2 automation: if intent cannot acquire transaction shape, it cannot become sovereign consequence.

E.1 Capability-Intent Resolution Contract (CIRC)

CIRC governs the pre-execution phase. It is the semantic collapse contract. It ensures that probabilistic inference (e.g., embedding searches, LLM intent parsing) collapses into one deterministic, replayable route decision or an explicit abstention.

To pass the CIRC gate, the IOI Daemon MUST enforce the following invariants:

1. The Three-Layer Rule: The resolver MUST enforce distinct layers:

2. Intent: Domain-level semantics (what the user wants).

3. Capability: Primitive execution boundaries (prim:*, what is physically possible and isolated).

4. Tool: Concrete implementation mechanism (how the action is executed).

5. Fail-Closed Action: If a tool tries to bypass semantic ranking or if capabilities encode domain logic (e.g., prim:math.eval instead of prim:sys.exec), the runtime MUST reject the configuration with OntologyViolation.

6. The Structural Retrieval Rule: Retrieval affordances MUST describe structural evidence shapes (e.g., queryable_index, timestamped_record), not domain semantics or provider families (e.g., google_news).

7. Fail-Closed Action: If query inference directly emits provider IDs, hostnames, or pre-designated query-class switchboards instead of typed retrieval requirements, the runtime MUST abort with ResolverContractViolation.

8. Feasibility & Hard Constraints: Feasibility MUST be determined strictly upfront. Trial-and-error routing is forbidden. The resolver MUST verify that all required prim:* capabilities are satisfiable by the active tools, and that wallet.network policy does not prohibit execution.

9. Fail-Closed Action: If the top-ranked intent is infeasible, it MUST emit IntentInfeasible or PolicyBlocked. It MUST NOT short-circuit to a tool before intent winner selection.

E.2 Capability Execution Completion Contract (CEC)

CEC governs the post-resolution execution discipline. It is the effect collapse contract. CEC takes the already-resolved intent and governs payload synthesis, execution, and verification. It permits probabilistic synthesis prior to execution, while strictly enforcing a single-shot boundary during execution.

The IOI Daemon MUST enforce the CEC Execution State Machine:

1. contract_loaded & discovery: The runtime gathers ground-truth host topology and provider candidates based on typed discovery.

2. provider_selection / payload_synthesis (The Safe Sandbox): Probabilistically generating, linting, dry-running, and iteratively refining the execution payload is explicitly permitted and encouraged within this state only.

3. execution (The Single-Shot Boundary): Once the payload transitions to execution, it is the point of no return. It MUST be a single-shot invocation.

4. Fail-Closed Action: Post-execution heuristic retries using the real environment as a sandbox (unbounded "try-and-catch" code-rewriting loops) are strictly forbidden. If an execution fails, it MUST emit ExecutionFailedTerminal.

5. verification: The runtime MUST verify read-state evidence with a cryptographic commit. It MUST NOT assume success from process exit status alone.

6. completion_gate & terminal: The final gate before integration.

To pass the CEC Completion Gate, the IOI Daemon MUST enforce the following:

1. The Judge Integrity Rule: Runtime success adjudication MUST be receipt-driven. Final chat reply text or debug strings MUST NOT be the primary evidence channel for pass/fail. Completion gates MUST rely on typed receipt fields (e.g., contract_version, satisfied, evidence_commit_hash).

2. Receipt Completeness Invariant: Every governed execution MUST emit machinereadable evidence records matching its applicability_class (e.g., topology_dependent, deterministic_local, remote_retrieval).

3. Fail-Closed Action: If any required receipt is missing, any required postcondition is missing, or verification fails, the runtime MUST emit ERROR_CLASS=ExecutionContractViolation and block the agent__complete status.

E.3 The Anti-Heuristic Doctrine

In the IOI architecture, ambiguity equals failure. There are no "best effort" policy bypasses or "heuristic" state merges.

Implementations MUST NOT:

1. Use predesignated query archetypes or domain buckets as a stand-in for typed provider discovery.

2. Gate success primarily on reply text or substring matches over debug output.

3. Route back to payload synthesis for a heuristic retry after a verification failure at the completion gate.

This Fail-Closed Verdict Logic is the bedrock of the Determinism Boundary. It guarantees that while an agent's thoughts and synthesis may be probabilistic and creative, its consequences are always mathematically bound, receipt-backed, and legally insurable.

Internet of Intelligence Protocol - Whitepaper v1.0 - (c) 2026 IOI Foundation

Appendix F: References & Normative Standards

This section details the normative specifications, cryptographic standards, and academic literature that form the foundational assumptions of the IOI Protocol.

F.1 Normative IETF & Web Standards

These standards govern the deterministic formulation of intents, payload serialization, and network routing within the IOI Kernel.

• [RFC 8785] Rundgren, A., Harrison, R., & Sporny, C. (2020). JSON Canonicalization Scheme (JCS). Internet Engineering Task Force (IETF). Defines the strict canonicalization required to prevent hash malleability in JSON payloads (used throughout the IOI Determinism Boundary).

• [RFC 3986] Berners-Lee, T., Fielding, R., & Masinter, L. (2005). Uniform Resource Identifier (URI): Generic Syntax. IETF. Defines the parsing and resolution structure adapted for the ai:// Agentic Interoperability Protocol (AIIP).

• [RFC 5234] Crocker, D., & Overell, P. (2008). Augmented BNF for Syntax Specifications: ABNF. IETF. Defines the grammar for parsing the AIIP namespace.

• [RFC 8949] Bormann, C., & Hoffman, P. (2020). Concise Binary Object Representation (CBOR). IETF. The normative binary transport format for offload and session packets to minimize network overhead.

• [RFC 3161] Adams, C., Cain, P., Pinkas, D., & Zuccherato, R. (2001). Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). IETF. Referenced for off-chain anchor validity.

F.2 Cryptographic Standards (Post-Quantum & Classical)

The protocol's Strict Hybrid Cryptography model relies on the following National Institute of Standards and Technology (NIST) and industry specifications.

• [FIPS 202] National Institute of Standards and Technology. (2015). SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. Defines the SHAKE-256 algorithm targeted for Post-Quantum artifact hashing.

• [FIPS 203] National Institute of Standards and Technology. (2024). Module-Lattice-Based Key-Encapsulation Mechanism Standard. Defines ML-KEM-768 (derived from CRYSTALS-Kyber), utilized in the protocol's Application-Layer Hybrid KEM channel handshakes.

• [FIPS 204] National Institute of Standards and Technology. (2024). Module-Lattice-Based Digital Signature Standard. Defines ML-DSA-44 (derived from CRYSTALS-Dilithium), utilized alongside Ed25519 for dual-signature identity and policy commitments.

• [RFC 8032] Josefsson, S., & Liusvaara, I. (2017). Edwards-Curve Digital Signature Algorithm (EdDSA). IETF. Defines the classical signature primitive (Ed25519) utilized in the Hybrid Identity Stack.

• [BLAKE3] O'Connor, J., Aumasson, J. P., Neves, S., & Wilcox-O'Hearn, Z. (2020). BLAKE3: one function, fast everywhere. The target internal collision-resistant hash function for high-throughput FQF Merkle trees.

F.3 Consensus & Distributed Systems

Asymptote Fault Tolerance (AFT, Section 5.3) builds upon the following foundational BFT research and consensus optimizations.

• [PBFT] Castro, M., & Liskov, B. (1999). Practical Byzantine Fault Tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). The foundational baseline for BFT mesh assumptions.

• [HotStuff] Yin, M., Malkhi, D., Reiter, M. K., Gueta, G. G., & Abraham, I. (2019). HotStuff: BFT Consensus with Linearity and Responsiveness. Proceedings of the ACM Symposium on Principles of Distributed Computing (PODC). Serves as the structural basis for the LFT/AFT linear-view pipeline.

• [MinBFT] Veronese, G. S., Correia, M., Bessani, A. N., & Lung, L. C. (2011). Efficient Byzantine Fault-Tolerance. IEEE Transactions on Computers. Provides the mathematical proofs that hardware-backed monotonic counters can reduce equivocation, enabling more efficient Byzantine fault-tolerant replication under the paper's stated assumptions.

F.4 Artificial Intelligence & Infrastructure

Protocols and algorithms supporting the cognitive and operational capabilities of the IOI architecture.

• [MCP] Anthropic. (2024). Model Context Protocol Specification. The standard open integration protocol utilized by the IOI Authority Gateway to securely expose and mediate host tools to third-party cognitive engines.

• [ERC-4337] Buterin, V., et al. (2021). Account Abstraction Using Alt Mempool. Ethereum Improvement Proposals. The structural target for the Agent Execution Account (Ops Wallet) managed by the Tier 2 Vault.

• [MoE] Shazeer, N., et al. (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer. Referenced as the model-routing analogue for IOI's execution-layer Mixture of Workers concept.