Overall Iām leaning toward supporting this direction. Imo thereās two options for the long term to enhance the user experience. Even though rebalancing as-is works and can be profitable, it does appear to be a net-negative on UX specifically.
1.) Put an extensive amount of effort into non-stop education of how to manage rebalancing, essentially forcing users to understand it before using the platform
2.) Implement a solution that mitigates how often rebalancing effects most people
What I like about this solution is that it gives borrowers more control over their position, but the downside is that people that do get rebalanced feel the effects heavily.
Still more to think about, but currently leaning toward this solution.
Maybe Iām misreading this but does this not just penalize people who have large loans as they will be impacted the most when rebalancing occurs? Essentially this would just mean that people would be driven away from taking out a bnUSD loan as the larger a loan you take on, the more youāll be effected by rebalancing. Ultimately would this not just drive down the amount of loans and significantly reduce the use of bnUSD?
Maybe Iām misreading this or @benny_options can clarify how this would benefit any oneā¦
My understanding is that it would drive people to have smaller and smaller loansā¦eventually people with even small loans would suffer a lot of rebalancing as no one would have large loans any moreā¦
People with larger loans would essentially be guaranteed of getting liquidated if we have a ton of reverse rebalancing again as theyād be targeted the mostā¦the effect of rebalancing on them would likely be worse than we even had last timeā¦
People who are taking out loans are essentially providing a service to maintain the peg. Why would they be penalized the mostā¦surely if anything they should be incentivized more (e.g. increased BALN rewards distribution or somethingā¦itād need to be a massive increase though to outweigh the risk they take).
Hmm sorry if Iām misreading this completelyā¦maybe this is only referring to standard rebalancing (not reverse). I guess this would make more sense but itād again just mean that the borrowers are being penalized the most. No borrower will want to be targeted as having all their collateral sold off at low levelsā¦so I guess itād have the same effect whether you mean forward or reverse balancingā¦itād drive people away from taking any form of loan and hence reduce the utility of bnUSD
This proposal is only for regular or negative rebalancing ā selling collateral to buy bnUSD to pay down your loan ~ like in the example.
They are not being penalized ā rebalancing is how the peg is maintained, and it is always profitable at the time of rebalancing (you are always buying at a discounted rate).
Edit: if they are not getting rebalanced, then they are not maintaining the peg.
If negative rebalancing is happening, then bnUSD is under valued. You could say, there is too great a supply of bnUSD.
Using sICX to buy bnUSD is how the value is restored.
Borrowers do that through rebalancing, the responsibility is shared evenly.
With this proposal, the borrowers who have created the most excess supply in relation to their collateral take the responsibility.
This will incentivize those who do not want to have their loan rebalanced to pay down their loan, helping to reduce the supply (and increase the value).
In my view, this proposal puts the responsibility of maintaining the floor price (the low threshold) of bnUSD on the ones most responsible for creating excess supply.
I like this proposal but I wonder how the groups will be defined. In the example of groups I can see the benefit, however if each borrower gets defined separately this will result in the loans with the highest LTV being repaid entirely.
You could define the groups in LTV percentages (group A 0-5%, B 5-10% ā¦) or you could say that the group will be created as a first step of rebalancing. Say a 500 bnUSD rebalancing comes in. The rebalancing proces wil create a group with a set multiplying factor. Lets say the factor is 10 as a parameter. In this case a group will be filled with accounts with the highest LTV untill 5000 bnUSD is filled and then the rebalancing happens in the created group. So from the shared 5000 bnUSD loan 500 bnUSD will be repaid. If you define groups like this you can pre set the rebalancing percentage with the multiplying factor for each seperate rebalancing event (10% in this case). This would make it more transparent pherhaps.
Plus we will have control over howmucht percentage of a loan can be rebalanced per event reducing the effect @benny_options described that the rebalancing can be very heavy on a small group of borrowers (or at least give us more control over it).
Firstly, this would be for regular rebalancing only, not for reverse rebalancing (need to come up with some better terms here haha). So reverse rebalancing (increasing collateral and increasing debt) would not be effected in any way by this @Simon
There is, however, the concern that people would be āracing to the bottomā in terms of bnUSD minted. However, the borrower rewards does mitigate this. If everybody is having such a low LTV, higher LTV accounts will be at risk of having a portion of their position closed, however, theyāll be having higher rewards.
@Chiel per your comment, there are several ways to hone this idea. This idea originally came from Liquity.org, an ETH based project. They will rebalance positions in full, starting with the highest LTV position, then work their way down as more rebalance transactions come in.
We could limit the impact per account (maybe maximum of 50% of your debt?), and could also have a larger group than only the highest LTV (maybe top 10?). All of these could also be governance parameters for continued honing by the DAO.
So far, I like the idea of adding more parameters and moving to this system. In fact, with these parameters, we could even go back to a similar system to what we have now (i.e. top 50 borrowers, 0.1% max debt payoff)
Thanks for the reply and clarification! I see all your points but I still think itāll end up driving people away from taking out loans and hence decreasing the utility of bnUSD.
The incentive for having a loan open just doesnāt outweigh the risk of having your ICX/collateral sold off. I get that itās a premium of what the market value is, but for long term holders, they wonāt be content with their ICX sold at a slight premium if they intend to hold long term and hope to sell at multiples of what the current price is.
Completely see all your points though. Itās a tricky one to be honestā¦not sure what the best solution isā¦I guess thereās going to be a ton of changes made in combination to this if rebalancing is ever going to work in the long term.
Iām still of the belief that bnUSD should just be scrapped if the only way of maintaining it is rebalancing. The ICX community is quite small and the reaction has been extreme at the best of timesā¦if BTP comes into play and tons of people from other protocols start encountering rebalancing I think itāll be a huge negative for Balanced and the whole ICON ecosystem as itāll drive people away.
I love Balanced and am hoping everything comes together but I just canāt see rebalancing ever being sustainableā¦I get some people say itās a lack of education etcā¦but even with educationā¦I think if someone properly understands the risks and what youāre doing when you take a loan out - thatās enough to drive away the majorityā¦
Thanks for the reply Benny! Iāve replied to AmaxJagoās response (should have tagged you there too!) and that kind of sums up what I would be replying here too.
Rebalancing is a really tricky one that concerns me for the future growth of Balanced. I really hope it all comes together given time but right now I just canāt see how itād ever be sustainable. Iām not a developer so maybe itāll be a multiple-pronged approach that will all culminate in rebalancing being something that is barely noticeable and can work in the long run. Hoping it all works out!
Hey @Simon@AwaxJago - as I said Iāve been poking around the Liquity community. I suggested to them āhey, why not to rebalancing equally to all borrowers based on debt? Why only target the highest LTV borrower?ā This is pretty much asking them āwhat do u think about how Balanced currently does it vs how you guys do it?ā
This was the response. A ātroveā is a position.
current model gives people an incentive to maintain healthy troves. we know we get liquidated at <110%, we know we run the risk of redemption if we are >110% but not by much, we know we donāt have much risk of either by being >250% etc. The current UX for the borrower is that āif I keep my trove healthy my ETH will always be thereā, so redemptions against the entire set would degrade that experience.
I think this is a great point. Heās saying that borrowers on Liquity, if they donāt want to get rebalanced, can actively try to make sure they donāt get redeemed against, and those that donāt care can take our higher leverage. Iām curious what people who have found strategies that benefit from the current system would think about this. Maybe @bwhli or @arch could share some thoughts.
My biggest take away from this is the understanding of their positions as something other than a traditional loan/collateral. Trove with liquidity, and maker with the term vault. Trove and Vault are dynamic entities that require monitoring and adjustments.
This makes sense for āsellā rebalancing, and as many people have mentioned it would not apply to ābuyā rebalancing. In this case, what does ābuyā rebalancing look like?
I think knowing what that is like can help us decide what it looks like on the āsellā side.
EDIT: One thing this method seems to do, is make the discrete instances of rebalancing, the size of the actual rebalancing call, matter versus account size. What happens when its larger than a highly leveraged small position? Is it better or worse if it was like current rebalancing(pool of 50) but the top 50 LTV positions shared in it? is that too heavy computationally?
My thought would be to keep ābuyā rebalancing (much easier and more clear than āreverseā rebalancing and āregularā rebalancing haha) as-is, but of course subject to decisions on other enhancements such as asymmetric thresholds and rate-limits
For this part, I was thinking that we would take a larger set than just one account. 50 accounts currently has a fee of ~.13 ICX or something like that (last I checked), so I think going up to 50 would be fine.
Also, once an account is rebalanced to a 0 debt position, they would be removed from the list. This is how we would handle it if the group doesnāt have enough debt to cover the entire requirement. The group would be zeroed out, then it would move on to the next.
Actually, now that I think about it, having it be multiple accounts is kind of unnecessary since a position can be closed in full through this process. Thereās no need (thinking as Iām typing here) to have it iterate through many accounts if itās just going to continue to closing anyway.
Well if it was already sorted, then you would just move to the next 50, which is pretty much what we have now.
But having said that, I still need to understand the best way to keep the list sorted on the contract. Liquity does it where the front end finds the right place and inserts the position, but need to understand what rules are actually on-chain to prevent non-UI users from always being at the back of the list with high LTV
If we are taking rate limiting and LTV rank into account for āsellā side rebalancing, could we arrange the positions by LTV into cohorts based on their share of debt?
For example, if we know that over a 3 day period only 20% of the total debt will be eligible for āsellā rebalancing, then could we create a cohort of positions worth an amount over 20%, and have rebalancing cycle through those positions.
I donāt know if thatās a possibility or worthwhile to investigateā¦
In my mind it was similar to current system, where it would only rebalance a portion instead of closing the positions entirely. Sort of flattening the LTV curve as it went along, but then it runs into the issue currently where it takes too many rebalance calls
Itās not the expense really, itās the lack of scaling. If the list has 1M accounts, iterating and sorting the entire list is not just expensive, itās impossible afaik.
So having said that, keeping the list sorted is probably somehting we can learn from liquity
As you say about letting the gui decide where to put the position should be the way to go, quite easy to implement and cheap to execute for the contract. When it comes to batching top LTVs i do not see any benifit here in comparison to just doing the top 1. Just doing the top 1 would be alot less edge case as well as alot cheaper
I think i was somewhat wrong here, for rebalancing this could still be very expensive. Since after rebalancing each position affected has to be resorted into the list which will be expensive. It might be better than the current solution (mabye) but still wont scale super well if userbase grows large