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:Query Functions
Usage in Protocol
Orchestrator queries the registry during intent validation (fromcontracts/Orchestrator.sol:416):
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:acceptAllEscrows == true, the Orchestrator accepts intents for any escrow (useful for permissionless deployments).
Query Functions
Usage in Protocol
Orchestrator validates escrow during intent signaling (fromcontracts/Orchestrator.sol:411):
3. OrchestratorRegistry
Authorizes Orchestrator contracts that can call Escrow functions. Location:contracts/registries/OrchestratorRegistry.sol
State Variables
Key Functions
Add Orchestrator:Usage in Protocol
Escrow validates orchestrator for liquidity operations (fromcontracts/Escrow.sol:103):
contracts/unifiedVerifier/BaseUnifiedPaymentVerifier.sol:48):
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):Query Functions
Usage in Protocol
UnifiedPaymentVerifier nullifies payments after verification (fromcontracts/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 (fromcontracts/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 (fromcontracts/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: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
- Hash Consistency: Always use lowercase strings for payment method and currency hashes
- Idempotent Queries: Design off-chain systems to tolerate registry changes
- Event Monitoring: Index registry events to maintain off-chain state
- Graceful Degradation: Handle removed payment methods/currencies gracefully in UI
- Test Coverage: Test registry interactions in integration tests, not just unit tests
Related Contracts
- Escrow - Uses PaymentVerifierRegistry and Orchestrator reference
- Orchestrator - Uses EscrowRegistry, PaymentVerifierRegistry, PostIntentHookRegistry, RelayerRegistry
- Payment Verification - Uses OrchestratorRegistry and NullifierRegistry