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

# Content addressing

> Every blob is addressed by its BLAKE3 hash and verified in-stream with bao, so clients never trust a node to return the right bytes.

## Decision

Every blob is identified by its **BLAKE3 hash**. Clients and nodes verify received bytes against the known hash on every transfer. The hash→backend mapping is internal to each origin-backed node and never shared — no participant in the network can learn or bypass the node's backing storage.

## Why BLAKE3

* **Fast.** Several GB/s on modern hardware — faster than SHA-256, often limited by memory bandwidth rather than CPU.
* **Tree-structured.** The BLAKE3 hash tree enables streaming verification: a client can verify chunks as they arrive rather than waiting for the full blob.

## Verified streaming

Delivery uses **bao** — an interleaved verified-stream encoding of the BLAKE3 tree. The `cdn/client/v1` paid-delivery payload is always bao bytes: content interleaved with the hash proofs needed to verify each 16 KiB chunk group against the root the client expects. The bao decoder verifies every chunk group as it arrives. A malicious node cannot insert a single corrupt byte and still earn — the client rejects the stream before paying for that chunk group.

Because every chunk group carries its own proof, a resumed or ranged fetch verifies **independently** — the decoder aligns the requested offset down to its 16 KiB chunk-group boundary, so there's no need to re-read from the start. Payment meters all transmitted bytes, including the proof bytes: the verification overhead is roughly **0.4%** of blob size, not free metadata.

An origin-cold node must import or build the blob's **outboard** (its BLAKE3 tree) before it can serve verified ranges. Node-to-node cache-miss pulls stay bao-encoded and pipelined end to end.

## Hash-to-object-key mapping

Origin backends speak their own namespace: S3 objects are addressed by key, NFS by path, local disk by filename. Blobs are addressed by BLAKE3 hash. The mapping lives in a **content catalog** — a small database (PostgreSQL or SQLite) maintained by the operator:

```text theme={null}
catalog: hash → { s3_bucket, s3_key, size_bytes, content_type }
```

The catalog is not on-chain; it is an operational concern. Origin-backed nodes query it on cache miss to locate the pull URL.

## Why the origin is hidden

Leaking the origin URL would bypass the pay-per-byte economic model — anyone could download directly from S3 and skip the CDN entirely. Redirects point to other nodes, never to an external URL. The origin backend is not addressable from outside the node process.

This also protects origin operators from direct egress cost attacks: an adversary cannot generate S3 traffic by pointing clients at the bucket URL.

## What clients verify vs. trust

| Property          | Verified         | Trusted                                                                    |
| ----------------- | ---------------- | -------------------------------------------------------------------------- |
| Byte correctness  | BLAKE3 hash tree | —                                                                          |
| Blob availability | —                | Node's signed availability claim (slashable via phantom-announcement path) |
| Origin durability | —                | Origin operator's S3/NFS configuration (off-protocol)                      |