Open Intelligence: a volunteer network for distributed AI research

1 Motivation

Recent work has shown that very large populations of language-model agents can make progress on hard technical problems when they are organised rather than merely multiplied. The most visible example is OpenAI’s reported Navier–Stokes effort of September 2026: roughly ten thousand concurrent agents in communicating groups, cross-pollinating intermediate results, followed by formalisation in Lean. That effort is an existence proof for the computation model, but it is an existence proof under one condition: a single organisation owned every machine, every model, every credential and every result.

Nobody has shown the same loop with independently owned, untrusted nodes and with problems chosen in the open. That is the gap Open Intelligence targets. Our working thesis is:

Structured collective intelligence — decomposition, exploration, cross-pollination, adversarial verification and adaptive allocation — produces more verified progress per token than the same budget spent on independent agents.

We treat this as a falsifiable bet, not a finding. The proposed test is simple to state: one task, a fixed token budget, and three conditions — one strong agent, N independent agents, and N agents coordinated by the network. If structure does not beat independence, that null result is still worth publishing, and we commit to doing so.

The attempt is timely for three reasons. The distributed plumbing — orchestration, sandboxing, volunteer-compute patterns — is mature, so effort can go to the epistemic part. Capable local models and bring-your-own-key economics let volunteers contribute real cognition without the network holding credentials. And objective verification tooling is usable today for mathematics and code, which is why those are the first domains.

The image we keep returning to is a research university without a building: each machine a small lab, no lab needing to know the whole solution, some exploring, some challenging, some verifying, and only the knowledge that survives scrutiny rising to a shared record.

2 Principles

The network is built on a short list of non-negotiable invariants. They are what make a population of untrusted, heterogeneous nodes that join and leave freely both safe and elastic. We group them as the design document does.

State and knowledge

• No shared mutable filesystem between nodes.
• Artifacts are immutable and content-addressed.
• Workers read versioned snapshots of knowledge.
• Workers publish events and results rather than mutating global state.
• PostgreSQL is the authoritative source of truth.

Task lifecycle and scheduling

• Tasks are leased, never permanently assigned.
• Heartbeats renew leases.
• Lease expiry causes automatic reassignment.

Execution semantics

• Task execution is at-least-once, not exactly-once.
• Duplicate results are legal and may be used for validation.
• Every execution has a unique attempt ID.

Workspaces and collaboration

• Subagents get separate local workspaces.
• Collaborative code editing uses branches or worktrees and a merge.

Membership and elasticity

• Node arrival and departure require no global synchronisation.

These rules reinforce one another. Immutable, content-addressed artifacts and a single authoritative store mean nodes never contend over shared mutable state. Leasing, heartbeats, at-least-once execution and attempt IDs make the network tolerant of a volunteer’s laptop closing mid-task. Treating duplicate results as validation turns redundancy from waste into a verification asset. And requiring no global synchronisation on join or leave is what lets the network grow from two nodes to many without the coordinator becoming a bottleneck. A sixth group, the execution boundary, is important enough to have its own section (§4).

Two further principles, carried over from the original design discussion, shape everything else. Governance consensus is not epistemic consensus: popularity may decide what to investigate, but never what is true. And verification uses classes, not majority vote: recalculation, tests, formal proof, artifact reruns, citation checking and, only where unavoidable, critic panels and humans. Counting votes among correlated models is not verification.

3 Architecture

The first version has a centralised control plane and decentralised compute. That is a deliberate choice: there is no blockchain, token or peer-to-peer layer until the epistemic core is proven. Peer-to-peer identity and federation are deferred, not rejected.

The coordinator as a thin ledger

The coordinator is a thin coordination ledger in PostgreSQL. It records facts, pointers and events — problems, work units, leases, attempts, results — and grows with the number of rows, not with the size of the work. Everything else is expressed as leased task kinds on one attempt protocol: solving, verifying, planning, snapshotting, and in code campaigns writing, integrating and rebasing. The coordinator’s own responsibilities are split into replicable roles (API, lease expiry, outbox, artifact service) so that none is inherently a single point of scale.

Leases, heartbeats and fencing

A node never owns a task; it holds a lease on it. Heartbeats renew the lease while work continues. When heartbeats stop, the lease expires and the work returns to the pool for another node. Every execution carries a unique attempt ID, and results are bound to the lease and attempt that produced them, so a node whose lease has lapsed cannot overwrite the work of its successor. In Phase A this was exercised end to end with multiple nodes, lease-expiry reassignment, fencing and coordinator restart.

Content-addressed artifacts

Inputs and outputs larger than a ledger row live in a content-addressed store. An artifact is named by its digest, is immutable once written, and can be fetched from any backend that holds it; storage backends are swappable without changing the protocol. A node can therefore check that it received exactly what was referenced.

Outbound-only transport

Nodes dial out over HTTPS to the public coordination endpoint and to artifact backends. Nothing listens on a volunteer’s machine; there is no inbound connection, no mesh and no node-to-node traffic. This removes NAT traversal as a problem and sharply limits what a compromised coordinator could reach.

Identity and admission classes

Each node holds an Ed25519 key pair generated locally; the private key never leaves the machine. A node joins by redeeming a single-use invite and receives a coordinator-signed contract, which it verifies against a trust root shipped with the client — the coordinator’s public key — rather than trusting on first use. Trust is not binary: every node sits in an admission class, starting untrusted and moving to probationary and then trusted through agreement with other nodes, performance on known-answer tasks and age (§5). Admission class bounds what work a node may lease and how much weight its results carry.

4 Execution boundary and safety

The single most important safety property of the network is about code, and it is precise about whose code.

The network never ships runnable code to a node. Task manifests, artifacts, leases and contracts are data, addressed by digest. A node executes nothing the coordinator or any peer sends. Problem submitters cannot supply arbitrary containers; tasks are manifests interpreted by a standard runtime the volunteer installed. We call this property no network-supplied code.

A node’s own model may write and run code — locally, in a sandbox. From Phase B, the language model a volunteer chooses, using the volunteer’s own key on the volunteer’s own machine, is a solver rather than a proposer of static answers: it may generate code and run it. That code runs only inside a per-attempt sandbox managed by the node’s harness, which must enforce no network, no host filesystem, no secrets in the environment (the model key and node identity stay in the daemon), CPU, memory, process and wall-clock limits, a non-root user with a read-only root filesystem and no capabilities, a pinned image, and one throwaway container per attempt. The sandbox’s output is parsed as schema-checked data and is never executed. Docker is the first isolation tier; gVisor and Firecracker are the tiers for when the network opens beyond invited nodes.

Only the checked, signed result leaves the node. Sandbox code, logs and state never cross the wire. The coordinator sees a lease go out and a signed result come back, and does not know whether a model was involved.

Two separate security problems

The design keeps two problems apart, because confusing them is the most common mistake in volunteer-compute security.

The sandbox protects the owner; verification protects the network. Running code in a sandbox does not make a result more trustworthy — whoever owns a machine can fake its output — so no sandbox, however strong, substitutes for verification.

Volunteers keep their own model credentials. The network never sends API keys to untrusted machines, and as a side effect it becomes a heterogeneous cluster of models, which we regard as a feature: model diversity reduces correlated failure.

5 Verification and the trust ladder

A result counts only after the network has checked it. Verification is organised by what can be checked, not by how many participants agree.

The first version restricts its claims to the domains where verification is objective — the upper rows of this table — and says so. Mathematics is the ideal target: a proof assistant returns true or false, not an opinion.

Verification happens twice. The node checks its own answer with the problem’s deterministic checker before it signs anything, which saves the network from wasted submissions. The coordinator then checks the signature and lease and re-verifies the result itself; the node’s self-check is a courtesy, not evidence.

Above individual results sits the trust ladder. A node starts untrusted, becomes probationary and then trusted on the strength of three signals: agreement with independent nodes on duplicated work, correct answers on known-answer (“gold”) tasks mixed invisibly into its workload, and age. The ladder is what will eventually let the network open beyond invited participants. Its parameters — gold-task rates, update rules, the consequences of failure — are not yet designed, and it is scheduled for Phase C. It complements verification and never replaces it: a trusted node’s result is still checked.

In the longer term, findings will live on a shared record with provenance, confidence and a lifecycle: proposed, replicated, disputed, verified, retracted. We expect that record and the merge gate of a self-extending codebase to be the same mechanism — claim, evidence, adversarial review, promotion — whether the payload is a lemma, a patch or a configuration change.

6 Problems and scoring

A problem is admitted to the network only if it comes with an objective verifier: a deterministic program that, given a candidate solution, says whether it is valid and how good it is. Without one, a result cannot be checked by an untrusted coordinator, and the problem is out of scope for this version.

The first campaign follows this rule closely. Phase A runs a graph k-colouring workload: nodes lease colouring tasks, solve them with a shipped deterministic handler, and return signed results that the coordinator checks. Phase B sharpens the objective. Because a standard greedy heuristic always produces a proper colouring, “proper” leaves no headroom; the target becomes a colouring that uses no more than the planted number of colours, as confirmed by the checker. A model-driven solver passes only if the checker says so.

Scores are published on a public leaderboard of verified results, attributed to the node that produced them. Every entry is a score the coordinator re-verified, not a score a node claimed.

Because execution is at-least-once, the same work may be done by several nodes. That is not waste. Duplicate results are legal, and independent nodes reaching the same answer is replication — the oldest validation technique in volunteer computing — and one of the inputs to the trust ladder. Content addressing makes agreement cheap to detect: identical outputs have identical digests.

7 Roadmap

Each phase must be useful on its own, even if the next never ships.

Phase A — compute harness (done)

A single installable package provides the coordinator, the node library and command-line client, and the k-colouring workload. Nodes connect with an invite and a trust root, lease work, run a shipped handler, and return Ed25519-signed results; Phase A uses no language-model tokens. Multi-node operation, fencing, lease-expiry reassignment and restart were verified on the coordinator host, and the public endpoint has been live since 2026-09-17. Phase A runs only trusted, shipped handlers and does not yet sandbox anything.

Phase B — the node’s own model as solver (designed)

Phase B adds the per-attempt sandbox supervisor described in §4 and an optional model adapter: a volunteer’s own model, with a key that never leaves the node, writes and runs solver code inside the sandbox, and only the checked, signed result is submitted. The coordinator is unchanged. The first experiment compares one node, two nodes, and two nodes with a model solver against the same checker-defined objective. A null result is a legitimate outcome.

Phase C — trust ladder (deferred)

Phase C introduces gold tasks, agreement-based promotion between admission classes, and reputation. It is the prerequisite for opening the network beyond invited nodes, and for stronger sandbox tiers. Further out, and conditional on the open problems below, are a shared findings record with adversarial review and, as the north star, bounded self-extension: the network working on its own harness, with verification standing in for the human merge gate only where data shows it is as good.

Deliberately not on the roadmap yet: a public voting interface, tokens or incentives, blockchain, peer-to-peer federation, domains beyond code and mathematics, and thousand-node scale.

8 Open questions

These are the problems that decide whether the thesis holds. Naming them precisely is part of the contribution; none is solved.

1. Knowledge poisoning and the validation protocol. One wrong finding promoted with high confidence is consumed by every downstream agent. How many independent replications are needed, and how independent must they be — different model families, different operators? Who reviews, chosen how? When a verified finding falls, what happens to everything derived from it? The same protocol would be the merge gate for self-extension, so if its poison rate cannot be bounded, self-extension stays off the table by design.
2. Verification outside formal domains. Mathematics has proof assistants and code has tests; a novel scientific hypothesis has no assertion to run. Model-as-judge is useful signal and unacceptable ground truth. Humans close the gap but are scarce, and a human-review layer with real throughput is undesigned. Until it exists, the network restricts its claims to verifiable domains.
3. Task decomposition. Everything downstream is bounded by how a raw problem is split into directions. Overlapping directions waste the network; badly sized ones defeat it. How to estimate the expected information gain of an unexplored branch, which any adaptive allocator needs, is itself open.
4. Cross-pollination topology. Share too much and the network converges prematurely; share too little and it duplicates effort. Round-based redistribution of the best findings is a starting heuristic, not an answer.
5. Sybil resistance and reputation. Invite-only operation sidesteps this; a public network cannot.
6. Governance and admission review. Voting eligibility, capture resistance, and a safety review that prevents the network being pointed at harmful workloads are obligations before any public launch.
7. Incentives. The first version runs on goodwill, as volunteer computing has before. What sustains contribution at scale is open, and we do not intend to answer it with a token.

Nothing aspirational in this document is presented as settled. The project’s credibility depends on keeping that separation.

References

1. Open Intelligence site repository. https://github.com/dkatsiros-dev/open-intelligence-site
2. Einstein Arena — related work on open problems with objective scoring. https://github.com/vinid/einstein-arena
3. BOINC — Berkeley Open Infrastructure for Network Computing; prior art for volunteer computing, work units and replication-based validation. https://boinc.berkeley.edu/
4. Folding@home — prior art for volunteer distributed computing in science. https://foldingathome.org/

← Back to open-intelligence.space