ZKP2P Protocol V3 — Overview

ZKP2P V3 is a modular, non-custodial exchange protocol for verified off-chain payments and on-chain tokens. EscrowV2 holds seller liquidity, OrchestratorV3 owns the intent lifecycle, and off-chain payment evidence is normalized into an EIP-712 attestation checked by the unified on-chain verifier.

V3 now adds opt-in, continuous stake-backed risk controls without rewriting the custody or payment-verification layers.

Architecture

Layer	Role
EscrowV2	Deposit custody, payment-method configuration, rate floors, and liquidity locks
OrchestratorV3	Signal, cancel, fulfil, manual release, fees, hooks, and bounded risk callbacks
RiskManager + StakeVault	Free takes, continuous stake capacity, griefing penalties, chargeback coverage, delegation, exits, and deferred payouts
UnifiedPaymentVerifierV2	Attestation signatures, intent snapshot matching, nullifiers, and release capping
Attestation Service	Enclave-hosted buyer and seller payment verification that issues PaymentAttestations
Curator	Quotes, gating signatures, and separately exposed stake/capacity views

See Smart Contracts, OrchestratorV3, and Stake, Capacity, and Risk.

What changed from the earlier V3 stack

• OrchestratorV3 risk hooks: a depositor selects a risk hook for future intents; each intent snapshots the selection.
• Continuous capacity: stake backs two independent curves—pending-order griefing and post-settlement chargebacks. There are no protocol buyer tiers, cooldowns, tier caps, concurrency bands, or tier discounts.
• Free takes: eligible non-chargebackable methods can offer a configurable number of separate lifetime free intents.
• Delegated stake: a stake owner can authorize a taker or relayer while retaining token ownership and withdrawal rights.
• Chargeback reserves and windows: fulfilled reversible payments keep a snapshotted amount slashable for a bounded period.
• Deferred payouts: when enabled and explicitly selected, settlement proceeds can be held through the chargeback window instead of reserving the full amount from stake.
• Failure-safe accounting: terminal risk callbacks are bounded and fail open for Escrow liveness, while durable records allow permissionless reconciliation.

Existing V3 features remain: off-chain TEE verification, a unified verifier, oracle rate floors, delegated rate management, pre- and post-intent hooks, multi-recipient referrals, and the multi-orchestrator registry.

End-to-end flow

1. Quote: the client requests seller liquidity, price, output, and fees. Quotes are not filtered by wallet stake and do not reserve capacity.
2. Capacity: the client separately reads the taker's stake owner, free/reserved stake, free takes, and both platform curves.
3. Intent signing: Curator returns the deposit's gating signature and payee details.
4. Signal: OrchestratorV3.signalIntent locks Escrow liquidity, snapshots the deposit risk hook, and atomically admits a free, stake-backed, deferred, or no-risk position.
5. Pay: only after signal succeeds, the buyer sends the exact off-chain payment.
6. Verify: Buyer TEE Verification or Seller Autopilot produces a signed PaymentAttestation.
7. Fulfil: the unified verifier checks the attestation. OrchestratorV3 releases the exact amount, applies fees, and reports settlement to the risk hook.
8. Mature: non-chargebackable positions end immediately. Chargeback coverage or deferred proceeds remain until a valid claim consumes them or anyone releases the matured position.

Trust and safety boundaries

• The attestation witness set and TEE measurement are trust dependencies for payment verification.
• RiskManager governance controls future platform policies and the chargeback evidence verifier.
• Policy, Escrow-period, stake owner, reserve, and window terms are snapshotted per position.
• Sellers choose whether to use the risk hook and remain exposed above partial reserves and after chargeback windows.
• Stake owners must trust delegated takers to use their shared capacity responsibly.
• Clients must treat the final on-chain signal as authoritative and never direct fiat payment after a failed admission.

V2 coexistence

OrchestratorV2 and OrchestratorV3 can both be authorized by OrchestratorRegistry. Existing V2 deposits and active intents keep their original behavior while selected deposits migrate to V3. Clients and indexers must resolve the actual Orchestrator and risk hook for each route rather than assuming a global cutover.

Configuration source of truth

Do not copy mutable production values from examples. Use V3 Deployments to locate the environment's contracts, then read current platform policy from the deployed RiskManager. The design formulas and invariants are documented in the contracts policy specification; follow the status stated there.