kleros/kleros-interaction

[Bug Bounty: up to 50 ETH] Token Token Curated Registry

Closed this issue · 1 comments

clesaege commented

Token Token Curated Registry Bounties

This bug bounty is also posted on solidified.
You can report bugs on solidified or by sending a mail to clement@kleros.io. 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

Token Token Curated Registry

This is token curated registry of tokens. It implements the ERC792 Arbitration Standard and the ERC 1497: Evidence Standard.

Token Listing

The list will be used to verify that:

  • Name (ex: Pinakion)
  • Address (ex: 0x93ed3fbe21207ec2e8f2d3c3de6e058cb73bc04d)**
  • Ticker (ex: PNK)
  • Symbol Hash (hash of the image of the logo)
    Are matching.

Requests and Challenges

Anyone can request a token to be added by putting a deposit.
Challengers are then able to challenge this request to add this token.

Anyone can request a token to be removed.
Challengers are then able to challenge this removal request.

Making requests and challenges require putting deposits.
When a request is challenged, a dispute is created.

Dispute Deposit structure

The amounts required are deposits, not fees. Parties putting unchallenged tokens or winning their disputes get back their deposits.

The deposit structure is as follow:

  • A challenge reward, which acts a fixed deposit.
  • The arbitration fees.
  • A variable deposit proportional to the arbitration fees. Its value is determined by the arbitration fees and sharedStakeMultiplier.

This deposit is similar for both the requester and the challenger.
Requesters and challengers are required to fully fund their deposits.
When winning a dispute, the winning party gets deposit of the losing party (minus arbitration fees).
If the dispute ends up into a tie (arbitrator refusing to rule), the request is denied but the reward is split between both parties in proportion of their contributions (most of the time 50/50, but an unequal split can occur if the arbitration fees are modified after a party made its deposit).

Appeal Deposit Structure

The deposit structure is as follow:

  • The arbitration fees.
  • A variable deposit proportional to the arbitration fees. Its value is determined by multiplying the arbitration fee by:
    • winnerStakeMultiplier for the current winner of the dispute.
    • loserStakeMultiplier for the current loser of the dispute.
    • sharedStakeMultiplier when the arbitrator did not give ruling in the current round.

Funding of the losing side is only possible during the first half of the appeal period.
If one side doesn't fund its fees within the time limit, it is automatically considered as losing.
To avoid parties not having/wanting to risk high amount of money, appeals can be crowdfunded.
The winning side receives the deposit of the losing one (minus arbitration fees). If the fees are crowdfunded, parties share the rewards in proportion of their contributions (per round, not per dispute).

Fee modification

The arbitrator can modify the fees (this should not happen often but should still be dealt with).
Once a side deposit is fully funded, no extra deposit is required even if the fee increases. Disputes and appeals are created immediately after both sides are fully funded, this means that the last side will pay at least the arbitration fees so we are guaranteed to have enough fees for the arbitrator.

Arbitrator

The arbitrator is ERC792 Arbitrator contract which returns the appeal period (arbitrators without this functionality are not compatible with the T2CR). It is considered trusted.

Governor

The governor is trusted and this address will be the one of a DAO (when ready).

Smart Contract Guidelines

We use those guidelines 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 ArbitrableTokenList.sol and all files it relies upon.
  • 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 clement@kleros.io .
  • 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!
gitcoinbot commented

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 0.5 ETH (65.63 USD @ $131.26/ETH) attached to it as part of the @kleros fund.