Cowrie Research

zkp2p

3 min read

ZKP2P

  • Name: ZKP2P
  • URL: https://docs.peer.xyz/protocol/zkp2p-protocol
  • Tags: ethereum-ecosystem
  • Category: proof-backed fiat-settlement middleware / zkTLS payment-attestation system / escrowed release infrastructure
  • Summary: ZKP2P is proof-backed release plumbing for fiat-to-crypto trades. The point is not another ramp UI; it is the split between escrowed liquidity, offchain payment evidence, attestation, and onchain release policy.
  • What it does:
    • Lets sellers deposit onchain token liquidity while buyers pay them offchain in fiat or other offchain payment platforms
    • Locks liquidity through an intent/orchestration flow, then releases tokens when a valid proof of offchain payment is attested and verified
    • Supports multiple proof primitives including zkEmail, TLSNotary, proxy-based zkTLS approaches like Reclaim, and a path toward TEEs
    • Uses an offchain Attestation Service to normalize provider proofs into a standard EIP-712 PaymentAttestation format for onchain verification
    • Adds configurable gating, oracle-driven or delegated rate management, pre-intent hooks, referral/manager fee routing, and multi-orchestrator support around settlement
  • Key claims:
    • The most important design move is that ZKP2P turns “proof of payment” into a modular settlement stack rather than a bespoke application flow. The docs separate Escrow, Orchestrator, Attestation Service, UnifiedPaymentVerifier, Gating Service, hooks, and rate managers, which makes the practical control plane much clearer.
    • V1 and V2 show the protocol’s evolution from a narrower zkEmail-powered fiat onramp into a more generic proof-verification system. The protocol docs explicitly describe support for zkEmail, TLSNotary, proxy-based zkTLS, and eventually TEEs, which is analytically useful because it frames payment settlement around interchangeable proof primitives instead of one fixed verification method.
    • V3’s offchain Attestation Service is a particularly important control surface. It validates provider proofs, normalizes them, and signs a standard EIP-712 PaymentAttestation, which means provider-specific complexity and future extensibility move offchain while the onchain verifier remains stable.
    • UnifiedPaymentVerifierV2 is the protocol’s canonical onchain settlement primitive. It checks signatures, snapshot consistency, nullifiers, and release caps, which means the system’s trust assumptions sit not only in proof generation but also in witness management and attestation-verifier governance.
    • Intent gating and hook layers reveal that this is not simply a permissionless escrow. Sellers can rely on offchain gating signatures or onchain pre-intent hooks such as whitelist or signature checks, so market access and who can lock liquidity become configurable policy surfaces.
    • Rate management adds another layer often flattened away in ramp products. Depositors can set fixed rates, oracle-driven floors, or delegated rate-manager policies with fee sharing, which means economic control can move to external managers without changing custody contracts.
    • The zkTLS docs are useful because they expose where decentralization is still incomplete. ZKP2P currently describes hosted notary and WebSocket proxy components for some flows, while also discussing optimistic notarization and slashing as future decentralization paths. That is a more honest and analytically useful picture than generic “trustless onramp” branding.

Internal linkages

Graph View