Open Discussion: Umbrella Arbitration Criteria

Umbrella Arbitration Criteria:

When considering our role as arbiters within the Umbrella system, we must carefully lay out how we plan to determine the validity of an exploit. The two main protection providers today (Cover and Nexus) take highly divergent paths. Cover has no publicly stated criteria and the community is free to vote as they please, before it goes to a council of auditors that make a final ruling. Nexus, on the other hand, requires proof of loss when submitting a claim, as well as requiring the hack to specifically occur in the covered protocol (ie. Harvest exploit resulting from Curve manipulation would not be covered for Harvest protection seekers).

There are multiple angles to consider here:

  • Arb vs. Exploit - Code is Law?: Where is the line for an exploit 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?

    • Proposed Policy: 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.
  • Composability vector: Affected protocol is NOT the manipulated protocol (ie. all the Curve flashloan exploits) - Which does Umbrella protect?

    • Proposed Policy: 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.
  • Severity of Exploit: Sushi recently experienced an exploit totalling 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? This is likely the most difficult decision to make.

    • Proposed Policy: Perhaps there is a threshold that exists as a ratio of (exploit lost funds) / (total coverage purchased) such that if the amount lost to exploit is less than say 50% of coverage purchased, a payout does not occur.

This is an open discussion, and there may be additional considerations to account for and different solutions.

5 Likes

Arb vs Exploit: Your line of reasoning works well. The “unexpected” or “unintended behavior” is a good principle.

Everything that’s known is the underwriter’s risk exposure. For instance: If someone provides coverage for something that says “…protocol functions with a single oracle (namely Uniswap)” then this is a known fact and attack vector. Assessing the likelihood of such exploit is up to the underwriter.

Composability: In general, this sounds good. I cannot remember the details of the Harvest exploit.

Is there a limit to composabilty? Insofar as layers of composability would encourage moral hazard by the protection buyer.

Severity: Normally it’s the other way around. Small claims are easily disbursed, big ones are challenged. Small claims might be relevant to smaller investors who are reliant on the insurance. Also, “paying out” is the core function of an insurance. A track record of payouts should instill confidence by insurance buyers in Umbrella.

I’d argue it’s the other way around: There’s a threshold above which arbitration becomes relevant. Below that, it’s a less critical arbitration discussion.

Also, what’s the likelihood of small exploits happening? Most hackers don’t take the risk for $20k. Smaller damages might be more genuine bugs vs the really big ones.

There’s also the possibility that a policy only kicks in above a certain threshold. That would also work with what we have seen in DeFi: <$100k exploits/bugs get reimbursed by the protocol (eg Hegic afaik). It’s the big damages they want to insure against.

3 Likes

我认为应该对购买保险者有一些操作规范或是法律层面的约束,其他标准就好办了

Hey great thoughts @trente + @nonstopTheo

Arb vs Exploit

Ya “unexpected” or “unintended behavior” is a great principle.

We can use the parameters set by the MetaPool Designers to help decide what falls under “unexpected” / “unintended.”

(One MetaPool Designer, for example, may clearly state liquidations related to single-source oracles are not “unexpected” and therefore not an exploit.)

Composability

100% def, I like the mindset here a lot trent. Would want to see composability and rule where loss of funds occurred.

Severity of Exploit

I agree with Theo - we want to payout, it instills confidence in Umbrella. I support a percentage payout (if it falls under the ratio of (explot lost funds)/(total coverage purchased) vs all or nothing.

awesome thoughts! thanks for kickin this conversation off trent

1 Like

Due to the lack of understanding in the insurance domain, some general thoughts:

  • Would it be possible to create some kind of market research about the most epic defi fails that fit into the categories described by @trente above? I’m think about some kind of one-pagers/summary per fail to explain it to a six year old :stuck_out_tongue_winking_eye:
  • Next step would be to assign/map these incidents to the relevant categories
  • One option would to start with a phased approach and to beging to provide coverage for incidents with the most simple criteria to determine the validity of the exploit. This approach does only makes sense if there is an overlap between strong market demand and easy to settle claims/incidents.
  • If we would think of an auditor council, would make sense to try to engage relevant white hat hackers for participating in the council?

One last thing, how do we mitigate this risk:

  1. Create a backdoor which looks like an accidental exploit
  2. Utilize the backdoor to hack the protocol
  3. Settle the insurance claim on top of exploiting the protocol.
  4. Sometime even the funds are returned after hacks, but the token price is -90%. Would the see the token price <90% as a loos that is covered by an insurance?
2 Likes

We can certainly create a list of DeFi hacks and examples of how YAM would vote based on the criteria we develop. Ultimately people are going to be able to vote however they want, however, and we need to be cautious of that.

Regarding a phased approach to what we cover, it’s not a bad idea but I do think we need to cover most known exploits and anything that is just a straight up logic bug (like Cover).

Auditor council is interesting. I could also see teaming up with Kleros. Could make the arbiter a 2/3 multisig: Yam, Kleros, Council, to grant a payout, though that’s a lot of overhead.

No real way around insurance on top of being the exploiter at this point :confused:

1 Like

Regarding Severity:

I’ve asked Brock to create the ability for partial payouts. The best way to calculate this imo would be to pay out a percentage (funds lost) / (TVL in contract or protocol). I think this is a huge improvement for protection providers, as a 100k hack on 1M of protection purchased will no longer result in a 1M payout. The other way to do it would be (funds lost) / (protection purchased).

How we perform this calculation can also be a discussion, from a code perspective all that’s implemented is the ability to payout a percentage of coverage. It can also depend on what’s being protected (specific contract vs. entire protocol).

3 Likes

Collaborating with Kleros as Arbiters is an idea I’m interested in. I feel like it could help bring a lot of trust and confidence to Umbrella.

I can imagine some scenarios where it would be beneficial to bring an organization like Kleros on board:

  • When a claim is denied, we could have an appeals process that’s sent to Kleros for a second opinion.

  • If the Yam community can’t come to a consensus, or fails to reach quorum on a vote.

  • If there’s a conflict of interest, like let’s say Yam Treasury is the main Protection Provider.

2 Likes

In addition, will there some kind of formal / technical prerequisites to get accepted for protection or to determine the insurance rates?

Insurance rate = There more of these prerequisites are met, the lesser risk and payment to insurance(Simpilfied)

For example:

  • Minimum one / multiple audit reports
  • Non anon team
  • Pen testing by additional hired security experts
  • Mandatory bug bounty program
  • Development infrastructure:
    • CI/CD pipeline
    • Automated code quality checks
    • AI checks to finds bugs
    • Frequent review of GitHub project quality metrics
  • If applicable: Review of DAO setup and governance processes (Multisig / Onchain votes)