Reads are not neutral
Balance checks, simulation previews, and log queries expose addresses, contracts, and storage slots. Even when responses are correct, the server learns user behavior and intent.
Functional access without oversharing.
PAP is a privacy model for blockchain read paths. It limits what infrastructure providers can infer from your queries — addresses, balances, contract interest, and timing — while keeping applications usable.
Cryptographic verification tells you data is authentic — but every eth_getBalance, eth_call, and eth_getLogs still reveals who you are, what you hold, and what you intend to do. In Web3, the RPC provider is an adversary by default: metadata becomes someone else's dataset.
Balance checks, simulation previews, and log queries expose addresses, contracts, and storage slots. Even when responses are correct, the server learns user behavior and intent.
All-or-nothing privacy breaks UX. Applications need configurable exposure: strict for wallets, pragmatic for dashboards, broader where analytics require it.
Trustless state access removes correctness risk from RPC lies — but a verified answer can still be observed, delayed, or correlated. Privacy must be designed into the read path.
PAP adapts how data is requested and exposed depending on context — reducing leakage while keeping Web3 applications functional.
Privacy discussions in Web3 often focus on transactions. But decisions are formed through reads — and those reads are observable long before anything reaches the mempool.
Transactions execute a decision; reads form it. Balances, simulations, storage queries, and historical data all flow through RPC providers by default — externalizing the decision process and making it the primary source of information leakage.
Read sequences reveal the shape of a planned action: which contracts were evaluated, which parameters tested, which simulations run. A single request can be indicative; a sequence before signing can expose target, size, and timing — with no on-chain footprint.
Adversaries with read-level visibility can anticipate transactions, identify high-value targets, and profile users over time. Front-running and strategy exploitation do not require mempool access when intent is visible at the read layer.
As long as reads remain externally observable, Web3 privacy is structurally incomplete. PAP addresses this layer explicitly — not only what executes on-chain, but what is revealed while deciding.
PAP models read privacy along two independent axes — who can observe a request (Transport) and what can be inferred from it (Content). Each axis has three levels; a Privacy Profile combines one T with one C.
Who is acting?
Requests follow stable, directly linkable transport paths. Long-term correlation and attribution are straightforward.
Requests are distributed across paths or providers. Linkability is reduced, but attribution remains possible.
Routing makes persistent attribution impractical under realistic threat models — e.g. Tor or mixnets.
What is being read or inferred?
Reads expose concrete state and semantics directly. Intent is immediately visible.
Reads are partially aggregated or abstracted. Intent may still be inferred, but with reduced confidence — the pragmatic default for most apps.
Reads are structured to limit semantic interpretation. Intent inference is minimized, often at higher cost.
Each read operation maps to one cell in the T × C matrix — for example T1/C1 for pragmatic transport and content privacy, or T2/C2 for strong protection in both dimensions. The matrix is a design space, not a ladder: stronger privacy always trades against latency, bandwidth, and complexity.
PAP is not a single switch. Applications choose how strictly to limit exposure based on user risk, feature needs, and operational constraints.
Read patterns adapt to what the application is doing — wallet balance vs. public dashboard vs. batch indexer — so exposure matches the actual need.
Teams set policy per flow: maximum privacy for signing decisions, pragmatic defaults for exploration, optional relaxation where UX requires broader reads.
PAP works alongside multiple provers, query broadening, local provers, and network-level privacy — verification for correctness, PAP for what gets revealed.
Applications integrate PAP to the degree their product requires. It is a model and integration path, not an all-or-nothing mandate.
Colibri is the reference implementation of PAP alongside full cryptographic verification. Correctness and privacy are both handled locally — without trusting RPC providers for either.
The conceptual model and the technical implementation — from privacy principles to per-RPC exposure analysis in colibri-stateless.
Threat model, adaptive read policies, integration patterns, and how PAP pairs with trustless verification.
Read the PAP whitepaperDetailed PAP function mapping — per Ethereum RPC method privacy exposure, mitigation strategies, and colibri-stateless implementation.
Open specificationPAP reduces what infrastructure learns from your application. Colibri delivers the verified foundation it runs on.