Products / File storage

File storage that proves itself.

Upload any file and serve it back byte-for-byte provable — content-addressed, chunked, and verified against chain consensus on every download.

The file you get out is the file you put in.

A URL tells you where a file lives, not what it is. Buckets get overwritten, CDNs re-encode, links rot — and nothing about the bytes you receive proves they're the bytes that were stored.

Willow stores files content-addressed: chunked, hashed, and Merkle-committed to chain consensus. The file's identifier is a fingerprint of its content, so the address and the bytes can't drift apart. On download, your client re-hashes what it receives and verifies it against the chain.

Storage nodes don't just promise to hold your data — they prove availability to the network on an ongoing basis, so a file that's "stored" is a file that's actually there.

Content-addressed

A file's address commits to its content. Two parties holding the same identifier can independently confirm they're looking at the same bytes.

ChunkedDeduplicated addressing

Verified downloads

Chunks verify against the Merkle commitment as they arrive. A flipped bit, a truncated file, or a swapped version fails the proof on your machine.

Byte-for-byteVerify on receive

Availability you can audit

Storage nodes stake and continuously prove they still hold the data. Missed proofs are visible to the network, not hidden in an SLA.

Availability proofsClient-side encryption
How it works

From setup to verified reads.

  1. 01

    Upload

    Files are chunked and hashed client-side. Encrypt first if the content is private — verification works on ciphertext just as well.

  2. 02

    Commit

    The file's Merkle commitment lands in chain consensus. From this point the content and its address are inseparable.

  3. 03

    Serve

    Storage nodes hold the chunks and keep proving availability. Downloads pull from the network like any CDN fetch.

  4. 04

    Verify

    The SDK re-hashes received chunks against the on-chain commitment. If verification passes, the bytes are provably the original.

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

// Upload — chunked, hashed, committed
const file = await client.files.upload(reportPdf);

// file.id is the content address
const bytes = await client.files.download(file.id, {
  verify: true, // re-hash against the chain
});

Common questions.

  • How is this different from S3 or IPFS?

    S3 is trust-based — you get whatever the bucket returns. IPFS gives you content addressing but no consensus commitment and no accountability for availability. Willow adds both, plus the same SDKs and proofs as your records, so files and structured data live in one verifiable system.

  • Can files be private?

    Yes — encrypt client-side before upload. Content addressing and verified downloads work on ciphertext exactly as they do on plaintext; the network never needs to see the contents.

  • What happens if a storage node disappears?

    Nodes prove availability continuously, so a disappearing node is detected by missed proofs rather than discovered by a failed download. The network re-replicates from remaining holders.

Store something provable.

Upload a file from the dashboard and download it back with the proof attached.

Partners

Request a call