Skip to main content

The ZKP2P Protocol

Introduction​

ZKP2P is a permissionless, non-custodial protocol for exchanging off-chain money, such as a Venmo or Revolut balance, for on-chain tokens. Smart contracts escrow the seller's tokens and release them when a predicate is met: proof that the buyer's off-chain payment happened. The protocol is agnostic to how that proof is produced; versions have used zkEmail, TLS-based proofs and trusted execution environments (TEEs).

Peer (peer.xyz) is the app built on ZKP2P.

V3 (current)​

V3 is the production protocol on Base mainnet.

  • Off-chain attestation. The Attestation Service verifies payment evidence inside an AWS Nitro Enclave and signs an EIP-712 PaymentAttestation, through Buyer TEE Verification or Seller Autopilot.
  • One on-chain verifier. UnifiedPaymentVerifierV4 checks the attestation for every payment method: signature, intent snapshot, nullifier and release cap.
  • Orchestrated intents. OrchestratorV4 runs the intent lifecycle and fees; EscrowV2 holds deposits and funds. OrchestratorV3 stays registered for older clients.
  • Policies. A signal policy admits takers (deposit whitelists, groups and the gating signature), and a settlement policy applies Stake to Take dispute protection.
  • Rate management. Depositors can track oracle prices with a spread and a fixed floor, or delegate pricing to a rate manager such as RateManagerV1.
  • Payment method IDs. Payment methods are bytes32 identifiers (for example keccak256("venmo")) resolved through a registry, so the contracts don't depend on provider-specific verifiers.

See the V3 overview and Deployments.

How a trade works​

  1. Signal intent. The buyer picks a deposit and amount. Peer's API signs the intent, and the contract locks that amount of the seller's tokens for a limited time.
  2. Pay off-chain. The buyer pays the seller through the selected payment platform.
  3. Verify. The enclave reads the payment (from the buyer's session or the seller's connected account) and extracts the payee, amount, timestamp, currency and payment ID.
  4. Release. The contracts check the attestation against the intent (deposit, payee, amount, currency and timing), mark the payment as used, and release the tokens.

Components​

  • Smart contracts on Base hold deposits and enforce release rules. See Smart Contracts.
  • Attestation Service verifies payments in a TEE and signs attestations. Clients can verify the running enclave through GET /attestation before trusting it. See Attestation Service.
  • PeerAuth extension and mobile app capture the payment session needed for verification and encrypt it to the enclave. See PeerAuth Extension.
  • Gating service (Peer's API) signs intents and returns the seller's payment details. It never holds funds. See Gating Service.
  • Quotes come from Peer's API, which indexes the liquidity in the protocol.

Earlier versions​

V1 (2023) was a proof of concept: swaps between USD on Venmo, EUR on Revolut and INR on HDFC Bank and USDC, verified with ZK proofs over payment emails using zkEmail.

V2 made the protocol generic across payment platforms and currencies, let one deposit accept several platforms, and moved non-custody logic to off-chain relayers. Buyers generated zkTLS proofs (TLSNotary and proxy-based zkTLS) that per-platform contracts verified on-chain. The V2 contracts remain deployed on Base but no longer receive updates; V3's Attestation Service replaces their on-chain proof verification.