This page provides step-by-step instructions for integrating any Uniswap V4 hook with the Hooks DCI.
Determine Your Requirements
Before implementing anything, determine what (if anything) you need to customize:
Decision Tree
START: I want to index my Uniswap V4 hook
Q1: Is my hook composable (works with empty hookData)?
├─ NO → ⚠️ STOP: Non-composable hooks not yet supported
│ Wait for future release with hookData source support
└─ YES → Continue to Q2
Q2: Where does my hook store liquidity?
├─ In PoolManager (ERC6909 claims)
│ └─→ INTERNAL LIQUIDITY
│ ✓ No custom code needed - your hook will be automatically indexed
│
│
└─ In external contracts (vaults, protocols, etc.)
└─→ EXTERNAL LIQUIDITY
⚙️ Requires metadata generator + parser
→ Continue to the next step
Q3: (External liquidity only) Does my hook need custom entrypoint encoding?
├─ NO → Implement Generator + Parser only
│ Skip custom orchestrator (use default)
│
└─ YES → Implement Generator + Parser + Custom Orchestrator
Quick Reference Table
Hook Type
What to Implement
Internal Liquidity
Nothing (auto-handled)
External Liquidity (Standard)
Generator + Parser
External Liquidity (Custom)
Generator + Parser + Orchestrator
Non-Composable
Not supported yet
Prerequisites
Understand the Hook's Architecture:
Where tokens are stored (which external contracts?)
How balances are queried (what functions?)
How limits are determined (withdrawal limits, caps, etc.)
What state needs to be simulated
1. Minimal Setup (Internal Liquidity Hooks)
If your hook stores all liquidity in the PoolManager and is Composable, your hook should be auto-indexed by Tycho.
If you have external liquidity, continue to the next Section
2. Custom Setup (External Liquidity Hooks)
2.1 Implementation Steps
Step 1: Implement Metadata Request Generator
The generator creates requests to fetch external data for your hook.
Trait to Implement:
Template:
Euler Reference Implementation:
Key Decisions:
Balance Request: How do you query balances? Direct call, lens contract, or multiple calls?
Limits Request: Do you have withdrawal limits, liquidity caps, or other constraints?
State Overrides: Do you need to deploy helper contracts or modify state for queries?
Token Pairs: Do limits apply per token or per token pair?
Step 2: Implement Response Parser
The parser converts raw RPC responses into structured metadata.
Trait to Implement:
Template:
Euler Reference Implementation:
Key Considerations:
Response Format: Understand the ABI encoding of your response
Most hooks can use the default orchestrator. Implement a custom one only if you need:
Special entrypoint encoding logic
Custom balance/limit transformations
Hook-specific state updates
Non-standard token accounting
When Default is Sufficient:
Balances come directly from metadata
Limits are straightforward max amounts
Standard Uniswap V4 swap encoding works
No special state transformations needed
Euler Example: Uses the default orchestrator because it meets all standard requirements.
Custom Orchestrator Template (if needed):
For most use cases, proceed with the default orchestrator and skip this step.
Step 4: Register Components
Set up all registries to wire your implementation into the Hooks DCI.
Registration Code:
In your integration folder add a register function with your protocol specifics
Then add it in the global registration function with other hooks
Key Configuration Points:
Generator Registration: Use register_hook_identifier() if your components have a "hook_identifier" static attribute, or register_hook_generator() for specific addresses
Parser Name: Must match the generator_name in your MetadataRequests
Routing Key: Must match the routing_key in your MetadataRequests
Estimation Method: Choose with_limits() if you provide limits, with_balances() otherwise
Sample Size: Number of entrypoints to generate per token pair (typically 4)
Step 5: Initialize Hooks DCI
Create and initialize the UniswapV4HookDCI instance.
Initialization Code:
Configuration Parameters:
max_retries: Maximum total retry attempts before permanently failing a component
pause_after_retries: Number of retries before pausing (setting "paused" attribute)
Typical Values:
max_retries: 5, pause_after_retries: 3
Step 6: Testing Your Integration
Test your implementation at multiple levels.
Unit Tests:
Integration Tests with Real RPC:
Final Step: Submitting a PR
After your integration is tested, please submit a PR on Github so we can add it to our codebase and start indexing the hook on our hosted service.