ar.io
Verification and accountability

Storage is not delivery.

Arweave proves that data was committed and replicated. It does not prove that the gateway in front of it served that data honestly to you. ar.io closes that gap with five composable layers, and is precise about what each one actually proves.

Try the appSee the architecture
The gap

A storage guarantee says nothing about the messenger.

Content-addressed storage gives you a strong property: the identifier is bound to the content. That property lives at the storage layer and does not travel through an intermediary.

A gateway sitting between the record and the reader can serve stale bytes, omit results, misreport its own state, or quietly censor, without breaking a single storage-layer guarantee. Nothing about permanence prevents any of it.

No single mechanism fixes this. The layers below address different failure modes, and they are meant to compose.

Five layers

Each layer catches what the others cannot.

  1. 01

    Commitment

    Arweave

    An identifier is cryptographically bound to its content through the signature and Merkle structure. This holds at the storage layer, and stops there.

  2. 02

    Gateway self-checking

    Each gateway

    A background worker re-reads cached data, recomputes its Merkle root, and compares it to the root indexed from the chain. Mismatches are re-imported rather than served.

  3. 03

    Signed claims

    The response

    Responses carry HTTP Message Signatures tied to a staked onchain identity, so an assertion can be attributed to the operator who made it.

  4. 04

    Client-side checking

    Your application

    Wayfinder can recompute the hash, the data root, or the full signature locally. For a known ID this is trustless: the gateway cannot fabricate matching content without the signer's key.

  5. 05

    Peer observation

    The network

    Gateways sample each other every epoch and stake is at risk for persistent failure, which deters misbehaviour that no single request would reveal.

Claims and proofs

Not everything called verification is a proof.

A signature proves a gateway made a claim. It does not prove the claim is true. Knowing which is which is the difference between auditable infrastructure and a reassuring badge.

The ID you asked forbTM9x…q4ZkSHA-256The signaturechecked against the owner's public keycommits toThe bytes you receivedfrom whichever gateway answered
Every link is something you compute yourself. To hand you different bytes that still hash to this ID, a gateway would need the signer's private key.
X-AR-IO-Verified headerClaimThe gateway asserts it verified its own cache.
HTTP Message SignatureSigned claimThe gateway is accountable for that assertion. It does not make the assertion true.
Co-signed Content-DigestVerifiable digestYou can hash the body yourself and compare.
Arweave signature verificationProofYou verify the content against the signer's key. No operator has to be trusted.
Where trust still lives

What you can check, and what you still take on faith.

Data by known transaction ID

Verifiable locally

That the bytes match the signed commitment for that ID

Still requires trust

Availability of the signature and owner key

An ArNS name

Verifiable locally

That the bytes match the resolved ID

Still requires trust

That the name resolution is correct and current

A gateway trust header

Verifiable locally

That the gateway really made the claim

Still requires trust

Whether the claim is true, which needs independent checking

How the gateway network works
Check it yourself

Do not take our word for it.

Wayfinder performs these checks client side, so an application can confirm what it received without trusting the gateway that served it.

Try the appRead docs