TheseusTheseus
Core Concepts

System Architecture

Three-layer architecture built for AI workloads: execution, storage, and consensus working as one system.

Architectural Overview

Theseus System Architecture

Three Main Processes

AIVM executes inference and forwards valid transactions; TheseusStore handles model/context data with DA sampling; HS BFT PoS provides HotStuff-based finality. All communicate via RPC/Networking layer.

Three-Layer Stack

Execution Layer: AIVM

Deterministic tensor-native runtime with Tensor Commits:

Tensor operationsAgent schedulingProof generationSHIP DSL

Availability Layer: TheseusStore

Erasure-coded storage for model weights and agent contexts:

Reed-Solomon encodingRAG contextsStorage minersMerkle roots

Consensus Layer: Proof of Stake

HotStuff BFT with AI-specific requirements:

Valid model rootsVRF selectionOne-block finalityCoupled layers

Block Structure

block.header
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 must be provably retrievable

TheseusStore Deep Dive

TheseusStore is the availability layer, handling gigabytes of model weights and agent context on-chain.

Model Storage

Immutable weights (Reed-Solomon encoded) addressed by content hash. Cold storage optimized, enforced by miner staking.

Context Storage

Mutable agent data (conversations, embeddings, RAG). Reed-Solomon encoded with faster retrieval.

Agent State Synchronization

Dual-ledger pattern:

On-Chain: Balances, model versions, config in agent state root
Off-Chain: Large context (PDFs, embeddings) in TheseusStore with memory anchors
Sync: libp2p diff-sync with last-write-wins + optional semantic merge

Prover and Verifier Selection

Provers

Run full forward passes. VRF selects by capacity + stake.

Publish hardware specs → Registry tracks → VRF filters (RAM ≥ model) → Cache popular models

Verifiers

All active verifiers check every inference.

Never download weights~2ms per check1K validators → 100 jobs <1s2/3 agreement for finality

Security Model

Theseus assumes a partially synchronous network with up to 1/3 byzantine validator stake. Within those bounds, three properties are protected by economic and cryptographic mechanisms working together.

Inference integrity

A dishonest prover producing a wrong inference result is caught by Tensor Commit verification: every active verifier rechecks every proof in roughly 2 ms. A faulty proof fails KZG pairing checks deterministically.

Slash condition: invalid Tensor Commit. Stake is burned, and the inference is rejected before the block can finalize.

Liveness

A request must reach an honest prover that can run the model. The protocol picks n candidates per request via VRF, weighted by stake and hardware capacity. The probability that at least one is honest is:

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

Where h is the honest fraction. With h = 0.67 and n = 10, liveness is >99.99% per request. With h = 0.33 worst-case and n = 10, >98%.

Data availability

Model weights and agent context must be retrievable for verifiers to check proofs and for agents to make progress. TheseusStore uses Reed-Solomon erasure coding so any sufficient quorum of storage miners can reconstruct missing shards.

Slash condition: storage miner failing to serve pinned shards. Recovery: any other miner holding the shard can re-pin and earn the lost reward.

Out of scope

Network-level censorship by a majority validator coalition, supply-chain attacks on model weight files before commitment, and attacks on the VRF beacon are out of scope of the consensus security model and are addressed by separate protocol layers and operational discipline.

Transaction Lifecycle

1

Model Deployment

Developer uploads weights (with Tensor Commit) to TheseusStore

2

Inference Transaction

User submits {modelRoot, input, maxGas} to AIVM

3

Block Proposal

Validator packages model and inference TXs with TheseusStore root

4

Execution & Proofing

AIVM runs the model and emits a Tensor Commit receipt

5

Finality

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

AIVM Details →

Deep dive into execution layer

Tensor Commits →

Learn about proof mechanisms

Documentation