# neXus × ICP: Verifiable Autonomous Computing on the Internet Computer

A Technical Collaboration Proposal

Author

Affiliation

SSCCS Foundation [](mailto:contact@ssccs.org)

[SSCCS Foundation](https://ssccs.org)

Published

May 30, 2026

Abstract

neXus is building a Wasm-native, decentralized agent computing system on FIH (Fact / Intent / Hint) primitives that enable lock-free, serverless, verifiable research at scale. The Internet Computer Protocol (ICP) provides a globally distributed Wasm execution environment with orthogonal persistence, subnet-based horizontal scaling, and Byzantine fault-tolerant consensus. This proposal explores the hypothesis that deploying neXus as an ICP canister could create a symbiotic architecture: ICP would supply the distributed infrastructure layer, while neXus would contribute a verifiable truth engine — the deterministic knowledge graph that ICP’s general-purpose canisters cannot natively provide. The hypothesis targets an on-chain, globally replicated, cryptographically auditable research machine that scales from a single laptop to a planetary compute fabric without architectural redesign.

Repository

[Github](https://github.com/ssccsorg/nexus)

References

[ICP](https://internetcomputer.org)

[neXus Docs](https://docs.ssccs.org/projects/nexus)

Other Formats

[LLMs](https://docs.ssccs.org/proposal/icp.llms.md)

## Architectural Convergence

ICP and neXus independently arrived at the same architectural conclusion: the future of decentralized computing runs on Wasm. Docker containers and x86 VMs represent the past — multi-gigabyte runtimes that cannot be efficiently distributed, verified, or composed. Wasm bytecode, typically under a few megabytes, is the only runtime that satisfies the simultaneous demands of portability, sandboxing, and deterministic execution that decentralized agent systems require.

ICP built a decentralized cloud on Wasm: canisters executed across globally distributed subnets with automatic state persistence and BFT consensus. neXus is building a verifiable agent computing model on the same substrate: FIH primitives that decompose all computation into auditable, content-addressed, append-only records. The two systems, as they converge, are architectural complements.

| Dimension | ICP (Internet Computer) | neXus |
|----|----|----|
| Runtime | Wasm (canister) | Wasm (agent) + bare-metal RISC-V |
| Objective | Decentralized World Computer | Verifiable Autonomous Computing |
| State Model | Orthogonal Persistence (Stable Memory) | FIH Blackboard (Fact / Intent / Hint) |
| Scaling | Subnet-based horizontal scaling | Recursive agent structure + lock-free parallelism |
| Agent Model | Canister (actor model) | Domain Entity (OODA loop) |
| Verifiability | BFT consensus-dependent | Deterministic engine + C2PA signatures + on-chain proof |

Both systems converge on the same pattern: a lightweight Wasm runtime hosting autonomous agents that coordinate through a shared state space. ICP provides the substrate for that shared state; neXus provides the semantic structure that makes the state verifiable.

## The Integration Hypothesis

Heterogeneous porting of neXus will expand gradually. Starting from a basic Wasm target, the compiler orchestrator will incrementally optimize and extend native compilation — ICP canisters being a primary target among edge nodes, portable devices, blockchain runtimes, and bare-metal system containers. The core crate already compiles to `wasm32-unknown-unknown` with zero platform-specific code in its core logic. Every platform dependency (storage, clock, networking) is abstracted behind Rust traits (`KeyValueStore`, `BlobStore`, `ObjectStore`, `Now`). ICP bindings would require implementing these same traits against ICP’s system API, with no modifications to the core.

![](icp_files/figure-html/fig-icp-integration-output-1.svg)

Figure 1: Hypothesized deployment of neXus as an ICP canister: the FIH Blackboard would become an on-chain knowledge graph, while agents execute as independent canisters communicating exclusively through FIH primitives.

### Storage Mapping: FIH Traits to ICP Primitives

neXus’s `CompositeColdStorage` orchestrates three abstract storage tiers. Each would map to ICP’s system API:

| neXus Storage Trait | ICP Primitive | Role |
|----|----|----|
| `KeyValueStore` | Stable Memory (`ic_cdk::storage`) | Recent Facts, Intents, Hints, flush cursor |
| `BlobStore` | Canister Stable Memory (bulk pages) | Flushed JSON-lines archives, snapshot blobs |
| `ObjectStore` (CAS) | `ic_cdk::api::stable::stable64_write` with CAS semantics | Atomic claim gating, ownership transfer, state coordination |
| `Now` | `ic_cdk::api::time()` | Monotonic timestamps for cursor advancement |

The `put_state(key, expected, new)` CAS primitive — the single coordination mechanism that gates all Intent claims in neXus — would map directly to ICP’s stable memory with no additional consensus overhead. ICP’s BFT layer already guarantees that only one canister’s write to a given memory location succeeds; neXus’s CAS semantics are a natural fit.

### Why Orthogonal Persistence Matters

ICP’s Orthogonal Persistence automatically persists canister memory to stable storage without explicit serialization. This aligns with the FIH Blackboard model: Facts are immutable once committed, Intents carry a provenance hash, and the entire state is a monotonic append-only log. No explicit checkpoint management or snapshot serialization would be needed — ICP would handle it transparently.

When a neXus canister is upgraded, ICP restores its stable memory before invoking the new Wasm module. neXus’s `from_snapshot_with_cold` factory function is designed for exactly this pattern: the hot graph (petgraph in-memory) would be restored from the snapshot, and the cold storage backend would be provided fresh with current ICP bindings. The canister upgrade cycle would become a seamless snapshot roundtrip.

## Differentiated Value: What neXus Would Add to ICP

ICP provides a general-purpose decentralized compute platform. neXus would provide a special-purpose verifiable computing engine. The hypothesized value neXus could add to the ICP ecosystem falls into three categories:

### Deterministic Verification Beyond Consensus

ICP’s canisters execute arbitrary code. Two canisters can compute different results from the same inputs, and ICP’s consensus will faithfully record both. neXus would add a layer above consensus: the Verifier exhaustively checks whether a claimed Fact is consistent with the accumulated knowledge graph, contract rules, and physical constraints. This is not a consensus problem — it is a verification problem, requiring the FIH graph structure and the homeomorphic verification layer that neXus provides.

A concrete example: the `ev` agent verifies silicon chip designs by checking all possible input combinations against the SSCCS Field Composition model. ICP’s consensus could confirm that `ev` ran and produced output X; neXus’s Verifier would confirm that output X is the only logically consistent output given the accumulated knowledge graph. The first is procedural trust; the second is semantic trust.

### C2PA-Anchored Provenance

Every neXus Fact carries a content-addressed hash (`FihHash`) computed from its fields and type tag. The chain F₁ → I₁ → F₂ → I₂ → F₃ forms a Merkle-like provenance tree that extends from the original document (SDBS source) through every hypothesis, simulation, and physical validation. ICP’s consensus would timestamp this chain, creating an on-chain, globally verifiable record of research provenance that any smart contract could reference.

This is distinct from what ICP natively offers. ICP provides execution provenance: “canister A called canister B at time T.” neXus would provide knowledge provenance: “Fact F₃ was derived from Facts F₁ and F₂ through Intent I₁, which was constrained by Hint H₁, and all three were validated against contract rules at revision R.” The former is an execution trace; the latter is a scientific audit trail.

### Lock-Free Agent Coordination via FIH Primitives

ICP’s actor model requires explicit message-passing between canisters. neXus replaces message-passing with stigmergy: agents read from and write to the shared FIH Blackboard, never addressing each other directly. Because Facts are immutable and Intents are claimed atomically via CAS, there are no locks, no deadlocks, and no coordination protocols between agents. The Blackboard is the sole coordination mechanism.

A consequence for ICP deployment: agent canisters could be upgraded, replaced, or scaled independently without affecting any other agent. A new version of the `ev` agent could begin claiming Intents alongside the old version; the CAS gate would ensure only one succeeds per Intent. The system would degrade gracefully under partial failure and recover without manual intervention.

## Implementation Roadmap

Heterogeneous porting begins from a basic Wasm compilation target and expands incrementally. The compiler orchestrator drives this expansion, optimizing each target in sequence. Within this framework, ICP integration decomposes into four phases, each producing a deployable artifact:

### Phase 1: Core Canister (ICP Trait Bindings)

Implement `KeyValueStore`, `BlobStore`, `ObjectStore`, and `Now` traits against ICP’s system API (`ic_cdk`). This requires:

- `KeyValueStore`: map to `ic_cdk::storage::stable` for recent entity buffer
- `BlobStore`: use stable memory pages for JSON-lines archive chunks
- `ObjectStore`: implement CAS via `ic_cdk::api::stable::stable64_read/write` with versioned keys
- `Now`: delegate to `ic_cdk::api::time()`

No core logic changes. The existing composite unit tests and integration tests serve as the acceptance criteria: when they pass against ICP bindings, the canister is functionally complete.

### Phase 2: Agent Canister Template

Package the agent lifecycle (submit Fact, claim Intent, heartbeat, conclude) into a reusable canister template. This template would compile any domain agent (ev, OpenROAD, robot controller) into a standalone ICP canister that communicates exclusively through the neXus Blackboard canister via FIH primitives.

### Phase 3: Cross-Canister FIH Protocol

Define the Candid interface for FIH operations between canisters:

``` candid
type FihHash = text;
type Fact = record { id: FihHash; origin: text; content: text; creator: text };
type Intent = record { id: FihHash; from_facts: vec text; description: text; creator: text };
type Hint = record { id: FihHash; content: text; creator: text };

service NexusBlackboard {
    submit_fact: (Fact) -> (variant { Ok; Err: text });
    submit_intent: (Intent) -> (variant { Ok; Err: text });
    claim_intent: (intent_id: FihHash, worker: text) -> (variant { Ok; Conflict; NotFound });
    heartbeat: (intent_id: FihHash) -> (variant { Ok; Err: text });
    conclude_intent: (intent_id: FihHash, result_fact: Fact) -> (variant { Ok; Err: text });
    read_state: () -> (BoardState) query;
    submit_hint: (Hint) -> (variant { Ok; Err: text });
}
```

This interface is a direct projection of the existing Rust `Blackboard` trait. Every method maps one-to-one to a Candid service method, with ICP handling serialization, authentication, and cross-canister invoication.

### Phase 4: On-Chain Governance

Deploy the `contract.nex` governance rules as an ICP canister that issues Hints to the neXus Blackboard. The governance canister would read accumulated Facts, evaluate them against contract rules, and emit Hints that constrain which Intents are admissible. This would close the loop: the protocol that governs research would itself be on-chain, auditable, and governed by token-weighted community voting.

## Risk Assessment and Mitigation

| Risk | Likelihood | Impact | Mitigation |
|----|----|----|----|
| ICP stable memory size limits per canister | Medium | Medium | CompositeColdStorage already partitions data across tiers; blob tier maps to stable memory pages with explicit size management |
| Canister upgrade cycle latency | Low | Low | neXus’s append-only model means no migration is needed; `from_snapshot_with_cold` restores state in a single pass |
| Cross-canister call cost for high-frequency FIH operations | Medium | Medium | Batch operations (submit multiple Facts per call); read_state is a query call with no cost |
| ICP subnet capacity for compute-intensive verification | Medium | High | Verification agents (ev) run as separate canisters on separate subnets; the Blackboard canister is lightweight |
| Governance canister upgrade complexity | Low | Medium | Contract rules are Hints, not code; governance logic changes by emitting new Hints, not by upgrading canister code |

## Strategic Alignment

This collaboration hypothesis is not a migration. neXus remains what it is becoming: a self-evolving, contract-governed agentic research infrastructure. ICP remains what it is: a decentralized World Computer. If realized, the integration would make both systems more valuable:

- For ICP: neXus could provide a verifiable truth layer that general-purpose canisters cannot natively offer. C2PA-signed Facts, exhaustive verification proofs, and the FIH provenance chain would be new primitive capabilities in the ICP ecosystem.
- For neXus: ICP could eliminate the last infrastructure dependency. No servers to provision, no databases to replicate, no consensus protocol to implement. A single `dfx deploy` command would distribute the FIH Blackboard across ICP’s global subnet.
- For both: The Wasm runtime is the common denominator. neXus targets `wasm32-unknown-unknown` as its primary compilation target — the same binary format ICP executes natively. The architectural fit is a direct consequence of both projects independently converging on the same substrate for decentralized agent computing.

## Next Steps

1.  Technical feasibility assessment: Compile the `nexus-graph` crate against the `wasm32-unknown-unknown` target with ICP’s `ic-cdk` as the platform binding layer. Measure binary size, stable memory consumption per Fact, and cross-canister call latency.
2.  Reference canister deployment: Deploy a minimal neXus Blackboard canister on the ICP mainnet with a Candid interface, serving as a public demonstration of the architecture.
3.  Agent canister ecosystem: Onboard existing SSCCS agents (ev, OpenROAD) as independent ICP canisters communicating through the neXus Blackboard, demonstrating the stigmergic coordination model at scale.