← Back to Docs

System Architecture

Theseus is built on a three-layer architecture designed specifically for AI workloads, combining execution, storage, and consensus in a unified system.

Three-Layer Stack

Execution Layer: AIVM

Deterministic, tensor-native execution of inference transactions via Tensor Commits. The AIVM handles:

  • • Matrix multiplication and tensor operations
  • • Agent scheduling and execution interface
  • • Proof generation and integration
  • • Natural language to bytecode translation (SHIP)

Availability Layer: TheseusStore

Chunked, erasure-coded storage and retrieval of immutable model weights and mutable agent contexts:

  • • Erasure-coded model weight storage with Reed-Solomon parity
  • • Mutable agent context management (RAG data, fine-tuning, etc.)
  • • Storage miner incentives for data availability
  • • On-chain model and context blob Merkle roots

Consensus Layer: Proof of Stake

Block ordering and state finalization with AI-specific enhancements:

  • • HotStuff-inspired BFT consensus
  • • Model-transaction coupling (blocks cannot finalize without valid model roots)
  • • VRF-based validator selection
  • • One-block finality under honest-majority stake

Block Structure

header {
parent_hash, height, timestamp
post-state Merkle root
Terkle tree of Tensor Commits
Merkle root of available model and context blobs
gas limit
VRF-selected validator signature
}
body { Transaction[] }

A block cannot finalize unless both conditions hold:

  • 1. Inference integrity: Every inference must include a valid Tensor Commit proof
  • 2. Agents availability: Every stored condition for inference (models, contexts) must be provably retrievable at the same height

TheseusStore Deep Dive

Theseus requires a native, first-class on-chain storage of model weights and agent context. TheseusStore is the Agent Availability Layer for Theseus, handling gigabytes of data per model.

Model Storage

Model weights are immutable and addressed through content hash. Storage process:

  • • Models are split into blobs with Reed-Solomon parity
  • • Storage is enforced by storage-miner staking
  • • Cold storage optimization (like AWS S3) - retrieval does not need to be extremely quick
  • • Tensor Commits require minimal liveness for secure inference

Context Storage

Agent contexts are mutable and need quick retrieval:

  • • Conversation transcripts, vector embeddings, policy checkpoints
  • • RAG databases and fine-tuning data
  • • Stored with Reed-Solomon encoding
  • • Context is updated frequently as agents develop

Agent State Synchronization

Agents use a dual-ledger pattern for state management:

On-Chain Checkpoints:

Critical variables (balances, last model versions, config flags) live directly inside the agent's state root

Off-Chain Memory Vault:

Bulky context data (PDFs, embeddings, RAG logs) stored in TheseusStore with periodic memory anchors

Diff-Sync Protocol:

Agents sync states over libp2p, keeping replicas consistent without global locks via last-write-wins plus optional semantic merge

Prover and Verifier Selection

Provers

Provers run the heavy work—full forward passes—and are selected via VRF lottery based on capacity:

  • • Provers publish hardware specs (240gb VRAM, 512gb SYSRAM, 25gbps bandwidth)
  • • Capacity Registry tracks declared resources on-chain
  • • VRF lottery filters by RAM ≥ model size, then stake-weighted selection
  • • Popular models kept in RAM proactively for frequent use

Verifiers

Every verifier in the active set verifies every single inference:

  • • Verifiers never download model weights
  • • Check time: ~2ms on modern CPU for proof verification
  • • 1,000 validators can confirm 100 simultaneous prover jobs in under 1 second
  • • 2/3 verifier agreement needed for consensus

Liveness Mathematics

With honest-stake fraction h and n eligible provers for a given model:

Pr(Liveness) = 1 - (1 - h)ⁿ

Even h = 0.33 and n = 10 gives ≥ 98% probability that at least one honest prover is chosen, ensuring high availability for inference requests.

Transaction Lifecycle

1. Model Deployment

Developer uploads weights (with model's Tensor Commit) to TheseusStore

2. Inference Transaction

User (human or agent) submits {modelRoot, input, maxGas} to AIVM

3. Block Proposal

Validator packages model and inference TXs and includes latest TheseusStore root

4. Execution & Proofing

AIVM runs the model and emits a Tensor Commit receipt

5. Finality

PoS finalizes the block; TheseusStore miners pin any new context/model shards

Inter-Process Interfaces

All three processes communicate over gRPC/libp2p channels. A common block header carries the state root, the model-set Merkle root, and batched AIVM/Tensor commit receipts, ensuring that execution, storage, and consensus stay cryptographically coupled.

This architecture ensures that agent logic remains stateful, verifiable, and decentralized—the three pillars enabling true AI sovereignty on Theseus.

AIVM Details →

Deep dive into the execution layer

Tensor Commits →

Learn about proof mechanisms