Cronos EVM Docs
  • Getting Started
    • Getting Started
    • Background
    • Architecture
    • Cronos roadmap
  • FOR USERS
    • 💳Crypto.com Card Top Up
    • 🔥Crypto Wallets
    • 🦊MetaMask Configuration
    • 🦁Brave Wallet
    • 🌉Bridges
      • From the Crypto.com App and Exchange
        • From the Crypto.com App
        • From the Crypto.com Exchange
      • IBC (Cronos POS Chain, other Cosmos chains)
        • Cronos Bridge Web App
      • Independent bridges
      • FAQs for Bridge transfers
      • FAQs for transactions from/to centralized exchanges
    • 🚰Testnet Faucet
    • 💡Tips & FAQs
    • 👮Key Principles for Wallet Security
    • GasTracker
  • FOR DAPP DEVELOPERS
    • 💡Founder FAQs
    • 🏅Hacker's Getting Started Resources
    • 📃Smart Contracts
      • Contract Development on Testnet
      • Contract Deployment and Verification
      • Contract Verification Export: Cronoscan To Cronos Explorer
      • Best Practices
      • Token Contract Addresses
    • 💻dApp Creation
      • Free and commercial RPC endpoints
      • Wallet integrations
      • Web3-wallet
      • JSON-RPC methods
      • Address Conversion
      • Swagger Playground
    • ⚙️Dev Tools & Integrations
      • All dev tools & integrations
      • Account Abstraction
      • Band Protocol
      • Banxa
      • GoldRush
      • Cronos Safe
      • Flair
      • Google Bigquery
      • Moralis
      • Pyth
      • Secret Network
      • SubQuery
      • Witnet
    • Crypto.com AI Agent SDK
  • FOR NODE HOSTS
    • Running nodes
      • Cronos Mainnet
        • Quicksync
        • State-sync
        • Public Node Sync
        • KSYNC
        • The "Huygen" upgrade guide (v0.6.* to v0.7.*)
        • The "v0.7.0-hotfix" upgrade guide (v0.7.* to v0.8.*)
        • The "Galileo" upgrade guide (v0.8.* to v1.0.*)
        • The "Titan" upgrade guide (v1.0.* to v1.1.0)
        • The "v1.2" upgrade guide (v1.1.* to v1.2.0)
        • The "v1.3" upgrade guide (v1.2.* to v1.3.0)
        • The "v1.4" Pallene upgrade guide (v1.3.* to v1.4.1)
        • Patching Unlucky & Duplicate Tx
      • Cronos Testnet
      • Devnet
      • Best Practices
      • Cronosd build with Nix
      • VersionDB
      • MemIAVL
      • Local State Sync
    • Cronosd
  • CRONOS PLAY
    • Introduction
    • Unity Engine
      • Current Version
      • Legacy Version
        • EVM
        • Login Example
        • Custom RPC
        • ERC20
        • ERC721
        • ERC1155
      • Useful Links
    • Unreal Engine
      • Installation and Enabling
      • Working with Blueprint
        • Actors and Blueprint Classes
        • Cronos Configuration
        • Connect Defi Desktop/Onchain Wallet with URI
        • Connect Wallets with QR Code
        • Connect WalletConnect Step by Step
        • WalletConnect 2.0 and Unreal Engine 5: Hello World Example
        • Wallet
        • ERC20
        • ERC721
        • ERC1155
        • Broadcast Transactions
        • Get Tokens or Transactions
      • Working with C++
        • Creating a C++ Project
        • Creating a child DefiWalletCoreActor
        • Querying a contract
        • Customizing Network
      • Demo
    • Cronos Play C++ SDK
    • Crypto.com Pay Integration
    • Cronos Play FAQ
  • Block Explorers
    • Block Explorer and API Keys
    • Cronos Explorer
    • Cronoscan
  • CRONOS CHAIN PROTOCOL
    • Chain ID and Address Format
    • Cronos General FAQ
    • Genesis
    • Modules
      • module_bank
      • module_distribution
      • module_slashing
      • module_feemarket
    • Chain Details
      • List of parameters
      • Technical glossary
      • Protocol Documentation
    • Common IBC Commands
  • Cronos zkEVM
    • Cronos zkEVM
  • Resources
    • Media / brand kit
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. CRONOS CHAIN PROTOCOL
  2. Modules

module_distribution

Previousmodule_bankNextmodule_slashing

Last updated 4 months ago

Was this helpful?

distribution module

Introduction

The distribution module is responsible for the distribution of rewards to the validators and delegators.

Overview

Network Parameters

Below are all the network parameters for the distribution module:

  • community_tax - The rate of community tax;

  • base_proposer_reward - Base bonus on transaction fees collected in a valid block;

  • bonus_proposer_reward - Maximum bonus on transaction fees collected in a valid block;

  • withdraw_addr_enabled - Whether delegators can set a different address to withdraw their rewards.

Rewards

There are two main types of rewards

  • Block rewards, governed by the module; and

  • .

Block reward

Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains cro with each reward, all validators will maintain equal weight over time.

For the validator operator, the distribution information is updated if:

  • the amount of delegation to a validator is updated (delegation, unbond, slashing etc.);

  • a validator successfully proposes a block and receives the reward;

  • any delegator withdraws from a validator, or

  • the validator withdraws it's commission.

For delegators, once they have delegated to a validator, they will be entitled to a portion of the total reward obtained by the validators. The reward is proportional to their delegated amount, and the commission charged by the validator operator (if any).

Transaction Fees Bonus

When a validator is selected to propose the next block, they must include at least 66% precommits of the previous block. To incentivise validators to include more than 66% precommits, the module provide a bonus reward (a portion of the transaction fee in the block) to the proposer.

This bonus reward is dependent linearly on the precommits from the other validators. Stating from 66% of the precommits, the basic bonus will be base_proposer_reward and increase linearly to bonus_proposer_reward when the validator includes 100% of the precommits.

Community tax

Transactions and Queries

Transactions

tx distribution withdraw-all-rewards - Withdraw all delegations rewards for a delegator

Delegator can withdraw their reward(s) from the validator(s) that they have delegated all at once.

tx distribution withdraw-rewards [validator-addr] - Withdraw rewards from a given validator address

Delegator can withdraw their reward from a specific validator.

Remark: Validator operation can withdraw the commission in addition to the rewards by adding the commission flag --commission.

tx distribution set-withdraw-addr [withdraw-addr] - Change the default withdraw address for rewards associated with an address

Delegator can set a different address to withdraw their rewards.

tx distribution fund-community-pool [amount] - Funds the community pool with the specified amount

Users can make a contribution to the community pool with a specific amount.

Queries

query distribution commission [validator] - Query distribution validator commission

We can check the commission of a specific validator.

query distribution community-pool - Query the amount of coins in the community pool

We can check the balance of the community pool.

query distribution rewards [delegator-addr] [validator-addr] - Query all distribution delegator rewards or rewards from a particular validator

We can check the current rewards for a delegation on a specific validator.

query distribution slashes [validator] [start-height] [end-height] - Query distribution validator slashes

We can check the history of slashing event of a validator.

query distribution validator-outstanding-rewards [validator] - Query distribution outstanding rewards for a validator and all their delegations

We can check distribution outstanding (un-withdrawn) rewards for a validator and all of their delegations.

query distribution params - Query the current distribution parameters

We can query the current distribution parameters by

$ cronosd query distribution params --output json | jq

REST endpoint

The parameters can also be checked by browsing to the following REST endpoint on Mainnet:

{
  "params": {
    "community_tax": "0.000000000000000000",
    "base_proposer_reward": "0.000000000000000000",
    "bonus_proposer_reward": "0.000000000000000000",
    "withdraw_addr_enabled": true
  }
}

Appendix

distribution module: Network Parameters and configuration

The following tables show overall effects on different configurations of the distribution related network parameters:

community_tax

base_proposer_reward

bonus_proposer_reward

Type

string (dec)

string (dec)

string (dec)

Higher

More reward will go into the community pool

Higher basic transaction fees bonus for the proposer

Easier for a proposal to be passed

Lower

Less reward will go into the community pool

Lower basic transaction fees bonus for the proposer

Harder for a proposal to be passed

Constraints

Value has to be less or equal to 1

Value has to be less or equal to 1

Value has to be less or equal to 1

Sample configuration

0 (0%)

0.01 (1%)

0.04 (4%)

This mechanism aims to incentivize non-empty block proposals, better networking between validators as well as to mitigate censorship. For further example, kindly refers to this .

The community_tax is the tax rate to the reward obtained by the validator. Specifically, part of the reward will be taxed and send to the community pool. The funds in the community pool can be withdrawn by submitting a community pool spend proposal with the .

Even if the community_tax is set to be zero, the balance of the community pool could be non-zero. For example, the truncated remainder in some accounting edge cases will be sent to the community pool as well. Besides that, users can fund the community pool voluntary, and there could be funds allocated to the community pool in the .

/

mint
Transaction fees bonus
link
gov module
genesis
https://rest.cronos.org/cosmos/distribution/v1beta1/params