⚙️Mechanisms
How Blend can operate as a hyperstructure
Last updated
How Blend can operate as a hyperstructure
Last updated
The information provided by Aloe Labs, Inc. (“we,” “us” or “our”) on docs.aloe.capital (the “Site”) is for general informational purposes only. All information on the Site is provided in good faith, however we make no representation or warranty of any kind, express or implied, regarding the accuracy, adequacy, validity, reliability, availability or completeness of any information on the Site.
Under no circumstance shall we have any liability to you for any loss or damage of any kind incurred as a result of the use of the site or reliance on any information provided on the site. Your use of the site and your reliance on any information on the site is solely at your own risk.
Most products require consistent maintenance and upkeep in order to operate properly. Lending markets like Compound and AAVE rely on liquidators to eliminate bad debt, and AMMs like Uniswap rely on arbitrageurs to keep prices up-to-date with centralized exchanges. In general, people who perform these upkeep tasks are called "keepers."
With Aloe Blend, the keepers' job is to rebalance pools every day. Unfortunately this isn't free -- each rebalance costs around $100 -- so Blend has to give keepers some sort of incentive. There are a few off-the-shelf solutions for this (keep3r.network, Gelato, etc) but they tend to inject awkward tokenomics and constrain the incentive design space. So we built our own.
Since each pool needs to be rebalanced, each pool manages its own incentives. The payout is proportional to "urgency" which scales linearly with time. It resets to 0 whenever the pool's primary Uniswap position is re-centered around the current price.
As you can see, the payout is dependent on gasPrice. Blend estimates this value by assuming that keepers break-even when they call rebalance -- i.e. reward is approximately equal to transaction cost. Therefore,
This gas price estimate is performed at the end of every rebalance and appended to a circular buffer so that the pool can track the moving average. There's a separate circular buffer for each ERC20 that's been used for rewards.
Just because a pool has been rebalanced doesn't mean it has been re-centered. Re-centering only takes place when the pool's inventory ratio is 50% ± 1%. If that condition isn't met, limit orders (range orders that are tickSpacing ticks wide) will be placed to get back to 50/50.
What this means is that the rebalance incentive may remain high even after multiple rebalance calls. It only goes to 0 after re-centering. You can see which case is playing out by checking rebalance event logs or getRebalanceUrgency().
The previous section showed how Blend determines how much it wants to pay keepers. But how much can it pay keepers, and where does that money come from?
To fund rebalances, Blend streams up to 10% of earnings to its maintenance budgets. There's one for each token: maintenanceBudget0 and maintenanceBudget1. With sufficient TVL, the contract will reach equilibrium and each maintenance budget will be clipped to maxBudget.
K is set to 20. This creates a buffer so that the pool can incentivize rebalances despite fluctuating earnings and gas prices.
maxRebalanceGas is the maximum amount of gas that has ever been used during a rebalance call.
Once maxBudget is reached, the maintenance budgets can be replenished at-cost. So instead of paying 10% of earnings to the maintenance budgets, the pool only has to pay around $100/day (or however much rebalance transactions cost).
Blend maintains a flag called maintenanceIsSustainable. This flag is true if either maintenanceBudget0 or maintenanceBudget1 is greater than maxBudget, and false if either of them drops below maxBudget / L (L=4).
When maintenance is sustainable, the width of Blend's Uniswap position is based on implied volatility -- usually a few thousand ticks wide. But if maintenance isn't sustainable (i.e., the pool doesn't have enough TVL to incentivize daily rebalances), Blend will expand its Uniswap position considerably -- tens of thousands of ticks wide. In this mode, the pool could go for months without rebalancing, albeit with slightly lower capital efficiency.
If some teams/protocols want to ensure maximum capital efficiency despite low TVL, they can subsidize the cost of rebalancing or simply do it themselves (at a loss).
For token0 and token1, payouts to keepers are constrained to be less than the maintenance budgets. If the contract happens to hold other tokens, keepers can request those and no constraint will be applied (just the usual reward computation described here).
New entries into the gas price oracle's circular buffer are clipped such that they're not less than currentAverage - currentAverage / D where D=10. This helps protect against a certain form of attack, described and simulated here.
After each rebalance, 5% of pool funds will be left sitting in the contract (not deployed to Uniswap or silos). While this slightly reduces capital efficiency, it drastically reduces gas costs for depositing, withdrawing, and placing small limit orders.
To save gas, maintenance budgets are only updated during rebalances. This causes deposit and withdraw to give you slightly (very slightly) less than what you're owed. So if you're depositing or withdrawing a significant fraction of the pool, it's best to do so immediately after a rebalance. You can trigger one yourself or wait for keepers to do it.