# Privacy Guarantees

ZK Login is designed from the ground up with privacy as a foundational property, not a feature added on top. The use of zero-knowledge proofs means that authentication is verifiable without being revealing.

#### What the Chain Never Sees

When a user authenticates and transacts via ZK Login, the following information is **never exposed on-chain**:

<table><thead><tr><th width="241.28125">Data</th><th>Why It Stays Private</th></tr></thead><tbody><tr><td>Email address</td><td>Never part of any on-chain submission</td></tr><tr><td>Google <code>sub</code> identifier</td><td>Hidden inside the ZK proof; not included in public inputs</td></tr><tr><td>JWT contents</td><td>Used only off-chain to generate the proof</td></tr><tr><td>Ephemeral private key (<code>esk</code>)</td><td>Never transmitted; used only locally to sign transactions</td></tr><tr><td>Salt value</td><td>Held by the Salt Service; never posted on-chain</td></tr></tbody></table>

The chain only ever sees:

* The ZK proof (a mathematical attestation that the inputs are valid).
* The public inputs (a minimal set of values required to verify the proof, which reveals nothing about your identity).
* The wallet address (derived deterministically, but unlinkable to your email without the salt).

#### Unlinkability

Each ZK Login session uses a freshly generated ephemeral key pair. This means that even if two transactions are submitted from the same Gmail account in different sessions, they cannot be linked to each other on-chain without access to the Salt Service's records. The on-chain footprint of two separate sessions is indistinguishable.

#### What the Salt Service Knows

The Salt Service is the one component that holds the mapping between your Gmail identity and your on-chain address. This is a deliberate architectural trade-off. Full on-chain privacy is achieved, but the Salt Service acts as a trusted intermediary for address derivation.

{% hint style="info" %}
Applications can run their own Salt Service to eliminate this trust dependency entirely, giving users full sovereignty over the salt and removing any single point of knowledge about the identity-to-address mapping.
{% endhint %}

#### Ephemeral Key Expiry

The ephemeral key pair used to sign transactions has a limited lifespan defined by `epk_expiry_time`. Once expired, it cannot be used to authorize further transactions. A new login session generates a fresh key pair, ensuring that compromised session keys have a bounded window of exposure.

#### Summary of Privacy Properties

<table><thead><tr><th width="212.296875">Property</th><th>Guarantee</th></tr></thead><tbody><tr><td>Identity privacy</td><td>Email and OAuth identity never posted on-chain</td></tr><tr><td>Address unlinkability</td><td>Address cannot be reverse-engineered to reveal email</td></tr><tr><td>Session unlinkability</td><td>Separate sessions cannot be correlated on-chain</td></tr><tr><td>Key exposure window</td><td>Bounded by ephemeral key expiry time</td></tr><tr><td>Trust minimization</td><td>Salt Service dependency can be self-hosted</td></tr></tbody></table>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://wp.vola.network/docs/vola-architecture/zk-login-and-identity/privacy-guarantees.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.