Bringing Sanctum Infinity's unified liquidity approach from Solana to Ethereum
MultiSwap creates a unified liquidity layer for all Liquid Restaking Tokens (LRTs) on EigenLayer, enabling seamless swaps between them with minimal slippage, dynamic fees, and zero impermanent loss. The protocol is powered by a custom Uniswap v4 hook that implements a novel pricing mechanism optimized for similarly-valued assets.
The Ethereum LRT ecosystem faces significant liquidity fragmentation. With multiple LRT providers, users face:
- Fragmented Liquidity: Each LRT pair requires its own pool, diluting liquidity
- Inefficient Capital Usage: LPs need to provide liquidity across multiple pools
- High Slippage: Low liquidity in specific pairs leads to high slippage for traders
- Impermanent Loss: Traditional AMMs cause IL when pricing assets that track the same underlying value
Despite all LRTs representing the same underlying asset (staked ETH), the market treats them as completely different tokens, leading to liquidity inefficiency.
Our solution is inspired by Sanctum Infinity, which has successfully implemented a unified liquidity layer for LSTs (Liquid Staking Tokens) on Solana. We're bringing this innovative approach to Ethereum's LRT ecosystem using Uniswap v4's hook architecture.
MultiSwap represents a paradigm shift in how Ethereum handles LRT tokens:
Instead of requiring separate pools for each LRT pair, MultiSwap creates a single unified pool where all tokens share the same liquidity. This approach:
- Increases Capital Efficiency: 10x more efficient use of capital than traditional AMM approaches
- Reduces Slippage: Larger effective liquidity for all token pairs
- Simplifies LP Experience: LPs provide liquidity once instead of to multiple pools
Unlike traditional AMMs, MultiSwap uses a specialized constant-sum curve that recognizes LRTs as wrappers over the same underlying asset:
- Fair Value Swaps: Exchange rates based on actual underlying ETH value
- Oracle Integration: Rates updated via oracles to maintain accurate pricing
- Protection for LPs: No divergence loss when token prices change together
MultiSwap implements a novel fee structure that:
- Encourages Balanced Pools: Lower fees for swaps that rebalance the pool
- Optimizes Capital Efficiency: Fees guide pool toward target weights
- Prevents Arbitrage Exploitation: Dynamic fees that adjust to market conditions
MultiSwap's innovative fee mechanism uses a combination of input and output fees to maintain pool balance:
-
Input Fees (0.03-0.05%):
- Applied when adding tokens to the pool during a swap
- Lower fees (0.03%) for tokens that are underweight in the pool
- Higher fees (0.05%) for tokens that are already abundant in the pool
- Encourages users to provide tokens the pool needs most
-
Output Fees (0.02-0.04%):
- Applied when withdrawing tokens from the pool during a swap
- Higher fees (0.04%) for withdrawing scarce tokens
- Lower fees (0.02%) for withdrawing abundant tokens
- Discourages draining the pool of specific tokens
-
Protocol Fee (0.01%):
- A small portion collected for protocol development and maintenance
- Consistent across all swap types
-
Example: When swapping xETH to yETH:
- If xETH is abundant and yETH is scarce in the pool:
- Input fee will be higher (0.05% for xETH)
- Output fee will be higher (0.04% for yETH)
- If xETH is scarce and yETH is abundant:
- Input fee will be lower (0.03% for xETH)
- Output fee will be lower (0.02% for yETH)
- If xETH is abundant and yETH is scarce in the pool:
This dynamic fee structure creates natural market forces that help maintain optimal pool composition without requiring frequent external rebalancing.
As a Uniswap v4 hook, MultiSwap is:
- Highly Composable: Can be integrated with other DeFi protocols
- Gas-Efficient: Uses v4's singleton pool model for reduced gas costs
- Extensible: Framework for supporting future LRT tokens
The protocol consists of three main components:
The core hook implementation that integrates with Uniswap v4. Key features:
function _beforeSwap(
address,
PoolKey calldata key,
IPoolManager.SwapParams calldata params,
bytes calldata
) internal override returns (bytes4, BeforeSwapDelta, uint24) {
// Custom swap logic for LRT-to-LRT exchanges
// Uses specialized constant-sum curve with dynamic fees
// ...
}- Implements custom swap logic with rebalancing fee adjustment
- Manages LRT rates and reserves
- Controls token weights and target allocations
An ERC20 token representing a basket of all LRTs in the pool:
function getTotalBasketValue() public view returns (uint256 totalEthValue) {
for (uint256 i = 0; i < lrtTokens.length; i++) {
address token = lrtTokens[i];
uint256 balance = IERC20(token).balanceOf(address(hook));
(uint256 rate, ) = oracle.getLRTRate(token);
totalEthValue += (balance * rate) / 1e18;
}
}- Tracks and manages the basket composition
- Allows users to mint and burn basket tokens
- Similar to Sanctum's Infinity token on Solana
The protocol features a dynamic fee system that encourages pool rebalancing:
function updateTokenFees(address token) public {
// Calculate current pool composition and compare to target
// Adjust fees to incentivize rebalancing
// ...
}- Automatically adjusts fees based on pool composition
- Higher fees for swaps that imbalance the pool
- Lower fees for swaps that restore target weights
The fee calculation considers both input and output sides of the transaction:
function calculateInputFee(address token) public view returns (uint24) {
// Compare current weight to target weight
uint256 currentWeight = getTokenWeight(token);
uint256 targetWeight = tokenTargetWeights[token];
// If token is overweight in the pool, charge higher input fee
if (currentWeight > targetWeight) {
return HIGH_INPUT_FEE; // 0.05%
} else {
return LOW_INPUT_FEE; // 0.03%
}
}
function calculateOutputFee(address token) public view returns (uint24) {
// Compare current weight to target weight
uint256 currentWeight = getTokenWeight(token);
uint256 targetWeight = tokenTargetWeights[token];
// If token is underweight in the pool, charge higher output fee
if (currentWeight < targetWeight) {
return HIGH_OUTPUT_FEE; // 0.04%
} else {
return LOW_OUTPUT_FEE; // 0.02%
}
}Building MultiSwap involved overcoming several technical and design challenges:
- Hook Constraints: Working within the constraints of the hook system while implementing custom swap logic
- Delta Calculation: Computing appropriate balanceDelta values to communicate with the pool manager
- Gas Optimization: Making the hook efficient enough for production use
- Balanced Incentives: Creating a fee system that encourages rebalancing without creating arbitrage opportunities
- Mathematics: Designing formulas that properly factor in pool weights, token rates, and desired allocations
- Edge Cases: Handling extreme market conditions without adverse effects
- Input/Output Fee Balance: Finding the optimal ratio between input and output fees to maintain pool stability while minimizing overall swap costs
- Rate Accuracy: Ensuring accurate rates for proper exchange calculations
- Manipulation Resistance: Designing the system to resist oracle manipulation
- Failure Modes: Creating fallback mechanisms for oracle failures
- Reserve Management: Balancing liquidity needs across multiple token pairs
- Slippage Control: Minimizing slippage while maintaining efficient capital usage
- Reserve Allocation: Determining optimal token weightings
git clone https://github.com/AliErcanOzgokce/MultiSwap.git
cd MultiSwap
forge installforge test- Set your private key:
export PRIVATE_KEY=your_private_key- Run the deployment script:
forge script script/DeployMultiLRT.s.sol --rpc-url <your-rpc-url> --broadcastWith additional funding and development time, MultiSwap could be extended in several ways:
- Multi-Oracle Integration: Aggregate rates from multiple providers for robustness
- TWAPs: Time-weighted average prices to smooth volatility
- On-Chain Rate Validation: Mathematical validation of rate consistency
- EigenLayer LRTs: Support for upcoming LRTs from EigenLayer
- Cross-Chain LSTs: Integration with LSTs from other chains via bridges
- Liquid Restaking Derivatives: Support for more complex LRT derivatives
- DAO-Controlled Parameters: Community governance of fees and weights
- Fee Sharing: Protocol fee distribution to stakeholders
- Liquidity Mining: Incentive programs for early LPs
- Fee Parameter Optimization: Data-driven adjustment of input/output fee ranges
- Circuit Breakers: Automatic protections against extreme market conditions
- Rate Discrepancy Guards: Detection and handling of oracle issues
- Emergency Shutdown: Controlled unwinding capability
- Direct Staking/Unstaking: Seamless conversion between ETH and LRTs
- Validator Diversity Management: Helping promote decentralization by balancing across providers
- Custom LRT Provider Hooks: Specific optimizations for each LRT protocol
- Core protocol design and implementation
- Dynamic fee mechanism for pool rebalancing
- Integration with Uniswap v4 hook system
- Basket token implementation
- Comprehensive test suite
- Frontend UI implementation
- Mainnet deployment
- Advanced oracle integration
This project is licensed under MIT.
- Uniswap Labs for the v4 architecture and hook system
- Atrium Academy for the Uniswap V4 Hookathon opportunity
- Sanctum Finance for inspiration from their Solana LST implementation
