Kleros Governor Explainer

Kleros recently moved all governance control to the Governor which relies on Snapshot voting based on initial proposals created by community members. To read the announcement article, click here. To find out more about how the governance process works, continue reading.

An Example

In the situation where a parameter on one of our dapps needs to be modified, for example, the minimum stake for the general court, this would now be proposed via the Snapshot interface voted on by PNK holders and automatically enforced by the governor contract.

The first step is to tell the Governor smart contract that a vote has passed and what update needs to be made. Kleros team members, jurors, community members or anyone interested in having the ruling enforced can do this from the Kleros Governor interface. The smart contract does not allow duplicate lists of instructions to be submitted, so only one party can make the submission.

Each governor session enforces governance decisions that were passed prior to the start of the current session.

A user submits a list of transactions to be executed by the governor contract at the end of the session. If there is only one list submitted for the session, it will be accepted and the deposit is returned to the submitter.

If a competing list is submitted in the same session, a dispute will be created in Kleros Court to choose which list is correct. After dispute resolution concludes the deposit from the losing list will be used to pay the jurors and reward the user that submitted the winning list.

Lists that most completely enforce the greatest number of governance decisions will be accepted. The process for choosing between lists can be seen here.

Creating a List

Lists are made up of one or more transactions. There should be the same number of transactions as decisions that need to be executed. There are four parts to every transaction.

• The title of the transaction. This is used to make it easier for verifiers to understand what the transaction is meant to be doing. It can reference a vote number or otherwise just give a short description of the action being taken.
• The address of the target smart contract. In the screenshots above, it is the address of the Kleros Liquid contract that runs Kleros Court.
• Set an ETH amount that will be sent with the transaction. In this case changing the subcourt juror fee does not require any ETH, so we put 0 (zero). In a case when ETH is required, it can be entered in this field, but the submitter does not have to pay it. After a list has been accepted, another contract interaction is needed to execute the list and supply the payment needed execute the calls.
  Note: the Kleros Cooperative will likely provide the fees needed by the governor transactions, but anyone can do it.
• The raw hex data. This is inputted to tell the smart contract exactly what needs to be done. In this example, we have the function signature for changeSubcourtJurorFee followed by its values for the two parameters _subcourtID and _feeForJuror which are 0 and 100000000000000000 respectively.

In Case of Dispute

If more than one List is submitted in a period, a dispute is automatically created and sent to Kleros Court. Jurors will study the lists submitted and decide which one reflects the correct changes that were voted upon.

The Governor will not allow new list submissions until a dispute has been resolved.

Once jurors make a ruling on the correct list, anyone who disagrees with the decision can pay appeal fees to send the dispute to another round. The appeal system is similar to other Kleros projects, such as the T2CR.

After a final ruling is accepted, the submitter of the correct list, as well as the crowdfunders who supported the correct list in the appeal process, are rewarded from the deposit and appeal fees of losing lists.

Where Can I Find Out More?

Join the community chat on Telegram.

Visit our website.

Follow us on Twitter.

Join our Slack for developer conversations.

Contribute on Github.

Download our Book