Trying to understand this, perhaps the author (@BigMike ) can shed some light on the following:
Establish a stable “safe” ratio at which the deficit can assumed to be in order for the protocol to function as intended. This ratio may increase or decrease in the future due to new features and revenue streams.
Establish an “unsafe” ratio at which the deficit can be assumed to be too low in order for the protocol to function as intended.
I am guessing this is a protocol wide ratio. Let’s just use an example:
If deficit <= 75% then we will consider this “safe”
if deficit > 76% then we will consider this “unsafe”
The above states:
an “unsafe” ratio at which the deficit can be assumed to be too low
Is this suppose to be an unsafe ratio at which deficit can be assumed to be too high?
Mint this token only when the deficit is below the stable ratio.
Is this suppose to be, mint the token when the deficit is above the safe ratio? i.e. 76% or more?
If there is a total of 1,000 dBNT sold at 5 DAI each, we’re looking at a pool total of 6,000 DAI. Buyback Pool = Total dBNT x dBNT price x 120%
Using this example, are you saying that the pool should allow for $6K worth of dBNT and $6K worth of $BNT? i.e. a pool that is ~$12K in size?
Safe ratio could be 20% deficit. Unsafe could be 40% deficit, and I envision it as a sort of “uh oh, we’ve been operating unsafely already but now we need further steps to remove deficit”. I guess you could call the ratios “levels” of deficit instead.
Yes. Looking back over it, the names of these ratios are a bit confusing.
In my above example in this post, the deficit in this case would be higher than 20%. If the “safe” level is deemed to be no deficit at all, then it would be 0%.
There is absolutely no $BNT involved whatsoever. It’s based on USD (DAI) value at all times. dBNT would not be traded on the platform. It would purely be bought directly from the platform and sold directly back to the platform.
We should continue discussing how to simplify the proposal in order to find a balance between spent dev time and the ROI/positive effect on the deficit instead of dismissing it because of dev time, when we are still at the drawing board and don’t even know how much dev time it would really cost in the end. Possible implementations were discussed, so I am a bit confused to see you disregard this proposal with that (non) argument.
Yudis example where we could bring it to basically zero dev time when it is just as a DAO vote commiting to cover the debt based on future revenue would be a first step to regain trust and I don’t see anything speaking against it. But at the same time I think it wouldn’t bring as much confidence as the original proposal so we should discuss what could improve that example. Do we need a debt token? Do we need it now? Or should it come after we gained some trust with new big features? May a commitment to an BNT airdrop be sufficient?
Any ideas for simplifications while still having most of the positives the original proposal could bring?
A feature such as this I believe would be the new big feature. Whatever the solution is, it needs to be trustless in the sense that Bancor and the DAO cannot go back on their word in the future, no matter what happens. Trustlessness is the key in building back trust, as funny as that sounds.
If Bancor had a positive reputation, then I imagine a DAO commitment would hold much more weight. As it stands, that commitment would effectively mean nothing.
I agree, a DAO vote alone isn’t enough, especially as we see proposals these days that go strictly against the what DAO voted in the past (v2.1 forced migration vs upgradability clause).
Thanks for the Diagram, it clears up some of the things that I had questions on.
I am confused here because in the original post you mentioned that:
staking of a token means that it is tradeable and therefore needs BNT trading liquidity approved by the Bancor DAO.
Unless what you are suggesting is the following:
Any new dBNT that gets created has a fixed price that people can buy at (we would have to figure out what that is)
People that buy dBNT need to deposit this on Bancor so that we can direct revenue to them (depending on deficit levels) at some time interval so that they can collect fees proportional to how much dBNT they have. This is not an AMM pool in the sense that it is paired with another asset.
Proceeds from the sales of dBNT go towards deficit reduction across the protocol.
Revenue collected from when the protocol is in safe levels go to the buyback pool (this is capped based on how much dBNT was sold and the premium we are going to pay) to eventually buy dBNT and burn.
After buyback pool is filled and deficits are in safe levels, then everything goes back to LPs.
I think that sounds correct but let me know if it does not.
I am using the term “staking” loosely. dBNT would be able to be deposited to a theoretical holding pool that just allows for the accrual of fees and the selling of dBNT directly back to the protocol. No trading, nothing fancy.
Correct. dBNT is always sold at a fixed price.
Correct. dBNT is in no way related to AMM features. It is simply a device of purchasing debt. Think of it as a loan with a guaranteed interest rate when the deficit recovers.
Correct
Correct. The buyback pool will always be equal to the USD or DAI value of the total amount of dBNT sold by the protocol, plus a reward percentage. dBNT cannot be minted and sold by the protocol while operating at safe levels either.
Correct. Once the buyback pool is filled, there would be no longer be any incentive to hold dBNT, so holders would naturally sell it back to the protocol to be burned for their initial purchase price plus reward.
I have to agree with that - any time that isn’t spent on the recovery efforts right now actually reduces the chance that any deficit tokenization will have value.
So even though I support this in general, I do think that spending this time on recovery is the best avenue for everyone.
Hard disagree. The recovery efforts you speak of currently are completely nebulous to the DAO. More and more liquidity leaves the protocol daily and I expect the amount to increase swiftly as the elephant in the room (LINK and eth 2.0) approaches. The protocol needs to do something visible quick to stem the bleeding before all liquidity leaves and any remaining vestiges of trust disappear. This would be a good start.
What has been done and has any of it had a significant impact and are we better off today than two months ago?
I think the answer is not much and little impact.
What recovery is currently being worked on and how much can effort can we afford to spend on debt tokenization? Only the coding team can give us a Gantt chart of current projects, so that the DAO can properly evaluate where to place effort on recovery projects vs. debt tokenization. It is being made to sound like we have so little coding manpower that any effort to do tokenization will seriously impact other recovery projects. Is that really true? We are too in the dark here over how much effort ANYTHING takes. It is mighty hard, therefore, to allocate resources. Even if we pass a DAO proposal, we don’t know if it is going to sit on the loading dock, or if it can be done in a few days, weeks, or months.
What is left to try? Do we think any currently proposed recovery plans will have a significant impact over the next few months? I really don’t know, but if something doesn’t reverse the current trend, and soon, the problem may become too big to remedy with any solution. We are having a bit of cognitive tension between the short term impact and long term recovery. It will probably have to be a blend of the two, with the ratio of effort changing over the next few months.
We have to look at all proposed solutions simultaneously, evaluate the manpower cost and speed of execution coupled with the size of both the short and long term impact. Governance has several proposals in initial stages that are fledged out enough to evaluate. If we are to decide which ones get implemented, then we have to have at least a rough cost and impact analysis of each one.
I agree here, in my opinion the core issue is that the DAO has no insights about what the devs are currently working on and how much manpower we even have. Mostly it is only Yudi who is giving us a rough idea how time intensive the various proposals would be, which I appreciate but I think isn’t enough, especially for people who have no experience in coding.
The DAO being kept in the dark about what the devs are currently working on makes it hard to decide on any proposal such as this one. It limits the DAO’s ability to make an informed decision, as it enables anyone to disregard proposals by claiming the dev time is not worth it, as there always is potentially some more valuable work going on. It sets the bar for any slightly dev time intensive proposal extremly high which discourages people from creating proposals.
If we knew what is getting worked on the DAO could decide if new proposals should have higher or lower priority than the current coding. But we don’t get that information, we can only get a rough idea if you follow the channels closely. My impression is they are likely busy with the the v3 features they initially planned as they are trying to make them can work in the current circumstances, but I can’t vote based on an rough impression based on some breadcrumbs.
So as I don’t know what kind of high priority features are getting developed and how much ressources it needs, I can’t really tell if the dev time is worth it so I have to trust Yudi here that it is not worth it in the current form even tho I really like the idea in general. Maybe we can still try to work towards a DAO vote, making it commit to create some kind of debttoken/airdrop/whatever for LP’s who deposited before the halt of ILP, it should be based on a trustless smart contract but that doesn’t have to get built now and can get postponed until dev ressources aren’t as stressed as they currently seem to be. It shouldn’t take years tho as it needed to regain trust and make sure the DAO can’t turn back on that promise.
in my opinion a vote only confirming an intention of “we’ll do something in this direction at some point” is definitely not sufficient. as has been pointed out repeatedly, trust is decisively broken, and something needs to happen sooner rather than later.
in fact, personally i’d rather see priority given and more time spent on developing this proposal, an entirely new feature providing a new source of relief and a potential way to restore the protocol’s function via outside funding, rather than continuing on the path of creating some new fee generating feature or whatever is being worked on right now (as that is what we plebs have been allowed to given the idea of what is being worked on at the moment).
I’d like to clarify the process - usually before coding, there are product features/specs - once product features are presented, there will be a DAO discussion, vote and only then it’ll move to implementation.
Lots of community members have been discussing different recovery options/features/ideas and there are few that look more promising but as I mentioned in various places, in terms of efficiency, it’s always better to do the first assessment before discussing the solutions.
My suggestion is to wait a bit longer until the features that seems more promising are being discussed and then think together where something like this tokenization can be implemented in terms of priority.
As to the developers, there aren’t enough and we are definitely missing more manpower.
Few people are working on getting more developers, it’s always a process that takes time but I know there’s some progress lately.
Of course, there are many things that different community members are discussing that are in the initial assessment phase and once they pass that, I imagine some will be posted here.
For example, a feature for DAOs/projects that can bring significant revenue to the protocol and help reduce the deficit.
It can be something like a more advanced liquidity pool for projects.
