Revise re-balancing threshold to a variable rate

Proposal Discussion WIP: BIP
#1

Our current system of having a fixed re-balancing threshold value and gradually having it lowered is starting to show signs of weakness since re-balancing is occurring more frequently as the peg tightens. According to on-chain data, users who took out loans had nearly 50% of their loans removed in the last month alone.

A better solution to this problem would be to change the re-balancing threshold from a fixed value to a variable one. When Balanced was first launched, we had a re-balancing threshold of 5% and users were re-balanced infrequently. However, now that we’ve reduced it to 2.5%, re-balancing has become so frequent that the total amount of bnUSD minted has fallen significantly according to stats.balanced.network.

It’s evident from the last 6 months of observations that a tighter peg leads to more frequent re-balancing. Therefore, I’d like to propose that we make the re-balancing threshold that constantly changes from 4% to 0.25% back to 4%, by checking the value of the block height every time the rebalance method is triggered.

For example, in a typical week, we can have 3 days with a peg of 4%. After that, for the next 12 hours, the smart contract would set the peg to 0.25%. Once the 12 hours has passed, it would change back to 4% again. Rinse and repeat. This ensures that Balanced users have the opportunity to swap their tokens with bnUSD at CEX (Centralized Exchange) prices at least twice a week, while borrowers are re-balanced less frequently.

I believe this proposal would satisfy the following parties:

  • Users who like to trade at CEX prices will have the ability to do so at least twice a week.
  • Arbitragers will still have the ability to trade (which generates a significant amount of network fees for BALN holders).
  • Users will be more willing to mint bnUSD due to less frequent re-balancing.

There is likely an even better solution to this, but this will be the easiest and quickest proposal to address re-balancing concerns since the amount of coding required to implement this is minimal as it only requires one additional check of the block height to determine the threshold value.

Thanks for reading

…

sirs.

6 Likes
#2

Definitely seems like a better mechanism than the one in place now. Better have this running in the interim till we get other features rolling that support the peg.

#3

Thanks for sharing Ken - I’m open to building this as I don’t think it would be all that difficult, but I would first like to try a few other ideas. Check out this comprehensive post I just made about the current situation.

Whether it’s this enhancement or another one, honing the rebalancing process is a core responsibility. My thought is that the rebalancing threshold should be set to the cost of arbitrage + some spread for arb traders to earn. But will continue thinking more about it

#4

One thing I want to point out (though slightly off topic, my apologies), is that this is essentially by design. There’s too much bnUSD out there, so rebalancing keeps burning it. My recent post explains this in detail. Check out the section on Borrower Behavior

1 Like
#5

Coming back to this, as I’ve been thinking about it alot. Overall, I think periodic rebalancing rather than constant at a fixed threshold could make sense. Trying to think of which variables we could play with that aren’t all that difficult to develop, like you said.

1.) Time - this is what you suggested
2.) Amount of bnUSD retired - could be a fixed number of bnUSD or a percentage of total supply, which can be fetched from the bnUSD contract rather easily
3.) Something else I haven’t thought of
4.) Some combination of multiple.

Would love more thoughts from others as well, @arch @bwhli @Uglyrage @Ken_M let’s try to build this list and come up with more tangible rebalancing enhancements, then we can discuss which to implement. Overall I have no issue with Ken’s initial suggestion, just want to think about alternatives before implementing.

1 Like
#6

Evening!,

as previously stated in Rebalancing, bnUSD supply and DAO Management - #25 by Uglyrage and Rebalancing, bnUSD supply and DAO Management - #30 by Uglyrage i dont believe changing the peg has that much effect on rebalancing… Also i used to think transaction routing would help, but i no longer think that is the case (since all transaction routing does is combine the trade, and the following internal arbitrage into 1 transaction).

There is an idea forming in my head though that is linked to the POL (The longer i think about it… the more i like this idea) discussion.

The idea is this: Have the Dao hold liquidity in 2 pools (Baln / ICX (pool 2)& Baln / bnUSD(pool3?) ). And give both pools shifting targets (peg breaking down, shift DAO fund LP’s towards pool3, Peg breaking up, shift towards pool2).

If the peg breaks one way or another for too long, we could have a second mechanism of dynamic LTV, and use forced rebalancing as a method of last resort.

================ Addition ================

And down the rabbit hole we go again… The option stated above will probably be severely undercut by newton’s third law (Every action has an equal and opposite reaction.)

The DAO fund moving from BALN sICX to BALN bnUSD would make the market do the opposite due to changing reward rates.

Come to think of it… That basicly sums up the entire problem we are facing :rofl: :rofl:

Let me google that… Newton’s third law in finance

#7

Oh I forgot about this thread as well, I should have refered to it when making my suggestion on rate limiting.

@benny_options I would like to note what I feel is an important distinction between my suggestion in the other thread and @Ken_M 's idea.

What he proposes is the peg alters as time and as distance to peg passes. While it the effect is likely similar in most cases, at any particular time the ‘force’ towards the peg is infinite. Anyone can call the method as many times as required to put it to the exact amount, even if the amount itself is dynamically set. It also requires us to set various explicit amounts.

What I think is better is to control the amount of ‘force’ towards the peg. In that way we can have a known constant absolute peg, which can be even 0%, as long as the force is low near 0%. To be honest both implementations can very closely approximate each other but I think the framing of it in terms of force/speed/rate is more natural.

This also allows larger deviations in peg for short periods, preventing large swings from making people ‘feel bad’ when it sell at the bottom and it bounces back, and is additional flash crash protection. It also more closely models other types of stablecoins, where while even if they are perfectly backed, there is a time cost to do so, which gives their value more ‘elasticity’ than bnUSD. I feel like bnUSD even when the peg is wide, still has a too rigid peg. I think wide or narrow should be independent to the speed at which it converges and while you could absolutely implement it as a dynamic peg % that is still too rigid I feel.
The rigidity allows large traders to trade against the collateral as well, which is not intentional I assume. I think regardless of any other measures, some time factor is required to prevent traders trading against the collateral. No matter how stable a stable coin is, if you traded USDC heavily in either direction on ICON today, it would take quite a while to correct. There is no ‘infinite liquidity’ at exactly 2.5% or 4% premium or whatever is chosen.

2 Likes
#8

If i understand you correctly the main differentiation you are arguing is when peg is further off, rebalancing can be triggered more often, or in bigger batches, while when the peg is closer. There can still be rebalancing, but less often, or with less volume?

If i understood this correctly. I think this is a big step up from @Ken_M’s original proposal. What do you think @Ken_M ?

#9

Yes, thats the gist of it

For anyone that missed it in the other thread I also go through it in a bit more detail here

#10

Guys,

I might have found a solution to keep the peg stable without the need for rebalancing. To be honest… It’s so simple, i am sure i am missing something.

What if, instead of a variable peg, we use variable trading fees on the bnUSD/ICX pair? In my mind… That would stabilise the peg, and maybe even increase trading on the dex by multiples. It would work like this… If bnUSD peg is broken to the downside, we should lower the fee to buy bnUSD with ICX. and maybe increase fees on the other side of the trade. If it breaks up we do it the other way around.

That way, when the peg breaks down… we limit the sell pressure on bnUSD, and create Buy pressure. & The other way around when it breaks up. Maybe it would need a direct bnUSD / ICX pool instead of going through sICX though.

If i’m not mistaken… The lower trading fees would be more than made up for by exposing us to the 60m+ daily ICX volume (according to CMC: ICON price today, ICX to USD live, marketcap and chart | CoinMarketCap ).

@arch, @benny_options, @Ken_M @AwaxJago and any other big brains i might have missed. Please point out the flaws in my reasoning.

Thanks!

#11

That doesn’t really work imo, because the fees are just part of the trade already. You are sort of right that rebalancing will reduce, but the amount that rebalancing will happen less by is exactly the amount lost in fees. The new peg is just fee% + peg %, which is what the current non dynamic fee% + peg% is. The trader doesn’t care if the loss is due to bnUSD being worth less or a higher trade fee, the end result, how much do I get, is what effects the trader.
The same effect could be achieved by spending collected fees to prop up bnUSD which is basically a variation on the same concept of using the DAO as part of the rebalancing pool, just instead of being ‘first’ and running out, it participates a small % of every rebalance. Again you’re not wrong that it will reduce rebalancing, it is always possible to spend DAO money to reduce the effects of rebalancing. Rebalancing is already being compensated for, thats what the rewards are for. Either it is or it is not sufficient, and personally I would argue it is over compensated still, so would be quite against additional incentives, like fundamentally funneling trade fees into borrowers is.

Rebalancing is not a loss, it is not an enemy, paying people to stop rebalancing is essentially just manipulating the market. The goal of time based rebalancing limits is not to reduce rebalancing, that is a small side effect. The goal is to stop people being able to trade against the collateral at the peg premium. The participants in the LP signed up for being traded against, the participants in the collateral did not. As it stands with the rigid peg, regardless of the peg, of ANY amount, once its at the edge, it allows traders to trade against it by calling rebalance in between small trades.

Like you have said, changing the peg wont efect the amount of rebalancing, and the peg is just fee%+peg%. Adding a time component is very beneficial IMO.
Other than the primary goal of not letting traders trade against the collateral pool, adding a time component lets it smoothen out volatility which naturally will result in less rebalancing required. And if the in the event the market is in a striaght direction with no volatility, then that is in fact the role of rebalancing, but at least smaller flucuations will cause less of it.

I still believe the rigidity of the peg is the issue, even the most stable stablecoins in the world if for whatever reason they are at 2.5% off peg, can still fall if there is market forces for it. Our stable should also be allowed to do that. What matters is the eventual or long term stability. The bnUSD peg doesn’t need to be perfect 100% of the time, it needs to give people confidence that it will be pegged eventually. If bnUSD falls below 2.5%, but you and me KNOW rebalancing would push it up, it gives you and me time to trade agaisnt it, and therefore buy bnUSD, which won’t make rebalancing unneeded, but it will make it less. Because people will be more willing to take the trade. As it stands, ONE party will buy bnUSD, and then spam rebalance, and then sell the bnUSD. Having time in between makes it more natural, and have more participants involved.

1 Like
#12

Thanks for the insight!

Dont get me wrong… I agree with you that the goal isn’t to eliminate rebalancing. The problem we are facing right now is that the rate of rebalancing, and the fact that the peg is (almost) allways broken to the downside is seriously hindering our ability to collect fees.

We have allmost doubled the collateral requirement, In essence halting the minting of bnUSD (seriously cutting into dao profits). and still the loans have been rebalanced for over 30% in the last month. This undercuts the entire promise made around the zero interest loan. On top of that… The fact that the stablecoin isn’t stable, and fact that the rebalancing doesn’t correct that against an acceptable cost appears to work against the reputation of the dex.

I have never before considered the point that the ridgid peg we have right now can easily be taken advantage of, but i think you are right here, and think this should be fixed asap (and can be fixed by the method you are proposing).

However, at this moment i am not convinced it is enough to bring the peg to $1 for any acceptable amount of time, or seriously change the minting / rebalancing dynamic.

#13

Rereading the above i believe we can all agree on a couple of things:

  1. bnUSD needs to reach $1 every now and then for it to function as a stable coin.
  2. There needs to be some flexibility in the peg to prevent people from abusing the system
  3. Where possible, forced rebalancing, or its effects on the community should be minimized, while stil ensuring stability of bnUSD.

If anyone doesn’t agree with one or more of the above statements i am very curious to hear more. Same if i missed a key point.

So far i have read the following possible solutions:

  1. Change the peg throughout time, forcing it back to $1 every now and then
  2. Change LTV
  3. Change “elasticity” of the peg, alternating the force towards it, the further off it gets
  4. Change trading fees based on peg

As far as my understanding goes…

  • Solution 1 only helps on statement 1
  • Solution 2 only helps on statement 3
  • Solution 3 only helps on statement 2
  • Solution 4 only helps on statement 2 & 3

I am curious if we all agree on the above statements

1 Like
#14

I don’t want to flood the thread but in my opinion, 4 is just the same as 1, there is no difference between changing the fees and changing the peg, because right now the effective peg will always be trade fee% + peg width%. This is the way it is already, and this will be the way it is with a dynamic peg(Sol.1) and will the the way it is with dynamic fees(Sol.4).

Increasing the fees on one side of the trade merely weakens the peg in that direction, from 2.5%+0.3% currently, to for example 2.5%+1%. Or whatever. It also significantly impacts the perception of routing imo, where with that new system the fees are opaque. The calculations can still be correct, but currently you at least know the fees by number of hops, instead of with that other system. I would strongly favour a dynamic peg over dynamic fees.

EDIT: I also do not agree with statement 3. Rebalancing should be tweaked to reduce its impact on borrowers insofar as it doesn’t destroy the stablecoin. As written, adhering to 3 means market movement can easily depeg it and damage trust which will accelerate the depegging.