This contract implements the Kleros arbitrator.
Arbitrator contracts can arbitrate
Arbitable ones as describded in ERC792.
The general logic is the following
The full logic cycle for a batch of disputes runs in a single session the length of which is approximately 3.5 days. A single session is divided into five periods.
- To have the chance of being drawn a juror deposits Pinakion during
- A random number is picked during
Period.Drawand the judges are drawn based on it.
- Jurors submit their voting decisions during
- Losing parties in the dispute can appeal during
- Pinakion is redistributed during
Period.Executionbased on how the Jurors voted. This is also the period rulings are executed.
- Jurors must restake their Pinakion on each new session.
- We have a web UI for both jurors and
Abritableparties. They can be found at https://juror.kleros.io/ and https://escrow.kleros.io/ respectively.
- A full walktrough of the Kleros system from the eyes of a user can be seen at https://www.youtube.com/watch?v=PhjcjtYRiDs&t. We recommend you to watch it in order to get a good feel of how the arbitration process works. Note that in the cryptoeconomics test release, the disputes will be listing disputes and not escrow disputes to start with usecases with non critical failure modes.
Notes on security
- With numeric operations we don't use SafeMath on purpose, as it is redundant (with lowering the value if it would lead to over/underflow) in the majority of cases and in some cases blocking the execution is a worse failure mode than an overflow.
- In many cases, we use
sendto prevent intentional blocking of the contract. This is the expected behaviour, it is smart contract responsability to make sure their fallback function does not revert / out-of-gas on
- In this release, we will use a blockhash random number generator which can be slightly manipulated by the miners (by block withholding and building upon the block of their choice in case of fork). We will use a more secure random number generation method in the future. But note that even with a blockhash RNG, miners can just reroll random numbers they don't like but not set them to a particular value. As the number of jurors increases (with appeals), it would be harder and harder to manipulate the RNG to create a set of juror statistically different from the underlying juror pool. This RNG is part of another submission.
- In this release, the
Arbitrablecontract will be an arbitrable curated list. If other disputes are created, jurors should refuse to arbitrate (vote 0). This arbitrable curated list is part of another submission.
- In this realease, the governor is an address controlled by Kleros team. It will be switched to a liquid voting mechanism when contracts for this purpose will be ready. Note that it is not our intention to build a centralized or backdoored system but we prefer to release an early version for testing rather than to wait for the governance mechanism to be implemented. The governor has full control over the Kleros contract. We assume that this governor is honest and change parameters only when it does not lead to issues for the remaining parts of the contract.
- The Pinakion contract has already been deployed there.
- Kleros: 0x211f01e59b425253c0a0e9a7bf612605b42ce82c
- Pinakion: 0x93ed3fbe21207ec2e8f2d3c3de6e058cb73bc04d
- RNG: 0x1738b62e403090666687243e758b1c29edffc90e
- Doge List: 0xb7faddf3ecd2402a7e48cea6d2637d90eeb5a7e6
Bugs or vulnerabilities on deployed (and in use) contracts are eligible up to 20 ETH of bounties (depending of their vulnerability, using the OWASP rating). Please disclose them to both firstname.lastname@example.org and email@example.com using "[Bug Bounty]" in the subject.