Skip to main content
Version: Mainnet - Dymension

Governance

RollApp “Governors” manage the onchain governance enabling features such as onchain votes for transferring tokens owned by the community pool and adjusting onchain parameters.

What is a Governor?​

Governors do not operate nodes yet they receive token delegations, vote on onchain governance proposals and disburse the revenue (rewards) generated to their delegators. Each Governors sets their own commission rate. This commission is deducted from the rewards received from the RollApp.

It is permissionless to become a Governor for a RollApp. To enter the active set of Governors, a Governor needs to receive enough delegations to enter the active set determined by the maximum amount of Governors (e.g., if the max amount of Governors is 3, only the top 3 Governors with respect to amount of delegations will receive rewards and operate as governors).

Customizing Governance on Genesis

Example​

"gov": {
    "starting_proposal_id": "1",
    "deposits": [],
    "votes": [],
    "proposals": [],
    "deposit_params": {
      "min_deposit": [
        {
          "denom": "arollapp",
          "amount": "10000000"
        }
      ],
      "max_deposit_period": "172800s"
    },
    "voting_params": {
      "voting_period": "172800s"
    },
    "tally_params": {
      "quorum": "0.334000000000000000",
      "threshold": "0.500000000000000000",
      "veto_threshold": "0.334000000000000000"
    }
  },

min_deposit​

This is the required amount of tokens for a proposal to be active for voting.

"min_deposit": [
  {
    "denom": "stake",
    "amount": "10000000"
  }
],

max_deposit_period​

This is the amount of time a proposal has to reach the min_deposit prior to be discarded by the RollApp.

"max_deposit_period": "172800s"

voting_period​

This is the amount of time a community has to vote on the active proposal after the deposit minimum is reached in time.

"voting_params": {
  "voting_period": "172800s"
},

tally_params​

  • Quorum: Percentage of RollApp stakers that must participate in the proposal for the result to be considered valid.
  • Threshold: Percentage of voters that must approve (i.e. vote Yes) or decline (i.e. vote No) on the proposal.
  • Veto threshold: Percentage of No With Veto votes that decline the proposal and move the deposited funds to the community pool.
"tally_params": {
  "quorum": "0.334000000000000000",
  "threshold": "0.500000000000000000",
  "veto_threshold": "0.334000000000000000"
}

Staking​

Token holders stake (i.e. delegate) their tokens with Governors. This allows token holders to receive a pro-rata share of the rewards that are distributed by the RollApp. To be eligible for this distribution a token holder must stake their tokens with a Governor in the active set.

Only RollApp token stakers may vote on governance proposals. If a staker does not vote, their chosen Governors vote on their behalf. Tokens may be unstaked at anytime. Unstaking requires undergoing an unbonding period which is adjustable by onchain governance parameters.

Customizing Staking on Genesis

Example​

"staking": {
    "params": {
    "unbonding_time": "604800s",
    "max_validators": 100,
    "max_entries": 7,
    "historical_entries": 10000,
    "bond_denom": "arollapp",
    "min_commission_rate": "0.000000000000000000"
    },
}

unbonding_time​

This is the amount of time it takes for a user to unbond their tokens after delegating. Primarily used for timing out IBC light clients (e.g.,"unbonding_time": "604800s").

max_validators​

This is the maximum amount of active Governors for a RollApp at a time. The voting power is defined by the amount of tokens delegated to them (e.g.,"max_validators": 100). It is recommended to maintain less than 1000 max_validators, while not affecting consensus network this does add computational load to the RollApp.

max_entries​

Users may undelegate and redelegate, however to prevent speculative shifts of delegation that could destabilize governance, max_entries limits the number of redelegations a delegator can make within a certain timeframe (e.g., "max_entries": 7).

historical_entries​

The historical_entries parameter specifies how many of these snapshots the blockchain should retain. The primary purpose of maintaining historical_entries is to facilitate the IBC protocol and other mechanisms that need to verify the state at a specific block height in the past (e.g., "historical_entries": 10000).

bond_denom​

The denom of the token required for delegating to a Governors (e.g., "bond_denom": "stake").

min_commission_rate​

This is the minimum percetage that a Governor must charge delegators for participating in governance ("min_commission_rate": "0.05"). This may help in reducing centralization of 0% commission providers.