Alliance 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.
The following is an in-depth look at how the Alliance module is able to stake Alliance assets. For a general overview of Staking and the Alliance module, visit the How Alliance works page.
Reward weight
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 the amount of staking rewards a staked Alliance asset will generate in proportion to a natively staked coin. A chain’s native staking asset always maintains a reward weight of 1. This amount is referred to as the "total reward power" of an asset, denoting the proportion of staking rewards an asset will receive.
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 amount of staking rewards received by the entire staked supply of Ally 1 will be equal to the amount of the entire staked supply of the native asset. Each asset will receive 50% of the total consensus rewards.
If another token (Ally 2) is added to the chain with a reward weight of .5, the reward weight percentages change in relation to the whole, but their proportions remain the same. The native staking asset will receive 40% of the rewards, Ally 1 will receive 40%, and Ally 2 will receive 20%.
The following illustration demonstrates the consensus and reward power of different assets relative to their reward weights.
RewardDelayTime
In addition to the RewardWeight parameter, Alliances assets are subject to a RewardDelayTime. This module parameter defines the amount of time users have to stake their new Alliance assets before the consensus power of the Alliance 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. When a new Alliance asset is whitelisted by governance, the RewardDelayTime period begins, and users must wait until the end of the period to start earning rewards.
Staking
The Alliance module does not require major changes to any native modules. To users, staking an Alliance asset is as seamless as staking a native asset. 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.
The default staking parameter for most Cosmos chains is 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 the 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. The Alliance module mints or burns native tokens as needed to ensure delegation records are always current and reflect the reward weight proportions. The Alliance module account is the technical owner of all the native tokens it mints. This method of staking ensures compatibility with Cosmos-SDK chains and does not require any changes to existing Cosmos modules. Native stakers use the x/staking module to stake their native assets, and Alliance assets are staked using the x/alliance module.
Governance
Although Alliance asset delegators can earn a portion of rewards, they cannot vote on governance proposals using staked Alliance assets. The native coins minted by the Alliance module that represent the reward power of Alliance assets are owned solely by the Alliance module, and therefore cannot be used by delegators to specify votes. Only delegators who stake native assets directly to validators can participate in governance.
By default, Alliance assets cannot be used 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.
The Alliance module does not change consensus or the standard governance role of staked native coins owned by delegators. Delegators that stake native (non-Alliance) assets directly to validators can always participate in governance using the existing 1 staked native coin = 1 vote standard.
Rebalancing
To maintain the reward weight 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 reward power of validators proportional to the RewardWeight parameters. Alliance assets can never have more reward power than their specified reward weights, even if the supply of Alliance assets exceeds the supply of a native asset.
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 reward 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.
Reward power rebalancing
Rebalancing is calculated using a proportion of each Alliance asset’s reward power, specified by the asset’s RewardWeight. In consensus, one staked native coin is equal to one vote. Therefore, the total reward 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 reward 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 reward power when the staked supply of the native token changes. This example shows staking pools as total amounts across all validators. Note that the reward 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 reward 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 reward power proportion for assets must remain constant, the reward power of individual validators will vary depending on the size of their stake. To calculate the reward 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 reward power staked to a validator for a specific asset.
The following example shows the reward 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.