Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Ethical ads to power Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Follow the orgs you like more with tribes and build relationships and meaningful projects.
Meet the top hunters and contributors from our community.
Most people working with Ethereum have questions about ETH2.0. Kevin Owocki hosted some developers working on the project for a recent episode of the…
Sia recently ran the Skynet Hackathon with Gitcoin for Skynet’s launch, leading to over 40 project submissions in a 2 week period. This piece, …
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
# Kleros Liquid Bounties
This bug bounty is also posted on [solidified](https://web.solidified.io/contract/5c771a8cc2dd660011638192).
You can report bugs on solidified or by sending a mail to firstname.lastname@example.org. Bugs are rewarded up to 50 ETH according to the classification indicated on solidified:
- Minor bugs: 5 ETH
- Major bugs: 25 ETH
- Critical bugs: 50 ETH
## Kleros Liquid
This contract will be the main Kleros contract of Athena release. The [token](https://etherscan.io/address/0x93ed3fbe21207ec2e8f2d3c3de6e058cb73bc04d#code) and [RNG](https://etherscan.io/address/0x1738b62e403090666687243e758b1c29edffc90e#code) will stay the same.
### Phases and Periods
Periods indicates the status of a dispute. Periods are individualized by dispute in order to make the flow of disputes continuous.
Periods of a dispute are:
- Evidence: Where parties can submit evidence. Draw must happen during this period.
- Commit (only for private votes): Where parties commit h(v,s) where v is their vote and s a salt.
- Vote: Where parties can cast votes (for public votes) or reveal them (for private ones).
- Appeal: Where the current ruling can be appealed.
- Execution: Where token shift is executed and rule called on the arbitrable contract.
At the global level, we have phases. They are required to make economies of scale in term of random numbers and to have time where everyone can unstake tokens. Jurors can only stake/unstake tokens during the Staking phase to prevent attackers to add/remove PNK in order to set sum trees such that they are drawn after they know the random numbers. Phases are way shorter than periods (they just need the time for random number generation and recording draws).
- Staking: Where jurors can stake or unstake PNK. All actions are allowed during this phase. This phase has a minimum duration but no maximum one. We go to the next phase if the minimum duration has passed and at least one new dispute/appeal occurred.
- Generating: This is the phase where the random number is drawn. It has no minimum nor maximum duration. This phase is passed as soon as the random number is ready.
- Drawing: This is the phase where a draw is called, jurors are informed that they’ve been drawn, the PNK corresponding to possible incoherence penalties are locked. This phase has no minimum duration but a maximum one. It is passed either when all the newly created and appealed disputes are drawn or after it reaches maximum duration.
### Action callbacks
Actions like passing periods/phases, setting delayed stakes, executing repartitions or drawing jurors are required. A bot will execute them but would the bot stop anyone could. If they are not executed in time, it is possible for the result to be different (for example another random number can be used), this is fine (because any interested party can call those functions) as long as it does not lead to an invalid state staying "stuck".
Subcourts are created through governance and governance (i.e the governor) can modify its parameters. Subcourt characteristics are:
- **parent**: The parent court where appeals are transferred once the maximum number of jurors are reached.
- **children**: List of children of this court.
- **minStake**: The minimum amount of PNK to stake in this subcourt. The minStake of a court should always be greater or equal to the one of its parent.
- **alpha**: Proportion of minStake which can be lost when someone rules outside of the consensus. This variable is denominated in ‱ (1 / 10 000).
- **hidden**: True if votes are hidden through commit and reveal. False otherwise.
- **feeForJuror**: The minimum arbitration fee which must be paid to each juror.
- **jurorsForJump**: Amount of jurors which if it’s reached, will lead to the dispute “jumping” to the parent court. For example, if jurorsForJump=20 and a dispute with 31 jurors is created (either directly or as a result of a dispute jumping from a child court), it is handled by the subcourt normally but in case of appeal, it jumps to the parent court. When a dispute jumps to the parent court, the amount of jurors is also doubled and one is added (same as if it stays in the same court). The appeal and appealCost functions need to take jumps into accounts. For the general court, if this amount is reached, appealed are not possible anymore.
Jurors have to specify how their tokens are staked in the subcourt. The sum of tokens staked in the child courts of a court must always be lower or equal to the stake of the parent court. For computational reason, the maximum amount of subcourt path an account can make is capped by **MAX_STAKE_PATHS**.
![Valid / Invalid stakes](https://i.ibb.co/VwFtStk/valid-invalid-staking.png "Valid / Invalid stakes")
### Sortition Sum Tree
A Sortition Sum Tree is used to draw jurors in proportion of their tokens. You can see more information about this structure [in this other 50ETH dedicated bounty](https://github.com/kleros/kleros/issues/115).
### Delayed Execution
Modifying the sortition sum tree during a the random number generation or drawing of jurors could be abused by modifying ones position in the tree in order to be drawn. To cope with the issue, modification of stake not happening during the staking period are delayed.
### Drawing Jurors
Jurors are drawn with a likelihood proportional to their amount of staked tokens in the subcourt. A juror can be drawn more than once. If it is the case, its vote, fees and token repartitions are counted multiple times.
When a juror is drawn, tokens corresponding to the maximum amount of tokens it could lose in the token repartitions are locked. This is to avoid juror moving tokens they would lose. Those tokens are unlocked after the repartition.
Jurors are considered coherent if they voted like the majority in the final appeal round.
If the final result is a tie, all jurors who voted are considered coherent.
Jurors who failed to vote are considered incoherent.
### Arbitration Fee Payout
We draw as many jurors as the arbitration fee allows.
The fee is then divided between coherent jurors. This means that each juror is paid at least the juror fee but can be paid more.
Fees are split at the appeal level (not overall).
If no one is coherent, the fees are given to the governor.
### Token Repartition
Incoherent jurors lose alpha * minStake tokens. If they don't have enough, they lose all of them. Those tokens are then split at the appeal level between coherent jurors.
If there is no coherent jurors, they are sent to the governor instead.
### Token Controlling
Juror do not transfer PNK to the Kleros contract (this will allow forking PNK into vote tokens for the DAO governance). Instead the Kleros contract becomes the TokenController of the Pinakion contract.
Token redistribution can be done by the controller because it can move funds at will.
Preventing staked and locked (maximum amount which can be lost due to token repartition) token transfer is done by verifying that tokens can be moved by onTransfer.
### Trust Model
The trust model is the following:
- The **governor** is to be **trusted** and will be moved to a PNK based DAO when ready. In particular it is not a problem if the governor can take actions which would lead to some issues or invalid states as its trust model will be similar to the one of Kleros (majority of active PNK not belonging to malicious entities). The governor has full contract over the contract as it will be useful for updates.
- The [**Pinakion** contract](https://etherscan.io/address/0x93ed3fbe21207ec2e8f2d3c3de6e058cb73bc04d#code) is a Minime Token which is to be **trusted**. Its governor will also be replaced by a the DAO when ready.
- The random number generator is to be trusted. It is currently based on the [blockhash](https://etherscan.io/address/0x1738b62e403090666687243e758b1c29edffc90e#code) and will be replaced by one based on [verifiable delay functions](https://vdfresearch.org/) when they will be ready. Note that an attacker can "reroll" the blockhash but not fix it to a particular value.
- The **arbitrated** contracts are **not** to be **trusted**. They should follow [ERC792](https://github.com/ethereum/EIPs/issues/792) but someone could create a contract not following it.
## Smart Contract Guidelines
We use [those guidelines](https://kleros.gitbook.io/contributing-md/code-style-and-guidelines/solidity) to write smart contracts. In particular, we do not try to prevent stupid behaviors at the contract level but leave this task to the UI. Letting the possibility to a user to harm itself is not a vulnerability (but should of course be dealt at the UI level).
Violation of guidelines are not vulnerabilities but can be reported as "suggestion for tips".
## Bounty rules
- This bounty includes [KlerosLiquid.sol](https://github.com/kleros/kleros/blob/master/contracts/kleros/KlerosLiquid.sol) and all files it relies upon (if the vulnerability in this file leads to a vulnerability in KlerosLiquid).
- Non significant rounding errors are not vulnerabilities.
- Simple misnaming is not a vulnerability but can be reported as "suggestion for tips".
- If you make a security report, you can submit it as a "suggestion for tips".
- Do not focus on typo as those are not eligible for tips (you can still be nice and report them as "suggestion for tips" but we won't give tips for them).
- This bug bounty is also available outside of solidified. Only the first reporter of a vulnerability is eligible for a bug bounty.
- Vulnerabilities are paid in ETH. Tips are given in PNK.
- If you have any questions, don't hesitate to ask on the channel or by sending a mail to email@example.com .
- All this code is provided under MIT license and can be reused by other projects. If you do, don't hesitate to inform us and we may list your deployed contracts in the `@deployed` of the RAB pragma.
- Good luck hunting and have fun!