neXus on Cloudflare: Wasm-Native Infrastructure at the Edge

Author

Affiliation

SSCCS Foundation

Published

May 30, 2026

Abstract

neXus is a self‑evolving, contract‑governed agentic research infrastructure built on FIH (Fact/Intent/Hint) primitives, compiling to wasm32-unknown-unknown as its primary runtime target. Cloudflare Workers, Durable Objects, KV, and R2 provide the globally distributed, strongly consistent storage fabric that neXus requires for decentralized agent coordination. This document describes a completed architectural solution to the async‑sync boundary problem: the IoBuffer+StoreSession pattern, which keeps neXus’s deterministic core synchronous while wrapping it in an async bridge that hydrates from Cloudflare bindings, runs the computation, and flushes back within a single Worker request lifecycle, no block_on required. neXus is designed to deploy on Cloudflare Workers as a reference architecture for running verifiable agentic computation at the edge, with zero external infrastructure dependencies.

Repository

References

Other Formats

Executive Summary

The SSCCS Foundation is building neXus, a self‑evolving, contract‑governed agentic research infrastructure. neXus decomposes all computation into three primitive types: Fact (validated observation), Intent (proposed exploration), and Hint (constraint), forming a deterministic, auditable provenance tree that scales from a single process to a globally distributed agent fabric.

neXus compiles to wasm32-unknown-unknown as its primary compilation target. The storage layer is abstracted through pure‑sync Rust traits (KeyValueStore, BlobStore, ObjectStore). There is no async runtime dependency, no tokio, no async-std, no nightly Rust features. This creates a natural fit with Cloudflare Workers: Workers provide a Wasm execution environment with globally distributed KV, R2 object storage, and Durable Objects for strongly consistent coordination.

The core challenge was the async‑sync boundary: Workers run on a single‑threaded event loop where block_on is impossible. neXus recently completed an architectural solution to this problem: the IoBuffer+StoreSession pattern. It keeps the deterministic core synchronous while wrapping it in an async bridge that hydrates from Cloudflare bindings, runs the computation, and flushes back within a single Worker request lifecycle. The work is already production‑ready: 0 core files changed, 4 new files (iobuf.rs, store_session.rs, session_server.rs, session.rs in model), 30/30 existing tests pass plus 8 new IoBuffer session tests, full workspace CI passing.

neXus is designed to deploy entirely on Cloudflare Workers + KV + R2 + Durable Objects, with no external infrastructure. The platform credits and resources needed to complete the Cloudflare‑specific binding layer and maintain the public deployment are modest, and we are open to discussing which partnership or support model best fits.

Why Cloudflare

Cloudflare Workers + Durable Objects + KV + R2 provide the exact set of primitives neXus requires for a globally distributed FIH Blackboard. No other edge computing platform offers this combination of Wasm execution, strongly consistent coordination, and tiered storage across a single unified API surface.

neXus Requirement	Cloudflare Primitive
Wasm execution with no async runtime dependency	Workers (wasm32-unknown-unknown)
Globally distributed key-value storage	Workers KV
Content-addressed blob archival	R2 (S3-compatible object storage)
Strongly consistent atomic CAS	Durable Objects (single-threaded, strongly consistent)
Stigmergic agent coordination via shared state	Durable Objects as shared coordination namespace
Deterministic execution per request	Workers single-event-loop model
Upgradeable contract governance	Durable Object with stored state

The WASM runtime is the common denominator. neXus targets wasm32-unknown-unknown as its primary compilation target. This is the same binary format Workers execute natively. Every Cloudflare binding (KV namespace, R2 bucket, Durable Object stub) can be wrapped behind the same storage traits neXus already defines, requiring no changes to core logic.

From Cloudflare’s perspective, neXus represents a workload that is genuinely difficult to run elsewhere: it demands Wasm execution (not containers), strongly consistent CAS semantics across workers, and globally distributed tiered storage, all under a single API surface. These are capabilities that Cloudflare alone provides as a unified platform.

The Async-Sync Problem and How We Solved It

The Problem

Cloudflare Workers run on a single-threaded event loop. When a Worker receives a request, it must complete synchronously within the event handler or use await for I/O. The critical constraint: there is no block_on in WASM. A sync Rust library that needs to call async functions cannot simply block the thread and wait; there is no thread to block.

neXus’s core is pure synchronous Rust. The storage abstraction layer (CompositeColdStorage) orchestrates CAS operations across three storage tiers synchronously. Before the IoBuffer architecture, this core could not run inside a Worker without either:

Rewriting all storage traits to async fn in trait (AFIT), requiring nightly Rust and destabilizing the core.
Embedding a blocking async runtime in WASM, which is impossible in the Workers sandbox.
Moving the core out of the Worker entirely, defeating the purpose of edge deployment.

The Solution: IoBuffer + StoreSession

The solution introduces an in-production I/O buffer layer that proxies all storage operations as in-memory writes with dirty tracking, then flushes atomically to real storage after sync execution completes. The architecture requires 0 changes to the core storage traits. The foundation stays pure-sync Rust stable.

Figure 1: IoBuffer bridge architecture: the sync core (CompositeColdStorage) operates on in-memory IoBuffer proxies, which accumulate dirty entries. After sync execution, the async bridge drains dirty entries and flushes to Cloudflare bindings.

The lifecycle inside a Worker request handler proceeds as follows:

Create IoBufferSession: Instantiate an IoBufferSession backed by empty IoBufferKv, IoBufferBlob, and IoBufferObject instances. All three are in-memory HashMap with dirty-key tracking.
Hydrate from Cloudflare bindings: Call kv_buf().hydrate_batch(...) to populate the KV buffer from the Worker’s KV namespace (async KVNamespace.list() or get()), similarly for R2 blobs and Durable Object state. This is the only async step before execution.
Run sync core: Execute CompositeColdStorage operations (claim Intent, submit Fact, flush cursor, etc.) through the SessionExecute::storage() trait method. Every set(), put(), put_state() call writes to the in-memory buffer and marks the key as dirty. Every get(), get_state(), list() reads from the buffer. The CAS put_state(expected, new) operates entirely in memory.
Drain and flush: After sync execution completes, call drain_kv_puts(), drain_kv_deletes(), drain_blob_puts(), etc. to collect all dirty mutations. Flush these to Cloudflare bindings as async KVNamespace.put(), R2Bucket.put(), DurableObjectStub.fetch() calls. This is the final async step before returning the response.

Key Properties

No block_on, no async runtime in WASM: The sync core runs synchronously inside the Worker event handler. Async I/O is confined to hydrate and flush phases, both outside the sync core.
0 core files changed: The KeyValueStore, BlobStore, ObjectStore, and ColdStorage traits remain pure-sync. The IoBuffer trio implements these traits without modification.
Dirty-tracking is the bridge: Each IoBuffer tracks which keys were mutated. The drain phase produces only the delta, minimizing bandwidth and write cost to Cloudflare bindings.
Atomic flush is the caller’s responsibility: The IoBufferSession exposes the dirty delta; the Worker bridge layer decides whether to flush atomically (within a single DO stub call) or best-effort (KV+R2).
Thread-safe design: The IoBuffer types use Arc<RwLock<...>>, making them safe for SessionServer (sequential job queue) in native builds while remaining usable in WASM via manual process_one() drive.

Storage Mapping

neXus defines three core storage traits and one composite orchestrator. Each maps directly to a Cloudflare primitive.

KeyValueStore to Workers KV

KeyValueStore provides get, set, delete, and list operations on string-keyed string values. Workers KV provides exactly this API through KVNamespace.get(), .put(), .delete(), and .list(). KV’s global replication is ideal for Facts (immutable, widely read) and Hints (configuration-wide constraints).

BlobStore to R2

BlobStore provides put, get, delete, and list for arbitrary byte data. R2 provides S3-compatible object storage with put(), get(), delete(), and list(). R2 is the natural tier for archived Fact streams (JSON-lines snapshots), C2PA-signed provenance bundles, and cold storage of resolved Intent logs.

ObjectStore to Durable Object

ObjectStore provides CAS semantics through get_state(key) and put_state(key, expected, new). This is the only coordination primitive in neXus: all cross-worker Intent claims flow through this single atomic gate. Durable Objects provide the exact strongly consistent, single-threaded execution model needed: the DO stub is the final arbiter of each CAS operation.

CompositeColdStorage to DO + KV + R2 orchestration

CompositeColdStorage binds the three tiers together with a flush cursor, FIH persistence logic, and time-range queries. It maps naturally to a DO that holds the hot state (recent Facts, active Intents) in memory, backed by KV for warm data and R2 for cold archival.

Figure 2: neXus storage traits mapped to Cloudflare primitives. The CAS two-step (get_state, put_state) is the single cross-worker coordination mechanism, handled by Durable Objects.

Durable Object as Atomic Arbiter

The CAS two-step is the only cross-worker coordination primitive in neXus. Every Intent claim follows this sequence:

get_state("intent:{id}"): read current state from the ObjectStore
If state is "available", call put_state("intent:{id}", "available", worker_id): CAS write
If put_state returns true, the claim succeeded. If false, another worker claimed this Intent.

This maps naturally to Cloudflare Durable Objects. The DO provides:

Single-threaded execution: Only one request executes at a time within a DO. CAS contention serializes without additional locking.
Strong consistency: Every get_state reads the latest committed state. No eventual consistency window.
Stored state: The DO maintains the authoritative CAS namespace in memory. State persists across requests and survives DO migration.
Atomic flush gateway: When a Worker completes sync execution, it flushes the dirty ObjectStore delta to the DO via a single fetch() call. The DO applies all CAS operations atomically. If any CAS fails (race lost), the Worker learns which keys failed and can roll back locally.

The DO is thus the final arbiter of all Intent claims. Multiple Workers may attempt the same CAS simultaneously; only the winner survives; losers roll back their local IoBuffer state and retry or yield.

Technical Roadmap

Phase 1: Single-Worker IoBuffer Demonstration

Deploy a basic Worker that:

Hydrates an IoBufferSession from KV and R2 bindings.
Runs CompositeColdStorage operations (submit Fact, list Facts by prefix).
Drains dirty entries and flushes back to KV and R2.
Returns a JSON response with execution results.

Single-region, single-worker. Demonstrates the full hydrate-execute-flush lifecycle with no DO dependency.

Deliverable: A deployable Worker at workers/nexus-single/ with CI-verified hydrate and flush roundtrip. Metrics: roundtrip latency, KV read/write count per request, binary size.

Phase 2: DO-Based CAS Gating

Extend the Phase 1 Worker with a Durable Object that hosts the ObjectStore namespace for Intent claims.

Deploy a DO class (NexusCoordinatorDO) that stores CAS key-value pairs in its in-memory state.
The Worker creates a DO stub in its async bridge layer. Hydration reads get_state from the DO. Drain writes put_state to the DO.
Multiple Workers can connect through the same DO, demonstrating cross-Worker Intent claim arbitration.

Deliverable: Two Workers (or two instances of the same Worker) competing for the same Intent claim. Only one wins. CI test validates CAS correctness.

Phase 3: R2 Blob Archiving and Snapshot Persistence

Add the cold storage tier:

FlushCapable cursor advancement: after a flush, the Worker writes a JSON-lines archive of flushed Facts to R2.
Snapshot persistence: the DO periodically writes its hot state as a R2 object, enabling recovery after DO eviction.
Content-addressed CAS: blobs are keyed by their FihHash, providing content-addressable storage for immutable Fact data.

Deliverable: R2 archive of all Facts partitioned by flush window. from_snapshot_with_cold factory function that restores DO state from R2 snapshot.

Figure 3: Phase 3 architecture: Worker hydrates from KV/R2/DO, runs sync core, drains to KV/R2/DO. The DO is the CAS arbiter; R2 provides blob archival.

Phase 4: Multi-DO Sharding, Subnet-Aware Routing, and Contract Governance

Scale the architecture beyond a single DO:

Multi-DO sharding: Partition the CAS namespace across multiple DO instances by key hash (e.g., intent:{id} % N). The Worker bridges to the correct DO stub based on the partition key.
Subnet-aware routing: For Workers in the same DO colocation region, route to the nearest DO stub to minimize latency.
Contract governance as DO Worker: The contract.nex governance rules run as a standalone DO Worker that emits Hints to the Blackboard. The governance DO reads accumulated Facts, evaluates them against contract rules, and writes Hints that constrain which Intents are admissible.

Deliverable: A sharded DO cluster with configurable partition count. Governance DO that enforces contract rules on Intent admissibility. CI test validates cross-partition CAS consistency.

Value for Cloudflare

A Showcase Workload for the Workers Platform

neXus demonstrates that Cloudflare Workers can run a complete agentic research infrastructure with zero external dependencies: no VMs, no containers, no external databases. Everything runs on Workers + KV + R2 + DO. This is a compelling proof point for the Workers platform as a general-purpose compute substrate, not just a CDN or API gateway.

The FIH Blackboard model is a novel use case for Durable Objects: not just a coordination primitive for chat or multiplayer games, but a verifiable knowledge graph where every mutation is a CAS-gated, content-addressed, auditable fact. This pushes DO beyond its typical usage patterns and validates the platform for enterprise knowledge management, scientific research, and regulated data workflows.

The IoBuffer Pattern as General Technique

The IoBuffer+StoreSession pattern is a general solution for running deterministic sync code inside async WASM Workers. Any Rust library that compiles to wasm32-unknown-unknown and assumes synchronous I/O can adopt this pattern:

Proxy all I/O behind a trait (like KeyValueStore).
Implement an in-memory buffer that implements that trait with dirty tracking.
Run the sync library against the buffer.
Drain dirty entries and flush asynchronously.

This pattern applies to game engines running simulation ticks, database query engines evaluating read-only queries, compilers performing incremental compilation, and simulation frameworks running Monte Carlo steps. neXus provides the reference implementation, which we will document and publish openly.

KV + R2 + DO as Unified Storage Fabric

neXus validates the combined product story: KV for hot reads, DO for strongly consistent CAS, R2 for cold archival. All three are used together in a single request lifecycle. This is a reference architecture for any application that needs tiered storage with consistency guarantees. It is a pattern Cloudflare can cite as a documented best practice.

WASM Ecosystem Investment

neXus pushes wasm32-unknown-unknown to its limits. The core crate compiles with zero platform-specific code. The storage traits are pure-Rust traits with no FFI, no C dependencies, no platform intrinsics. Every new WASM capability Cloudflare adds (bulk memory, reference types, tail calls) directly benefits neXus’s performance.

Supporting neXus through a startup or open-source program validates the Workers platform for heavy computation: not just request-response handlers but verifiable agent systems that process Facts, run constraint satisfaction, and maintain provenance graphs. We will attribute the support that makes this deployment possible in all public communications.

Deployment Requirements

The SSCCS Foundation is a pre-incorporation, open-source research initiative operating with a solo founder and no institutional funding. The deployment footprint is modest:

Resource	Estimated Need	Purpose
Workers account	1 account	Phase 1-4 deployment across dev and production environments
Workers KV	2 namespaces, standard read/write limits	Fact and Hint persistence, globally distributed reads
R2	1 GB base storage + standard operations	Blob archival for JSON-lines Fact streams and snapshot persistence
Durable Objects	5 DO classes (1 per partition + 1 governance)	CAS namespace, Intent arbitration, contract governance

neXus is compute-light by design. The core execution loop processes in-memory HashMap operations in microseconds; the dominant cost is KV/R2 I/O during hydrate and flush phases. A single Worker can handle the full agent lifecycle with sub-100 ms roundtrip latency.

The project compiles and tests successfully against wasm32-unknown-unknown with simulated storage backends. The Cloudflare binding layer (wrapping KVNamespace, R2Bucket, and DurableObjectStub behind the existing storage traits) is the remaining implementation work. We will open-source all binding code, publish a technical blog post documenting the deployed architecture, and maintain the public deployment as a reference for the Workers platform.