Voting power and staking
Alliances assets can be added to new chains prior to genesis. In order to add an Alliance asset to an existing chain, you’ll need to specify the asset’s parameters and create a governance proposal. Visit the integration guide for more information on adding an Alliance asset.
RewardWeight and voting power
To preserve the role of a native staking asset and to prevent the power dilution of a chain's native assets, each Alliance asset added to a chain is given a RewardWeight. This parameter determines how much consensus voting power a new Alliance asset has in proportion to the natively staked token. A chain’s native staking asset always maintains a reward weight of 1.
Example:
A chain with the Alliance module enabled has two assets: a native staking asset and an Alliance asset named Ally 1. If Ally 1 has a reward weight of 1, the voting power of the entire staked supply of Ally 1 will be equal to the total voting power of the entire staked supply of the native asset. Each asset will have 50% of the voting power.
If another token (Ally 2) is added to the chain with a reward weight of .5, the percentages of voting power change in relation to the whole, but their proportions remain the same. The native staking asset will have 40% of the power,Ally 1 will have 40%, and Ally 2 will have 20%.
The following illustration demonstrates the voting power of different assets relative to their reward weights.
RewardDelayTime
In addition to the RewardWeight parameter, new Alliances can also specify a RewardDelayTime. This parameter defines the amount of time users have to stake their new Alliance assets before the voting power of the new asset is applied to the chain. This delay prevents early stakers from gaining outsized rewards with a relatively small total stake of a new Alliance asset. The default setting for this parameter is one week.
Staking
The Alliance module does not require changes to any native modules. To users, staking an Alliance asset is as seamless as staking a native asset. The only difference is that delegators cannot use Alliance assets to participate directly in governance. Delegators can stake, unstake, redelegate, or earn rewards with an Alliance asset just like they can when staking a native asset. All the underlying logic behind Alliance assets is fully contained within the x/alliance module, which works in tandem with the other Cosmos modules.
Cosmos chains are built to only have one native staking asset. In order to preserve the functionality of Cosmos-SDK modules, the Alliance module does not stake Alliance assets directly to validators. Instead, the module keeps track of all Alliance asset staking accounts, and mints a proportional amount of native tokens. These tokens are then staked to a validator on behalf of a delegator. Whenever Alliance assets are staked, unstaked, or redelegated, the Alliance module performs all these actions in the background using the chain’s native asset, minting or burning as needed to ensure staking amounts are always current. This method of staking ensures compatibility with Cosmos-SDK chains, and does not require any changes to existing Cosmos modules. The Alliance module account owns all delegations in custody of stakers and keeps a record of all staked assets. Native stakers use the x/staking module to stake their assets, and Alliance assets are staked using the x/alliance module.
Although the term "voting power" is used to describe consensus and staking power for validators, delegators cannot vote on governance proposals using staked Alliance assets. The native coins minted by the Alliance module that represent the power of Alliance assets are owned solely by the Alliance module, and therefore cannot be used by delegators to specify votes.
Alliance delegators do not participate directly in governance; however, their underlying staked native assets are still used in consensus and governance by validators. In the Cosmos governance process, validators vote with their entire stake, including the staked native assets owned by the Alliance module. This process is called inheritance.
Rebalancing
To maintain the voting power proportions between native and Alliance assets, the Alliance module updates its staking delegations by minting and burning native coins. This process is called rebalancing. The rebalancing of the staked supply of assets updates the voting power of validators proportional to the RewardWeight parameters.
The following example shows how the Alliance module stakes native assets on behalf of delegators, in order to preserve the reward weight ratio. With a reward weight ratio of 1:1:1, the voting power between all assets is equal, regardless of any particular asset’s staked supply.
To conserve computing resources, rebalancing only occurs when there is a change in delegations, at most once at the end of a block. If there is any change in delegations during a block, the Alliance module will update its staking proportions to ensure that validator delegations reflect the state of staked assets. For more information on the rebalancing process, visit the State transitions page.
Voting power rebalance
Rebalancing is calculated using a proportion of each Alliance asset’s voting power, specified by the asset’s RewardWeight. In consensus, one staked native coin is equal to one vote. Therefore, the total voting power of staked Alliance assets must be proportional to the number of native coins staked. If an Alliance asset has a reward weight of 1, the total voting power of the Alliance asset’s staked supply is always equal to the number of staked native coins, regardless of the Alliance asset’s supply.
The following example illustrates the rebalancing of voting power when the staked supply of the native token changes. This example shows staking pools as total amounts across all validators. Note that the voting power proportions set by the reward weight must always be constant with the supply of the native staked asset, regardless of the supply change of Alliance assets.
Calculating a rebalance
The following equations illustrate how voting power is calculated during rebalances.
Because all votes are based on a 1 staked native asset = 1 vote constant, the total number of votes possible for all assets can be calculated by multiplying the sum of reward weights by the total number of staked native assets.
In order to calculate the total number of votes for a specific asset, the reward weight of that asset can be multiplied by the total number of staked native tokens.
So far, the previous equations describe values for the total staking pools of assets shared across all validators. Although the total voting power proportion for assets must remain constant, the voting power of individual validators will vary, depending on their proportion of the total staked supply. To calculate the voting power of an asset staked to a specific validator, the ratio between the asset amount staked to a validator and the asset’s total staked supply is multiplied by the asset's total votes. This product will determine the voting power staked to a validator for a specific asset.
The following example shows the voting power rebalancing of a staked Alliance asset (AL1) when a user redelegates from one validator to another. Note that the total supplies of staked assets remain constant.
For more information on the rebalancing process, visit the State transitions page.