Skip to main content
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.

​
What stays where

​
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.

Architecture

Capture, proving, verifier and cells.

Claims

The one output a consumer reads.

Profiles and policies

How a site and a rule are described as data.

zkTLS SDK

Integrate proving into an iOS or Android app.