After having dealt with the claims process ourselves, our team at Ease has some feedback on how it could be improved for the end user.
Summary of Events:
We recently submitted a claim regarding loss from an Ease product. We wrote up a thorough summary of what occurred, announced it publicly, calculated exactly what the cost would be to reimburse users, and submitted our Nexus claim.
Hugh was initially the only one to respond and he mentioned his views on the situation. We responded to his views to facilitate open discussion on our claim, and then discussion was silent, with 100% of the vote currently in favor of approval.
On Friday, March 24th 6:33 PM UTC, an anonymous individual funded a wallet through Binance with wNXM and immediately staked 10,000 against claim ID v2#9, for Ease protocol cover. (Source). Why we find this concerning:
- They chose to vote at the end of the work week at the very end of the initial voting period.
- This user provided no contributions into the discussion of this claim. It’s surprising for a large holder, who has never voted on a claim before, to vote ‘no’ on a relatively minor claim, with a very large stake and without any stated reasoning behind it.
Improving Claims Assessment
After this experience from the claimant side, we believe there are some improvements to be made for the sake of transparency. Here are our current thoughts
- Require reasoning on assessment vote:
Claims discussion is an important step in the assessment process. There is a large burden on the policyholder to provide evidence to support their claim submission. There should be a similar burden on the assessor to provide reasoning when they vote on a claim. Require all assessors to provide reasoning behind their approval or denial when submitting an on-chain vote. Assessors including direct references to policy wording in their reason would be strongly encouraged.
This would accomplish a few things. First, it would allow a claimant to either, be able to give a counter argument, or shore up any record keeping issues for their 2nd claim submission. Second, it would also allow assessors to acknowledge when they utilize discretion for a claim that might not be 100% valid according to the policy wording. And third, it could make it easier for the advisory board to identify fraudulent votes if a voter inputs clear dummy information.
- Limit of voting power:
This one is pretty straightforward. No one user should have too much influence on the process. There still should be some level of prevention so the assessment process requires multiple users to vote. One idea would be to require X times the USD value of the claim in votes on the policy for it to pass. And then, users can only vote an amount equal to Y, which is a fraction of the total required vote.
One example: A policy claim for $100K requires $400k of NXM in total votes, but no one can vote more than $100k of NXM.
- Clearer UI for Assessment Votes:
Showing values of Yay/Nay votes rather than percentages for increased transparency. Also a UI that shows voting history, what address voted when, how much, link to txn hash, etc.
A timer showing the cool down period countdown after voting ends would be nice too, in addition to detailed statuses (approved/denied; claimed, with tx id).
- Separate Assessor and Underwriter wallets
For the sake of reducing conflict of interest it would be a good step to have any wallet that is underwriting unable to stake on a vote for claims assessment and vice-versa.
For example, if a user has 100k NXM total, and underwrites with 50k of it, and then uses the remaining 50k NXM to stake for voting, a clear conflict of interest is created.
Improving Policy Wording
- A transparent list of what code is covered by protocol cover:
A source of division among us and assessors was whether arNXM was covered by an Ease claim, as arNXM was originally an armor brand. However, we rebranded all Armor products under Ease branding 27 days before Ease was even listed as a covered protocol. So our belief was it fell under the definition of Designated protocol (see below). It might be best for claims moving forward if there is less ambiguous wording about what code falls under the scope of a protocol’s cover policies.
- Stricter Definition for “loss of funds”:
Another division was whether the loss of wNXM backing value for our claim constituted loss of funds. We believed it did, as a user withdrawing wNXM had an irrecoverable loss of .024 wNXM for each arNXM withdrawn post-exploit. But the argument against it was “no value was taken from the protocol due to an excess mint of tokens”. The below wording should be amended in some way if reduction of backing value isn’t supposed to fall under policy wording.
These were some of the thoughts our team had after dealing with the claims process ourselves. We would love to hear feedback, as I’m sure Nexus best knows what is possible to be realistically implemented into the system.