Skip to main content

The ZKP2P Protocol

ZKP2P is a permissionless, non-custodial protocol for exchanging verified off-chain payments for on-chain assets. Sellers place tokens in Escrow; buyers pay sellers directly through supported payment services; cryptographic or trusted-computing verification proves the payment; and the contracts release the corresponding tokens.

The protocol does not custody fiat or hold a buyer's payment credentials.

Version history​

V1​

V1 proved that privacy-preserving payment data could unlock on-chain assets using zkEmail-based proofs. It was an alpha implementation with a narrower set of payment methods and currencies.

V2​

V2 introduced generic Escrow deposits, payment-method registries, gating services, pluggable verifiers, multiple currencies per deposit, and an Orchestrator-owned intent lifecycle. V2 contracts remain deployed and can continue serving legacy deposits and active intents during the V3 migration.

V3​

The V3 stack keeps EscrowV2 custody and the standardized off-chain PaymentAttestation path while adding OrchestratorV3's per-deposit risk-hook boundary.

Its current design includes:

  • Buyer TEE Verification and Seller Autopilot inside an attested AWS Nitro Enclave;
  • UnifiedPaymentVerifierV2 for signed attestation, snapshot, nullifier, and release checks;
  • OrchestratorV3 for intent lifecycle, fees, pre/post hooks, and bounded risk callbacks;
  • continuous stake-backed capacity instead of buyer tiers;
  • separate griefing-bond and chargeback-reserve curves;
  • configurable free takes for eligible non-chargebackable methods;
  • delegated stake ownership for Safe/relayer and operator workflows;
  • chargeback coverage windows with partial-coverage disclosure;
  • deferred payouts as an optional alternative to post-settlement stake reservation; and
  • permissionless reconciliation and maturity paths that preserve Escrow liveness.

Read the V3 Overview and Stake, Capacity, and Risk.

Intent flow​

  1. A client fetches seller quotes. A quote is informational and does not reserve liquidity or buyer stake.
  2. The client separately reads live buying capacity and warnings.
  3. Curator signs the deposit-specific gating data.
  4. The buyer signals an intent. Escrow liquidity locks and any selected V3 risk position is admitted atomically.
  5. Only after on-chain success, the buyer pays the seller off-chain.
  6. The Attestation Service verifies payment evidence and signs a PaymentAttestation.
  7. The unified verifier validates that attestation and Orchestrator releases the allowed amount.
  8. Any chargeback reserve or deferred payout remains slashable until its snapshotted window matures.

Risk model​

The protocol can reserve buyer-owned or delegated USDC stake to compensate sellers for two mutually exclusive risks:

  • a time-based penalty if a pending order is cancelled or expires after its grace period; or
  • bounded coverage if a fulfilled off-chain payment is later charged back.

The pending reservation is the larger of those requirements, not their sum. Sellers opt into the risk hook and remain responsible for uncovered losses, post-window chargebacks, pricing, and aggregate exposure.

The exact formulas and invariants are maintained in the authoritative contracts policy. Current platform settings are mutable on-chain state; locate the active contracts through V3 Deployments and read the deployed RiskManager rather than relying on copied values.

Coexistence safety​

OrchestratorRegistry can authorize OrchestratorV2 and OrchestratorV3 simultaneously. An intent keeps the rules and hook snapshots of the contract through which it was created. Clients, indexers, and operators should resolve the route's actual contract addresses and must not infer V3 risk behavior from a payment-method name alone.

Trust assumptions​

  • Attestation integrity depends on the configured witness verifier and the attested enclave path.
  • Governance can change contract configuration for future activity.
  • Oracle-backed rates depend on adapter correctness and fresh price feeds.
  • Depositors choose optional hooks and accept their failure and economic assumptions.
  • Fiat payment services can delay, reject, or reverse transactions independently of the protocol.

See Privacy & Safety for user-facing guidance.