Update on the Omnipool Rebalance Methodology

“It is I, C-3PO! You probably do not recognize me because of the red arm…”

We would like to share an exciting change we are making to the Conic Omnipool design that deviates from our whitepaper.

In our current design outlined in the whitepaper, rebalances are done by users being able to swap LP Tokens. Giving LP Tokens to the Omnipool that it is under-allocated in relative to the target, and in turn receiving an equivalent value of LP tokens that it is over-allocated in. While this system works, we have found during implementation and testing that it is rather verbose and could benefit from a simpler design.

Instead what we will be using is an incentivised and passive rebalancing system based on deposits and withdrawals from the Omnipools. When a user deposits into an Omnipool it will always go to the least allocated Curve Pool, and when a user withdraws it will come from the most over-allocated Curve Pool. This means that with regular deposits and withdrawals the pool will maintain a balanced state.

To incentivise regular deposits and withdrawals, we will be giving out CNC emissions to users who deposit into Omnipools while the pools are imbalanced. The CNC received will be based on the amount deposited, and will also increase over time while a pool is imbalanced, and will stop when the pool is balanced again.

This is a much simpler and easier to understand system for users, while having a nice benefit of sharing CNC distribution to users who deposit into Omnipools, instead of just users who are swapping LP Tokens.

Another benefit with this approach, is that rebalances do not incur a loss for the pool. With the old design, because of minor inaccuracies in the pricing of LP Tokens, we could expect a small loss to the pool with each rebalance. Which would limit how often we were able to do governance votes for rebalances. With this new design, we can rebalance more often.

Thanks to this change we can boost the governance power of vlCNC and allow for more frequent voting of Omnipool liquidity allocation weights :rocket:

We’re excited to be in the last stretch for Omnipools and are looking forward to bringing these to you soon

7 Likes

The new method does look easier to grasp than the previous one.
Providing regular tokens is much easier for everyone instead going through the trouble of providing liquidity to Curve first and then balance on Conic. One less step is cool. :slight_smile:

So what about big withdrawals? Would they still be taken via multiple pools to reduce slippage? If so, is there a threshold for when withdrawals are made via multiple pools?

1 Like

Thanks @Lauriii :robot:

For small to medium deposits & withdrawals, it will go through the most under-allocated or over-allocated Curve Pools respectively. For large deposits & withdrawals it will deposit or withdraw from several pools such that it leaves the pools in the most balances state afterwards. The threshold for this, is any deposit or withdraw that would leave the Omnipool less balanced than before the deposit or withdraw if it went via a single Curve Pool.

3 Likes

Thank you

Did this important modification cause you any major changes in the code?

Also, is there a limiter as in that the reward strictly only cover the imbalanced part of the pool?
Say the pool is 48:52 so depositors could earn rewards for these 2%.
What if someone deposited 3% at once though?
I assume he would be rewarded for the 2% and the remaining 1% goes unrewarded?

The main impact on the codebase is just that there is less less code needed. Which as nice as we can have a cheaper quicker audit, less surface area for bugs, cheaper gas, ect.

Yes there is a limiter in the CNC emissions. The way that this is implemented is that the CNC rewards a user receives is based on how far they bring the pools in line with being rebalanced. So if the pools are currently 30% imbalanced, and the user brings them to being 20% imbalanced, then they will receive 33% of the remaining CNC allocated for the rebalancing. Once the pool is balanced, the rewards as set to zero, and will stay as zero until the next rebalance period.

So in your example, the user would receive 100% of the remaining CNC emissions for the rebalance (as they would bring it into perfect balance). And then no more CNC as the allocated emissions would be zero.

1 Like

Please forgive me if this is a stupid question, maybe I didn’t fully understand the code base.

If somebody deposits into an omnipool they have the right to withdraw from the pool right? So if we reward depositors for rebalancing pools, how do we prevent them from “farming” cnc by just depositing and immediately withdrawing their deposits again?

Thank you.

How much CNC is being put aside for this new emission stream?

for some reason they don’t seem to find full tokenomics breakdown important to release.

Hi @Michzor

Yes of course, users can withdraw at any time, and there are no withdrawal fees :robot:

Two mechanisms prevent this “farming”.

Firstly, it will not be possible to withdraw or deposit to make the Omnipool imbalanced. If a withdrawal or deposit would happen that would imbalance the Omnipool past a threshold of X%, then the withdraw or deposit would instead withdraw or deposit from several Curve Pools such that the Omnipool would be perfectly balanced afterwards.

Secondly, once the Omnipool is balanced within X%, CNC emissions to incentivise deposits will be set to zero until the next rebalance period.

You can find our tokenomics at a high level here.
There will be a more detailed breakdown once the protocol is finanlized and under audit.

This amount is not yet finalised, we will share more details on this once the protocol is complete and under audit.

2 Likes

What happens if the allocated CNC tokens for rebalancing are depleted?

There are systems in place to accept external tokens to incentivise rebalancing (similar to bribes) and redirecting protocol fees to incentivise rebalancing :robot:

2 Likes