# Mechanisms

> 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.

### Rebalance Incentives

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](https://docs.keep3r.network/), [Gelato](https://www.gelato.network/), 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.

```solidity
urgency = 100000 * (block.timestamp - _recenterTimestamp) / 24 hours;
reward = gasPrice * gasUsed * urgency / 100000;
```

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, $$gasPrice\_{new}=\frac{reward}{gasUsed}$$

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.

{% hint style="info" %}
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()`.
{% endhint %}

### Maintenance Budgets

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`.

```solidity
maxBudget = K * gasPrice * maxRebalanceGas;
```

* `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).

{% hint style="info" %}
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).
{% endhint %}

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](#rebalance-incentives)).

### Other Notes

* 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](https://colab.research.google.com/drive/1XfBQashmhGTaHyf_Byl_vMIPNB-Y_Xd3?usp=sharing).
* 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.aloe.capital/aloe-blend/mechanisms.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.