Agentic Chain Whitepaper

Abstract

Agentic Chain is a novel Layer 1 blockchain that introduces Proof of AI Verification (PoAIV), a consensus work function in which the computation securing the network is the verification of blockchain integrity itself -- performed by Claude AI agents, proven via zero-knowledge proofs, and attested via cryptographic signatures. By unifying consensus security with state correctness verification, Agentic Chain eliminates the gap between "securing the chain" and "checking that the chain is correct" that exists in all current blockchain architectures. The protocol features privacy-by-default isolated ledger spaces, inclusive CPU staking with hardware-normalized compute measurement, and a dual attestation trust model combining mathematical proof with institutional verification. Under adversarial conditions exceeding the standard one-third Byzantine threshold, Agentic Chain provides strictly stronger safety guarantees than pure BFT systems: a supermajority adversary can halt the chain but cannot finalize invalid state, because zero-knowledge proof soundness prevents the forging of false correctness proofs. This guarantee applies to the deterministic state-transition component verified by the zkVM. The Claude API attestation layer follows a trust-but-verify model; its compromise affects the qualitative anomaly-detection layer but does not compromise mathematical state validity. The Phase 2 TEE backup (Section 11) further reduces this trust dependency.

Table of Contents

1. Introduction
2. Background and Related Work
3. System Architecture
4. Proof of AI Verification
5. Consensus Protocol
6. Privacy Architecture
7. Staking and Validator Economics
8. Tokenomics
9. Security Analysis
10. Comparison with Existing Systems
11. Roadmap
12. Conclusion
13. References

1. Introduction

1.1 The Problem

Current blockchain architectures force a three-way trade-off between privacy, decentralization, and verification quality.

High-throughput chains such as Solana achieve sub-second block times and thousands of transactions per second, but at the cost of transparency: all state is publicly readable, and correctness relies entirely on the economic assumption that a supermajority of validators are honest. Privacy-focused chains such as Zcash and Aleo protect transaction data with zero-knowledge proofs, but constrain programmability or require specialized hardware for proof generation. Decentralized compute networks such as Akash and Render enable resource staking, but lack formal guarantees that contributed computation was performed correctly.

In all of these systems, a critical disconnect persists: the work that secures the chain (mining hashes, locking capital, generating puzzle proofs) is entirely separate from the work that verifies the chain is correct (re-executing transactions, checking state roots). Node operators are trusted to perform verification honestly, but there is no mathematical proof that they did so. A validator in Ethereum or Solana that signs a block is attesting to its correctness on their reputation and economic stake alone -- if a supermajority colludes or is compromised, invalid state can be finalized with no cryptographic recourse.

1.2 Why AI-Powered Verification Changes the Equation

Large language models have demonstrated the ability to reason about complex structured data, detect anomalous patterns, and perform multi-step logical analysis. When combined with deterministic computation proven in a zero-knowledge virtual machine, AI agents can serve as a new class of blockchain verifier: one that not only checks whether the math is correct (a task suited to deterministic circuits) but also assesses whether transaction patterns indicate economic exploits, governance attacks, or novel vulnerability patterns (a task requiring heuristic intelligence).

This insight motivates a fundamentally new consensus design. Rather than wasting computation on hash puzzles (Proof of Work), requiring only passive capital lockup (Proof of Stake), or generating proofs of generic coinbase puzzles (Proof of Succinct Work), the chain can require that the work securing consensus is the generation of zero-knowledge proofs that the chain's state transitions are correct, augmented by AI-powered anomaly detection attested via cryptographic signatures.

1.3 Contributions

Agentic Chain introduces four interconnected innovations:

1. Proof of AI Verification (PoAIV): A consensus work function where every unit of computation consumed to secure the chain simultaneously verifies its correctness. Verification proofs combine STARK proofs of deterministic state-transition logic with signed attestations from Claude AI agents for anomaly detection.

2. ZK-Private Agent Channels: A multi-layered communication architecture providing privacy for verification task assignment, agent coordination, and user transaction submission, built on VRF-based cryptographic sortition, end-to-end encrypted channels, and optional mixnet integration.

3. Isolated Ledger Spaces: A privacy-by-default state model using Aleo-inspired programmable records with nullifier-based double-spend prevention and tag-based record discovery, providing cryptographic isolation between users while maintaining global state consistency proven by zero-knowledge proofs.

4. Inclusive CPU Staking: A dual-staking model combining token deposits with measured CPU contribution, using hardware-normalized Verification Proof Units (VPU) with diminishing returns to prevent GPU farm dominance while allowing participation from consumer hardware. The system is inclusive in that consumer-grade hardware can meaningfully participate in verification and earn rewards -- unlike Solana, which requires datacenter-class servers. Professional operators with GPU hardware earn proportionally more in absolute terms (reflecting greater computational contribution), but diminishing returns above the VPU cap ensure that consumer participants remain economically viable.

2. Background and Related Work

2.1 Consensus Mechanisms

The consensus design space has evolved into three major families, each with distinct trade-off profiles.

Classical BFT derivatives such as Tendermint/CometBFT provide instant finality per block through two-phase commit protocols, but face O(n²) message complexity that limits validator set size to approximately 150-200 nodes. The HotStuff family achieves O(n) communication complexity through threshold signatures and pipelined phases, enabling larger validator sets with sub-second finality. Aptos uses a HotStuff variant (Jolteon/Shoal) for its parallel execution engine.

DAG-based BFT protocols, notably Narwhal/Bullshark and Mysticeti (used by Sui), separate data dissemination from consensus ordering. Every validator proposes simultaneously via a Directed Acyclic Graph, eliminating the leader bottleneck. Mysticeti achieves finality in approximately 390 milliseconds with theoretical throughput exceeding 100,000 TPS.

Nakamoto-style protocols such as Ethereum's Gasper (LMD-GHOST fork choice with Casper FFG checkpoints) sacrifice finality speed for maximum validator participation, supporting over one million validators at the cost of approximately 13-minute economic finality.

Solana's Tower BFT deserves special mention as the primary inspiration for Agentic Chain's Phase 1 ordering. Tower BFT uses Proof of History (a SHA-256 VDF serving as a cryptographic clock) to replace wall-clock timeouts, and applies exponentially increasing vote lockout (2ⁿ slots for the nth confirmation) to create economic finality that strengthens over time. This design achieves approximately 400ms block times with rooted finality in approximately 6.4 seconds.

2.2 Privacy Approaches

Zcash pioneered the nullifier/commitment model: private state is represented as notes committed to a global Merkle tree, and spending produces nullifiers that prevent double-spending without revealing which note was spent. The Orchard upgrade migrated to Halo 2 (no trusted setup, IPA-based) with action-based transaction structures that hide whether a transaction is a spend, receive, or both.

Penumbra extends the Zcash model to DeFi primitives, supporting private staking, private governance voting, and sealed-bid batch DEX swaps within a shielded pool. Its "rate schedule" approach enables delegators to compute rewards from public data without revealing individual delegation amounts.

Aleo introduces the most programmable privacy model: records are UTXOs with arbitrary data fields, governed by programs written in Leo. Its Proof of Succinct Work (PoSW) consensus uses ZK proof generation as the mining function -- the closest existing precedent to Agentic Chain's PoAIV. However, PoSW generates proofs of generic coinbase puzzles rather than directed chain verification.

Aztec (Layer 2 on Ethereum) achieves the most flexible hybrid privacy model: private state as encrypted notes proven client-side, composable with transparent public state in a single smart contract. Its Noir language compiles to UltraPLONK/Honk circuits and represents the state of the art in ZK developer experience.

2.3 Compute Staking Networks

Three decentralized compute networks provide reference models for Agentic Chain's CPU staking:

Akash Network operates a reverse-auction marketplace for general cloud computing on Cosmos SDK, where providers stake AKT tokens and tenants bid for resources. Compute verification relies primarily on economic incentives and reputation -- a weakness that Agentic Chain addresses with ZK proofs.

Render Network provides decentralized GPU rendering with verifiable output: OctaneBench scores standardize GPU measurement, redundant rendering enables cross-validation, and a burn-and-mint equilibrium (BME) token model ties token value directly to service usage.

io.net aggregates distributed GPUs into virtual clusters for AI/ML workloads, using driver-level hardware attestation and Proof-of-Work-style periodic challenges to verify claimed hardware specifications.

The fundamental challenge shared by all compute networks is trustless verification of computation quality. Render benefits from visually verifiable outputs; Akash and io.net rely on economic deterrence and benchmarks. Agentic Chain resolves this by making verification itself the compute contribution: the work is ZK proof generation, and the proof is its own verification.

2.4 What is Missing

No existing system combines all four of these properties:

1. Consensus work that directly verifies chain correctness (PoW wastes computation; PoS requires only capital; PoSW generates generic proofs)
2. AI-enhanced verification that detects anomalous patterns beyond deterministic rule checking
3. Privacy-by-default state with programmable records and cryptographic isolation
4. Inclusive compute participation where consumer CPUs can contribute meaningfully alongside professional hardware

Agentic Chain fills this gap.

3. System Architecture

3.1 High-Level Architecture

+=========================================================================+
|                      AGENTIC CHAIN ARCHITECTURE                       |
+=========================================================================+
|                                                                         |
|  +-------------------+    +-------------------+    +------------------+ |
|  |   USER / CLIENT   |    |   USER / CLIENT   |    |  USER / CLIENT   | |
|  | (wallet, dApp)    |    | (wallet, dApp)    |    | (wallet, dApp)   | |
|  +--------+----------+    +--------+----------+    +--------+---------+ |
|           |   Dandelion++ / Nym (L3: anonymous submission)   |          |
|           +---------------------+----------------------------+          |
|                                 |                                       |
|  +==============================v====================================+  |
|  |                    CONSENSUS LAYER (Phase 1)                      |  |
|  |                                                                   |  |
|  |   Leader Rotation --- Block Proposal --- BFT Voting (~500ms)     |  |
|  |   Tower BFT-inspired vote lockout --- Optimistic Confirmation    |  |
|  +===============================+===================================+  |
|                                  |                                      |
|           VRF Task Assignment    |  Block ordered, verifiers selected   |
|                                  |                                      |
|  +===============================v===================================+  |
|  |                   EXECUTION LAYER (Phase 2)                       |  |
|  |                                                                   |  |
|  |   +------------+  +------------+  +------------+  +------------+  |  |
|  |   | Claude     |  | Claude     |  | Claude     |  | Claude     |  |  |
|  |   | Agent #1   |  | Agent #2   |  | Agent #3   |  | Agent #N   |  |  |
|  |   | (zkVM +    |  | (zkVM +    |  | (zkVM +    |  | (zkVM +    |  |  |
|  |   |  API attn) |  |  API attn) |  |  API attn) |  |  API attn) |  |  |
|  |   +-----+------+  +-----+------+  +-----+------+  +-----+------+  |  |
|  |         |                |                |                |       |  |
|  |   Commitment-Reveal   E2EE Channels (L2)   Proof Submission      |  |
|  +===============================+===================================+  |
|                                  |                                      |
|                    T_verify proofs collected                             |
|                                  |                                      |
|  +===============================v===================================+  |
|  |                    PRIVACY LAYER (State)                          |  |
|  |                                                                   |  |
|  |   +------------------+  +---------------------+  +-------------+  |  |
|  |   | Public State     |  | Private Commitment  |  | Nullifier   |  |  |
|  |   | Tree (PST)       |  | Tree (PCT)          |  | Set (NS)    |  |  |
|  |   | - validator set  |  | - Poseidon commits  |  | - PRF-based |  |  |
|  |   | - chain params   |  | - encrypted records |  | - double-   |  |  |
|  |   | - governance     |  | - tag-based index   |  |   spend     |  |  |
|  |   +------------------+  +---------------------+  +-------------+  |  |
|  +====================================================================+  |
|                                                                         |
|  +====================================================================+  |
|  |                    STAKING LAYER                                   |  |
|  |                                                                   |  |
|  |   Token Stake (AGNTC)  +  CPU Commitment (VPU)  =  Effective Stake|  |
|  |         40%                    60%                                |  |
|  |                                                                   |  |
|  |   TEE Attestation --- Benchmark Challenges --- Perf Monitoring   |  |
|  +====================================================================+  |
|                                                                         |
+=========================================================================+

3.2 The Four Layers

Consensus Layer handles block production and ordering. A deterministic leader schedule assigns slot leaders who propose blocks from pending transactions. Validators vote on proposed blocks through a BFT protocol with exponential vote lockout. A block achieves optimistic confirmation when it receives two-thirds stake-weighted votes, typically within 500ms to 1 second (one to two slots), as BFT voting messages propagate across the validator set.

Execution Layer performs AI-powered verification. Once a block is ordered, VRF-based cryptographic sortition privately assigns verification tasks to Claude agents. Each agent independently verifies the block by running deterministic state-transition logic inside a zkVM and querying the Claude API for anomaly detection. Agents submit composite proofs (ZK proof plus signed attestation) through a commitment-reveal protocol that prevents free-riding.

Privacy Layer manages the chain's state model. User data resides in a Private Commitment Tree as encrypted, programmable records. Spending a record publishes a nullifier (preventing double-spending) without revealing which record was consumed. A separate Public State Tree holds transparent protocol data: the validator set, chain parameters, and governance state. Zero-knowledge proofs maintain consistency between private record operations and the global state root.

Staking Layer manages participant registration, resource measurement, and economic incentives. Stakers commit both AGNTC tokens and CPU resources. Hardware is verified through TEE attestation, periodic benchmark challenges, and continuous performance monitoring. The Verification Proof Unit (VPU) normalizes heterogeneous hardware into a single metric, and diminishing returns on VPU prevent disproportionate dominance by GPU operators.

3.3 Layer Interaction

The layers interact through a pipelined flow. The Consensus Layer orders blocks at high speed (500ms slots). The Execution Layer verifies ordered blocks asynchronously (10-30 seconds). The Privacy Layer provides the state that both layers operate on. The Staking Layer determines who participates in both ordering (BFT voting) and verification (VRF-assigned proving), with effective stake computed as a weighted function of token deposits and measured CPU contribution.

4. Proof of AI Verification

4.1 Formal Definition

Definition 1 (Verification Task). A verification task V_i is a tuple:

V_i = (block_hash, task_type, state_snapshot, assignment_proof)

Where block_hash identifies the block to be verified, task_type specifies the verification operation, state_snapshot is a Merkle-root-anchored view of the relevant state at the parent block, and assignment_proof is a VRF-based proof that the task was validly assigned to the executing agent.

Definition 2 (Verification Proof). A verification proof Pi_i for task V_i is a composite structure:

Pi_i = (zk_proof, attestation, verdict, metadata)

The zk_proof is a STARK proof generated by a zkVM (SP1 or RISC Zero) attesting that the agent correctly parsed and validated all transactions, computed the state transition, verified Merkle proofs and nullifier non-membership, incorporated the attested Claude API response, and confirmed the validity of its VRF assignment.

The attestation is a signed response from the Claude API containing a hash of the structured query, the analysis response, a server timestamp, and a cryptographic signature (ECDSA or Ed25519) over these fields using Anthropic's attestation key.

The verdict is one of {VALID, INVALID, INCONCLUSIVE}.

Definition 3 (Block-Level PoAIV). A block B_k achieves AI Verification when the number of proofs with verdict VALID meets or exceeds the verification threshold T_verify, all ZK proofs are valid, all attestation signatures are valid, and no two proofs contain conflicting state transition results.

Definition 4 (Consensus Work Function). The consensus work function maps a staker's CPU time and assigned verification tasks to a set of verification proofs. Unlike Proof of Work where computation is discarded after mining, every proof generated in PoAIV has intrinsic value: it verifies blockchain correctness. The amount of work is measured in Verification Proof Units (VPU).

4.2 Verification Task Types

TX_VALIDITY and STATE_TRANSITION are mandatory for every block. CROSS_LEDGER runs on a sampling schedule triggered by cross-user transactions. PROOF_CORRECTNESS is applied to random samples of prior proofs for ongoing integrity assurance.

4.3 The Hybrid Proof Structure

AI agent computation cannot be fully encapsulated in a zero-knowledge proof. LLM inference runs on remote infrastructure with proprietary model weights and potentially non-deterministic sampling. The architecture therefore separates provable from attestable computation:

                    AI Verification Agent Execution
    +--------------------------------------------------------+
    |                                                        |
    |  1. Parse verification task assignment                 |
    |     (deterministic: decode assignment, load state)     |
    |                                                        |
    |  2. Execute deterministic verification logic     <---- PROVEN in zkVM
    |     - Parse and validate transactions                  |
    |     - Verify cryptographic signatures                  |
    |     - Compute state transitions                        |
    |     - Check Merkle proofs and nullifier set            |
    |                                                        |
    |  3. Query Claude API for anomaly analysis        <---- ATTESTED via
    |     - Send structured verification query               |   signed API
    |     - Receive signed response with analysis            |   response
    |                                                        |
    |  4. Aggregate results and produce verdict        <---- PROVEN in zkVM
    |     - Combine deterministic verification results       |
    |     - Incorporate attested inference response           |
    |     - Generate composite verification proof            |
    |                                                        |
    +--------------------------------------------------------+

The zkVM circuit verifies the Claude API signature inside the proof. The final proof attests: "I executed verification logic X (mathematically proven), received analysis Y from Claude (signature verified within the proof), and produced verdict Z based on both." The trust model becomes: trust the ZK proof for deterministic logic, trust Anthropic's API signature for inference results.

API Provider Dependency. The current design relies on Anthropic's Claude API as the attestation authority for AI inference results. This creates a single-vendor dependency that the architecture explicitly mitigates through two mechanisms: (1) the multi-authority attestation model (Section 7.6) supports adding alternative AI providers as additional signing authorities, reducing reliance on any single vendor; (2) the Phase 2 TEE upgrade enables local model execution within trusted execution environments, eliminating the need for external API calls entirely. The protocol is designed so that the Anthropic dependency can be fully removed without changes to the consensus mechanism -- only the attestation source changes, while the ZK proof structure remains identical.

4.4 Why This Is Novel

PoAIV is the first consensus mechanism that makes the work function directly productive. Every CPU cycle consumed by the consensus protocol simultaneously strengthens chain security by verifying state correctness. The AI component adds a qualitative security layer: Claude agents can detect economic exploits, governance attacks, and novel vulnerability patterns that deterministic rule-checking would miss. The dual attestation model (mathematical proof plus institutional signature) creates a two-factor trust structure stronger than either factor alone.

5. Consensus Protocol

5.1 Two-Phase Pipelined Consensus

Agentic Chain decouples block ordering from correctness verification through a two-phase pipeline. Phase 1 provides low-latency block production via BFT consensus. Phase 2 provides ZK-verified finality via asynchronous proof generation and collection.

Block Lifecycle:

Time -->
|---- Phase 1: BFT Ordering ----|---- Phase 2: ZK Verification ----|
|  ~500ms                        |  ~10-30s                         |

  [PROPOSED] --> [ORDERED] -----------------> [VERIFIED] --> [FINALIZED]
       |             |                              |
    Leader       2/3+ BFT votes               T_verify proofs
    proposes     confirm ordering              with VALID verdict
    block        (optimistic confirmation)     (ZK finality)

5.2 Phase 1: Fast BFT Ordering

Phase 1 draws from Tower BFT and HotStuff, adapted for Agentic Chain's verification model.

Leader rotation. A deterministic schedule computed from stake weights and epoch randomness assigns leaders to two-slot windows (approximately one second). The schedule is computed in advance, allowing pre-loading of transaction queues.

Block proposal. The slot leader constructs a block from pending transactions, computes the proposed state transition, and broadcasts the block to the validator set.

Voting and lockout. Validators vote on proposed blocks. A block achieves "ordered" status when it receives two-thirds stake-weighted votes. Votes carry exponentially increasing lockout: a vote at depth d locks the validator from voting on a conflicting fork for 2ᵈ slots. This creates economic finality that strengthens geometrically over time, even before ZK verification completes.

Optimistic confirmation. Once ordered, a block is optimistically confirmed. Applications can read its state with the understanding that ZK finalization is pending -- a latency model comparable to Solana's optimistic confirmation before rooting.

5.3 Phase 2: ZK Verification Finality

As soon as a block is ordered, the verification pipeline activates.

1. Task assignment. Each active agent locally computes a VRF using the chain's random beacon and the block hash. If the VRF output falls below the assignment threshold (calibrated to select N_target verifiers per block proportional to effective stake), the agent is privately assigned to verify the block. No one else learns the assignment until the agent publishes their proof.

2. Independent verification. Each assigned agent independently fetches the block data and relevant state, runs verification logic inside the zkVM, queries the Claude API for anomaly analysis, and generates a STARK proof of correct execution.

3. Commitment-reveal. To prevent free-riding, proof submission uses a two-phase protocol. In the commit phase (first 10 seconds), agents publish the hash of their proof. In the reveal phase (next 20 seconds), agents reveal the full proof. Agents that alter their verdict between phases are slashed.

4. Finalization. When T_verify valid proofs with VALID verdicts have been collected, the block transitions to FINALIZED. This represents the strongest finality guarantee: a finalized block's correctness is proven by multiple independent zero-knowledge proofs.

5.4 Verifier Selection and Security

The number of verifiers per block is a critical security parameter.

At steady state with 13 verifiers and a threshold of 9, an adversary controlling one-third of effective stake has approximately a 0.04% chance of controlling enough verifiers to mount an attack on any given block.

5.5 Timing Parameters

5.6 Dispute Resolution

When verification produces conflicting results, the protocol handles four cases:

Unanimous INVALID. The block is rejected. The block proposer is slashed. Verifiers earn a dispute bonus. The next leader proposes a replacement block.

Split verdict. The block enters a dispute state. Additional verifiers (2x N_target, fresh VRF round) independently re-verify. If the second round reaches consensus, the block is finalized or rejected accordingly.

Insufficient proofs. The verification window extends to 60 seconds. If still insufficient, T_verify is temporarily reduced for that block.

Timeout. The block remains ordered but not finalized. After one epoch, a governance-selected committee performs re-verification.

5.7 Parallel Proving and Recursive Aggregation

To reduce proving latency, blocks are segmented into transaction chunks that multiple agents prove in parallel:

Block B_k: 200 transactions

Step 1: Segment into chunks
  Chunk 1: txns 1-50    --> Agent A --> Proof_1 (state_0   -> state_50)
  Chunk 2: txns 51-100  --> Agent B --> Proof_2 (state_50  -> state_100)
  Chunk 3: txns 101-150 --> Agent C --> Proof_3 (state_100 -> state_150)
  Chunk 4: txns 151-200 --> Agent D --> Proof_4 (state_150 -> state_200)

Step 2: Recursive aggregation
  Aggregate_1 = RecursiveProof(Proof_1, Proof_2)  -- state_0   -> state_100
  Aggregate_2 = RecursiveProof(Proof_3, Proof_4)  -- state_100 -> state_200

Step 3: Final composition
  Final_Proof = RecursiveProof(Aggregate_1, Aggregate_2) -- state_0 -> state_200

This reduces proving time from O(n) to O(n/p + log(p)) where p is the number of parallel provers.

6. Privacy Architecture

6.1 State Model

Agentic Chain uses a hybrid private/public state model inspired by Aleo's programmable records and Aztec's composable privacy approach.

Global State Root
    |
    +---- Public State Tree (PST)
    |     Transparent, replicated across all validators
    |     - Validator set and aggregate stake information
    |     - Chain parameters (block height, epoch, inflation rate)
    |     - Aggregate metrics (total supply, total staked, total VPU)
    |     - Attestation authority public keys
    |     - Governance proposals and results
    |
    +---- Private Commitment Tree (PCT)
    |     Sparse Merkle Tree of record commitments (depth 40)
    |     - Each leaf: commitment = Poseidon(owner || data || nonce || tag || program_id)
    |     - Encrypted records transmitted to owners via DA layer or P2P
    |     - Append-only: records are created, never modified in place
    |     - Capacity: ~10^12 records (~17 years at 1000 TPS)
    |
    +---- Nullifier Set (NS)
          Sparse Merkle Tree of spent-record nullifiers
          - Each entry: nullifier = PRF(spending_key, record_commitment, nonce)
          - Double-spend check: reject transaction if nullifier already exists

6.2 Programmable Records

Each record in Agentic Chain is a programmable unit of private state:

Record {
    owner:      PublicKey        -- owner's viewing/spending key
    data:       Vec<Field>      -- arbitrary data fields (balance, metadata, etc.)
    nonce:      Field           -- random nonce for commitment uniqueness
    tag:        Field           -- filterable tag for efficient record discovery
    program_id: ProgramHash     -- which program governs this record
    birth_slot: u64             -- slot when the record was created
}

Only the commitment (a Poseidon hash of all record fields) is stored on-chain. The full record is encrypted to the owner's viewing key and distributed via the data availability layer or direct peer-to-peer transmission.

6.3 Isolated Ledger Spaces

A user's "isolated ledger space" is the set of all unspent records encrypted to their viewing key. Isolation is cryptographic, not physical: all records live in the same global commitment tree, but a user can only decrypt and spend records for which they hold the appropriate keys.

6.4 Record Discovery

Users discover their records through tag-based filtering. When a record is created, a tag is derived using the recipient's viewing key. Tags are stored in a public index alongside commitment positions. Since tags are PRF outputs, they appear random to observers who do not hold the viewing key.

6.5 Cross-User Interactions

Simple transfers follow a two-phase protocol. The sender consumes their record (publishing a nullifier) and creates a new record encrypted to the recipient's key, generating a ZK proof of valid consumption, correct formation, and value conservation. Complex interactions such as atomic swaps use escrow programs in the Public State Tree.

6.6 Communication Privacy

7. Staking and Validator Economics

7.1 CPU Commitment and Attestation

Stakers register by submitting both a token deposit and a CPU attestation containing hardware profile information, benchmark results, and optionally a TEE attestation report (Intel TDX or AMD SEV-SNP) cryptographically binding the hardware to the staker's key.

CPU attestation uses three complementary layers:

Layer 1: TEE attestation provides hardware-grade proof of CPU specifications.

Layer 2: Benchmark challenges are periodic, unpredictable computation tasks derived from a VRF-based random beacon.

Layer 3: Performance monitoring continuously tracks each staker's actual proof generation rate against their declared capacity.

7.2 Verification Proof Units

The Verification Proof Unit (VPU) is the standardized measure of CPU contribution. One VPU is defined as the computational work required to generate a STARK proof for a reference verification circuit of one million RISC-V cycles on the Agentic Chain Reference Benchmark (PSRB).

7.3 Managing GPU Dominance

GPU-accelerated provers outperform CPU provers by 10-100x. To preserve inclusive participation while allowing GPU acceleration, VPU earnings follow a diminishing-returns curve:

effective_vpu = min(vpu, vpu_cap) + (max(vpu - vpu_cap, 0))^0.6
where vpu_cap = median(active_stakers_vpu) * 3

7.4 Dual-Staking Formula

A participant's effective stake is a weighted function of both token stake and CPU contribution:

effective_stake = alpha * normalize(token_stake) + (1 - alpha) * normalize(effective_vpu)

where:
  alpha = 0.40   (token weight)
  (1 - alpha) = 0.60   (CPU weight)
  normalize(x) = x / sum(all x)

The 40/60 split reflects Agentic Chain's emphasis on actual compute contribution over passive capital lockup.

7.5 AI Agent Protocol

Each staker runs one or more Claude agent instances proportional to their CPU capacity. The agent lifecycle progresses through states: REGISTERED, WARMING_UP, ACTIVE, VERIFYING, PROOF_SUBMITTED, and potentially PROBATION, COOLDOWN, or SLASHED.

7.6 Claude API Trust Model

Claude API attestation uses a multi-authority architecture with key rotation:

• Version 1: Two Anthropic API endpoints in separate data centers, each with independent key pairs.
• Version 2: A TEE-based local inference backup using a smaller open-source model running inside a hardware enclave.
• Future: 2-of-3 threshold across Anthropic Primary, Anthropic Backup, and TEE Local.

7.7 Reward Distribution

Rewards are sourced from token inflation, transaction fees, and verification fees.

Per-Epoch Reward Distribution:

  Orderer share:  10%   (block proposers/leaders + 100% of priority fees)
  Verifier share: 55%   (verification agents, proportional to VPU consumed)
  Staker share:   35%   (all token stakers, proportional to token stake)

7.8 Slashing

8. Tokenomics

8.1 The AGNTC Token

The AGENTIC token (ticker: AGNTC) serves four functions:

1. Gas. Required to pay transaction fees (base fee plus priority fee).
2. Token staking. Staked to participate in consensus and earn rewards.
3. CPU staking bond. Minimum token deposit required alongside CPU commitment.
4. Governance. Voting on protocol parameters, upgrades, and treasury allocation, weighted by the same effective_stake formula used for consensus.

8.2 Supply and Distribution

Initial circulating supply at genesis is exactly 21,000,000 AGNTC (2.1%), sourced entirely from the Public Sale allocation. All other allocations are fully cliff-vested with no genesis unlock. This ultra-low initial float -- a deliberate echo of Bitcoin's 21 million cap -- creates maximum scarcity during the bootstrap phase while ensuring that all insiders are fully aligned with long-term network success. The Community Staking Pool (30%) is not airdropped; it is emitted gradually to users who opt into free community staking, proportional to their CPU delegation.

8.3 Inflation Schedule

Agentic Chain uses a disinflationary model starting at 6% annually, declining by 15% each year, with a 1% floor.

8.4 Fee Model

Base fee: 5,000 lamports per signature. Fifty percent of base fees are burned; fifty percent go to the block orderer.

Priority fee: Per-compute-unit, user-specified. One hundred percent goes to the block orderer.

Verification fee: A per-block protocol-level deduction from the block's total fee revenue, distributed to verification agents proportional to their proof contribution.

Storage fee: A per-byte per-epoch rent-exempt deposit (approximately 0.001 AGNTC per byte), refundable when an account is closed.

8.5 Fee Burn and Sustainability

The 50% base fee burn creates deflationary pressure proportional to network usage, partially offsetting inflation. The burn rate is governance-adjustable within bounds of 25%-75%.

9. Security Analysis

9.1 Adversary Model

Agentic Chain's security analysis considers four adversary tiers:

Level 1 -- Rational Adversary. Controls one or a few staker identities; motivated by profit.

Level 2 -- Resourceful Adversary. Controls up to f < 1/3 of total effective stake; can coordinate multiple identities.

Level 3 -- State-Level Adversary. Can compromise hardware, issue subpoenas for attestation keys, and perform large-scale network attacks.

Level 4 -- Cryptographic Adversary. Can break underlying cryptographic assumptions (quantum computer). Mitigated by STARK-based proofs (post-quantum resistant).

9.2 Safety Properties

Transaction validity. No invalid transaction appears in a finalized block. Guaranteed by ZK proof of transaction validation verified by T_verify independent agents.

State transition correctness. The post-state root of a finalized block is the correct result of applying the block's transactions to the pre-state.

Double-spend prevention. No record can be spent twice in any finalized history. Guaranteed by nullifier set membership checks within the ZK proof.

Ledger isolation. No user can read or modify another user's records without the owner's keys.

9.3 Liveness Properties

Block production continues as long as more than two-thirds of BFT voting stake is online (standard BFT liveness).

9.4 The Key Insight: Strictly Stronger Safety Than Pure BFT

This is Agentic Chain's most important security property.

In pure BFT systems (Ethereum, Solana, Penumbra), a supermajority adversary controlling more than one-third of stake can finalize invalid state transitions. In Agentic Chain, this attack is impossible. Even if an adversary controls T_verify of the assigned verifiers, they cannot produce valid ZK proofs for an incorrect state transition.

The consequence:

• A >1/3 adversary in Solana or Ethereum can finalize invalid state (safety failure) AND halt the chain (liveness failure).
• A >1/3 adversary in Agentic Chain can halt verification (liveness failure) but CANNOT finalize invalid state (safety preserved).

The chain may stop, but it will never lie.

9.5 Collusion Resistance

VRF-based task assignment ensures that the adversary cannot predict or control which agents verify any given block. The dual-staking model compounds collusion difficulty: an attacker needs both significant capital and physical compute infrastructure.

10. Comparison with Existing Systems

10.1 Comparative Matrix

11. Roadmap

Phase 1: Research and Specification (Current)

• Modules 01-04: Consensus landscape analysis, tokenomics research, ZK privacy architecture survey, and algorithm specification (complete).
• Module 05: Whitepaper synthesis (this document).
• Deliverables: Published whitepaper, formal specification of PoAIV, security model documentation.

Phase 2: Prototype and Testnet

• Implement the Agentic Agent Runtime with zkVM integration (SP1 or RISC Zero).
• Build the PSRB benchmark suite and calibrate VPU measurements.
• Implement the commitment-reveal verification protocol and VRF-based task assignment.
• Deploy a permissioned testnet with 20-50 Foundation-operated nodes.
• Open testnet to community stakers with test tokens.
• Conduct formal security audit.

Phase 3: Mainnet

• Mainnet launch with minimum 100 active CPU stakers.
• Bootstrap phase with 2x reward multiplier declining over 24 months.
• Foundation anchor nodes (20% initial stake) providing liveness guarantee.
• Progressive decentralization: Foundation anchor nodes deprecated by month 18.
• Target: 500+ active CPU stakers and 10+ deployed applications within 18 months.

Post-Launch Evolution

• MPC-based verdict aggregation (upgrade from commitment-reveal to threshold secret sharing).
• TEE-based local inference backup for Claude API attestation.
• Dynamic inflation mechanism (governance-activated).
• Encrypted mempool for MEV resistance.
• Cross-chain bridge infrastructure with ZK-verified state proofs.

12. Conclusion

Agentic Chain presents a new paradigm for blockchain security: one where the computation that secures the network is the verification of the network itself. By combining zero-knowledge proofs of deterministic state-transition logic with AI-powered anomaly detection attested via cryptographic signatures, Proof of AI Verification eliminates the trust gap inherent in all existing consensus mechanisms.

The protocol's privacy-by-default architecture, built on programmable records with nullifier-based double-spend prevention, provides cryptographic isolation between users without sacrificing global state consistency. The inclusive CPU staking model, normalized through the VPU system with diminishing returns, enables meaningful participation from consumer hardware while accommodating professional infrastructure.

Most significantly, the ZK verification layer provides a safety guarantee that no pure BFT system can match: under adversarial conditions exceeding the standard one-third Byzantine threshold, the chain may halt, but it cannot finalize false state. This property -- that the chain will never lie, even if it sometimes falls silent -- represents a fundamental advance in blockchain security.

References

Consensus and BFT

[1] Castro, M. and Liskov, B. "Practical Byzantine Fault Tolerance." OSDI 1999. [2] Yin, M. et al. "HotStuff: BFT Consensus with Linearity and Responsiveness." PODC 2019. [3] Yakovenko, A. "Solana: A new architecture for a high performance blockchain." 2017. [4] Gilad, Y. et al. "Algorand: Scaling Byzantine Agreements for Cryptocurrencies." SOSP 2017. [5] Danezis, G. et al. "Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus." EuroSys 2022. [6] Babel, K. et al. "Mysticeti: Reaching the Limits of Latency with Uncertified DAGs." 2024.

Zero-Knowledge Proof Systems

[7] Groth, J. "On the Size of Pairing-Based Non-interactive Arguments." EUROCRYPT 2016. [8] Gabizon, A., Williamson, Z., Ciobotaru, O. "PLONK." 2019. [9] Ben-Sasson, E. et al. "STARKs: Scalable, transparent, and post-quantum secure computational integrity." 2018. [10] Bowe, S., Grigg, J., Hopwood, D. "Halo: Recursive Proof Composition without a Trusted Setup." 2019. [11] Kothapalli, A., Setty, S., Tzialla, I. "Nova: Recursive Zero-Knowledge Arguments from Folding Schemes." CRYPTO 2022. [12] Thaler, J. "Proofs, Arguments, and Zero-Knowledge." 2022.

Zero-Knowledge Virtual Machines

[13] RISC Zero. "RISC Zero zkVM Documentation." dev.risczero.com. [14] Succinct Labs. "SP1 Documentation." docs.succinct.xyz. [15] Aleo. "Aleo Developer Documentation." developer.aleo.org.

Privacy Chains and Protocols

[16] Zcash Protocol Specification. zips.z.cash. [17] Aztec Protocol. "Aztec Documentation." docs.aztec.network. [18] Penumbra Labs. "Penumbra Protocol Specification." protocol.penumbra.zone. [19] Aleo. "Aleo: A Platform for Private Applications." aleo.org. [20] Secret Network. "Secret Network Documentation." docs.scrt.network.

Anonymous Communication

[21] Piotrowska, A. et al. "The Loopix Anonymity System." USENIX Security 2017. [22] Fanti, G. et al. "Dandelion++." SIGMETRICS 2018. [23] Semaphore Protocol. semaphore.appliedzkp.org.

Compute Staking Networks

[24] Akash Network Documentation. docs.akash.network. [25] Render Network Documentation. rendernetwork.com. [26] io.net Documentation. docs.io.net.

Tokenomics and Economic Design

[27] Solana Foundation. "SOL Token Economics." solana.com/economics. [28] SIMD-0228. "Market-Based Emission Mechanism." 2025. [29] SIMD-0096. "Priority Fee Distribution." 2025.

General

[30] Buterin, V. "An Incomplete Guide to Rollups." 2021. [31] Electric Capital. "Developer Report." 2024. [32] Messari Research Reports. 2024-2025.

This document synthesizes research conducted in Modules 01-04 of the Agentic Chain Research Series (February 2026). All parameter values are specifications pending simulation and testnet validation. This is a living document; subsequent versions will incorporate findings from simulation, formal verification, and security audits.