Skip to main content

Overview

The zkp2p protocol uses a registry system to manage whitelists, authorizations, and configuration for various protocol components. Registries decouple authorization logic from core contracts, enabling flexible upgrades and governance.
Registries allow the protocol to add new payment methods, escrows, orchestrators, and hooks without upgrading core contracts.

Registry Architecture

Core Registries

1. PaymentVerifierRegistry

Maps payment methods to their verifiers and supported currencies. Location: contracts/registries/PaymentVerifierRegistry.sol

Data Structure

Key Functions

Add Payment Method:
Example usage:
Add Currencies:
Example:
Remove Payment Method:
Removes the payment method and all associated currencies.

Query Functions

Usage in Protocol

Orchestrator queries the registry during intent validation (from contracts/Orchestrator.sol:416):
Escrow validates payment methods during deposit creation (from contracts/Escrow.sol:1060):

2. EscrowRegistry

Whitelists Escrow contracts that can be used with the Orchestrator. Location: contracts/registries/EscrowRegistry.sol

State Variables

Key Functions

Add Escrow:
Remove Escrow:
Toggle Accept All:
When acceptAllEscrows == true, the Orchestrator accepts intents for any escrow (useful for permissionless deployments).

Query Functions

Usage in Protocol

Orchestrator validates escrow during intent signaling (from contracts/Orchestrator.sol:411):

3. OrchestratorRegistry

Authorizes Orchestrator contracts that can call Escrow functions. Location: contracts/registries/OrchestratorRegistry.sol

State Variables

Key Functions

Add Orchestrator:
Remove Orchestrator:

Usage in Protocol

Escrow validates orchestrator for liquidity operations (from contracts/Escrow.sol:103):
Payment Verifiers authorize orchestrators (from contracts/unifiedVerifier/BaseUnifiedPaymentVerifier.sol:48):
The Escrow contract uses a direct reference to its orchestrator, while payment verifiers use the registry. This means Escrow trusts a single orchestrator, while verifiers can work with multiple.

4. NullifierRegistry

Prevents double-spending of off-chain payments. Location: contracts/registries/NullifierRegistry.sol

State Variables

Access Control

Only addresses with write permissions (payment verifiers) can add nullifiers:

Key Functions

Add Nullifier (Writer Only):
Grant Write Permission (Owner Only):
Revoke Write Permission (Owner Only):

Query Functions

Usage in Protocol

UnifiedPaymentVerifier nullifies payments after verification (from contracts/unifiedVerifier/BaseUnifiedPaymentVerifier.sol:125):

5. PostIntentHookRegistry

Whitelists post-intent hooks that can be executed after fulfillment. Location: contracts/registries/PostIntentHookRegistry.sol (interface reference)

Key Functions

Usage in Protocol

Orchestrator validates hooks during intent signaling (from contracts/Orchestrator.sol:404):

6. RelayerRegistry

Whitelists relayers that can signal multiple intents simultaneously. Location: contracts/registries/RelayerRegistry.sol (interface reference)

Key Functions

Usage in Protocol

Orchestrator checks relayer status for multiple intent permission (from contracts/Orchestrator.sol:392):
Whitelisted relayers can always have multiple active intents, even if allowMultipleIntents == false.

Payment Method Hashing

Payment methods and currencies are identified by their keccak256 hash:
Convention: Payment methods and currencies should be lowercase when hashed for consistency.

Registry Upgrade Patterns

Pattern 1: Adding New Payment Method

Pattern 2: Migrating to New Orchestrator

Pattern 3: Adding Currencies to Existing Method

Registry Events

All registries emit events for off-chain indexing:

PaymentVerifierRegistry

EscrowRegistry

OrchestratorRegistry

NullifierRegistry

Access Control Summary

Security Considerations

Owner Centralization

All registries are owned by governance. Ensure multisig or DAO controls owner keys.

Writer Permissions

Only grant NullifierRegistry write permissions to trusted payment verifiers.

Registry Hygiene

Remove deprecated payment methods and verifiers to avoid confusion.

Accept-All Risk

Enabling acceptAllEscrows allows untrusted escrows. Use with caution.

Query Patterns

Check if Payment Method Supported

Check if Currency Supported

Check if Escrow Whitelisted

Check if Payment Nullified

Best Practices

  1. Hash Consistency: Always use lowercase strings for payment method and currency hashes
  2. Idempotent Queries: Design off-chain systems to tolerate registry changes
  3. Event Monitoring: Index registry events to maintain off-chain state
  4. Graceful Degradation: Handle removed payment methods/currencies gracefully in UI
  5. Test Coverage: Test registry interactions in integration tests, not just unit tests
  • Escrow - Uses PaymentVerifierRegistry and Orchestrator reference
  • Orchestrator - Uses EscrowRegistry, PaymentVerifierRegistry, PostIntentHookRegistry, RelayerRegistry
  • Payment Verification - Uses OrchestratorRegistry and NullifierRegistry