Verification

Everything Willow returns can be checked. This page explains what “verified” means and where the checking happens.

The idea

Willow commits its state into a Merkle-ized store. Every read can come with a proof: a small set of hashes showing that the value you got is part of the state committed at a particular block. Recomputing those hashes up to the committed root tells you the value is genuine and unmodified — without trusting the server that handed it to you.

A result whose proof checks out is Willow verified.

Where verification happens

The proofs are designed to be verified client-side:

• The SDKs verify proofs locally — in your backend or in the browser — before returning data to your code. The TypeScript SDK does this in pure TypeScript (no WASM); other SDKs verify natively.
• The dashboard verifies query results in the browser and shows a ✓ Willow verified line with the proof count.

If a proof fails to verify, the SDKs throw rather than return unverified data. Verification is on by default — you opt out, not in.

What’s covered

• Reads — key/value records and indexed rows come with Merkle proofs over committed state.
• Files — downloads are verified chunk-by-chunk against the file’s Merkle root.
• Indexing correctness — that the indexed data was computed correctly is handled separately, by the subgrove’s execution mode.

Identity

Writes are authenticated with a DID (decentralized identifier). Willow supports Ed25519 and secp256k1 (Ethereum-compatible) keys, so a write is signed and attributable.

Going further

• An optional light client verifies CometBFT block headers, so you can check proofs against headers you trust rather than headers the server asserts.
• For independently checkable computation proofs, see GkrExecution.