Raven

Raven is a framework for fetching state from a server without revealing which record you asked for.

Live Ethereum Mainnet Open Source WASM Client Private Information Retrieval
What Raven Does01
01

Hides Your Query

The server answers a question it cannot read.

Your query is encrypted before it leaves the device. The server computes over the whole database without ever learning which record you wanted. One server, so there is no non-collusion assumption to depend on.

02

Fits on the Edge

No gigabytes to sync, no hints to keep current.

The client is hintless and compiles to WebAssembly. A browser or a phone asks for the one record it needs, instead of downloading the entire dataset just to stay private.

03

Fresh to the Chain

Answers within seconds of the chain head.

A small live sidecar absorbs new blocks in milliseconds while a heavy main engine serves the snapshot. Reads stay current without rebuilding the world on every update.

Mechanism →02
How a blind read works

Single-Server PIR

The database is a matrix. Your encrypted query is indistinguishable from noise. The server multiplies it across every row and returns a single encrypted column that only your device can open. What it sees is a query for an opaque index, and nothing more.

Use Cases03
Shielded wallets & membership trees

Private reads for shielded wallets and membership trees

Before a wallet can build a proof, it reads its Merkle path and membership status from a server that holds the tree, and that read alone reveals which leaf is yours. Raven serves the read blind: the client fetches the path it needs while the operator learns nothing about which leaf was requested, and the proof is assembled locally. Shielded-pool reads and inclusion proofs share one PIR shape, a blind fetch of sibling nodes by index over an append-only tree, so the same engine serves a Privacy Pools or Railgun path and a Semaphore or World ID membership proof.

How it works
Data modelAppend-only tree (e.g. LeanIMT)
Query shapeBlind fetch of a leaf's siblings
RevealedNot which leaf (LWE-hard)
VerificationPath checked vs on-chain root
ClientHintless, in-browser
Balance & storage reads

Private balance and state reads

A balance or storage lookup hands your RPC provider the exact address and slot you care about, along with your IP, timing, and device fingerprint, enough to profile and deanonymize you. With hundreds of millions of active accounts, holding the state trie locally is infeasible on consumer hardware, so the read goes through a third party by necessity. Raven answers the same point reads without ever learning the target, by address or by row.

How it works
Data modelState as key-value or indexed table
Query shapePoint read by address or by row
RevealedNot the address or slot (LWE-hard)
VerificationOpen problem, not yet practical
ClientStateless per session
Stealth-address payments (EIP-5564)

Private stealth-address payment scanning

Stealth-address standards let a sender pay you at a fresh one-time address by publishing an ephemeral public key to an on-chain announcement set, which every recipient must scan to find payments meant for them. Scanning that public set through a server reveals which announcements you checked, the exact link the standard is designed to break. Raven lets a wallet scan the set blind, so the server learns neither which announcements you read nor which ones were yours.

How it works
Data modelAppend-only announcement log
Query shapeBlind scan over the set
RevealedNot what you read, nor what's yours
VerificationAddress re-derived locally
ClientAny EIP-5564-style scheme
Sanctions, scam & allowlist screening

Private allowlist and sanctions checks

Wallets and dapps increasingly check an address against a public list, sanctions sets, scam and address-poisoning blocklists, or an allowlist, but asking a server "is this flagged?" reveals exactly which address you are about to touch. Encoding the list as a compact approximate-membership filter answers the membership question without disclosing the queried key. Small lists are downloaded and checked entirely offline; when a list is too large to ship, the same filter is queried blind.

How it works
Data modelList as approximate-membership filter
Query shapeIs this key in the set?
RevealedNot which key was checked
ApproximateA hit is re-checked exactly
ClientLocal for small lists, blind for large
Architecture →04
Sharded Engine

A heavy main, a small live sidecar

The main engine serves a stable snapshot with fast sublinear queries. The sidecar holds only what changed since that snapshot and rebuilds every block. The client queries both and keeps the fresher answer.

When the sidecar fills it folds into the main on a parallel copy, which swaps in atomically. No downtime, no stale window, no torn reads.

Follows the sharded PIR design for Ethereum state. Read the research →

Key-to-row mapping05
The pluggable mapping layer

Mapping data to rows

A PIR server only ever sees a flat array of fixed-width rows and a request for row N. The mapping layer is the function from an application lookup to that row index, and Raven makes it pluggable. Pick a family to see the tradeoff:

StructuredPublic structure: the client derives the index itself.index
Cuckoo hashingA key hashes to candidate rows; placement picks one.keyword
Binary fuse filterA key's value is XOR-combined from a few slots.keyword
Probabilistic batch codesMany lookups spread across buckets, one query each.batch

Cuckoo hashing & PBC: SealPIR, eprint 2017/1142. Binary fuse filter: ChalametPIR, eprint 2024/092.

Blind. Verifiable. Fresh.

The query is encrypted before it leaves your device. The server computes the answer it is not allowed to read.

Verified against the on-chain root, fresh to within seconds of the chain head. Same proofs, same chain, blind reads.

Read the Post Launch Demo