> 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-model/pragmatic-adaptive-privacy/the-pap-model.md).

# The PAP Model

## Why PAP needs a model

Privacy in Web3 is not a binary property. Different applications, operations, and execution environments require different levels of protection. A mobile wallet, an IoT device, an AI agent, and an institutional trading system operate under different resource constraints, threat models, and security requirements.

Applying the strongest available privacy mechanism to every request is neither practical nor necessary. Maximal privacy often introduces computational overhead, bandwidth cost, latency, or implementation complexity that make it unsuitable for many production environments. Applying no privacy, however, exposes user identity and intent to profiling, strategy reconstruction, and real-time attacks.

An effective privacy model must therefore provide meaningful protection against practical attacks while remaining deployable within the constraints of today's Web3 infrastructure.

**Pragmatic Adaptive Privacy (PAP)** addresses this problem by treating privacy as a configurable system property rather than a fixed protocol feature. Instead of prescribing a single privacy mechanism, PAP defines a structured model for selecting an appropriate level of privacy for each operation while preserving trustless verification.

## Privacy dimensions

Privacy is exposed through different information channels. Protecting one channel does not automatically protect another. PAP therefore models privacy using two independent dimensions: **Transport Privacy** and **Content Privacy**.

**Transport Privacy** addresses the question of **who** can observe a request. It aims to reduce the ability to associate requests with a specific user, device, or network location. Information such as IP addresses, routing paths, timing information, and request correlation belong to this dimension.

**Content Privacy** addresses the question of **what** can be inferred from a request. Even if the origin of a request is completely hidden, the request itself may reveal the user's intent. Contract addresses, function calls, storage accesses, event filters, and other request parameters often provide sufficient information to reconstruct planned actions or application behavior.

These dimensions are orthogonal. Strong Transport Privacy does not prevent intent leakage if the request remains highly specific. Likewise, strong Content Privacy does not prevent long-term profiling if all requests can still be associated with the same identity.

Effective privacy requires both dimensions to be considered simultaneously.

Separating Transport Privacy and Content Privacy provides an architectural advantage. Improvements in one dimension do not require changes to the other. Existing privacy technologies and future developments can therefore evolve independently while remaining compatible with the same conceptual model.

PAP intentionally defines privacy properties rather than implementation techniques. The model remains stable while individual privacy mechanisms continue to evolve.

## Privacy levels and Privacy Profiles

Each privacy dimension is divided into a small number of levels that describe the degree of protection provided within that dimension.

For **Transport Privacy**, the levels describe how difficult it is to associate a request with its origin:

* **T0** — No Transport Privacy. Requests are sent directly and remain fully observable.
* **T1** — Reduced transport observability. Requests are distributed or routed in a way that makes correlation more difficult.
* **T2** — Strong Transport Privacy. Anonymous communication mechanisms, such as Tor or Mixnets, significantly reduce the ability to associate requests with a specific origin.

For **Content Privacy**, the levels describe how much information about the user's intent can be inferred from the request itself:

* **C0** — No Content Privacy. Requests reveal their exact purpose and intent.
* **C1** — Pragmatic Content Privacy. Requests are structured to reduce Actionable Information Leakage while maintaining low overhead and practical deployability.
* **C2** — Strong Content Privacy. Advanced privacy mechanisms minimize information leakage, even at the cost of additional computational complexity, bandwidth consumption, or latency.

The levels of each dimension are independent. Increasing the Transport Privacy level does not automatically improve Content Privacy, and vice versa.

A **Privacy Profile** combines one Transport Privacy level with one Content Privacy level. For example, **T1/C1** combines moderate Transport Privacy with pragmatic Content Privacy, while **T2/C2** represents strong protection in both dimensions.

Privacy Profiles describe the desired privacy properties of an operation. They do not prescribe the mechanisms used to achieve them. The same Privacy Profile may therefore be implemented with different technologies depending on the application, the available infrastructure, and future advances in privacy mechanisms.

Applications select a Privacy Profile. The **Privacy Application Layer (PAL)** determines how the corresponding Transport and Content Privacy levels are realized.