Vault Sharding

Abstract

Rebalance-auction slippage is the main bottleneck of LP-strategy vaults: at each rebalance a vault adjusts its token holdings to restore the desired price exposure, and the larger the vault, the worse the execution. Splitting one large vault into n sub-vaults with staggered rebalances shrinks each auction to a fraction of deposited funds, improving strategy performance with no change in depositor UX. The trade-off is gas, which makes the design L2-native.

1. The bottleneck

The main bottleneck of all of these LP strategies is slippage on the rebalance auctions, during which vaults adjust their token holding proportion to bring back the desired price exposure.

To solve this problem we apply so-called vault sharding. Instead of running one huge vault for $24M of deposited funds with a rebalancing auction once per 24h, we run 24 sub-vaults, each for $1M.

2. How sharding works

For example, in a case with a number of sub-vaults n = 4, we have 4 shards or sub-vaults, each of them holding 1/4 of the deposited funds (DF).

Each of the sub-vaults still rebalances once per 24h, but instead of having one huge auction for 10–20% of vault DF, we have 4 auctions each for 2.5–5% of the vault DF. With n = 24, we have 24 shards with rebalances each hour for only 0.42–0.84% of the total DF — which significantly decreases slippage on rebalances, hence improving strategy performance.

3. Depositor UX

For the depositor there is no change in UX, as all of these complexities can be abstracted away. If the user deposits funds into the Hedgehog strategy, these funds aren't instantly provided to the pool, but wait until the next rebalance — so instead of adding 100% of funds to one vault, we can add 1/n to each sub-vault, targeting equal fund distribution between all of the sub-vaults.

4. Being the largest LP in the pool

One more advantage of this architecture: even if we become the largest liquidity provider for a single pool — or even the only LP in the pool — everything still works without causing a negative feedback loop, as (n−1)/n (23/24) of the DF is still present in the pool at any moment. This is very important for new tokens with small pool liquidity, like oSQTH or Perp protocol pools.

5. Trade-offs

There is a trade-off between slippage and gas costs on rebalances. That's why the design is more suitable for deployments on L2s (e.g. Optimism) rather than on the Ethereum mainnet.

← Back to research