Skip to main content

Smart Contracts (V3)

V3 separates token custody, intent orchestration, payment verification, and optional risk policy. The split lets existing EscrowV2 liquidity coexist with more than one authorized Orchestrator while each deposit opts future intents into the hooks it accepts.

Use V3 Deployments for current environment addresses. Mutable platform risk policy must be read from the deployed RiskManager rather than copied from examples.

Core contracts​

EscrowV2​

EscrowV2 holds deposits, locks and unlocks intent liquidity, and transfers released tokens only for an Orchestrator authorized by OrchestratorRegistry. It also supports fixed and oracle-driven rate floors, delegated rate managers, third-party funded deposits, and dust sweeping.

See EscrowV2.

OrchestratorV3​

OrchestratorV3 extends the V2 signal, cancel, fulfil, manual-release, fee, verification, and hook lifecycle with:

  • a per-deposit IIntentRiskHook selection for future intents;
  • an immutable hook snapshot for every signalled intent;
  • bounded admission and terminal callbacks;
  • durable cancellation and settlement recovery records; and
  • required post-intent-hook enforcement for deferred payouts, including manual release.

See OrchestratorV3.

RiskManager​

RiskManager is the replaceable policy and accounting layer for continuous buyer capacity. For each enabled payment method it snapshots griefing, chargeback, free-take, and deferred-payout terms. It creates free, stake-backed, or deferred positions and owns chargeback evidence verification, reconciliation, and maturity.

Pending stake-backed admission reserves the larger of the maximum griefing bond and chargeback reserve. There are no named protocol tiers or tier-derived caps, cooldowns, concurrency bands, fees, or discounts.

StakeVault​

StakeVault is policy-agnostic USDC custody. It tracks owned, reserved, pending-withdrawal, and free stake; delayed partial withdrawals and full exits; taker authorization; claimable seller compensation; and deferred payouts. Only the recorded controller can mutate a position's reservation, while users retain the relevant withdrawal rights.

DeferredPayoutHook​

The canonical hook moves fulfilled net proceeds directly from an authorized Orchestrator to StakeVault, then atomically registers the deferred position with RiskManager. The hook validates the payout token, Orchestrator registry membership, and canonical manager/Orchestrator binding.

See Stake, Capacity, and Risk for formulas, lifecycle, delegation, chargebacks, and operational safeguards.

Verification​

UnifiedPaymentVerifierV2​

The unified verifier validates the EIP-712 PaymentAttestation, checks the signed data hash and on-chain intent snapshot, records a payment nullifier, and caps release to the signalled amount. Buyer TEE Verification and Seller Autopilot share this stable on-chain format.

AttestationVerifier​

The verifier authenticates the witness signatures over the payment-attestation digest. The active verifier and witness policy are deployment state and can be governed independently of Escrow.

See Unified Payment Verifier.

Registries and pricing​

  • OrchestratorRegistry authorizes both V2 and V3 Orchestrators against EscrowV2.
  • EscrowRegistry restricts supported Escrow deployments.
  • PaymentVerifierRegistry resolves payment methods to verifiers.
  • RelayerRegistry authorizes supported relayers.
  • RateManagerV1 supplies delegated rates and a snapshotted manager fee.
  • Chainlink and Pyth adapters normalize oracle rates; Escrow applies the configured spread and floor.

Hooks​

  • Pre-Intent Hooks reject an intent before state changes.
  • Post-Intent Hooks execute settlement actions after verification and fee calculation.
  • Risk hooks observe the full signal and terminal lifecycle but do not replace pre-intent access control or post-intent settlement actions.

Coexistence and resolution​

OrchestratorV2 and OrchestratorV3 use distinct addresses and intent namespaces. Existing V2 intent state is not migrated in place. Clients resolve the environment's contract set and the route's actual Orchestrator; indexers key lifecycle and risk entities by chain and contract address.

Source​

The canonical implementation and interfaces live in zkp2p/zkp2p-contracts. Client ABIs and addresses are published through @zkp2p/contracts-v2 after deployment.