Liquidity Sharding Protocol
The Liquidity Sharding Protocol leverages Concentrated Liquidity from Uniswap V4 and sharding principles from OpenBook. By implementing “liquidity sharding,” the protocol divides the LP pool into multiple subcontracts (Shards), each independently managing a portion of USDT funds with predefined buy-in thresholds. The protocol monitors prices on-chain and triggers a specific Shard contract to buy assets when prices fall below its threshold. If a Shard depletes its funds, the protocol sequentially activates the next Shard, creating a tiered liquidity backstop with large-scale buy orders.
Liquidity Sharding
The protocol divides total USDT funds into N Shards, with each Shard independently managing its assigned USDT funds.
The number of Shards, initial funding, and thresholds (Price Ticks) are configurable based on strategic requirements.
Price Monitoring and Trigger Mechanism
Each Shard integrates oracle interfaces (e.g., Chainlink) to fetch real-time KSP/USDT market prices.
When the oracle reports a price below a Shard’s threshold, the contract automatically calls a Router to execute a swap, converting USDT to KSP.
Before executing the trade, the Shard checks its USDT balance. If the balance is below the minimum trade amount, it reports to the Master Controller and ceases triggering.
Shard Relay Execution
The Master Controller contract maintains the status of all Shards (e.g., Inactive, Active, or Depleted).
When a Shard’s funds are depleted or it reaches its execution limit, the Master Controller automatically activates the next eligible Shard to continue liquidity backstopping.
Dynamic Parameter Adjustment
Governance addresses can update parameters through the Master Controller contract in real-time, including:
Slippage tolerance
Maximum single buy-in amount
Threshold recalculation
The protocol supports various threshold strategies:
Equidistant thresholds
Exponential thresholds
Adaptive thresholds
Last updated