# Proof by Structure

Atomic exchange, oracle resolution, and the self-verifying simulation loop

Author

Affiliation

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

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

Published

May 30, 2026

Abstract

neXus is a permission-less ecosystem: anyone may fork the code, build a tool, and participate. This openness creates a structural risk — participants who consume the shared knowledge graph without contributing degrade the commons. This document defines the exchange contract that makes freeloading physically impossible: accessing a Fact on the Blackboard requires providing a Fact in return, enforced at the function-call level. It also addresses the oracle problem — linking digital Facts to physical reality — through execution-as-proof rather than social consensus, and positions nexus-sim as the self-verifying loop that validates the entire system.

Reference

[Simulation](sim.llms.md)

[Architecture](impl_init.llms.md)

Repository

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

Other Formats

[LLMs](https://docs.ssccs.org/projects/nexus/proof.llms.md)

## The Structural Risk

neXus is a permission-less ecosystem. Anyone may fork the source, build a tool, register as a peer on the Blackboard, and participate. This openness is by design — the SSCCS model explicitly enables external parties to build commercial projects on its concepts and open-source tools.

But there is a structural asymmetry: the Blackboard’s value grows with every contributed Fact. A participant who reads without writing consumes this value without replenishing it. Over time, the commons degrades. In a permission-less system, there is no central authority to ban freeloaders.

The conventional answer is reputation systems, access tokens, or governance voting. All depend on social consensus — a human judgment about who is “trustworthy.” We require a structural answer: one where violation is impossible at the code level, before any social process can be invoked.

### The Open Ecosystem Threat Model

This openness creates three distinct threat vectors, each mapping to a FIH primitive that can be abused:

| Threat | Description | FIH Exploit |
|:---|:---|:---|
| **Free-Riding** | Entity A queries the Blackboard for Entity B’s verification results without contributing its own | Reading `Fact` without writing `Fact` |
| **Data Poisoning** | Entity A injects deliberately falsified observations to degrade the knowledge graph | Writing invalid `Fact` |
| **Governance Collapse** | Entity A exploits open `Intent` / `Hint` posting to overwhelm or misdirect the system | Spamming `Intent` / `Hint` |

## The Exchange Contract

### Principle: Read Requires Write

The Blackboard exposes a single function for Fact access. It is not a query. It is an exchange.

``` text
Exchange(session_token, query_spec) → Result<Vec<Fact>>
│
├── 1. query_spec.provided_data is committed as Fact(s) to the Blackboard
├── 2. The write is confirmed (Fact ID returned)
└── 3. Only then: search results are returned
```

The ordering is enforced by the function body. There is no branch, no fallback, no optional parameter that skips the write. A caller who provides empty data produces an empty Fact — valid, but valueless to them, and still costly (signing, storage, Merkle chain extension).

``` rust
fn exchange_fact(query: &QueryIntent) -> Result<Vec<Fact>, Error> {
    // Step 1: commit the requester's data — always first
    self.commit(query.provided_data())?;
    // Step 2: return search results — only after commit succeeds
    self.search(query.search_terms())
}
```

The order is non-negotiable. There is no separate read path. There is no way to query without first committing data. The function is the only entry point to the Blackboard’s Fact store.

### Why the Contract Targets Facts Only

- **Fact**: Exchange contract applies. Facts are the Blackboard’s only durable assets. Access requires contribution.
- **Intent**: Exchange contract does not apply. Intents are exploration proposals. Permitting unrestricted Intent submission keeps the system active. An Intent with no value is simply unclaimed.
- **Hint**: Exchange contract does not apply. Hints are derived patterns — products of previously exchanged Facts. Access is gated at the source, not at the derivative.

This minimal scope — only Facts — keeps the system simple. Intents and Hints flow freely. Only the permanent record is gated.

### Violation Is Structurally Impossible

![](proof_files/figure-html/fig-exchange-flow-output-1.svg)

Figure 1: The exchange function: write must complete before read returns.

Compare the two designs:

| Design | Violation Possible? | Why |
|----|:--:|----|
| Separate `read_fact(id)` and `write_fact(fact)` | Yes | Caller can call `read_fact` without ever calling `write_fact`. The compiler allows it. |
| Single `exchange(query)` where write is first | No | There is no `read_fact`. Access is only through `exchange`. Write executes first, always. |

### Game-Theoretic Effect

The exchange contract restructures the commons. A participant who wants to read N Facts must contribute at least one Fact. The quality and relevance of that Fact determines the value of their contribution — low-value Facts are valid, but provide no competitive advantage over peers who contribute high-value Facts.

This is not a social norm enforced by community pressure. It is a structural property enforced by the code. A peer that attempts to avoid contribution has no path to the Blackboard. There is no account to ban, no token to revoke, no vote to lose — there is simply no function they can call.

## The Oracle Problem

### The Industry’s Unsolved Challenge

Every blockchain project confronts the same fundamental problem: how to trust that off-chain data fed into an on-chain system is accurate. Whether the data represents a stock price, a sensor reading, or a property title, the entity that bridges the physical world and the digital record is a trust bottleneck.

| Approach | Mechanism | Weakness |
|----|----|----|
| Chainlink (majority oracle) | Multiple nodes report; median is trusted | Assumes most nodes are honest — a social, not structural, guarantee |
| TEE / enclave-based (Secret, Phala) | Hardware attests that computation was faithful | Trusts the hardware manufacturer; the sensor feeding TEE remains unverified |
| ZK-based (RISC Zero, Succinct) | Cryptographic proof of computation correctness | Proves the *computation* but not the *input*; the data source is still trusted |

Every approach ultimately relies on a trusted party at the boundary where physical reality meets digital record. The oracle problem is the unverified seam.

### SSCCS Resolution: Execution as Proof

neXus does not solve the oracle problem by finding a better oracle. It dissolves the problem by making the seam itself the proof.

A Fact produced in neXus is not a statement about reality that requires verification. It is the cryptographic trace of an execution that has already occurred. The observer who performed the scan, the simulation, or the measurement signs the Fact with their key. This signature is not a claim of accuracy — it is an irreversible record of the act itself.

``` text
Traditional oracle:  Trusted Source → Data → Smart Contract
                                 ↑
                          The seam: did the source lie?

neXus oracle:         Observer executes → Signs Fact → Blackboard
                            ↑
                     The seam is the signature.
                     No trust needed: the act is the record.
```

### Three Axes Linking Fact to Reality

A single Fact embeds three orthogonal axes, removing the need for any external verification at the boundary:

| Axis | Question | Fact Field | Proof |
|----|----|----|----|
| **Space** | Where and when did this occur? | `content.geo`, `content.timestamp` | Physical impossibility: an observer cannot be in two places at once; the signature timestamps the observation |
| **Ownership** | Whose asset does this concern? | `origin.asset_id` (on-chain ownership token) | Cryptographic: the asset token is a verifiable digital title; the Fact references it, linking observation to legal ownership |
| **Execution** | Who produced this record? | `creator`, `pubkey`, `signature` | Cryptographic: the observer’s private key produced the signature; non-repudiation is mathematically guaranteed |

These axes are not external proofs attached to the Fact. They are embedded in the Fact structure itself. A Fact without a valid asset reference, without spatial coordinates, or without a verifiable signature cannot be committed — the `exchange` function rejects it before completion.

### What This Does Not Require

- No trusted oracle node
- No majority consensus
- No hardware enclave
- No social reputation system

The only requirement is that the observer signs their work. The signature creates a liability trace. An observer who signs false data has produced a permanent, cryptographically attributable record of their falsehood. This is not a trust guarantee — it is a deterrence guarantee.

## nexus-sim: The Self-Verifying Loop

### Why Simulation Matters

The exchange contract and the oracle resolution are, at this stage, architectural claims. They are specified in code interfaces, not validated against adversarial scenarios. A participant determined to exploit the system will not respect architectural claims — they will test every boundary.

nexus-sim exists to test every boundary before any adversary does.

### Simulation Architecture

| Component | Role |
|:---|:---|
| **Agent Model** | Each agent is parameterized with strategies: honest, free-rider, poisoner, spammer, Sybil |
| **Exchange Function** | The `exchange_fact` implementation under test |
| **Blackboard State** | Full FIH state machine tracked across all simulation steps |
| **Scenario Generator** | Exhaustively enumerates all agent strategy combinations and interaction orders |

### Exhaustive Scenario Generation

nexus-sim takes the FIH specification — the contract, the exchange function, the Fact schema — and generates every structurally valid scenario:

![](proof_files/figure-html/fig-nexus-sim-output-1.svg)

Figure 2: nexus-sim: test scenarios → deterministic execution → verified Facts

| Scenario Class | Count | Purpose |
|----|----|----|
| Valid normal operation | Many | Confirms the exchange contract functions correctly |
| Valid edge cases (empty data, large data, duplicate hashes) | Many | Confirms boundary handling |
| Violation attempts (read without write, forged asset IDs, missing signatures) | All structurally possible | Confirms violation is impossible |

### Attack Scenarios Under Test

| Scenario | Strategy | Expected Outcome (Violation-Proof) |
|:---|:---|:---|
| **Direct Free-Riding** | Agent calls `read_fact()` — if such function existed | **Blocked**: No `read_fact` function exists in the API |
| **Evasive Free-Riding** | Agent calls `exchange_fact()` with empty or null data | **Blocked**: Commit fails validation; no results returned |
| **Falsified Contribution** | Agent provides synthetically invalid data to satisfy exchange | **Blocked**: Data fails structural validation (schema, signature) |
| **Poison Injection** | Agent attempts to inject deliberately corrupted observation | **Blocked**: C2PA signature verification fails; `Fact` rejected |
| **Intent Spam** | Agent floods the Blackboard with fake `Intent` blocks | **Tolerated**: `Intent` posting is open; `Hint` governance throttles spam |
| **Replay Attack** | Agent replays a valid signed `Fact` from another entity | **Blocked**: `Fact` ID already committed; duplicate rejected by Merkle chain |
| **Sybil Attack** | Agent creates multiple identities to circumvent contribution limits | **Rate-Limited**: `Exchange` requires computation (signing, Merkle extension), making mass Sybil economically infeasible |

The output of each simulation run is a Fact. The collection of all simulation Facts forms a cryptographic proof: the implementation, executed across the entire scenario space, produced no violations.

### Simulation Output

nexus-sim produces a violation matrix, a C2PA-signed proof artifact, and Hint generation rules from each exhaustive run. The complete output format and interpretation is in [Simulation](sim.llms.md).

### The Proof Is the Loop

``` text
Specification → nexus-sim → Exhaustive Facts → Verification → Specification
      ↑                                                          │
      └────────────────── validated ─────────────────────────────┘
```

This is not a test suite that checks for regressions. It is a self-verifying loop where the test execution itself generates the proof. Every scenario that passes is a Fact attesting to a property of the implementation. The aggregate of all scenario Facts is a proof that the implementation satisfies the contract.

When the specification changes, nexus-sim regenerates the scenario space and re-executes. The new Facts either confirm the changes or reveal violations. There is no separate verification phase — implementation and verification are the same loop.

## Ecosystem Implications

### Game-Theoretic Equilibrium

nexus-sim proves that the atomic exchange mechanism converges to a cooperative equilibrium:

- **Honest entities** gain access to the collective knowledge graph proportional to their contribution — the more verified observations deposited, the richer the queries
- **Free-riding entities** achieve zero knowledge extraction — the mechanism structurally prevents reading without writing
- **Malicious entities** are cryptographically excluded — C2PA signature verification ensures every committed `Fact` is traceable to an accountable creator
- **The optimal strategy is cooperation** — the only path to accessing the Blackboard’s knowledge is to contribute verified data

This equilibrium holds not because entities are trustworthy, but because the mechanism makes trust unnecessary.

### The Nautilus Principle

The atomic exchange principle extends beyond the Blackboard. Every agent in the SSCCS ecosystem — verification engines, synthesis tools, editor interfaces, and future domain-specific tools — operates under the same structural constraint: **to receive knowledge, you must deposit knowledge.**

The ecosystem does not negotiate with free-riders. It does not punish them. It makes their existence structurally impossible. The defense is not a barrier to be breached; it is a physical law to be obeyed.

### Permission-less Entry, Contribution-Mandatory Access

The SSCCS ecosystem is designed to be forkable. Anyone may:

- Clone the neXus source
- Build a commercial tool
- Run their own Blackboard instance
- Register as a peer

But access to *this* Blackboard — the shared knowledge graph that compounds across all participants — requires contribution. The exchange contract enforces this at the structural level, not through a policy layer.

### Why This Matters for Open Source

Open-source projects traditionally face two existential risks:

| Risk | Conventional Defense | neXus Defense |
|----|----|----|
| **Freeloading** | License restrictions (AGPL, BSL), contributor agreements | Exchange contract: access requires contribution; no legal enforcement needed |
| **Fragmentation** | Strong governance, BDFL model, foundation control | FIH graph is the integration surface; every instance contributes to and reads from the same graph |
| **Quality degradation** | Code review, CI, maintainer burnout | nexus-sim: exhaustive scenario testing generates its own proof of correctness |

The exchange contract converts the open-source risk of freeloading into a game-theoretic equilibrium. Contributing is not charitable — it is the only way to participate.

### Status

| Component | Status |
|----|----|
| Exchange contract specification | Draft (this document) |
| `exchange()` function implementation | Future (requires `nexus-core` Phase 2) |
| Fact schema with geo/asset/signature axes | Draft |
| nexus-sim scenario generation | Future (issue \#69) |
| nexus-sim deterministic execution | Future |
| nexus-sim proof aggregation | Future |

The exchange contract and oracle resolution are architectural specifications. nexus-sim (#69) provides the implementation-verification loop that validates them.

------------------------------------------------------------------------

### References

- neXus issue [\#69](https://github.com/ssccsorg/nexus/issues/69) — Nexus-SIM: virtual emulation test suite
- neXus issue [\#7](https://github.com/ssccsorg/nexus/issues/7) — FIH Blackboard core
- neXus issue [\#3](https://github.com/ssccsorg/nexus/issues/3) — Blackboard infrastructure
- [neXus architecture and implementation roadmap](impl_init.llms.md)
- [ExaVerif project (verification engine as neXus instance)](../ev/index.llms.md)