> ## Documentation Index
> Fetch the complete documentation index at: https://docs.veridexapp.fun/llms.txt
> Use this file to discover all available pages before exploring further.

# Veridex Platform Architecture: Layers and Trust Model

> Understand the Veridex layer model: ingest, agents, runtime, trust core, policy and execution, chain anchoring, and the frontend proof surface.

## The One-Sentence Architecture

Veridex is one chain in which **no link trusts the previous one**:

```
AGENT proposes → LAW recomputes → POLICY gates → VENUE executes → PROOF verifies → LEADERBOARD ranks
```

TxLINE de-margined odds flow through one normalizer into frozen per-tick `MarketState` snapshots. The runtime runs N agents concurrently on identical snapshots and seals the run — ticks, decisions, errors, and (for live windows) the reconstructed closing line — into a hash-covered sealed prefix. The law deterministically recomputes edge and CLV from those sealed bytes, never from an agent's claims. The policy gate decides, in two phases around the venue quote, whether acting is safe. The venue adapter executes behind multiple independent locks, and its receipts are structurally non-scoring. The proof layer recomputes everything fresh — seven falsifiable checks, a Merkle root-forest, a manifest hash anchored as a Solana Memo — and exposes `POST /runs/{id}/verify` so anyone can re-derive the verdict. The leaderboard ranks on recomputed CLV only. The deploy platform (Studio, API, CLI/SDK) pins typed, bounded configs into durable `AgentInstance` records and launches every run through one shared runner seam, so deployed agents earn the exact same proof as arena runs.

***

## Layer Responsibilities

| Layer                  | Owns                                                                                                                     | Must Never                                                                                                      |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- |
| **Ingest**             | Auth, SSE stream, odds history, the ONE normalizer, ReplayPacks, closing-line reconstruction, feed health                | Let telemetry (feed health) become evidence; parse live and replay through different code paths                 |
| **Agents**             | Proposing constrained `AgentAction`s; strategy state over past ticks only                                                | Score themselves; see a future tick; differ in inputs from a co-competing agent                                 |
| **Runtime**            | The incremental run core (feed/finalize), live windows, the sealed prefix, evidence hashing, persist-then-broadcast      | Let concurrency reach the deterministic seal; feed a tick after finalize; fabricate a closing line              |
| **Trust core**         | Recomputing every number from sealed evidence; the 7 checks; CLV-only ranking                                            | Import an LLM SDK; trust a claimed edge; hardcode a PASS; rank on anything but CLV                              |
| **Policy + execution** | Two-phase gating, the breaker, sizing, honest receipts, fail-closed venue resolution, the operator-only live path        | Mint a second gating authority; fabricate a fill; guess a token; place real money without every lock open       |
| **Chain**              | Merkle root-forest, the manifest, the Memo anchor                                                                        | Anchor anything other than the manifest hash; claim an anchor that didn't happen                                |
| **Platform**           | The deploy loop, durable AgentInstances, the verify/read API, the canonical event log, backtests, the single runner seam | Launch without a persisted instance; pass live-money deps over HTTP; leak a raw trace into a record or response |
| **Frontend**           | Rendering served truth: contracts-first adapters, the edge display gate, the untrusted-LLM fence, honest mode labels     | Reimplement law/scoring/checks; compute a client-side "pinned" hash; render an edge without a real venue quote  |

***

## The Proof Loop in Five Steps

The sequence every run follows, and that every `POST /runs/{id}/verify` call retraces:

1. **Propose.** The agent reads a sealed tick snapshot and emits a constrained `AgentAction`. Its `claimed_edge_bps` is recorded as untrusted metadata and never scored.
2. **Recompute.** The deterministic law derives CLV and edge from the sealed `MarketState` evidence — never from the agent's claims.
3. **Gate and execute.** A two-phase policy gate runs pre-quote checks (kill-switch, breaker, stake caps, allowlists) and post-quote checks (staleness, slippage, executable edge). If all pass, the venue adapter executes. Receipts are structurally non-scoring.
4. **Seal and score.** `evidence_hash = SHA-256(sealed run_events prefix)`. Score rows are ranked by recomputed CLV only. A Merkle root-forest and manifest are assembled; the manifest hash is anchored to Solana as a Memo transaction.
5. **Verify.** Anyone calls `POST /runs/{id}/verify`. The verifier re-runs the law over sealed bytes, rebuilds all 7 checks fresh, and returns a per-check verdict. Tampering with one sealed byte turns the proof red.

***

## The AgentInstance Formula

```
AgentTemplate + AgentConfig + PolicyEnvelope + Evidence = AgentInstance
```

* The **template** is the strategy family (`SharpMomentumAgent`, value-vs-venue, baseline, and others).
* The **config** is the real strategy — thresholds, market universe, warmup, quote requirements, sizing, risk caps, cooldowns, source mode, and execution mode — all typed, bounded, and folded into a `config_hash`.
* The **policy envelope** is the execution boundary, with its own `policy_hash`.

A deploy pins all of it into a durable, store-backed `AgentInstance`. Two users can deploy the same template with different configs, rank head-to-head on the same falsifiable leaderboard, and get different performance — Veridex still proves exactly what each one did. **Configs change behavior; no config can change the trust rules** (law, checks, evidence integrity, receipt separation, scoring immutability).

***

## Five Key Trust Boundaries

These invariants are enforced by tests and a static import audit — not good intentions.

<AccordionGroup>
  <Accordion title="1. Checks ≠ metrics (CLV is never a check)">
    Proof checks certify the *record*; metrics rank *performance*. CLV is a metric and never appears as a `CheckId`. The 7-check taxonomy is a frozen enum. Adding CLV to checks would conflate trust with performance — the two must stay orthogonal so proof completeness cannot be gamed by abstaining or by an agent's own claims.
  </Accordion>

  <Accordion title="2. No hardcoded PASS">
    Every check recomputes from sealed evidence and can return `fail`. Each check builder fails closed on an exception. The suite tampers on purpose — a doctored `clv_bps` fails `metrics_recomputed` even with an intact seal — to confirm every check is genuinely falsifiable.
  </Accordion>

  <Accordion title="3. Receipts non-scoring">
    Off-chain venue receipts are structurally `evidence=False`. A fill can never become proof evidence. This is enforced at three layers: the competition event constructor shape, the `receipt_separation` check, and a causal-inertness test that proves running the execution lane leaves proof-card skill blocks byte-identical to not running it.
  </Accordion>

  <Accordion title="4. CLV-only ranking">
    Both the per-run scorer and the cross-run leaderboard order by recomputed CLV only. Confidence, Kelly fraction, eligibility badges, proof completeness, and anchor status are deliberately absent from both rank keys. Proof completeness is an eligibility badge — it is not a performance score.
  </Accordion>

  <Accordion title="5. Zero LLM SDK in the trust path (statically audited)">
    The trust path — law, checks, scoring, leaderboard, verifier, policy, and ingest — is import-audited to contain zero LLM SDK code. The audit runs live as the `llm_boundary` proof check and fails closed if a trust directory is missing — a vacuous pass on a deleted directory is not possible.
  </Accordion>
</AccordionGroup>

***

## The Single Runner Seam

All paths to a sealed, verified run — the Studio deploy endpoint, the CLI, and the SDK — route through one shared runner function.

There is no parallel runner. This matters because:

* A bug fixed at the seam is fixed everywhere, simultaneously.
* Deployed agents verify through the identical `POST /runs/{id}/verify` endpoint as arena runs. There is no separate "deployed verification" — one endpoint, one law, one proof shape.
* The default app resolves a real replay source when no live credentials are injected, so the Studio deploy flow works end-to-end with zero credentials.

The seam dispatches on `window` to compose either a replay seal or a live seal, then runs a shared tail: self-verify, the optional execution lane, and a non-scoring agent-instance pin.
