Ethereum Read Privacy

Why Ethereum reads leak

Most wallets and dApps fetch state through remote RPC. The provider sees which accounts, contracts, and slots you touch, when you touch them, and how those reads cluster before a swap or transfer.

That access pattern enables profiling, correlation of on-chain and off-chain identity, and extractive strategies that do not need mempool visibility. TLS encrypts the pipe. It does not hide the query from the operator.

Verification vs privacy

A trustless client such as Colibri verifies proofs so you do not have to trust the RPC for correctness. Privacy is separate: the same verified request can still reveal intent to whoever serves the data and proofs.

PAP therefore sits beside verification. Correctness and confidentiality are both required for practical Web3 privacy — neither replaces the other.

Ethereum trustless clientColibri

PAP: two axes, not an on/off switch

Pragmatic Adaptive Privacy models read privacy along two independent axes. Transport (T) asks who is asking. Content (C) asks what is being asked. Each axis has levels; a Privacy Profile combines one T with one C.

• T0 — Direct RPC: one provider sees IP, session, and the full read pattern
• T1 — Split, rotate, proxy: fragment the profile across paths; not full anonymity
• T2 — Tor, mixnets, relays: stronger unlinkability of origin at higher latency
• C0 — Exact query: contract, method, and slot are visible as requested
• C1 — EVQ: broaden the read, verify the set, select locally
• C2 — Oblivious access: PIR, ORAM (for example inside a TEE)

PAP product pagePAP article

EVQ — Extended Verifiable Query (C1)

EVQ is the pragmatic content-privacy technique at PAP level C1. Instead of asking for one exact item (for example the price of pool A), the client generalizes the request to a broader, proof-backed set (for example all pools of the pair).

RPC, vRPC, or a prover returns data and proofs for that set. Colibri verifies every item locally, then extracts only the needed result. The provider sees a less specific query. Intent becomes ambiguous — not secret.

• Works on existing RPC infrastructure — no new private-read network required
• Low overhead where ambiguity is enough for the risk
• Always paired with local verification of the returned set
• Limit: ambiguity, not secrecy; long-term pattern analysis can still narrow intent

PAP live demovRPC

PIR, ORAM, and maximal content privacy (C2)

Private Information Retrieval (PIR) lets a client retrieve an entry without the server learning which entry was accessed. Oblivious RAM (ORAM) hides access patterns so reads and writes look indistinguishable to storage. Both sit at PAP level C2 — oblivious access.

These constructions can provide very strong content privacy. On Ethereum they collide with freshness, trustless verification, bandwidth, and latency. PIR and ORAM (including ORAM inside a TEE) are tools for high-risk reads, not a universal default for every eth_call.

PAP does not replace PIR or ORAM research. It places them on the same matrix as EVQ so teams can choose by risk, cost, and deployability — as much privacy as the read needs, and no more.

Content privacy options for Ethereum reads

Illustrative placement in the PAP Content (C) axis — not a claim that every product ships every technique.

FAQ