arbitration for audit vaults

[jellegerbrandy]

motivation: at the payout moment, projects have strong incentives to pay out as little as possible. We introduce an "audit arbitrator" - this will typically be a trusted third party, perhaps a connected audit firm - that has the possibility to overrule the committee's decision. In any case, the decision will be ratified by hats governance just as before

process - high level

1. committee creates claim
2. hacker is not happy and disputes the claim by contacting the arbitrator
3. the arbitrator creates a new claim
4. hats governance ratifies the new claim (or dismisses it)

process - details and implementation

Q the dispute can either start from an informal process (i.e. committe creates the payout, hacker contacts arbitrator, arbitrator stops the process) or more formal (i..e hacker creates the dispute and pays a deposit to cover the costs of the arbitration (he will get back if he wins). We work out the formal process here but we can also do a simplified version.

We will create a new AuditArbitrator contract, which has the following state variables:

• address public immutable vault (i.e. the AuditArbitrator contract has ajn immutable reference to the vault set on initialization)
• address public immutable arbitrator
• address public immutable hatsGovernance

1. hacker is not happy and calls auditarbitrator.dispute(claimId, ipfsdata)

   • hacker is required to put down a deposit (e.g. 50 usdc)
   • calls vault.challengeClaim(claimId), the vault now remains locked until the arbitratror releases it
   • the hacker can only dispute during the challengeperiod

2. auditarbitrator.arbitrator() contacts the hacker(s) (with the info from ipfsdata), does it's due diligence, etc, and will call either (2a) auditarbitrator.dismissDispute() (to signal that none of the received disputes are considered right)
   (2b)auditarbitrator.resolveDispute(newBeneficiary, newBountyPercentage) (to propose a new payout based on the dispute(s) received)

   • (2a) on dismissDispute, the disputer(s) loses their deposit
   • (2b) on resolveDispute, (all) disputers get their deposit back. The auditarbitrator gets a fee paid from the vault. We could also formalize this fee structure, but in practice the newBeneficiary will be a distribution contract, ad the arbitrator con include it's own addrss as part of the distribution

3. auditarbitrator.hatsGovernance() can now either call:

   • dismissClaim which will dismiss all claims and reset the vault to the origianl (pre-claim) state
   • approveClaim() which will approve the claim put forward by the arbitrator (i.e. if the arbitrator dismissed the dispute, it will approve the original claim made by the committee, if the arbitrator resolved the dispute, it will approve the arbitrators new claim.

[shayzluf]

i.e. if the arbitrator dismissed the dispute seems like hard to handle multiple disputes

[shayzluf]

separate arbitrator contract for each vault?

[shayzluf]

init params of create vault should include the arbitrator contract and its init params

[shayzluf]

the arbitrator creates a new claim so the arbitrator has a committee privileges to create claims?
can we set this arbitrator to have claim creation rights as well?

[jellegerbrandy]

i.e. if the arbitrator dismissed the dispute seems like hard to handle multiple disputes

i updated the text and added some plurals, the procedure remains the same.

separate arbitrator contract for each vault?

yes. A clone of course.

init params of create vault should include the arbitrator contract and its init params

we can have a createVaultWithArbitrator function perhaps

the arbitrator creates a new claim so the arbitrator has a committee privileges to create claims?

i meant this as a short way to say "the arbitrator chooses a new bountypercentage and beneficiary"

can we set this arbitrator to have claim creation rights as well?

So only the address at vault.committee can create claims. But we can of course have our own contract as the committee, which would forward calls from either the real committee or from our arbitrator. I'd consider this a separate (small) project, though

[ben-kaufman]

the vault is now locked until the arbitratror releases it

Not sure what does that mean? The vault is "locked" during the entire time there's an open claim.

Also, which token should the deposit be (always ETH? ERC20 settable on init?) and how much should it be for

[jellegerbrandy]

the vault is now locked until the arbitratror releases it

Not sure what does that mean? The vault is "locked" during the entire time there's an open claim.

what i meant is the arbitrator is now responsible for releasing the lock
i changed to the vault remains locked until the arbitratror releases it

Also, which token should the deposit be (always ETH? ERC20 settable on init?) and how much should it be for

shay was thinking usdc, oli was dreaming about it being hats. Let's make it an erc20 settable on init, consider making it changeable

[jellegerbrandy]

1. What should be the token (ERC20 or ETH?) and how much should be deposited to dispute the claim?

erc20 - think of 50 usdc but it should be changeable

2. Should the vault's challenge claim be called only once the governance calls the dismiss/approve or once the arbitator calls resolveDispute, or already when someone calls dispute?

arbitrator.dispute() calls vault.challengeClaim(claimId)

3. Should approveClaim be callable by governance even without any dispute being made or resolved?

this is all handled by the HATVault contract (or i misunderstand your question? :)

4. I think there should be a method to refund disrupters in case their dispute was found valid but maybe it was too late for example or so to refund them when resolving. Should this refund be callable by the arbitrator or hats governance (or both)?

well it cannot be too late, the idea is that the arbitrator is in control once the dispute is started, and the vault reamin locked until the arbitrator decides on a new distribution..

what is still missing form the spec is how the refunds (there could be several claims) will happen, though, i am not sure what the most straightforward wau to handle that is

[ben-kaufman]

what i meant is the arbitrator is now responsible for releasing the lock
i changed to the vault remains locked until the arbitratror releases it

I don't think this is possible with our current structure, nor do we want that because we don't want the vault to be locked forever if the arbitrator doesn't respond.

erc20 - think of 50 usdc but it should be changeable

Changeable means settable on init for each project or really allow changing the bond size with some setBondValue function?

this is all handled by the HATVault contract (or i misunderstand your question? :)

Now the arbitrator contract only can call the approveClaim and dismissClaim before the expiration time. Should that be possible to do by the governance at any time, or only if a dispute was resolved?

well it cannot be too late, the idea is that the arbitrator is in control once the dispute is started, and the vault reamin locked until the arbitrator decides on a new distribution..

We can't just lock the vault potentially forever though, that's too dangerous

[ben-kaufman]

what is still missing form the spec is how the refunds (there could be several claims) will happen, though, i am not sure what the most straightforward wau to handle that is

What I was thinking is to let the arbitrator, when calling resolveClaim (or with a separate refundDisputers function when needed) pass an array of disputers and just mark each as claimable for refund, then the disputers can call claimRefund to claim their deposits

[ben-kaufman]

Also, should the arbitrator be allowed to make a resolution without a dispute being submitted in the contract?

[jellegerbrandy]

1. We can't just lock the vault potentially forever though, that's too dangerous

We are not. HATVault has logic that allows anyone to dismiss the claim after a timeout, https://github.com/hats-finance/hats-contracts/blob/develop/contracts/HATVault.sol#L353

2. Should the arbitrator be allowed to make a resolution without a dispute being submitted in the contract?

I see no reason to introduce this. If nobody disputes, there is no problem. If the arbitrator wants to make a resolution by itself, it can alsows first create a dispute and then resolve it.

[ben-kaufman]

We are not. HATVault has logic that allows anyone to dismiss the claim after a timeout, https://github.com/hats-finance/hats-contracts/blob/develop/contracts/HATVault.sol#L353

Yes, that was my point, it's not going to be locked until arbitrator releases it necessarily, so if the arbitrator is not responding fast enough, there might be valid disputes that should be refunded but was not reviewed on time, and the arbitrator might want to refund it after the claim was already resolved.

[ben-kaufman]

I see no reason to introduce this. If nobody disputes, there is no problem. If the arbitrator wants to make a resolution by itself, it can alsows first create a dispute and then resolve it.

Ok, and should the hats governance be able to dismiss or approve the claim before the arbitrator suggest a resolution? Or before the challenge period ends? Or only once the arbitrator suggests a resolution/ dismisses all disputes on the claim?