# nex-icp

Platform Integration Guide and Ecosystem Deployment Strategy

Author

Affiliation

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

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

Published

June 4, 2026

Abstract

neXus delivers a Wasm-native, decentralized agent computing system built on FIH (Fact / Intent / Hint) primitives. By deploying neXus on the Internet Computer Protocol (ICP), the platform provides a globally distributed, cryptographically auditable execution fabric. This document defines the integration architecture, mapping neXus’s verifiable truth engine to ICP’s native Wasm execution and orthogonal persistence, enabling seamless scaling from edge devices to planetary compute without architectural redesign.

Code

[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/projects/nexus/apps/icp.llms.md)

## Architectural Alignment

Both neXus and ICP are engineered around the Wasm substrate, rejecting legacy x86 VMs and multi-gigabyte container runtimes in favor of lightweight, portable, and deterministic execution. neXus provides the semantic structure (the FIH Blackboard) that makes ICP’s general-purpose state verifiable, auditable, and purpose-built for autonomous agent coordination.

| Dimension | ICP (Internet Computer) | neXus Platform |
|----|----|----|
| 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 |

The integration pattern is established: a lightweight Wasm runtime hosts autonomous agents that coordinate exclusively through a shared state space. ICP provides the distributed infrastructure layer; neXus provides the verifiable semantic layer.

## Integration Architecture

The neXus core is designed for heterogeneous compilation, targeting `wasm32-unknown-unknown` with zero platform-specific logic in its core engine. All platform dependencies (storage, time, networking) are abstracted behind Rust traits (`KeyValueStore`, `BlobStore`, `ObjectStore`, `Now`). Deploying on ICP requires implementing these traits against the `ic_cdk` API, leaving the core deterministic logic entirely unmodified.

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

Figure 1: neXus deployment on ICP: The FIH Blackboard operates as an on-chain knowledge graph, while domain 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, mapped directly to ICP system primitives for optimal performance and cost:

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

The `put_state(key, expected, new)` Compare-And-Swap (CAS) primitive, which gates all Intent claims in neXus, maps natively to ICP’s stable memory operations. ICP’s BFT layer inherently guarantees that only one canister’s write to a given memory location succeeds per cycle, making neXus’s CAS semantics a direct, overhead-free fit.

### Orthogonal Persistence Alignment

ICP’s native orthogonal persistence automatically persists canister memory to stable storage without explicit serialization. This perfectly aligns with the FIH Blackboard’s append-only, immutable state model.

During a canister upgrade, ICP restores stable memory before invoking the new Wasm module. neXus’s `from_snapshot_with_cold` factory function is explicitly designed for this pattern: the hot graph (in-memory `petgraph`) is restored from the snapshot, and the cold storage backend is re-initialized with current ICP bindings. The upgrade cycle functions as a seamless, zero-downtime snapshot roundtrip.

## Platform Capabilities & Ecosystem Value

Deploying neXus on ICP introduces specialized verifiable computing capabilities to the ecosystem, extending beyond general-purpose execution:

### 1. Deterministic Verification Beyond Consensus

ICP’s consensus guarantees that a canister executed code and produced an output. neXus adds a semantic verification layer: the Verifier exhaustively checks whether a claimed Fact is logically consistent with the accumulated knowledge graph, contract rules, and physical constraints. *Example:* The `ev` agent verifies silicon chip designs. ICP consensus proves `ev` ran; neXus Verifier proves the output is the *only* logically consistent result given the SSCCS Field Composition model. This shifts trust from procedural execution to semantic correctness.

### 2. C2PA-Anchored Knowledge Provenance

Every neXus Fact carries a content-addressed hash (`FihHash`). The chain F₁ → I₁ → F₂ → I₃ forms a Merkle-like provenance tree extending from source documents through every simulation and physical validation. ICP timestamps this chain, creating a globally verifiable, on-chain scientific audit trail. While ICP natively provides *execution provenance* (“Canister A called B at time T”), neXus provides *knowledge provenance* (“Fact F₃ was derived from F₁ and F₂ under Hint H₁, validated at revision R”).

### 3. Lock-Free Agent Coordination via Stigmergy

ICP’s actor model relies on explicit message-passing between canisters. neXus replaces this 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, the architecture eliminates locks, deadlocks, and complex coordination protocols. Agent canisters can be upgraded, replaced, or scaled independently; the CAS gate ensures graceful degradation and conflict resolution without manual intervention.

## Deployment Roadmap

The integration is executed in four sequential phases, each producing a deployable, testable artifact:

### Phase 1: Core Canister Bindings

Implement neXus storage and time traits against ICP’s `ic_cdk` API:

- Map `KeyValueStore` to `ic_cdk::storage::stable`.
- Map `BlobStore` to stable memory pages for archive chunks.
- Implement CAS via `ic_cdk::api::stable::stable64_read/write` with versioned keys.
- Delegate `Now` to `ic_cdk::api::time()`. *Acceptance Criteria:* Existing composite unit and integration tests pass against ICP bindings with zero core logic modifications.

### Phase 2: Agent Canister Templates

Package the standard neXus agent lifecycle (`submit` → `claim` → `heartbeat` → `conclude`) into a reusable ICP canister template. This enables any domain agent (e.g., `ev`, OpenROAD, robot controllers) to compile into a standalone canister that communicates exclusively via the neXus Blackboard.

### Phase 3: Cross-Canister FIH Protocol

Define and publish the Candid interface for FIH operations, ensuring strict type safety across canister boundaries:

``` 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 });
}
```

### Phase 4: On-Chain Governance

Deploy the `contract.nex` governance rules as a dedicated ICP canister. This canister evaluates accumulated Facts against contract rules and emits `Hint` records to constrain admissible Intents, closing the loop with a transparent, token-weighted, on-chain governance model.

## Operational Considerations & Mitigation

| Operational Consideration | Scope | Platform Design Resolution |
|----|----|----|
| ICP stable memory size limits per canister | Medium | `CompositeColdStorage` inherently partitions data; the blob tier maps to stable memory pages with explicit, bounded size management. |
| Canister upgrade cycle latency | Low | The append-only FIH model requires no data migration. `from_snapshot_with_cold` restores state in a single, deterministic pass. |
| Cross-canister call cost for high-frequency FIH ops | Medium | Platform design mandates batched operations (e.g., submitting multiple Facts per call). `read_state` is implemented as a free query call. |
| Subnet capacity for compute-intensive verification | Medium | Verification agents (e.g., `ev`) are deployed as separate canisters on dedicated subnets. The central Blackboard canister remains lightweight and I/O-bound. |
| Governance canister upgrade complexity | Low | Contract rules are expressed as `Hint` data, not hardcoded logic. Governance evolves by emitting new Hints, bypassing the need for canister code upgrades. |

## Strategic Execution & Next Steps

This integration establishes neXus as the verifiable compute layer for the ICP ecosystem, eliminating external infrastructure dependencies (servers, replicated databases, custom consensus). A single `dfx deploy` distributes the FIH Blackboard across ICP’s global subnet.

Execution proceeds as follows:

1.  **Core Benchmarking:** Compile the `nexus-graph` crate against `wasm32-unknown-unknown` with `ic-cdk` bindings. Measure binary size, stable memory consumption per Fact, and cross-canister latency.
2.  **Reference Deployment:** Deploy a minimal neXus Blackboard canister on the ICP mainnet with the published Candid interface, serving as the canonical reference implementation.
3.  **Ecosystem Onboarding:** Migrate existing SSCCS agents (`ev`, OpenROAD) to operate as independent ICP canisters, demonstrating stigmergic, lock-free coordination at scale.