Of course it also got to do with the fees??? You are trying to increase the activity on building lusd and allowing more people to claim at lower P ratio… you have to pay a high fee for doing this. Why should I build more if I pay 2 to 4 dollars as a fee??? The net benefit for building does not justifythe cost for building. Also with that volatility you basically are going to trap more people into liquidation if a sudden correction occurs.
The $2-4 dollar fee being worth it is very subjective, to some it may make sense to build more LUSD (although needing to pay gas fees) and for others it won’t. Also worth noting is that users do not necessarily need to build to a 400 p-ratio. Conservative users can choose to keep a p-ratio of e.g. 600. However, allowing active users, with good risk management to build further should be a net benefit
Again what is the research supporting this. Simply stating the team has concluded that this would be ok doesn’t mean anything without concrete results and analysis. Please share the supporting analysis. Also the new ratio has not really been tested through a full cycle.
We’ve simply monitored the debt pool, usage and overall p-ratio on the platform (stands at 660) . As for not allowing a full cycle, that is true, yes. However, if we set that as a requirement (needing a full bear/bull cycle) that means we’ll get stuck and not be able to implement changes other than every 3-5yrs. I trust none really would support such action. We’ve also looked at similar protocols and their p-ratio’s and protocol risk. When we decided to launch at 500 later reducing to 450 and now 400, we wanted to ensure to take a measured and conservative approach. Initially when we posted the 500 → 450 prop some user argued that we should go to 400 directly. In hindsight this would have proved no problem, but we decided to err on the side of caution
I saw so many other suggestions to fix the peg none of them are followed up by. Are you tempering with p ratio because that is all that can be done as a DAO??? Please stop!!!
As mentioned during the call tonight (and thanks for joining and posing your questions to the team, appreciated) we look into all suggestions and proposals that the community presents. We’ve had great discussion with community member pho/philipp (and others) regarding the peg protection bot and research and thought are still going towards this.
Btw I saw some guy commenting on discord on possible solutions for the high fees. Have u seen that? Here is the message: Hey there, I was looking at the code and currently thinking about the decision process on the staking contract. Why you don’t use reentrancy guard with a modifier instead of accessing memory? (This cost more gas) Also why not moving everything to a mapping as to lower the gas fees without doing too many operations and accessing at the same time other mappings? And why not allowing bulk claim, without putting a time restraint? Thanks
Yes, we saw this, and while I’m not a dev and capable to ascertain if this is feasible, it has been forwarded to the dev team for consideration.
