Nexus: Technical Overview of a Trust-Minimized Delegated Compute Network for AI Trading (Team Overview)

Disclosure:
This post is an informational technical overview written by the Nexus team. It is not investment advice, marketing material, or a solicitation. The goal is to explain the system architecture, trust model, and engineering decisions behind Nexus for a technically literate audience.

⸻

This post provides a technical overview of Nexus, a decentralized compute network designed to let users run AI trading agents (TOMO) without owning GPU-class hardware and without delegating private keys.

Nexus is not positioned as a generic “decentralized AI” product. It is a distributed systems + cryptography + crypto-economic protocol focused on verifiable delegated computation, explicit state machines, and bounded financial risk.

⸻

1. The Problem We Are Solving

Modern AI trading agents require:
• Continuous inference
• Low latency
• GPU-class compute
• High availability

Common approaches today:
• Centralized inference APIs → users must trust the provider
• Remote execution with key delegation → unacceptable security risk
• On-device inference → hardware constraints limit access

The specific question Nexus addresses is:

How can AI computation be delegated without delegating execution authority or private keys?

Our design answer is trade-intent separation:
• Nodes compute recommendations only
• Consumers verify and sign locally
• Execution always happens from the consumer’s wallet

This constraint is foundational and shapes the entire system.

⸻

1. System Architecture Overview

Nexus is structured into four layers:

Coordination
• Nexus Coordinator (Rust): session orchestration, node matching, billing

Compute
• Node Agent (Rust): runs TOMO inference, generates attestations

Client
• Client SDK (TypeScript): policy enforcement, verification, signing

Settlement
• Solana smart contracts: escrow, staking, slashing

The coordinator exists for orchestration, but cannot sign trades, forge computation, or move user funds. Trust is shifted to cryptographic verification and deterministic state transitions.

⸻

1. Architectural Foundations

Nexus is intentionally architecture-heavy. Correctness, auditability, and failure isolation are treated as security properties.

3.1 Reducers as the Core Primitive

All business logic is expressed as pure reducers:

(State, Event) → State

Reducers:
• Contain no IO, time, or randomness
• Are deterministic and replayable
• Can be property-tested

This allows:
• Full auditability from event logs
• Deterministic replay
• Elimination of hidden side effects

⸻

3.2 Explicit Finite State Machines (FSMs)

All lifecycles are modeled as explicit FSMs:
• Session FSM
• Node FSM
• Escrow FSM
• Staking FSM

States are closed sets and transitions are named events.
Failures are modeled explicitly rather than handled as exceptions.

Example (Session):
Idle → Matching → Connecting → Active → Settling → Completed
↘ Failed / Suspended

⸻

3.3 Algebraic Effects (Ports, Not Side Effects)

Domain logic describes effects rather than executing them directly.

Examples:
• SendToNode
• SaveSession
• ReleaseEscrow
• SlashStake
• EmitMetric

This separation enables:
• Deterministic simulation
• Replay and chaos testing
• Multiple interpreters (production, test, simulation)

This pattern is common in safety-critical distributed systems but rare in crypto infrastructure.

⸻

1. Session Lifecycle

A session is a bounded interaction between:
• One consumer
• One node
• One TOMO instance

Flow
1. Consumer deposits GNN into escrow
2. Coordinator matches a node
3. Node performs inference
4. Node returns recommendation + attestation
5. Consumer verifies and signs trade intent locally
6. Session settles
7. Escrow releases funds

At no point does a node:
• Access private keys
• Execute transactions
• Control user capital

⸻

Bounded Risk Model

Each session enforces:
• Maximum budget
• Maximum trade size
• Confidence thresholds
• Timeouts

Worst-case loss is strictly limited to the escrowed amount.

⸻

1. Attestation Protocol

Every inference produces a signed attestation binding:
• Model hash
• Input hash
• Output hash
• Node identity
• Timestamp

Consumers verify attestations locally before signing any trade intent.

This prevents:
• Model swapping
• Prompt tampering
• Output manipulation
• Replay attacks
• Coordinator forgery

Future research areas (explicitly acknowledged as non-trivial) include streaming attestations, TEE integration, and partial zk-verification.

⸻

1. Economic Model

Token Flow
• Consumers pay in GNN
• Providers earn GNN
• Protocol retains a fixed share (~30%)
• Providers receive the remainder (~70%)
• Unused escrow is refunded

There are no inflationary emissions tied to node operation; usage drives demand.

⸻

Provider Incentives

Node selection and rewards factor in:
• Uptime
• Latency
• Session completion rate
• Consumer ratings
• Attestation accuracy
• Stake size and duration

Misbehavior results in:
• Reputation degradation
• Slashing
• Potential bans

This model is closer to cloud infrastructure economics than yield-based DeFi systems.

⸻

Slashing

Slashing is evidence-based and requires:
• Invalid attestations
• Proven protocol violations
• Cryptographic fraud proofs

It is not based on discretionary governance votes.

⸻

1. Progressive Trust & Automation

Automation increases with demonstrated trust:

Tier 0 – New users → manual approval
Tier 1 – Verified → limited automation
Tier 2 – Trusted → expanded automation
Tier 3 – Power users → full automation within policy

Trust is behavior-based and reversible.

⸻

1. Coordinator Trust Boundaries

The coordinator:
• Matches nodes
• Routes messages
• Computes billing

It cannot:
• Sign trades
• Forge attestations
• Move funds
• Bypass policy enforcement

All coordinator actions are replayable from logs.

⸻

1. Failure Handling & Self-Healing

Failures are expected and explicitly modeled.

Built-in controls:
• Circuit breakers
• Rate limiting
• Deadline propagation
• Backpressure everywhere
• No unbounded queues

Self-healing rules can restart actors, reduce load, switch nodes, or escalate alerts.

⸻

1. Testing Philosophy

Testing includes:
• Property-based reducer tests
• Deterministic replay tests
• Chaos simulations
• Fault injection
• Deterministic clocks

This approach is closer to distributed databases and safety-critical systems than typical crypto projects.

⸻

1. What Nexus Is Not
   • Not a generic GPU rental network
   • Not trustless execution of capital
   • Not zkML hype
   • Not permissionless inference correctness

Nexus is a verifiable recommendation network, not an execution engine.

⸻

1. Explicit Limitations

We explicitly acknowledge:
• LLM inference cannot be proven correct today
• zk-proofs for large models are impractical
• A coordinator layer exists
• Attestations prove what ran, not optimality

⸻

Closing Note

This post is intended to inform and invite technical scrutiny.
We welcome questions, criticism, and discussion from engineers and researchers.

If there is interest, we can follow up with:
• A threat-model deep dive
• Attack-surface analysis
• Comparisons vs other compute networks
• More detailed protocol specs

Thanks for reading.