> For the complete documentation index, see [llms.txt](https://corpus-core.gitbook.io/pap-colibri-stateless/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://corpus-core.gitbook.io/pap-colibri-stateless/the-problem/privacy-in-todays-web3-stack.md).

# Privacy in Today's Web3 Stack

## Data Flow in dApps

In practice, most Web3 applications do not interact directly with the blockchain. Instead, they rely on an intermediate data layer composed of RPC providers, indexers, and application-specific backend services. All read operations — such as `eth_call`, `eth_getBalance`, log queries, or transaction simulations — are executed through this infrastructure.

Transactions are only the final step of a decision process. Before submission, users and applications perform multiple reads to inspect state, test parameters, and simulate outcomes. In practice, these reads are externalized by default rather than executed against a locally controlled full node. This makes the decision process itself observable.

This architecture introduces a fundamental asymmetry: while the blockchain itself is designed to be trustless and verifiable, the access layer through which users obtain information is neither trustless nor private. Every read request is routed through third-party systems that can observe, log, and analyze both the request and its origin.

As a result, the act of querying the blockchain becomes observable. The interaction no longer occurs with a neutral protocol but with an infrastructure layer that has full visibility into access patterns.

## Identity Leakage Through Transport

Even without inspecting the content of a request, the transport layer already reveals sensitive information. Each interaction with an RPC endpoint exposes metadata such as the IP address of the requesting device, the timing of requests, and their frequency. Over time, these signals allow correlation across multiple requests and sessions.

This enables an observer to associate requests with a specific user or device, even in the absence of explicit identifiers. Behavioral patterns emerge naturally: repeated queries to specific contracts, bursts of activity, or periodic checks can be linked and analyzed.

Crucially, this form of leakage is independent of the application logic. Even if the payload were encrypted or obfuscated, the transport layer alone is sufficient to build user profiles. In this sense, identity leakage is a baseline property of the current architecture.

## Content Leakage and Intent Exposure

Beyond transport-level metadata, the request payload itself reveals the user's intent. Blockchain reads are inherently expressive: they encode which contracts are being accessed, which functions are invoked, and which parts of the state are relevant.

For example, a call to a DEX router contract via `eth_call` indicates preparation for a trade. Repeated balance checks suggest portfolio monitoring. Queries for specific logs can reveal participation in a protocol or tracking of particular events.

This information is available before any transaction is executed on-chain. An external observer can therefore infer user intentions in advance, reconstruct strategies, and anticipate future actions. The sequence of reads often reveals more than the eventual transaction because it exposes what was evaluated, compared, and discarded before execution. Unlike transaction privacy, which focuses on hiding executed actions, **read privacy** concerns the exposure of planned or exploratory behavior.

## Consequences

The combination of transport-level identity leakage and content-level intent leakage enables a wide range of attacks and analyses. Observers can link requests to users, reconstruct their behavior, and derive actionable insights.

This leads to:

* Deanonymization through correlation of requests and metadata
* Detailed behavioral profiling over time
* Front-running and back-running based on observed intent
* Targeted attacks, including phishing or manipulation based on user activity

The defining property of this system is that information is exposed before it becomes part of the blockchain state. Mempool visibility is not required. The privacy boundary is therefore not the transaction, but the read operation that precedes it.

## Limitations of Existing Privacy Approaches

Existing approaches to improving privacy typically address only a subset of the problem and often introduce new trust assumptions.

Transport-level solutions such as VPNs or proxy servers can hide the origin of a request but leave the content fully exposed to the operator of the service. Conversely, application-level obfuscation techniques may reduce the clarity of the payload but do not prevent correlation at the network level.

Centralized relays and RPC providers aggregate large volumes of requests, making them powerful observation points. While they may offer operational convenience, they fundamentally require trust in the service operator not to log, analyze, or misuse the data. And even a trustworthy acting service provider can be compromised.

These approaches share a common limitation: they shift trust rather than eliminate it. None of them provide verifiable guarantees about what information is observed or retained.

## PIR, ORAM, and Trusted Execution Environments

More advanced approaches attempt to address privacy at the level of access patterns. **Private Information Retrieval (PIR)** and **Oblivious RAM (ORAM)** are designed to hide which data is being accessed, even from the data provider itself. In theory, these techniques offer strong privacy guarantees.

In practice, both approaches remain expensive. ORAM adds multiple memory operations per logical read and can amplify bandwidth significantly. Practical ORAM deployments therefore often place the ORAM logic inside a **Trusted Execution Environment (TEE)**, with the client sending only encrypted traffic to the enclave. This reduces exposure at the infrastructure layer, but it shifts part of the trust model to TEE integrity, attestation, and side-channel resistance. PIR has a different cost profile, but the same practical outcome: high communication cost, expensive server-side computation, or both.

These characteristics make them difficult to deploy in environments with limited resources, such as browsers, mobile devices, or IoT systems. They also conflict with the low-latency expectations of interactive applications, where read operations are part of real-time user flows.

A more fundamental limitation is verifiability. In Web3, retrieved data must remain private and independently verifiable. For **PIR**, there is currently no broadly established and practically validated approach that achieves strong query privacy and trustless verifiability without either weakening privacy or imposing substantial additional cost. More generally, verification metadata can leak access patterns, while privacy-preserving verification adds protocol complexity, computation, and bandwidth overhead. Strong access-pattern privacy and trustless verification therefore do not yet combine efficiently in practical systems.

**Trusted Execution Environments (TEE)** can reduce infrastructure exposure, but they replace a purely cryptographic trust model with a hardware-assisted one. That adds dependency on enclave security, implementation quality, and the attestation and deployment chain.

In addition, many PIR- and ORAM-based approaches are still in relatively early stages of development and are not yet practical for production use in typical Ethereum and Web3 environments. Integration with existing RPC-based architectures remains limited, and there is little operational experience at scale.

As a result, while PIR and ORAM provide strong theoretical guarantees, they do not currently offer a general-purpose solution for read privacy in the Web3 stack.

## Cost and Latency

Any privacy mechanism must operate within the constraints of real-world systems. Web3 applications increasingly run on mobile devices, in browsers, and on IoT hardware, where computational resources, memory, and bandwidth are limited. Many user flows are also latency-sensitive: trading interfaces, real-time protocol interactions, and live transaction simulations cannot absorb additional round-trips without degrading the experience.

Approaches that introduce substantial latency, amplify bandwidth consumption, or require persistent background infrastructure are difficult to deploy at scale. The overhead of a privacy mechanism must fit within the performance budget of the target environment — not only be justified in the abstract.

## Trade-offs

The current landscape reveals a fundamental tension between privacy and practicality. Strong privacy guarantees often come at the cost of performance, complexity, or usability. Conversely, systems optimized for efficiency tend to expose significant amounts of information.

Existing Web3 infrastructure implicitly prioritizes performance and simplicity, resulting in minimal privacy. This is not a deliberate design choice but an emergent property of the architecture.

A viable solution must therefore reduce information leakage meaningfully while remaining compatible with existing systems and deployment environments. This points toward adaptive approaches, where privacy is calibrated to context and operational requirements rather than applied uniformly.