> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pesapay.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# zkTLS verification

> Prove a fact from a user's own HTTPS account, from their phone, without the account data leaving it.

To release escrow, Pesa needs to know that a fiat payment really happened. The payment provider will not sign that for us. zkTLS gets the fact straight from the provider's own HTTPS reply, as the payer sees it in their account.

Pesa's verification runs on a mobile zkTLS platform. Any app can use it to prove a fact from an HTTPS site: a completed payment, a balance, a year of income. Pesa is the first app on it.

## The idea in four lines

1. The payer's **phone** opens the TLS connection to the payment provider and signs in, as in a normal app.
2. Two **capture enclaves** (TEE\_K and TEE\_T) take part in the TLS session and each commit to their half of the reply. Neither sees the plaintext alone.
3. The phone **proves in zero knowledge** that the reply says what the policy needs: final status, exact amount, payee, payer and reference.
4. An attested **verifier** checks the enclaves' receipts and the proof, then signs a **claim**. The escrow contract checks the claim.

```mermaid theme={null}
sequenceDiagram
    participant P as Phone (SDK)
    participant K as TEE_K
    participant T as TEE_T
    participant B as Payment provider
    participant V as Verifier (attested)
    participant C as Contract or backend
    P->>K: verify enclave, authorise capture
    P->>T: verify enclave, join capture
    P->>B: phone-owned TCP connection, TLS 1.3
    K-->>P: keystream view
    T-->>P: tag check, ciphertext view
    K->>P: receipt (commits to its view)
    T->>P: receipt (commits to its view)
    P->>V: VOLE zero-knowledge proof + receipts
    V-->>P: signed claim
    P->>C: claim
```

## What stays where

| Data | Where it goes |
| - | - |
| The user's password and session cookies | The phone only. They are wiped when the capture ends. |
| The full payment record | The phone only. The enclaves hold encrypted shares, the verifier sees neither. |
| The claim | Public: a few booleans, a context digest, a nullifier, and the verifier's signature. |

## Why on the phone

Other designs ask the user to hand their session to a server or an enclave that logs in for them. That puts a live payment-account session outside the user's device for as long as it stays valid. Here the TLS connection starts and ends on the phone, the provider sees the user's own network, and no credential ever leaves.

<CardGroup cols={2}>
  <Card title="Architecture" icon="sitemap" href="/zktls/architecture">Capture, proving, verifier and cells.</Card>
  <Card title="Claims" icon="file-signature" href="/zktls/claims">The one output a consumer reads.</Card>
  <Card title="Profiles and policies" icon="sliders" href="/zktls/profiles-and-policies">How a site and a rule are described as data.</Card>
  <Card title="zkTLS SDK" icon="mobile" href="/zktls-sdk/overview">Integrate proving into an iOS or Android app.</Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.