Products / Structured storage

Structured storage with proofs built in.

Store SQL-shaped records on Willow and read them back with cryptographic proofs — tamper-evident data storage your users, auditors, and AI agents can check without trusting you.

A database whose answers you can check.

Every database you've ever used returns rows on trust. Whoever holds the keys can edit history — an UPDATE rewrites yesterday, and no SELECT will ever tell you it happened.

Willow stores structured records in authenticated subgroves committed to chain consensus. Every insert and update lands in a Merkle-anchored tree, and reads return proofs that the rows are exactly what consensus committed — nothing added, nothing dropped, nothing edited after the fact. Records can be private, too: the data stays with your provider, and only state-root commitments touch the chain.

Schemas, filters, range queries — it works like the structured storage you already know, through SDKs for Rust, TypeScript, Python, Go, Swift, and React Hooks. The difference is the receipt.

Schemas and queries

Define typed schemas under your own subgrove. Insert, update, and query with filters and range scans — SQL-shaped records without the SQL server.

Typed schemasRange queries

Tamper-evident by construction

Records are Merkle-committed at consensus. Editing history breaks the proofs — silent mutation is not a thing that can happen quietly.

Merkle-committedAppend-attributable

Proofs on every read

Query responses carry proofs anchored to the chain state root. Verify in a browser, a backend, or an AI agent's tool call — no callback to Willow required.

Local verificationPortable proofs
How it works

From setup to verified reads.

  1. 01

    Create

    Register a subgrove and define a schema for your records — fields, types, and the keys allowed to write.

  2. 02

    Write

    Inserts and updates are signed transactions. Every write is attributable to a key and ordered by the chain.

  3. 03

    Query

    Filter and range-scan through the SDKs, the same shape as a normal database call.

  4. 04

    Verify

    Responses include Merkle proofs anchored to the consensus state root. Anyone holding the data can re-check it, years later.

TypeScript
const client = new WillowClient({
  apiUrl: 'https://api.willow.tech',
});

// Insert a record under your subgrove
await client.data.insert('audit-log', {
  id: 'evt_01HZ...',
  actor: 'svc-payments',
  action: 'refund.issued',
  amount: 1499,
});

// Read it back later — with proof
const events = await client.data.query('audit-log', {
  filter: { actor: 'svc-payments' },
  include_proof: true,
});

Common questions.

  • Is this a SQL database?

    It's SQL-shaped — typed schemas, filters, range queries — exposed through the SDKs rather than a SQL socket. If you can model it as rows, you can store it and prove it.

  • Who can write to my data?

    Writes are signed transactions against your subgrove. Only keys you authorize can write, and every write is attributable and ordered by the chain — an audit trail by default.

  • What do verified reads actually protect against?

    Stale responses, dropped rows, and edited history. A proof that verifies means the rows match what consensus committed — not what a server, a cache, or an operator decided to return.

  • Can my records be private?

    Yes. Register the subgrove as private: your records stay with your storage provider and only state-root commitments go on-chain. Read access is per-identity, granted with encrypted keys through any of the SDKs — and the proofs still work, so private data stays just as verifiable.

Create a subgrove.

Define a schema from the dashboard and write your first provable records today.

DashboardRequest a call
Partners

Request a call