Well I have laid out my view of using three buckets of insurance/reinsurance. Namely a liquidity pool of DAI, self-insure using strategic reserves in BTC, and reinsure using Nexus Mutual cover. I think B. Protocol can take the place of a liquidity pool. If I had to make a decision on either of the next two taking priority I would say building a strategic reserve is of paramount importance. Without a rainy day fund Maker is playing a dangerous game. If the above has been implemented then I would say at that point we can move towards a bespoke insurance policy from Nexus Mutual.
Interesting…mechanically speaking, are you saying we would buy insurance on the buffer itself? I still haven’t thought of a good way that we can structure this with Nexus.
@g_dip I presume it’s relatively easy to measure any protocol losses that occur that would reduce the buffer, if so we can use that as the trigger instead. eg if losses > $xm within a month then trigger a claim payout.
You can also get more complicated if required, eg by linking the claim payout to some combination of strategic reserves and losses incurred. This would allow you to calibrate to the right level of self insurance vs reinsurance.
@ejbarraza your structure makes sense to me. One point, cover with Nexus is probably more valuable to Maker when you haven’t built up any strategic reserves yet, as this is when you are more exposed. It may make sense to implement cover first and then build up strategic reserves rather than the other way around.
@Hugh_Karp The reason I suggest building a strategic reserve first is that having the funds in place means Maker DAO can move quickly to stabilize the system if necessary. If we opt for buying Nexus cover without first having reserves, then we are at the mercy of the claims payout timeline. I presume that it will not be immediate which in DeFi can lead to catastrophic losses (e.g. Black Thursday). How long do you think it would take from a legitimate claim being filed to the point of Maker DAO being compensated?
@ejbarraza Claim payout will most likely be finalised with 2-3 days, at most 1 week. I believe this fits within the current flop auction time window (but I’m not 100% on that). This would be a technical detail to pick up in the working group. The goal would be to get the claim payment in before the auctions start.
re reserves, my only point was you still have to build reserves up whether you have Nexus cover or not, and building them up will take time. Nexus cover can help bridge that gap.
So this feedback is coming a little late, but I wanted to make a suggestion.
With some of the recent Declarations of Intent we’ve found that having the contents be highly specific has caused frustration on all sides when it comes to implementation. Generally, with something like this the domain teams may want to provide feedback and analysis regarding the numbers and mechanics involved.
Given their current workload the domain teams aren’t going to have time to look at something until it’s passed a governance vote. However, it is possible that they will feel obligated to recommend changes to the proposed numbers / mechanics after the Declaration of Intent vote takes place. This can cause problems if governance or the author of the subproposal thought they were voting for specific numbers / mechanisms that were already set in stone.
I think this process will move more smoothly if the Declaration is more general. This also helps capture support from those that agree in principle, but disagree with the specifics. I would maybe clarify in the wording that the pricing and / or tranches is a starting point, and is subject to change pending recommendations from the working group and / or relevant domain teams.
I’d also like to clarify that the domain teams aren’t obligated to work on implementation or analysis of this declaration if it does pass through governance.
This MIP has now been categorised as a Formal Submission.
This MIP did not pass the January Governance cycle, it failed at the Inclusion Poll stage.