Write an Extension of ERC792 to Allow Paying Arbitration Fees in ERC20 Tokens

[clesaege]

See ethereum/EIPs#792

[dburghelea]

Hi @clesaege

I’m a fan of Kleros myself and I think opening the system for token payments would be, in the long run, useful for all parties involved.

As more and more Dapps and ecosystems come out, some of them may need to use a proprietary token while also desiring to have Kleros as their justice layer. As Galia Benartzi from Bancor usually points out in her speeches, supporting local economies and the long tail of currencies that are going to come out is critical.

Forcing these Dapps & ecosystems to use ETH when all of their interactions are done without (except for gas) would results in a significant portion of them having to go with other solutions or implement a very bad UX, considering they may want to treat the opening and outcome of a dispute differently inside of their ecosystem (e.g., burning some tokens in certain scenarios), which would not be possible with ETH.

As I said, I’m excited about the work you guys are doing at Kleros and thought of a few quick ideas; you may already have better ones in mind.

1. Liquidity Layer — Adding one or multiple liquidity providers (like Bancor, Kyber, 0x or AirSwap) between the jurors and the requesters. This would be implemented directly into Kleros as a proprietary layer. Two reasons for this would be 1. The smoothness in how an external Dapp would be able to implement Kleros, due to the presence of a clear standard and 2. the need for controlling when the swap from token to ETH happens. If both parties pay the fee, in the end, only one deposit would have to be swapped to ETH, while the other one would be returned back ‘as is’.

2. Opt-In — Jurors manually opting-in and choosing which tokens they want to receive. As more Dapps come out, new users won’t want to lose time and select each token they want to be paid in (may be 10-20-30) from the list and current users may even forget to add new ones as they appear. In short, this would be bad UX. The first example is encountered today in many apps like Medium, where creating an account leads you to questions of what domains you like etc. Most users tend to skip it altogether.

3. Opt Out — By default, a new user gets paid in every available token, being free to opt out at any time from receiving a particular token.

Not knowing the exact limitations or other solutions others may have thought of, I believe a liquidity layer + opt out would be the best solution. If a user opts out of a token, he can still get paid from being a juror in the disputes opened by all Dapps. In the background, the “opt out” tokens are converted either to another token the user can receive or ETH, depending on the best rate. This would also allow for a staged implementation.

[clesaege]

Hi @dburghelea ,
Yes, we are considering both the liquidity and opt-in system.

• For the liquidity, we would use some exchange protocol like 0x or a bonded curve.
• For the opt-in, we could have subcourts with arbitration fee labelled in specific tokens.
  Opt-out seems less interesting as jurors don't want to have to deal with a high amount of different tokens.