> ## 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.

# Known Limitations

> Known limitations and constraints of the initial Walrus evidence release — what the v1 blob contains, what it does not yet contain, and the roadmap.

# Known Limitations

This page states the known limitations of the initial (Milestone 1) Walrus evidence release, so
integrators and auditors know exactly what a v1 evidence blob does and does not prove.

## Evidence blob content

* **Verdict rationale, classification and chain-of-thought are not yet in the blob.** The v1 record
  carries the attack prompt, agent response, binary verdict, numeric jury score, and provenance
  ([schema](https://docs.redsentinel.xyz/walrus/evidence-schema.md)). 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**. Until they ship, the rationale/classification/CoT remain in the platform's private
  evaluation store rather than in the public blob.
* **No per-blob TEE attestation receipt yet.** Enclave integrity is currently enforced by the
  platform: the enclave runs a measured, pinned build (PCR values pinned in the frontend
  configuration) and publishes its signing key through the Sentinel contract's
  `EnclavePubkeySet`/`EnclavePubkeyUpdated` events. The evidence blob itself does not yet embed a
  self-contained Nitro attestation document — that is the Milestone 2 `teeAttestation` field.

## Anchoring

* **Anchoring composes existing on-chain artifacts rather than a dedicated module.** Each blob is
  anchored via the Walrus system `Blob` object, the recorded register/certify transaction digests,
  and the Sentinel contract's `PromptConsumed` / `AgentDefeated` events. There is not yet a custom
  Move module emitting an explicit `EvidenceAnchored { attack_id, blob_id }` event; resolving
  attack → blob today goes through the platform indexer (surfaced in the explorer and profiles) or
  the attacker's owned `Blob` object. The dedicated module is on the
  [Milestone 2 roadmap](https://docs.redsentinel.xyz/walrus/milestone-2-status.md).

## Storage and retrieval

* **Cold reads can be slow.** A blob that has not been read recently may take tens of seconds to
  come back from the storage nodes via a public aggregator. The evidence explorer surfaces this as
  a "still retrieving — retry" state rather than a failure.
* **Aggregators are third-party infrastructure.** The public aggregator endpoints used for reads
  are operated by the Walrus ecosystem, not Red Sentinel. Anyone can run their own aggregator or
  use the Walrus SDK against the network directly; the blob id is the only permanent handle.
* **Storage is epoch-limited.** Records are reserved for 5 Walrus epochs. Walrus blob ids are
  content-derived, so re-registering identical bytes yields the same id if longer retention is ever
  needed.

## Trust model

* **Record content is server-authoritative at link time.** The platform builds the canonical
  record and verifies the stored blob field-by-field before linking the blob id to an attack. A
  client cannot forge `success`/`score` in a linked record — but a fully trustless reader would
  still rely on the read-back guarantee plus on-chain verdict events rather than re-running the
  model inside the enclave. Per-blob attestation (Milestone 2) is what makes the blob self-evident.
* **Prompts and responses are public by design.** Evidence blobs are readable by anyone with the
  blob id (and are listed in the public explorer feed). Attackers should treat their prompts as
  published artifacts.


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