Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
ERC 792: Arbitration Standard #792
The following describes a standard of
Using two contracts allows separation between the ruling and its enforcement. This abstraction allows
This contract enforces decisions given by the
To be called by the
function rule(uint _disputeID, uint _ruling)
Must trigger when a final ruling is given.
event Ruling(Arbitrator indexed _arbitrator, uint indexed _disputeID, uint _ruling)
This contract makes rulings. It must call the
NOTE: The variable
Returns the cost of arbitration
function arbitrationCost(bytes _extraData) view returns(uint fee)
Returns the cost of appeal
function appealCost(uint _disputeID, bytes _extraData) view returns(uint fee)
Create a dispute.
function createDispute(uint _choices, bytes _extraData) payable returns(uint disputeID)
Appeal the dispute
function appeal(uint _disputeID, bytes _extraData) payable
Return the [
function appealPeriod(uint _disputeID) public view returns(uint start, uint end)
function currentRuling(uint _disputeID) view returns (uint ruling)
function disputeStatus(uint _disputeID) view returns (DisputeStatus status)
NOTE: The value
Must trigger when a dispute is created.
event DisputeCreation(uint indexed _disputeID, Arbitrable indexed _arbitrable)
Must trigger when the current ruling is appealed.
event AppealDecision(uint indexed _disputeID, Arbitrable indexed _arbitrable)
Must trigger when appealing a dispute becomes possible.
event AppealPossible(uint indexed _disputeID, Arbitrable indexed _arbitrable);
Example implementations are available at
Presentation on how to make your own implementation:
Good work, I really like the look of this. I am very interested in this standard as I am also currently developing platform functionality for arbitration of contracts : https://github.com/TiiQu-Network/TiiQu-Network/wiki/White-Paper#crowd-sourced-arbitrage
referenced this issue
Dec 12, 2017
This was referenced
Dec 19, 2017
I was wondering that the
I really don't like the _extra_data bytes argument. Languages are typed to make code easier to analyze, and this feature forces developers to obscure type information. This could make bugs harder to catch. One way to fix this would be to remove _extra_data and force Arbitrator contracts to store relevant custom data using the disputeID, and to have their own functions for providing details about each stage of dispute resolution.
If you let
You can see that other standards took the same approach, for example ERC777: #777 .
referenced this issue
Mar 2, 2018
Wanted to add some more concrete thoughts on this EIP after our call @clesaege
In addition to the
In addition to this, I want to formally advocate for a settlements process that is on-chain, allowing people to settle disputes for a lower amount without having to pay arbiter fees. However, I would be open to settlement functionality not being included in the standard since I understand you (Kleros) don't include that functionality in your mechanism as of right now.
I also want to formally share my opinion that I believe it is premature for us to create an ERC for this when we have minimal evidence of the validity of our assumptions. Standards historically have evolved out of market successes (or based on user data about previous versions of a product), however the lack of decentralized dispute resolution mechanism in the market precludes us from making any assertions about what should be in the standard without including some of our own assumptions. I believe we should align on what a general standard for this would look like, and begin employing it, well before we pursue a finalization of this EIP (similarly to how ERC20 was used well before it was finalized).
The standard is not about functionalities, it's about interoperability. The
With the exception of the centralized arbitrators and Delphi proposals, all dispute resolution proposal I'm aware of (Kleros, Juris, Jury.Online, Aragon, TiiQu) includes an appeal system. If a contract does not allow appeals, it just has to return a high value to forbid it. But when the overwhelming majority of dispute resolution systems off-chain (state court system, ADR which even when they don't include an intra-ADR appeal system, can then be "appealed" by state courts), and on-chain proposals. It seems that the appeal system must belong to the standard.
Yes, for cases where an
An on-chain settlement process is not included in the standard as this standard is about standardization of interactions between
When speaking with projects needing dispute resolution, the contrary opinion has emerged. There a lot of teams building products which need dispute resolution and a handful of teams working on it. The projects which need dispute resolution generally don't want to have to integrate with each dispute resolution provider, especially knowing that those projects are early stage (the whole industry is) and most of them will have failed within a few years. Integration with a standard, instead of a particular project, allows them to let their users choose their dispute resolution system instead of locking them on a particular one.
In my opinion this would be best, similar to how there was a
Correct, but this information is entirely useless unless it is being returned to another contract for storage since it's impossible for the returned value to be passed to the sender of the original transaction (if the claim is opened by a user). This information should be emitted in an event. I would also like for the claim amount and fee information to be passed as parameters to this function as well (remember when I asked about what happens if a fee is greater than the
Could you please explain this to me? If a contract is arbitrable, it means it is a contract requiring arbitration, i.e. requiring the opening of claims against it. For our staking mechanism, these arbitrable contracts are the stakes which can have claims opened against them.
This viewpoint is admirable, and I am largely behind it, however I worry that trying to formalize this standard too early as an officially accepted EIP (instead of it simply serving as a reference for dispute resolution providers and recipients), we'll be screwing ourselves over in the future by requiring new standards to be backwards compatible. Having competitors and collaborators come together on a standard is an important part of the Ethereum developer community, however it requires a light touch, where developers are open to having their ideas questioned and overturned when the market (their users) provides them feedback that their assumptions are wrong.
In terms of including the appeals process in the standard as an extra function (which may revert for implementations without appeals), I believe this is a fine solution for the short term as we test out our implementations and figure out where they break.
It is non-trivial for all disputes to be implemented using the same contract standard, with there generally being various approaches to the dispute resolution problem which don't necessarily mirror the adjudication methods we see in the real world right now. In an effort to encourage this exploration of new and unique methods, we should try to be fluid in our development of this standard, and open to seeing it challenged and amended as we discover what works in practise.
This information is always being returned to another contract. It is returned to the
External accounts don't create dispute.
This is the case per
This is a general dispute resolution standard, claims not need to be monetary. A claim can for example be about blacklisting something (malicious ENS address, irrelevant item, spam) (see this contract for example https://github.com/kleros/kleros-interaction/blob/master/contracts/standard/permission/ArbitrableBlacklist.sol ). Thus the claimed amount cannot be part of the standard.
This standard is only about interaction between
That's why this ERC has been put in the issue section before making a pull request per the EIP Work Flow described by EIP1 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md :
The possibility off appeals cannot break anything. If you don't need it, don't allow appeals. At worse you lost 0.01$ when deploying your contract (only once if using a library). At best you avoided duplicating your
When there is no interaction between dapps (for example in the case of Augur where they both deal with dispute resolution and enforcement), there is no need to follow a standard.
For sure, but in the other way around (not preventing usages but allowing some). If someone were to show a dispute resolution method which could not fit in the standard, I would support modifying it (as long as it would only incurs limited extra gas cost and code complexity) in order to allow this new dispute resolution method.
It seems we have again found another strong difference in opinion.
For Delphi, claims are opened by people, against particular stakes. Claims ARE for monetary amounts (units of tokens, for what else could be administered on-chain otherwise?) Are you proposing that certain byte code would execute based on these claims? Is that what you intend to store in the bytes array, and not a content hash?
My desire here isn't to simply "remove appeals". We are approaching arbitration in very different manners and assuming that either approach is right from the outset is incorrect. I will apologize that I've had a bit of trouble understanding this architecture you've designed (the flow of actions between the arbitrable contract and the arbitrator contract).
Here is a list of reasons why this standard doesn't currently conform to the dispute resolution mechanism we've outlined with our arbitration mechanism:
Like I said above, there are many differences in our designs, and that should be encouraged, in order to test the assumptions underlying each of them. Trying to create one standard for all possible usecases of arbitration will be very difficult, owing to the variety of instances in life where arbitration is currently used (and the many new ones which are being ideated such as the blacklisting of accounts, or other new on-chain actions).
Items in lists, Oracle answers, Cryptokitties...
I'm proposing a system which allows the
No, the bytes contains specific information for the
That is not the case. I'm approaching arbitration from a general manner to allow every possible usecases (including yours) while you approach arbitration from a particular approach. Your approach (do you have code to link to so I can verify?) seems to be perfectly compatible with the standard.
The standard interface perfectly allows this. You have to implement this in the
Having arbitration fees not fixed is perfectly possible within the standard. If you want the
You are speaking about claims, the standard does not deal with claims (this does not mean claims are impossible, just that the
That the particular point of this standard, decoupling
No, there is not design difference, as the standardization of interactions between
There is standard framework for interoperability which is perfectly compatible with your design (from what I understood, but again, for me to verify that I'd need to see your code).
Again, feel free to give me a usecase which will not fit in. But note that the standard is about interactions between
Here is a link to the stake contract, which will be the "arbitrable" contract in the end. This work is still very much WIP and undocumented, but I think you'll quickly see that our implementation of arbitration is not the same as yours. (or maybe it is, and I've simply misunderstood)
Our respective implementations do not matter for standardization. Only the interaction needs to be standardized, not the implementation. I think that a lot of your previous comments are based on the wrong premise that the standard was about implementation.
I effectively think you misunderstood as your implementation can be slightly modified to fit in the standard.
Why are arbiters being paid in advance when we can trustlessly pay them when they rule?
If arbiters simply sort their bounties by the value of their fees instead of by their time of creation (or some weighted combination), the spammy bounties will be the lowest value disputes, and can therefore trivially be ignored. Otherwise if spammy claims have a meaningful supply of fees attached, they can choose to rule on them as they please.
It's not arbiters which are paid in advance, it's the
This is why the arbitrable contracts shouldn't be coupled to the arbitrators, who can choose to rule on claims they desire to (and trust) and ignore ones they don't.
Why do you assume that the arbitrator must be another contract and can't simply be an individual?
This is trivially done on the front end by comparing byte code / the master copy which proxies point to.
Again, it only triggers that process if arbiters want it to.
As you can see, a number of design differences are beginning to show themselves, and these are fine. However, trying to declare that one design should be STANDARD without any PROOF would be a terrible decision.
That's the precise goal of this standard, providing a standard interface for coupling
Another individual can be trivially put as a contract (cf: https://github.com/kleros/kleros-interaction/blob/master/contracts/standard/arbitration/CentralizedArbitrator.sol and we can do even better by using only a unique contract for centralized arbitrators which specifies the address of the centralized arbitrator in
They would need a list of all accepted
Dispute resolution systems do not necessarily have people acting as watchdogs of what a dispute could be.
Mark, this is a standard to allow interoperability between
Then this should not be promoted as an "arbitration standard", when it only covers specific cases of arbitration.
I am absolutely not against standardization, I have spent the last year pushing for standardization among bounty implementations on Ethereum, which is why I can tell you first hand that standards should evolve and not be enforced in a heavy handed manner. I resent any implication that my hesitation here is because I don't want a standard to exist, since my goal is very much the opposite. But standards must be administered in a prudent manner.
This is true, but a standard for arbitration doesn't need to know anything about who is adjudicating the claims (similarly to how the ERC20 contract doesn't know anything about which contract or individual is transacting with tokens).
If you would like to have a standard for Arbitrable contracts, then it should not be coupled to any Arbiter contract. A second standard for Arbiters may be developed independently, and the Arbiters can make sure they are compatible with the Arbitrable contract, but there's no reason for the bidirectional coupling.
This is only half true, it's entirely possible to pursue interoperability in the short term by working with select groups on connecting Kleros to their dispute resolution needs (and competitors can do so similarly, either following the same interface or a different one). Then, once we have a better understanding of user needs, we can develop a standard. Trying to develop a standard for your product before you have any users is opposite to every product development best practise that exists in the world, and entirely ignores the needs of your future users as they arise.
I have tried repeatedly to explain to you why the standard you are developing differs from the way we have built and architected arbitrable contracts (stakes).
I am not intending to prevent you from rushing into interoperability, I am attempting to prevent an ERC from being formally proposed which not only doesn't agree with other implementations for Arbitration on Ethereum, but is based on no user data about what actual needs will be when launched into production. As I said above, interoperability can be pursued with partners without proposing an ERC; we've done this fruitfully with standard bounties for over a year, and as it turns out, our initial implementation was not complete, and as we gained users, we learned why it was lacking. If we had proposed a standard from the outset, there would be significant complexity from having to support multiple versions simultaneously (and in perpetuity).
As I stated from the outset, we have significant differences in our implementations, and either one of us calling our ideas for Arbitration "complete" would be foolish. I wish you the best of luck with exploring an architecture of tight coupling between arbitrable and arbiter contracts, while we desire to decouple these components as much as possible. Neither of us has hard evidence about why our design pattern is best, so we should wait and collect that evidence before pushing an ERC forward.
And for the record, my mention of "my product 4 times" in no way is meant to promote it (who am I promoting it to? other developers who browse EIPs? Those are unlikely going to make up the bulk of an arbitration user base).
I mentioned our product because we have implemented a version of Arbitration that differs very strongly from yours. Not only does your design require high coupling between projects (dApp smart contracts) and arbitrators, it assumes that one single interface for arbitration can be used in all cases where dispute resolution is required.
I apologize that my comments to you seem rude, I've tried to express my disagreement with your view on multiple occasions, and instead of attempting to understand my point of view, you ignore it. We spent 45 minutes on a call during which you repeatedly tried to explain to me about the importance of an "appeals" process, instead of looking at our design differences from a broader perspective. I really don't intend to stunt your growth or hinder your efforts towards interoperability, but there are real-life, long term consequences of building and pushing EIPs forward. For a component as critical to trust transactions as arbitration, we should make sure we get it right.
Also for the record, my use of bold text and upper case letters is meant to serve to emphasize certain points, not to "shout" at you.
Mark, since you are misreporting our interactions, I would not interact with you anymore. The issue section of an ERC is not a place for personal attacks. Your point of view has been understood. Good luck on your ventures. Further off topic comments will be reported to an EIP editor.
Was your above comment not littered with personal attacks on my character?
If you decide you are interested in actually collaborating on a standard for Arbitration on Ethereum (and not simply formalizing your teams approach into a standard that others must conform to), I would be happy to help.
By the way, for those who want to participate in the initial discussions and write-up of the evidence standard feel free to list your usecases and comments there:
While speaking with developers of origin @wanderingstan , came the proposal to extend this standard to allow payments to be made in token.
In case the
@clesaege now that some time has passed, I want to enquire again whether you'd be interested in generalizing this EIP/ breaking it up into two separate EIPs: one for arbitrable contracts and one for arbitrator contracts, whereby the arbitrable contracts never make calls to the arbitrator contract (only storing the arbitrator to validate when they make decisions). This would allow both of our approaches to potentially rely on the same standard (with some overlap), rather than pursuing these different approaches entirely independently.
@mbeylin I stated in the previous posts, what you do can perfectly be done with this standard and there is no different approaches, your approach is included in this standard (except the payment in tokens that my previous post proposed to add).
We can however discuss about moving the
The advantage of this proposal I see are:
Overall, this proposal seem to fit only the case where an external account is the arbitrator but not the cases where the arbitrator is a more complex smart contract.
@clesaege by putting the createDispute function into the arbitrable contract, aren't there significant benefits around:
It's also unclear to me why the fee is paid to arbiters when a dispute is created- wouldn't it make more sense for the fees to be sent to the arbiter at the time when they properly rule on the claim?
It's also unclear to me why moving createDispute into the arbitrable contract would require the arbitrator to know anything about who is capable of creating the dispute or what happens to funds in the interim (this logic may live in the arbitrable contract).
Contracts may enforce the notion of only one dispute being opened at a time, rather than allowing competing disputes (again its unclear to me why this logic is at all related to the arbiters themselves).
Could you explain this a bit more? I'm not sure I follow.
Again you allude to the need for users to interact with the arbitrator contract in-protocol, but again it's not clear why.
This is categorically false: if arbitrable contracts are creating disputes with a given fee, and communicate this dispute to arbiters out-of-protocol, then arbiters may freely decide to rule on claims which provides a sufficient fee to satisfy them, and ignore those which don't. This allows the prices for dispute resolution to move much more freely than in your current implementation (where the price must for some reason be set in the contact). The problem of pricing is compounded when you start to think about fees paid in a myriad of tokens: how many units of a given token that will be sufficient to incentivize arbiters may change over time, and allowing arbiters to ignore claims which are insufficient is a great solution. Since the initiators of claims are always incentivized to get their claims resolved as quickly as possible, we know they'll always seek pricing information on current arbiter fees (out of protocol), and pay the necessary fees.
This fee structure begins to resemble the way transaction markets work on Ethereum: the protocol doesn't reject transactions which are below a fee which is explicitly set by miners, they simply wait in a pool of txns until the volume is such that they get picked up.
I think you mean requiring parties in a dispute to interact with the
The fee is not paid directly to the arbiters when a dispute is created, it is paid to the
Yeah, they can do so with the current proposal: since creating disputes must go through the
No I don't, my previous post was just a though experiment of what would happen if we were to move the
Sorry for the confusion, I mean determine who pays the fee. In the current proposal
Overall everything can behave as you declared you wish it to behave (except paying in token, thus my previous post proposing to add it).
But why bother putting the funds in the arbitrator contract in the first place ahead of time, why not just pay out when the decision is submitted? Why is this extra trust being placed on the arbitrator contract (to not allow funds to be taken without ever submitting a ruling) instead of just programming the arbitrable contract to remove this problem altogether?
I think the key in my mind, as a developer who would rely on this standard for only the
Because otherwise, malicious parties could start an expensive process without paying.
Because the parties trust the
@mbeylin Your posts show that you are not interested nor needing what this standard is doing. That's completely fine and we do not try to force you to do anything.
referenced this issue
Jun 27, 2018
referenced this issue
Aug 23, 2018
You can review the evidence standard proposal https://docs.google.com/document/d/1AsGt_Am2rbZwCd6FULfl4ssMIlo_WZVhjo8V7ZFztmo/ . If there is no issues found we'll submit it as an ERC.