ZKP2P’s core mechanism is noncustodial token release based on cryptographically attested offchain payment facts.
The protocol becomes more analytically useful in V3 because it standardizes provider-specific proof verification into an offchain Attestation Service that emits an EIP-712 PaymentAttestation, while a single onchain UnifiedPaymentVerifier handles signature checks, snapshot matching, nullifiers, and capping.
The real control plane is split across liquidity custody (Escrow), intent lifecycle and fee routing (Orchestrator), proof normalization and witness signing (Attestation Service), witness-set governance (AttestationVerifier), optional intent authorization (gating service or pre-intent hooks), and delegated rate-management policy.
ZKP2P is explicitly designed to swap proof primitives over time: zkEmail, TLSNotary, proxy-based zkTLS/Reclaim flows, and eventually TEEs. That makes it a strong comparison point for proof middleware rather than a one-off ramp application.
The docs also surface nontrivial trust assumptions: hosted notary and WebSocket proxy services exist in some zkTLS flows today, sellers trust notaries against collusion, buyers trust them against censorship, and the team describes optimistic notarization plus slashing as a future mitigation path.
Specific source signals worth retaining
zkp2p-protocol: best single source for the historical progression from V1 zkEmail-based ramping to V2 generic proof-aware escrow and V3 production architecture; also useful for the core user flow and service decomposition.
v3-overview: best concise source for why V3 matters — offchain attestation, single onchain verifier, multi-orchestrator support, pre-intent hooks, delegated rate management, and clearer trust-model notes.
v3-smart-contracts: best source for the exact control-plane split among Orchestrator, UnifiedPaymentVerifierV2, EscrowV2, OrchestratorRegistry, RateManagerV1, ChainlinkOracleAdapter, and pre-intent hooks.
v3-attestation-service: best source for the standardized PaymentAttestation structure and how proof-verification output gets serialized into an onchain-verifiable payload.
zk-tls: especially valuable because it spells out the tradeoffs between TLSNotary and proxy-based zkTLS approaches, including where the protocol is still centralized today and what decentralization path is envisioned.
Why this entry belongs in the corpus
It gives the corpus a clean example of offchain-fact verification used for economic settlement rather than identity or analytics alone.
It strengthens comparison work across zkTLS / TLSNotary / Reclaim / zkEmail / machine-commerce systems by showing how proof middleware can sit between offchain platforms and onchain escrow release.
The durable insight is that “fiat onramp” is an analytically weak label here; the important layer is the policy and verification stack that decides how offchain payment evidence becomes standardized, authorized, and settled onchain.