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

# Evidence Pipeline Architecture

> The TEE-to-Walrus pipeline: how an attack verdict produced inside the AWS Nitro Enclave verification environment becomes a certified evidence blob on Walrus.

# Evidence Pipeline Architecture

This page describes the TEE-to-Walrus evidence pipeline: the path a completed attack takes from
verification inside the enclave to a permanent, certifiable blob on Walrus.

## End-to-end flow

```
 Attacker (browser)
   │  1. submit attack prompt
   ▼
 Backend API ──────────────────────────────┐
   │  2. route prompt to Sentinel agent    │
   ▼                                       │
 TEE Verification Env. (AWS Nitro Enclave) │  canonical record
   │  Sentinel agent executes the prompt   │  bytes are built
   │  LLM jury scores the response         │  server-side and
   │  3. verdict: success / score          │  handed to the
   ▼                                       │  storer (never
 Backend API                               │  the reverse)
   │  4. persist attack doc + verdict      │
   ▼                                       ▼
 Walrus  ◄──────────── 5. encode → register → write → certify ────────
   │
   │  6. read-back verification (field-by-field)
   ▼
 On-chain anchoring: blob id + register/certify tx digests
 linked to the attack record (see Blob Anchoring)
```

### Step by step

1. **Attack submission.** The attacker submits a prompt against a Sentinel. The attack fee is paid
   on-chain and the attempt is recorded by the Sentinel smart contract
   (`PromptConsumed` event).

2. **Enclave execution.** The prompt is routed to the Sentinel agent running inside the **AWS
   Nitro Enclave** verification environment. The Sentinel agent produces its response, and an LLM
   jury inside the same trusted path evaluates it, producing the verdict (`success` flag and a
   0–1 evaluation `score`). Attack outcomes settle on Sui through Move smart contracts
   (`AgentDefeated`, fee transfers), so the verdict that later lands in the evidence blob is the
   same verdict that released or accumulated the bounty.

3. **Canonical record construction.** When the attack completes, the backend builds the canonical
   evidence record — the exact JSON bytes described in
   [Evidence Blob Schema](https://docs.redsentinel.xyz/walrus/evidence-schema.md) — from the persisted attack document. Record
   content is **server-authoritative**: the bytes are handed out for storage, but they are never
   accepted back from a client (see step 6).

4. **Walrus storage.** The record (2–10 KB of UTF-8 JSON) is written to Walrus and reserved for
   **5 storage epochs**. Two storage modes are supported:
   * **Backend-signed** — a backend-operated storage wallet encodes the blob and pays the register
     * certify transactions directly via the Walrus SDK (`@mysten/walrus`).
   * **User-signed** (the default for live attacks) — the attacker's own wallet owns the record:
     the browser fetches the canonical bytes, encodes the blob locally, signs and pays the
     `registerBlob` transaction, writes the encoded slivers to the Walrus storage nodes, collects
     confirmations into a certificate, and signs the `certifyBlob` transaction. The attacker
     keeps custody of the Walrus `Blob` object.

5. **Read-back verification.** Before a blob id is linked to an attack, the backend reads the blob
   back from the Walrus storage nodes and compares it **field by field** against the canonical
   record. A blob that does not match — wrong values or extra fields — is refused. A client can
   therefore never link an attack to content it forged.

6. **Anchoring.** Once verified, the blob id (plus the Sui transaction digests of the register and
   certify transactions) is linked to the attack record. See
   [On-Chain Blob Anchoring](https://docs.redsentinel.xyz/walrus/blob-anchoring.md).

## Trust model

* **What the TEE guarantees:** the Sentinel agent response and jury verdict are produced inside the
  enclave's trusted execution path — the platform itself cannot quietly rewrite an answer mid-attack.
* **What Walrus guarantees:** once certified, the record's bytes are immutable and permanently
  retrievable by blob id for the reserved epochs.
* **What the read-back verification guarantees:** the blob linked to an attack is byte-identical to
  the canonical record the platform built from the TEE-produced verdict.
* **What is *not* yet in the blob:** the jury's free-text rationale, the attack classification, the
  full chain-of-thought trace, and a TEE attestation receipt are Milestone 2 schema extensions — see
  [Known Limitations](https://docs.redsentinel.xyz/walrus/known-limitations.md).

## Operational parameters

| Parameter | Value |
| - | - |
| Record format | UTF-8 JSON, one object per attack |
| Record size | \~2–10 KB |
| Storage duration | 5 Walrus epochs (`WALRUS_STORE_EPOCHS`) |
| Storage payer | Attacker wallet (user-signed) or backend storage wallet (backend-signed) |
| Networks | Walrus mainnet (default) and testnet |
| Read path | Public aggregator, plain HTTPS GET |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.