Umbrella Terms and Conditions - Questions and Concerns
I have been working through calibrating the terms and conditions, which include arbitration criteria, and there are some issues that need to be resolved. In the quotes below I am paraphrasing the original statements from @trente and adding in the information discussed in the rest of the thread. It is a long one, so grab your favorite beverage and dive in with me.
Arb vs. Exploit - Code is Law?:
Where is the line for an exploit (unintended code functionality that was not expected by the developers or users) vs. intended code functionality that was not fully appreciated by users?
What’s an arb vs. an exploit? A good example is Compound’s recent DAI liquidations as a result of single-source Coinbase oracle. It was always known that Coinbase is the single oracle, and this was a somewhat known attack vector – is it an exploit?
When you get car insurance or home insurance, it’s because you know you might get in a wreck or have a home fire, but it is not expected or intended behavior.
In general, Yam’s guiding principle should be related to loss of funds related to unexpected or unintended behavior.
This seems to be generally agreed upon for a starting philosophy of how we handle arbitrations. Starting off with the low hanging fruit.
If the affected protocol is NOT the manipulated protocol, (ie. all the Curve flashloan exploits) which does Umbrella protect?
Umbrella is most concerned with loss of funds. In most of the Curve cases, Curve LPs actually profited. Umbrella will arbitrate claims according to loss of funds – if a composability exploit results in loss of funds for more than one protocol, each would be valid for a payout.
Open Question: Do we need to distinguish between exploits in the code vs social attacks? What about rug pulls?
In the event of a rug pull, the people in the pool clearly have lost money, but the protocol has functioned exactly as intended. Someone who owned tokens in the AMM pool lost money because they deposited into the AMM pool, even if the AMM pool itself was not exploited. The “exploit” happened elsewhere and took advantage of the mechanism of the AMM to function. If covering a protocol like Uniswap, the terms and conditions would need to explicitly exclude rug pulls, or exclude non-code related exploits entirely.
But have we now invalidated our answer to question 1, where we want to cover losses that occur due to unexpected behavior. Should the users of an unsafe project have expected a Rug pull?
Can this be avoided by making it very clear as to what the “correct and intended” function of a protocol is in our terms and conditions? In the example above, Uniswap functioned exactly as intended, so there would be no payout.
But, is there an edge case where someone comes up with a new exploit and takes advantage of the way Uniswap is supposed to work to drain funds or extract value? Do we pay out for that?
There is clear grey area here about what “functioning correctly” means that the DAO (or other arbiter) will have to deliberate about explicitly and in an educated way to make a fair decision in a claim event. Setting a precedent one way could impact the perceived trustworthiness of the protocol for the foreseeable future.
Severity of Exploit:
Sushi recently experienced an exploit totaling approximately $15k in lost rewards prior to the exploit being discovered and stopped. Cover did not consider this a valid claim. What is Yam’s
threshold for a valid exploit that deserves a payout?
Partial Payouts will be calculated as
funds lost in exploit / TVL in exploited contract or protocol. So an exploit that loses $100k from a contract that held $1M of funds will result in a payout of 10% of the purchased coverage.
How do we allow users to buy protect for specific pools within products while still allowing protection providers to cover many products and deal with changes to the products that are covered.
Diving into this question requires a bit of background on how Umbrella works at a high level:
In Umbrella as it is designed, there is no way to ascertain actual loss suffered by any specific protection buyer in an exploit. The contract pays out based on whether certain criteria (an exploit) happened and the protocol does not care if the person who is paid actually lost funds, as long as someone did. The person who is paid is just the person who bought protection. So it functions more like a prediction market with the DAO as an oracle than it does a normal insurance market.
Concepts are the name for what the Umbrella Smart Contract will store as a specific product/protocol/pool/etc. to be covered. They can be settled individually and are the individual “pools” that protection seekers buy. A concept is just something that a protection seeker can buy protection on and the arbiter will need to make a decision upon if there is an exploit. It can have any level of specificity we desire.
Broad or Narrow Concepts?
Up until now we have talked about defining concepts pretty broadly (i.e. uniswap, or ledger hardware wallets). This allows a lot of flexibility because the defining your concept broadly allows it to change without needing to re-make the contract. If I am providing protection for “Uniswap” then it doesnt matter if new pools are added or created because they still fall under the concept.
But there is a tradeoff here for protection buyers. It does not seem possible to allow users to buy protection for specific parts of a protocol that they use and also provide this broad flexibility. let me use an example with a concept that covers all Yearn vaults.
Let’s say we create a metapool with a concept that covers Yearn as a whole and the DAI vault is exploited for 10% of its TVL. As of this writing, the DAI vault has a TVL of 500M while Yearn has a TVL of 2.6B as a whole. That means that the DAI vault TVL is ~20% of the total TVL. If I had funds in the DAI vault, I would expect to be paid out 20% of my protection purchased to be made whole. But this could only work if I bought coverage for the DAI vault specifically. If the coverage that I bought is for Yearn as a whole, then anyone who bought that same protection on Yearn should get a payout that is equal to the $-value lost in the exploit compared to the total Yearn TVL (10% * 20% = 2%). Anyone who bought protection for Yearn (even if they bought protection for another Vault that was not affected) would receive the same payout as me (2%). If I bought protection thinking that I would be fully protected in the event of an exploit of the DAI vault, then got screwed since I lost 20% of my “protected” funds and only got paid out 2%.
This breaks the social contract of “protection” and turns Umbrella back into a betting market on whether a protocol will get hacked. If anything, this would be more like insurance for token holders who may now lose money through token depreciation due to a hack. Interesting, but not what we have been discussing as the function for Umbrella.
A Potential Fix
To make this work as I believe we intend it to, and to correctly calibrate the magnitudes and payouts of exploits, we would would need to build our concepts so that they are granular to a level in which protection buyers can specify which products they want to cover. If this granularity is developed to a level where pools are not divisible into smaller ones, The arbiter will be able to accurately determine who to pay out and buyers can be confident in getting an accurate payout based on what they bought.
Again Let’s take Yearn as an example. A metapool could cover all of the Yearn Vaults and individual protection buyers would buy individual vault protection (the concepts). So you would have concepts for the “DAI vault” and the “3CRV Vault” and so on. Now we have a clear way to fairly determine a payout for someone who bought coverage on a vault that was hacked. The TVL is not further divisible and only those who own this concept can claim in an exploit.
This seems like a good solution, but there are trade-off here as well. This idea works as long as the number of concepts that can be purchased remains mostly consistent over time, or if the concepts can be updated. If concepts are something that are explicitly defined in the creation of the smart contract (as it currently works), then the only way to add or remove concepts would be to create a new metapool and migrate to that contract. This is not something that is possible in an automatic way with the current contract. It could be done manually by the pool participants, but this has a number of issues and open questions:
- Protection providers are limited in how much they can withdraw from the contract. This is determined by the utilization rate. So they could not all migrate in a coordinated way without protection buyers also migrating.
- Protection buyers have purchased protection at a specific rate on the utilization curve. Migrating to a new contract would mean that they will probably pay a new rate. This could be better or worse for the buyer, but either way it does not make the transition simple.
- Ideally, you would promise lower rates on the new contract by moving funds there, but this is difficult or impossible if your funds are locked up in the existing contract. Without funds in the new contract, existing buyers may choose not to migrate, or there may not be enough liquidity.
- Incentives or a dedicated pool of liquidity to facilitate migrations could help this problem.
- A migration tool/event that would queue existing buyers and providers into the new pool would be an interesting, but potentially very complicated solution.
This will define how Umbrella works
If we want Umbrella to be “protection” for users who want to safeguard their funds deposited in a DeFi protocol then we will need to cover the specific pools of funds that could get hacked. This is possible but without upgradability of the contracts this may be hard to adjust as projects add features or pools.
Our other option is to accept the current limitations with broad concepts and be clear that Umbrella functions as a high level bet for or against a specific protocol or product being exploited, and not always as specific protection for funds that you may deposit in that protocol.
How we do this will impact who will want to use our product, how we market it, and how the user flow and website interfaces work. I am curious to hear others’ thoughts on these issues and whether there is an optimal path forward.