nex-cf

Author

Affiliation

SSCCS Foundation

Published

June 4, 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 the Cloudflare‑specific deployment of the AsyncStorage bridge 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.

Code

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 three pure‑sync primitives (KV, Blob, Object) as described in the general storage architecture. 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 solved this with the AsyncStorage bridge 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, 30/30 existing tests pass plus 8 new AsyncStorage 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 orchestration layer manages CAS operations across three storage tiers synchronously. Before the AsyncStorage bridge, this core could not run inside a Worker without either:

Rewriting all storage interfaces to async, 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: AsyncStorage Bridge on Cloudflare

The AsyncStorage bridge pattern resolves this for any backend. In the Cloudflare deployment, the in-memory buffers proxy KV, R2, and Durable Object operations, then flush atomically after sync execution completes.

Figure 1: AsyncStorage bridge on Cloudflare: the sync core operates on in-memory buffers; async I/O confined to Cloudflare bindings during hydrate and flush phases.

The Cloudflare-specific lifecycle:

Create AsyncStorage session: In-memory buffers for KV, Blob, and Object primitives, each tracking dirty keys.
Hydrate from Cloudflare bindings: Populate the KV buffer from KVNamespace.get() / list(), Blob buffer from R2Bucket.get(), Object buffer from DurableObjectStub.fetch(). This is the only async step before execution.
Run sync core: Execute storage orchestration operations (claim Intent, submit Fact, flush cursor) against in-memory buffers. CAS compare-and-swap operates entirely in memory.
Drain and flush: Collect dirty mutations and flush to Cloudflare bindings: KVNamespace.put(), R2Bucket.put(), DurableObjectStub.fetch(). 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.
0 core files changed: The three storage primitives remain pure-sync. AsyncStorage buffers implement the same interfaces without modification.
Dirty-tracking minimizes I/O: Only mutated keys traverse the Cloudflare binding boundary.
Atomic flush via DO: The Object buffer’s dirty delta flushes through a single Durable Object fetch() call, applying all CAS operations atomically.

Storage Mapping

The three storage primitives map directly to Cloudflare products.

KV Storage to Workers KV

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

Blob Storage to R2

Blob Storage 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, C2PA-signed provenance bundles, and cold storage of resolved Intent logs.

Object Storage to Durable Object

Object Storage provides CAS semantics through read-state and compare-and-swap. 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 is the final arbiter of each CAS operation.

Storage Orchestration to DO + KV + R2

The storage orchestration layer binds the three tiers with a flush cursor, FIH persistence, 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 primitives mapped to Cloudflare products. The CAS two-step 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:

Read current state for an Intent key from Object Storage
If state is available, issue an atomic compare-and-swap: “if still available, replace with worker_id”
If the swap succeeds, the claim is won. If it fails, 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 AsyncStorage buffer state and retry or yield.

Technical Roadmap

Phase 1: Single-Worker AsyncStorage Demonstration

Deploy a basic Worker that:

Hydrates an AsyncStorage session from KV and R2 bindings.
Runs storage orchestration 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 Object Storage 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 current state from the DO. Drain writes compare-and-swap 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:

Flush 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 blobs: blobs are keyed by their content hash, providing content-addressable storage for immutable Fact data.

Deliverable: R2 archive of all Facts partitioned by flush window. Snapshot-based factory 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 AsyncStorage Bridge as General Technique

The AsyncStorage bridge 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 storage interface (KV, Blob, Object).
Implement an in-memory buffer with dirty tracking that satisfies the same interface.
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 primitives are pure interfaces 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 primitives) 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.