ZKP2P Protocol V3 — Overview

V3 is the current ZKP2P protocol on Base. The Attestation Service verifies each fiat payment off-chain and signs an EIP-712 PaymentAttestation; one on-chain verifier checks that signature for every payment method, and the escrow releases the tokens. The contracts hold and move funds but never see payment credentials.

Contract names carry their own version numbers. New intents use EscrowV2, OrchestratorV4 and UnifiedPaymentVerifierV4; OrchestratorV3 was retired on 2026-11-05; historical intents and events remain readable. Addresses are on Deployments.

Roles

Role	Responsibility
Buyer (taker)	Signals an intent, pays the seller off-chain, then submits the attestation
Seller (maker, depositor)	Deposits tokens in EscrowV2 and sets payment methods, currencies, rates and order limits
Gating service (Peer's API)	Signs each intent so the signal policy admits it, and returns the seller's payee details to the buyer
Attestation Service	Verifies the payment inside an AWS Nitro Enclave and signs the attestation
Contracts	Lock and release funds, check attestations, block reused payments, apply fees and dispute protection

Intent flow

1. Quote. The client fetches quotes from Peer's API.
2. Sign. The client calls POST /v3/sign on Peer's API and receives a gating signature, its expiration and a payerCommitment. See Gating Service.
3. Signal. The taker calls OrchestratorV4.signalIntent(...). The rate must meet the deposit's effective rate, and the signal policy checks the deposit whitelist and the gating signature. Funds are then locked in EscrowV2. Any failure reverts the transaction.
4. Pay. The buyer pays the seller's off-chain account. On-chain, the intent stores only its hash (payeeId).
5. Verify. The enclave checks the payment through Buyer TEE Verification or Seller Autopilot.
6. Attest. The service returns a signed PaymentAttestation that includes the dispute window for the payment.
7. Fulfill. Anyone calls OrchestratorV4.fulfillIntent(...). UnifiedPaymentVerifierV4 checks the attestation, the escrow releases the verified amount, fees are paid, and the settlement policy pays the recipient or holds the payout until the dispute window ends. See Stake to Take.

What V3 changed from V2

• Off-chain verification. The Attestation Service validates and normalizes payment evidence. Adding a payment method needs registry configuration, not a new verifier contract.
• One verifier. UnifiedPaymentVerifierV4 checks the EIP-712 signature, the intent snapshot, payment nullifiers and the release cap for every method.
• Partial release. The verifier can release less than the intent amount, for example after an underpayment; the rest returns to the deposit.
• Rate management. Depositors can set oracle-based rates per currency and delegate pricing to a rate manager such as RateManagerV1. Manager fees are capped at 5%.
• Referral fees. Up to 10 recipients per intent, 50% combined cap.
• Multiple orchestrators. OrchestratorRegistry authorizes orchestrators on EscrowV2.
• Policies. On OrchestratorV4, a governance-selected signal policy admits intents and a settlement policy applies dispute protection. OrchestratorV3 used per-deposit pre-intent hooks, a lifecycle hook and post-intent hooks instead.

Trust model

• Attestation Service. Verification and signing run inside an AWS Nitro Enclave. Clients verify the enclave through GET /attestation?nonce=... before sending session material or trusting a signature. See Attestation Service.
• Witnesses. UnifiedPaymentVerifierV4 accepts only signatures from the witness set on MultiAttestationVerifier. Governance controls that set.
• Intent integrity. The attestation must match the on-chain intent. Each payment can settle only one intent, and the release amount never exceeds the intent amount.
• Gating service. Peer's API must sign every OrchestratorV4 intent. It can decline to sign, but it cannot move or freeze escrowed funds.
• Governance. The protocol owner can replace the signal and settlement policies, change registries and witnesses, set the protocol fee up to 5%, and pause signaling and fulfillment. Cancellation and manual release keep working while paused. The protocol fee is read at fulfillment; manager and referral fees are fixed at signal time.
• Oracles. Adapters are read-only. Stale or invalid oracle data stops new intents for that currency instead of falling back to a fixed rate. The INR/USD and CNY/USD feeds come from a single updater that the protocol owner sets, not from Chainlink.