Negative Rebalance Borrowers Based on LTV Position

[AwaxJago]

Title: Negative Rebalance Borrowers Based on LTV Position

Proposed Rebalancing Queue: At the time of rebalancing, a group of the highest LTV Borrowers are rebalanced.

As discussed here:

@benny_options

3.) Organizing Borrowers into a list sorted by LTV, then only rebalancing the highest LTV accounts - This is from Liquity.org , our closest comp from ETH ecosystem. I’m on the fence as to whether or not this is better than evenly spreading across all accounts. They don’t really have this option since ETH is so expensive. Of course, this would only apply to regular rebalancing, not reverse. Liquity, fwiw, has no reverse rebalancing at all. Their LUSD and climb to any height above $1.

Here is how it could work:

Group A

• Debt = 1,000 bnUSD
• LTV = 30%

Group B

• Debt = 2,000 bnUSD
• LTV = 40%

Group C

• Debt = 1,000 bnUSD
• LTV = 50%

A 500 bnUSD rebalancing comes in.

1. Group C has 500 bnUSD of their debt repaid through rebalance, leaving them with Debt = 500 bnUSD and LTV=33%
2. Groups B and C have nothing happen.

Next a 500 bnUSD rebalancing comes in.

1. Group B has 500 bnUSD of their debt repaid through rebalance, leaving them with Debt = 1500 bnUSD and LTV=33%
2. Groups A and C have nothing happen.
3. Groups B and C combine to become group B that share a Debt = 2000 bnUSD and LTV = 33%

Next a 500 bnUSD rebalancing comes in.

1. Group B has 500 bnUSD of their debt repaid through rebalance, leaving them with Debt = 1500 bnUSD and LTV = 27%
2. Groups A has nothing happen.

Please discuss and make suggestions. Let’s get this right.

[benny_options]

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.

[Simon]

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

[AwaxJago]

@Simon

People with larger loans would essentially be guaranteed of getting liquidated if we have a ton of reverse rebalancing

@Simon

maybe this is only referring to standard rebalancing (not reverse).

This proposal is only for regular or negative rebalancing — selling collateral to buy bnUSD to pay down your loan ~ like in the example.

@Simon

People who are taking out loans are essentially providing a service to maintain the peg. Why would they be penalized the most

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.

@Simon

No borrower will want to be targeted as having all their collateral sold off at low levels

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.

[Chiel]

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

[benny_options]

Hey @Chiel @Simon let me hop in.

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)

[Simon]

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…

[Simon]

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!

[benny_options]

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.

[AwaxJago]

@benny_options

This was the response. A “trove” is a position.

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.

[arch]

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?

[benny_options]

@arch

In this case, what does ‘buy’ rebalancing look like?

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

[benny_options]

@arch

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?

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.

[arch]

My thinking with 50 was it would re-evaluate what top 50 LTV is each time, but I assume thats expensive.

[benny_options]

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

[AwaxJago]

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…

[arch]

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

[benny_options]

@arch

My thinking with 50 was it would re-evaluate what top 50 LTV is each time, but I assume thats expensive.

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

[Andell]

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