Verification and Accountability

Arweave stores data permanently. Ar.io focuses on the delivery layer: retrieving that data, serving it through independent gateways, and giving clients ways to detect or hold gateways accountable when delivery is wrong.

The key distinction is that storage integrity and delivery integrity are different problems. Arweave can prove that data was committed to the storage layer. A client still needs to know whether a gateway served the right bytes, made honest claims about those bytes, and resolved mutable names correctly.

The Five Layers

The Core Property

When a client knows the transaction ID or data item ID it wants, the strongest verification path is cryptographic: verify the signature chain from the served bytes back to the requested identifier.

For Arweave L1 transactions, the identifier is derived from the transaction signature, and the signature commits to the transaction data root. For ANS-104 data items, the item ID is derived from the data item signature, and the signature commits to the item fields and data.

This means a gateway cannot fabricate different valid bytes for a known ID without the original signer's private key. Other parts of the ar.io architecture make that property easier to use in production.

What This Does Not Prove

Verification is powerful, but the limits matter:

• A signed gateway response proves that the gateway made a claim, not that the claim was true.
• There is no universal proof that a specific client received a complete response body.
• Client-side verification is opt-in and can be configured fail-open or fail-closed.
• Observer-based accountability is sampling-based and is designed for persistent public misbehavior, not every targeted attack.
• ArNS name correctness is separate from content integrity. A client can verify bytes for a transaction ID while still needing to verify that a name resolved to the right ID.

Explore