How the Aggregator Works
Step 1: Collect liquidity pool data
It gathers data from connected AMMs:
Direct pools (TokenA–TokenB)
Intermediate pools (via WETH, USDC, etc.)
Supported:
V2 Pools — constant product (x * y = k)
V3 Pools — concentrated liquidity
Order Book — e.g., Kuru
Step 2: Build the route graph
Nodes = tokens
Edges = liquidity pools
Step 3: Find optimal paths
Uses a modified Bellman-Ford algorithm to find up to 4-hop paths and selects the one with the best output.
Step 4: Simulate and calculate
Each route is simulated considering pool fee, liquidity, and slippage.
Route Graph Visualization
Here's how the aggregator maps available liquidity:
Graph Structure:
Nodes: USDT, WMON, USDC, MON (tokens)
Edges: Pool1, Pool2, Pool3, Pool4 (liquidity pools)
Possible Routes (USDT → DAI):
Direct: USDT → Pool2 → USDC → Pool4 → MON
Multi-hop: USDT → Pool1 → WMON → Pool3 → MON
Complex: USDT → Pool1 → WMON → Pool3 → MON + USDT → Pool2 → USDC → Pool4 → MON (split route)
Route Types
1. Direct Route
Single pool: [USDT] → [WMON]
2. Multi-hop Route
Through intermediates: [TokenA] → [WMON] → [TokenB]
3. Split Route
Split across pools: 60% Kuru, 40% Bean
Route Building Process
Pool discovery (5–10 ms)
Graph construction (10–20 ms)
Path search (50–200 ms)
Alternative search (30–100 ms)
Optimization
Weights assigned based on efficiency
Bonuses/penalties:
+15% for direct routes
+5% for V3
−2% per extra hop
Limits:
Max 60% per route
Min 5% per route
Convert to smart contract weights
Example:
Route 1: 60% → 6000
Route 2: 25% → 2500
Route 3: 15% → 1500
Total: 10000 ✅
Optimization and Distribution
Three strategies compared:
Single best route
Multiple direct routes
Multi-hop combinations
The system picks the strategy with the highest token output.
Slippage example
Expected: 1000 tokens
Fee 0.2% = -2
Slippage 0.5% = -5
→ Minimum = 993 tokens
Last updated