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

# On-Chain Blob Anchoring

> How every Walrus evidence blob is anchored to Sui — Blob objects, register/certify transactions, protocol events — and how to independently retrieve and verify a record.

# On-Chain Blob Anchoring

Storing evidence on Walrus alone would leave "which blob belongs to which attack" as a claim only
the platform could check. Anchoring closes that gap: the correspondence between each evidence blob
and its attack is fixed **on Sui**, so the complete evidentiary record for any attack can be
independently retrieved and verified from the chain alone.

## What anchors a blob

Each evidence blob is anchored by three coordinated artifacts:

1. **The Walrus `Blob` object on Sui.** Storing a blob on Walrus creates a `register` transaction
   and a `certify` transaction on Sui (the Walrus system package). The resulting `Blob` object is
   a first-class Sui object; in the default user-signed flow it is **owned by the attacker's
   wallet**.

2. **The register/certify transaction digests.** The Sui transaction digests of the blob's
   `register` and `certify` transactions are recorded alongside the attack record, together with
   the certification timestamp. These digests are the tamper-evident link between the attack and
   its blob: anyone can replay them on an explorer and confirm which blob id was registered, by
   which address, when.

3. **The protocol events.** The attack itself is already on Sui — the Sentinel contract emits
   `PromptConsumed` (attack paid, verdict received) and, on a breach, `AgentDefeated` (bounty
   released). Verdict data in the evidence blob therefore always corresponds to a concrete
   on-chain settlement.

## Independent verification walkthrough

Given a blob id (from the [Evidence Explorer](https://docs.redsentinel.xyz/walrus/evidence-explorer.md), a shared link, or an
attacker's profile), a third party can verify the record with nothing but `curl`:

```bash theme={null}
# 1. Fetch the raw bytes from a public Walrus aggregator
curl https://aggregator.walrus-mainnet.walrus.space/v1/blobs/<BLOB_ID>
```

* The response **is** the evidence record — the same bytes the platform verified at link time.
  Check the fields against the [schema](https://docs.redsentinel.xyz/walrus/evidence-schema.md): does `success`/`score` match the
  claim being made?
* Cross-check the provenance: `sentinelId` and `deployTxHash` can be looked up on
  [Suiscan](https://suiscan.xyz/mainnet) / [SuiVision](https://suivision.xyz), and `userAddress`
  identifies the attacker wallet that paid for and owns the record.

Given an attack on-chain instead, the reverse path works: the attacker's wallet owns the Walrus
`Blob` object, the register/certify digests recorded for the attack name the exact transactions,
and the platform surfaces the pair on the attacker's profile and in the
[Public Evidence Explorer](https://app.redsentinel.xyz/evidence).


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