Documentation
  • INTRODUCTION
  • USERS
    • White Paper
    • Main features of CyberWay
    • Bandwidth differences between EOS and CyberWay
    • Bandwidth implementation
    • How to Launch EOS dApps on CyberWay
    • Glossary
  • DEVELOPMENT ENVIRONMENT
    • Core Concepts
    • 1 Before You Begin
    • 2 Install the CDT
    • 3 Create Development Wallet
    • 4 Start keosd and nodeos
    • 5 Create Test Accounts
  • SOFTWARE MANUALS
    • Core
      • nodeos
      • cleos
      • keosd
      • cyberway.cdt
    • How To Guides
      • How To Ban An Unwanted Account
      • How To Calculate Reward For An Author
      • How To Calculate Reward For A Beneficiary
      • How To Calculate Reward For A Curator
      • How To Create A Wallet
      • How To Create An Account
      • How To Create A Proxy Account
      • How To Create Key Pair
      • How To Delegate Resources
      • How To Deploy A Node Using A Snapshot
      • How To Deploy A Smart Contract
      • How To Get Account Information
      • How To Get Block Information
      • How To Get Transaction Information
      • How To Import A Key
      • How To Link Permission
      • How To List All Key Pair
      • How To Stake Tokens
      • How To Stop A Node Using Docker
      • How To Submit A Proposal For HardFork
      • How To Transfer Tokens To A Worker
      • How To Undelegate Resources
      • How To Unlink Permission
      • How To Unstake Tokens
      • How To Vote
    • API Reference
      • Nodeos Chain API
      • Nodeos Producer API
      • Nodeos Net API
    • Cleos Command Reference
      • Convert
      • Create
      • Get
      • Multisig
      • Net
      • Push
      • Set
      • Sign
      • System
      • Transfer
      • Version
      • Wallet
    • Explorer Command Reference
      • How To Check Your Balance
      • How To Find Out Account ID
      • How To Convert Golos To Golos Power And Vice Versa
      • How To Stake Tokens CYBER
      • How To Transfer Funds From One Account To Another
      • How To Transfer Funds From Pending to Liquid
      • How To Bay Stake
      • How To Withdraw Stake
      • How To Vote For A Validator
      • How To Revoke Your Vote For A Validator
      • How To Bay Vesting Using Explorer
      • How To Vote For A Witness
      • How To Revoke Your Vote For A Witness
  • DEVPORTAL
    • System Contracts
      • BIOS
      • Domain names
      • Govern
      • Multi-Signature
      • Stake
      • Tokens
    • Application Contracts
      • Golos Contracts
        • Charge
        • Control
        • Emission
        • Publication
        • Referral program
        • Social
        • Vesting
        • Memo-keys
        • Determining Rewards for a Post
    • Guide to Creating and Deploying an Application on CyberWay
      • 1 Preliminary Work
      • 2 Creating a Simple Contract
      • 3 Creating Tokens
      • 4 Understanding ABI Files
      • 5 Data Persistence
      • 6 Secondary Indexes
      • 7 Adding Inline Actions
      • 8 Inline Action to External Contract
      • 9 Conclusion
    • The cyberway_wallet designed for the Bittrex market
    • The Event Model
  • VALIDATORS
    • Testnet Installation Guide
      • 1 General
      • 2 Configuring the Docker Image
      • 3 Create Container
      • 4 Connecting to a Node
      • 5 List of Commands Applicable to Any Kind of Container
    • Mainnet Connection Guide
      • Docker-Compose Start-up Instructions
      • APPENDIX A
      • APPENDIX B
    • Golos Blockchain Transit
    • How to join CyberWay for those who are interested in being validators ?
    • Stake Usage Guide
    • Regulations for CyberWay validators. Voting for Validators
Powered by GitBook
On this page
  • Purpose of the cyber.govern smart contract development
  • Terminology used
  • onblock
  • setshift
  • burnreward
  • Main regulations concerning the validators
  • Validator status
  • Active validators
  • Validator rewards
  • Requirements and actions applied to a validator
  1. DEVPORTAL
  2. System Contracts

Govern

PreviousDomain namesNextMulti-Signature

Last updated 5 years ago

Purpose of the cyber.govern smart contract development

The cyber.govern system smart contract contains the logic for selecting active validators and distributing remuneration for block production in accordance with the DPoS provisions.

The actions supported:

The events supported:

Terminology used

Cycle - the time spent on one queue in a schedule (if the schedule contains N vaditors, then N blocks per 1 cycle must be produced).

Round - the time it takes to complete four cycles (the time for which 4×N blocks must be produced, where N is number of schedule validators).

onblock

The onblock action is a system operation and is not accessible to an external user. It is called by the cyber.bios smart contract. The operation contains the logic of block production, including the logic of token issuance and the appointment of validators. This action has the following form:

[[eosio::action]] void onblock(name producer);

producer parameter is a name of validator that succeed producing the next block.

The cyber.bios smart contract activates the onblock action after each block produced by validators. Calling onblock requires authorization of the cyber.govern smart contract account.

setshift

This action allows validators to set a rate of change in their number. When assigning a new list of validators, their number will be changed to value specified in shift if the last change (or setshift call) was later than schedule_resize_min_delay (14 days).

[[eosio::action]] void setshift(int8_t shift)

shift parameter sets the rate of change in a number of validators. Valid values ​​limited by contract are (-1, 0, +1).

To perform the action, authorization of a cyber.prods account is required.

burnreward

The burnreward event reports on burning an award allocated to a validator. A validator is not rewarded if no one block was produced by him during one round. The highlighted reward to validators is marked on their special account at the beginning of the round. When the validator produces a block, he marks these funds as requested and at the beginning of the next round they are transferred to a validator account. If the validator skips block production, then this award is burned.

[[eosio::event]] void burnrevard(
    name      account,
    int64_t   amount
)

Parameters:

  • account — validator account whose funds are burned.

  • amount — amount of funds burned.

Main regulations concerning the validators

Validator status

  • The validators are divided into two groups according to the voting results — the main validators who received the biggest number of votes and reserved candidates.

Active validators

  • Block production-wise, a schedule of active validators is automatically compiled, which includes all the main validators and one reserve candidate.

  • The selection of a reserve candidate for the schedule of active validators takes place according to the following rules. The priority of the candidate is calculated in accordance with the established formula, taking into account the number of votes cast for him and the time interval since his last appearance in the schedule of active validators.

  • Active validators produce blocks alternately according to the schedule.

  • The schedule of active validators is updated periodically every 4×A blocks, where A is the current number of active validators.

  • The number of active validators changes upwards from 21 to 101 inclusive.

  • The number of active validators increases by one if two conditions are met:

    • at least 14 days have passed since the last increase in the number of active validators;

    • the number of votes cast for the main validators was less than 90 % of the total number of votes cast for all candidates.

Validator rewards

  • The validator is rewarded for blocks produced by him in accordance with the provisions of DPoS and taking into account the annual issue of tokens. Funds generated from the annual issue of tokens are distributed in the following fractions:

    • 10 % goes to reward pool for validators for block production;

    • 20 % goes to reward pool for workers;

    • 70 % goes to the stake pool that is distributed between validators and users that voted for them.

  • Validator rewards are distributed in the following proportions:

    • 10 % from the validators pool goes to a validator, as well as commissions that he/she sets, which are taken from the stake pool;

    • the rest of the stake pool is distributed between the proxy and generic accounts that voted for this specific validator.

Requirements and actions applied to a validator

  • Validators must produce blocks in accordance with sequence specified in the schedule. If the schedule contains N vaditors, then N blocks must be produced per one cycle.

  • Validator is not rewarded if no one block was produced by him during one round. The highlighted reward to validators is marked on their special account at the beginning of a round. When a validator produces block, he marks these funds as requested and at the beginning of the next round they are transferred to the validator account. If the validator skips block production, then this award is burned (this is reported using burnreward event).

  • If a validator skips 100 rounds (no any block produced during 4×100 cycles) in a row, his key will be reset and a ban on changing the key for one day will be set.

  • If 4 series are being skipped by a validator in a row of 100 rounds (no any block produced during 4×4×100 cycles), the validator will be automatically denounced by setting proxy_level to the maximum value and it will be forbidden to return to activity within 7 days.

  • If a validator does not demonstrate any activity within 30 days, then any user can suspend the validator using suspendcand action.

The status of a validator candidate can be obtained by any user who has signed up, switched to a zero proxy level and has his own stake in the amount of at least 50,000 CYBER as well as a server (node) that meets the requirements specified in .

The validators are selected from the candidates by users via voting (read more about ).

manual
voting process
onblock
setshift
burnreward