Staking and Voting

While each task can configure it's own penalty and voting calculations, we recommend something like the following example, as this is the primary case under which Gradual Consensus has been tested.

Staking 
Tokens are staked on a per-task basis, which ensures that there is always sufficient collateral to secure the underlying bounty and ensure stable and predictable outcomes in case of an audit. While the default structure for tasks is to use KOII tokens as stake, it is also possible to configure a Task to lock up and collateralize anything from an NFT to a K2 Token, or even an asset on another blockchain if a sufficiently secure vault contract can be deployed.
When an asset is staked, it is important to assign a lock period, otherwise the collateral may be withdrawn before malicious action is detected. Common minimum stake periods are 2-4 epochs (24-48 hrs). 

Voting & Vote Power
The primary reason that a stake is required by participating nodes is to secure the Gradual Consensus voting process which aggregates feedback from multiple nodes before an on-chain decision is confirmed. 
Vote Power is not a required feature for tasks to execute, but can be a powerful tool in enforcing good behaviour. Under this model, the vote of each node is scaled according to it's portion of the stake pool, along with any secondary reputation properties or historical performance that might be useful. In the original implementation, votes are scaled by the total stake and the total time the stake is locked. 

Microservices & Tasks - Previous

Gradual Consensus

Next - Microservices & Tasks

Task Design Guide

Last modified 11d ago

Copy link