(Re)Delegations in the Cosmos Hub

by All in Bits (Tendermint Inc)

Note: The Cosmos ecosystem is constantly growing and expanding. This article content is now outdated. For the latest content, see https://cosmos.network/.

The delegation of ATOMs to validators within the Cosmos Hub is a critical and vital part of the underlying security of the Hub that every ATOM holder is encouraged to partake in. As a delegator, having your ATOMs staked amongst a series of validators gives you a set of unalienable rights such as being able to participate in consensus, governance, and earn inflation rewards. This post is not meant to be an in-depth review of the mechanics of the Cosmos Hub or of the BPoS protocol, but rather a concise high level overview of (re)delegations and some of limitations and restrictions to keep in mind when performing them.

What are Delegations Anyway?

The Cosmos Hub utilizes Tendermint as the underlying BFT consensus engine and uses a BPoS protocol for block proposer elections, where each proposer (validator) is weighted according to their relative total bonded stake and where a validator’s total bonded stake is directly correlated to their chance to propose a block and the amount of rewards they receive for doing so. The protocol supports a fixed number of bonded validators [1].

These validators can self-bond, meaning they can delegate ATOMs to themselves, and they can also receive delegations from any other atom holder. These bonded ATOMs acts as collateral and cause each delegate, including validators, to have “skin in the game” so to speak. If any equivocation or byzantine behavior by a validator were to be committed, the validator and its delegates would be slashed a percentage of their relative total bonded stake.

Delegates may have many reasons to delegate their ATOMs. First and foremost, delegates and validators receive rewards each block that are proportional to their total amount of bonded stake per each validator they’re bonded to. Secondly, it directly contributes to the security of the entire network. Of course delegates and validators themselves may choose to unbond their ATOMs for a variety of reasons.

However, it is important to note that these ATOMs are subject to what is known as the UnbondingPeriod[2], an on-chain parameterized period of time upon which all delegates, including validators, must wait for their ATOMs to become fully unbonded. Until the UnbondingPeriod has passed, the ATOMs are essentially locked. In addition, these ATOMs are still subject to be potentially slashed upon commitment of any byzantine behavior. The UnbondingPeriod ensures a variety of security measures in the network, such as accounting for network synchrony assumptions, providing a lower bound for the length of a long-range attack [3] and solving the “nothing-at-stake” problem.

Before we dive into some of the constraints and finer details to consider when delegating, we’ll need to also define what a redelegation is. A redelegation is simply a “rebonding” or moving a portion (or full amount) of your staked ATOMs from one validator to another. This can be beneficial for a number of reasons. For example, if a delegator is no longer happy with the services or commission rates the validator is providing, then they may decide to move their bonded ATOMs to another validator without having to wait the full unbonding period to make the switch. However, there are some limitations and we’ll discuss those below.

(Re)Delegation Constraints

So now that we have a decent understanding of the role (re)delegations play in the network and the UnbondingPeriod they are subjected to, let’s take a look at some of the finer details to consider before performing them. As we’ve mentioned previously, bonded ATOMs are subject to an UnbondingPeriod. In addition to this, there is another on-chain parameter of importance, namely MaxEntries[4]. The MaxEntries parameter pertains to the total number of:

• Unbondings between a unique delegator and validator pair
• Redelegations between a unique delegator, source validator, and destination validator tuple

The concept of “entries” are used in the Cosmos Hub state machine to hold information between a delegator, the unbonding amount, and the corresponding validator(s). From the perspective of a user, they are mostly abstracted away.

To illustrate this better, we’ll use the following example. Assume a delegator D has bonded N ATOMs to validator X. Of course D could have other delegations of varying amounts to other validators, but for this example we’ll only consider a single validator. Now delegator D wishes to undelegate some of her staked ATOMs from X, so D sends a MsgUndelegate tx unbonding M ATOMs. This creates an “entry” in the ledger’s state machine between D and X. Going forward if D wants to further undelegate some more staked ATOMs from X, she’ll send another MsgUndelegate tx. However, D can only do this up to MaxEntries times! Any further attempts will yield the following error:

too many unbonding delegation entries in this delegator/validator duo, please wait for some entries to mature

So delegator D will have to wait the full UnbondingPeriod before she can attempt to undelegate any more staked ATOMs from validator X.

For redelegations, the same concept applies. In other words, if delegator D wishes to redelegate some of her staked ATOMs from validator X to another validator Y, she can only do this up to MaxEntries times. Note, for redelegations this is per unique delegator, source validator, and destination validator tuple.

There is one other important key factor to note about redelegations and that is that “transitive” redelegations are prohibited. Transitive redelegations can be seen as “hopping” from one validator to another. For example, if delegator D redelegates to validator X and then wants to further redelegate from X to another validator Y. Delegator D would have to wait the full UnbondingPeriod period to do this. However, it is advised not to delegate to a single validator only, so this restriction should not be a problem in most cases. This is also not to say that transitive redelegations will always be prohibited. In the future they may be enabled but with a cap on the total number of “hops”. Perhaps this will come through a governance proposal?

Slashing

Another critical aspect to keep in mind when performing (re)delegations is slashing. As a delegator, any stake that you have in a validator that is either bonded or in the process of unbonding is liable to be slashed if the given validator performs an equivocation or any other punishable byzantine act during a period in which the infraction is “valid” [5]. For further details on slashing, please review the spec.

With regards to redelegations, there are a few important things to keep in mind. Given our previous example where delegator D redelegates some of her stake from validator X to another validator Y, delegator D is still liable to both validators! Expanding upon this example, assume some infraction occurred at height H₁ by validator X (the original/source validator) and was later discovered and submitted at H₂. Delegator D would only be liable to be slashed if both of the following conditions are true:

• The redelegation was created after the infraction at height H₁
• The redelegation is not mature (ie. the completion time is after height H₂)

If the destination validator, Y in this case, committed the infraction under the same conditions, then it’s treated no differently than a regular delegation slashing event as described above.

Hopefully you now have a decent understanding of (re)delegations, the role they play in the Cosmos Hub BPoS network and some of limitations and restrictions to keep in mind when performing them. Happy delegation!

The views and details expressed in this blog post are those of All In Bits Inc (dba Tendermint Inc), and do not necessarily represent the opinions or actions of the Interchain Foundation.