> For the complete documentation index, see [llms.txt](https://esper.gitbook.io/esperchain-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://esper.gitbook.io/esperchain-docs/architecture/proof-of-ai-consensus.md).

# Proof-of-AI Consensus

Artificial intelligence is fundamentally transforming how humans communicate and act, ushering in an agentic future where people increasingly outsource daily tasks to intelligent agents. This shift is already evident with ChatGPT serving as personal therapy coaches and life organizers, demonstrating the growing integration of AI into intimate aspects of human experience.

As **agents become ubiquitous** across all domains of digital interaction, blockchain operations will inevitably follow this pattern. Crypto agents will autonomously discover yield farming opportunities, execute cross-chain bridges, conduct trades, and perform complex DeFi strategies on behalf of users. This represents a fundamental shift from manual cryptocurrency management to intelligent, automated blockchain interaction.

However, current blockchain architectures present significant challenges for this agentic future. Existing blockchains were designed primarily for manual, transaction-centric workflows rather than the continuous, intelligent operations that AI agents require. Additionally, these systems rely on **wasteful proof-of-work** consensus mechanisms or **capital-intensive proof-of-stake** models that may not align with the efficiency demands of agent-driven interactions.

The convergence of AI agents and blockchain technology signals a need for new infrastructure designed specifically for the agentic era—systems that can support the seamless, intelligent automation that will define the next phase of human-computer interaction across all digital domains.

**Esperchain introduces Proof‑of‑AI (PoAI)**: a Nakamoto‑style consensus in which *verifiable large‑language‑model inference* replaces useless hashing, and the resulting compute capacity is returned to token‑holders as a native, zero‑gas LLM API. PoAI rotates to the latest open‑weights model (e.g. Llama 3 and successors) every six months, guaranteeing ASIC resistance and continuous usefulness.

*From genesis, every cryptographic primitive is chosen to remain secure against large‑scale quantum computers:* lattice‑based or hash‑based signatures, hash‑based VRF, STARK proofs, and 512‑bit Poseidon hashing. Token‑holders receive *Compute Credits* that let them call the chain’s LLM with zero gas, making Esperchain both an L1 settlement layer and a permissionless AI compute commons.

**TL;DR: Esperchain has a native LLM-based AI agent securing the network.**

***

### 1  Introduction

Artificial intelligence is already changing how we communicate and act as humans. We believe the future is **agentic**: people will outsource many of their daily tasks to autonomous agents. We are already seeing this with ChatGPT acting as a therapy coach and life organiser. Agents will soon be ubiquitous, and blockchain interactions will be agent‑mediated: your crypto agent will hunt yield farms, bridge assets, negotiate trades, and manage on‑chain identity.

Current blockchains are **not ready** for this reality. They lack the throughput, latency, and AI‑centric primitives needed by always‑online agents. More importantly, their consensus protocols squander gigawatt‑hours on purposeless hashes or lock massive capital in security deposits.

**Esperchain** is an AI‑first layer‑1 that solves both issues:

* **Native AI compute** – Consensus itself executes deterministic forward passes of the current state‑of‑the‑art open LLM, secured by zero‑knowledge proofs.
* **Stake‑gated free inference** – Token‑holders receive *Compute Credits* that can be spent on LLM calls embedded directly in blocks.
* **Post‑quantum by default** – every asymmetric primitive uses NIST‑standardised lattice‑ or hash‑based schemes (Dilithium, Falcon, SPHINCS+), hash‑VRF, and STARK proofs.
* **Six‑month model rotation** – A DAO on‑chains a new open‑weights model every epoch, ensuring continuous utility and avoiding hardware ossification.

The remainder of this paper formalises Proof‑of‑AI, its economic incentives, security properties, and implementation roadmap.

***

### 2  System Overview

Esperchain comprises six principal components:

| Component             | **Responsibility**                         | **Post‑Quantum Primitive**            |
| --------------------- | ------------------------------------------ | ------------------------------------- |
| **Wallets & tx sigs** | Sign user transactions                     | Dilithium‑3 or Falcon‑512             |
| **VRF / randomness**  | Sample inference batches                   | Keccak‑XMSS hash‑VRF (RFC 9381 draft) |
| **Proof system**      | Succinctly attest to inference correctness | STARK (hash‑only) with Poseidon‑512   |
| **Block Producers**   | Perform inference, solve hash target       | —                                     |
| **Full Nodes**        | Verify STARK (\~15 ms), execute state      | —                                     |
| **DAO Governance**    | Vote with PQ sigs, update parameters       | Dilithium‑3                           |

***

{% @mermaid/diagram content="flowchart TD
%% ─────────────────────────────
%% Style helpers
classDef box fill:#f8f8f8,stroke:#555,stroke-width:1px,rx:4,ry:4,font-size:14px
classDef greybox fill:#fafafa,stroke:#999,stroke-width:2px,rx:6,ry:6,font-weight:bold
linkStyle default stroke-width:1px,stroke:#555

%% ─────────────────────────────
%% Top-level actors
subgraph USERS\["Stake / Wallets"]
direction TB
U1(\[Users]):::box
U2(\[Autonomous Agents]):::box
end
class USERS greybox

DAO\["Model DAO<br/>(stake-weighted)"]:::greybox

MEMPOOL\["MEMPOOL"]:::greybox
WORKER\["PoAI WORKER NODE<br/>(GPU / TPU farm)"]:::greybox
PEERS\["CONSENSUS PEERS<br/>(longest-difficulty chain)"]:::greybox
STATE\["GLOBAL STATE / LEDGER<br/><sub>balances · Compute Credits · LLM outputs · ModelID</sub>"]:::greybox
DAPPS\["Agents & dApps<br/><sub>(DeFi bots, games, bridges)</sub>"]:::greybox

%% ─────────────────────────────
%% Flows
USERS -- "① submit tx / LLMCall" --> MEMPOOL
DAO -- "⑧ vote new ModelID" --> MEMPOOL

MEMPOOL -- "② VRF samples\nmicro-batch Bₖ" --> WORKER
WORKER -- "③ broadcast Block{k, π, txs}" --> PEERS
PEERS -- "④ state transition" --> STATE
STATE -- "⑤ deliver LLM answers & receipts" --> DAPPS

%% feedback labels (optional)
class USERS,DAO,MEMPOOL,WORKER,PEERS,STATE,DAPPS box
" %}

### 3  Proof‑of‑AI Consensus

#### 3.1  High‑Level Intuition

PoAI inherits the longest‑chain rule from Bitcoin. The *work function* is a forward pass of a frozen model **Mᵗ** on a randomly‑sampled micro‑batch **𝔅ₖ**. A block is valid when the miner attaches a succinct zero‑knowledge proof that:

1. for all prompts in the batch, and
2. , where is the current difficulty target.

Because is deterministic (temperature = 0 greedy decode), *pre‑computing* is impossible—the miner must perform the inference after is revealed.

#### 3.1 Work Function (NEW VERSION)

For block *k* the producer must show

1. **Inference correctness**: for prompts in batch .
2. **Difficulty check**: .
3. **Succinct STARK proof** that 1 & 2 hold.

Poseidon‑512 grants 256‑bit Grover‑resistant security; difficulty retargeting compensates for Grover‑level speed‑ups if miners ever wield quantum ASICs.

#### 3.2  Block Production Algorithm

```
repeat
    S ← seed from previous block
    B ← SampleBatch(S, h_D, n)
    y ← ForwardPass(M, B)
    r ← PoseidonHash(B || y)
until r < T
π ← zkProve(M, B, y)
Broadcast Block{header, π, MerkleRoot(y), txs}
```

* **Batch sampling** uses a Verifiable Random Function (VRF) seeded by the previous block hash.
* **Proof system** uses Halo2 recursion; proof size < 2 kB; verification < 10 ms on commodity CPU.
* **Retarget** updates every 720 blocks (\~11 h) to hit a target block time τ.

#### 3.3  Difficulty Weights and Model Tiers

Esperchain supports multiple model sizes in parallel.

| Model         | Params  | Difficulty Weight ω |
| ------------- | ------- | ------------------- |
| Llama 3 8 B   | 8.1 B   | 1                   |
| Llama 3 70 B  | 70.2 B  | 8                   |
| Llama 3 405 B | 404.9 B | 45                  |

A block header stores ω; fork‑choice uses cumulative .

#### 3.4  Verification Rules

1. Verify zk‑proof .
2. Check and difficulty weight ω.
3. Execute all included transactions and state transitions.
4. Prefer the heaviest (cumulative‑difficulty) chain.

***

### 4  Model Lifecycle and Governance

1. **Proposal Window (7 days).** Anyone with ≥ 0.1 % stake submits the IPFS hash of candidate weights, architecture, and licence.
2. **Benchmark Voting.** Stake‑weighted DAO validates claims on a public benchmark suite (MMLU, MT‑Bench, GSM8K, etc.).
3. **Finalisation.** DAO commits the Merkle root and schedules activation height.
4. **Grace Period (14 days).** Nodes download weights and pre‑generate proving keys.
5. **Activation.** Circuit ID bumps; old weights are deprecated.

Emergency rollback requires a ⅔ super‑majority and re‑activates the previous model.

Quantum-proofness:

* Proposals and votes are signed with Dilithium‑3.
* The activation height commitment is included in a hash‑based VRF beacon to prevent last‑minute manipulation.

***

### 5  Deterministic Inference & Dataset

* **Prompt Bank 𝔇.** A versioned Merkle tree of JSON prompts (`system`, `user`, optional `mask_range`).
* **Decoding Rules.** Temperature = 0, greedy, max 128 tokens, stop at EOS.
* **Digest Construction.** Poseidon hash of `(ModelID || PromptIDs || Top‑K logits)` with minimises circuit size while retaining entropy.
* **Hidden Validation.** 10 % of 𝔇 is reserved for off‑chain accuracy auditing and slashing (§7).

***

### 6  Compute Credits and LLMCall Transactions

#### 6.1  Credit Issuance

Each address with non‑zero stake accrues Compute Credits (CC) per block: Credits expire after two epochs to discourage hoarding.

#### 6.2  Transaction Types

| Type          | Purpose                                               | Fee Model                                       |
| ------------- | ----------------------------------------------------- | ----------------------------------------------- |
| **Transfer**  | Standard token transfer                               | Gas paid in ESP                                 |
| **LLMCall**   | Embed prompt; miner must execute during block proving | Burns CCs proportional to token × output length |
| **LLMResult** | Return large (>1 kB) outputs if needed                | Tiny ESP fee                                    |

Miners choose which LLMCalls to include based on CC payout versus marginal compute cost, producing a self‑balancing market.

#### 6.3  Spam Mitigation

Rate‑limit = `min(CC_balance, per‑address cap)`. Priority queue orders by `CCs / estimated_tokens` so short queries do not starve.

***

### 7  Economic Model

**Per‑block reward** where *S* is a slashing term when a miner’s accuracy on hidden validation prompts falls below threshold θ.

The base subsidy halves every 2 years following a Bitcoin‑like schedule; CC spending is burned, creating long‑term deflation.

***

### 8  Security Analysis

| Threat                             | Mitigation                                                                                                                         |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **51 % compute attack**            | Requires majority inference throughput *and* solving the hash puzzle ⇒ identical to Bitcoin security budget, but with useful work. |
| **ASIC centralisation**            | Model rotates every epoch; architecture hash changes render fixed‑function ASICs obsolete.                                         |
| **Model poisoning / backdoors**    | Community audits during proposal window; emergency rollback via DAO.                                                               |
| **Low‑quality outputs**            | Hidden validation + slashing; deterministic decoding removes stochastic exploits.                                                  |
| **Sybil attacks on credit system** | Credits accrue by stake, so splitting does not multiply issuance.                                                                  |

***

Post-quantum security analysis:

| Threat                | Classical Mitigation       | PQ Status                                         |
| --------------------- | -------------------------- | ------------------------------------------------- |
| **51 % compute**      | Hash hardness; retarget    | Grover ⇒ √‑speed‑up ⇒ double output length (done) |
| **Signature forgery** | Ed25519 → Dilithium/Falcon | Shor‑resistant                                    |
| **VRF bias**          | EC‑VRF → Hash‑VRF          | Shor‑resistant                                    |
| **Proof forgery**     | Halo2 → STARK              | Hash‑based ⇒ Shor‑resistant                       |
| **Model backdoor**    | Community audit            | No change                                         |

Esperchain is therefore secure against both classical and known quantum algorithms up to ≈ 256‑bit hash security.

### 9  Environmental Impact

Esperchain recycles nearly 100 % of its security electricity into socially useful LLM inference, unlike PoW chains that discard it as heat. Model rotation ensures compute efficiency keeps pace with hardware advances, further lowering joule‑per‑token settled.

***

### 10  Comparison to Existing Consensus

| Property        | PoW (BTC)    | PoS (ETH)   | Bittensor PoI           | **Esper PoAI**                   |
| --------------- | ------------ | ----------- | ----------------------- | -------------------------------- |
| Work utility    | None         | None        | ML utility (subjective) | ML utility (objective)           |
| Security root   | Energy       | Capital     | PoS chain underneath    | Energy (deterministic inference) |
| Verification    | Trivial hash | Trivial sig | Reputation oracle       | 10 ms SNARK                      |
| Model evolution | N/A          | N/A         | By subnet designer      | DAO‑governed rotation            |
| End‑user AI     | Off‑chain    | Off‑chain   | Gateway                 | **On‑chain, gas‑free credits**   |

***

### 11  Implementation Roadmap

| Milestone         | Detail                                  | ETA     |
| ----------------- | --------------------------------------- | ------- |
| **Testnet 0**     | Llama 3 8 B, 30 s blocks, no CCs        | Q3 2025 |
| zk Optimisation   | 4‑bit sparse matrix, Halo2 recursion v2 | Q4 2025 |
| **Mainnet 1.0**   | Credits, LLMCall txs, DAO live          | Q1 2026 |
| Model 1 → Model 2 | Rotate to Llama 3.1 or Llama 4          | Q2 2026 |
| Multi‑tier mining | Enable 70 B tier with ω=8               | Q3 2026 |

***

### 12  Use Cases & Ecosystem

1. **DeFi Autopilot.** Agents that automatically farm, rebalance, and hedge positions without leaving the chain.
2. **Cross‑chain Bridge Oracles.** LLM agents read foreign‑chain data and construct proofs.
3. **On‑chain Knowledge Base.** Contracts query Esper LLM for natural‑language answers anchored by SNARK proofs.
4. **NFT & Gaming AI.** Fully on‑chain narrative engines and NPC behaviour driven by the current model.

***

### 13  Conclusion

Esperchain turns the security budget of a layer‑1 blockchain into a public good: **verifiable, zero‑gas large‑language‑model inference**. Its Proof‑of‑AI consensus combines Bitcoin‑level robustness with permissionless AI compute, giving agents—and their human owners—a native home for the next decade of the crypto‑AI convergence.

Esperchain marries **AI‑native useful work** with an **end‑to‑end post‑quantum cryptographic stack**, producing a blockchain ready for agentic finance and a Shor‑scale future.

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://esper.gitbook.io/esperchain-docs/architecture/proof-of-ai-consensus.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.