How will staking work on Babylon? | The Radix Knowledge Base

This page refers to features planned for the Babylon version of the Radix network, coming in July 2023, and may not apply to the current Olympia network version. For more information about the Radix roadmap, click here. To learn about other core capabilities of Babylon, return to Start Here! Upcoming Babylon Concepts and Technologies.

As with Olympia, the purpose of staking is to secure the network. However, with the existence of application-level “Validator components”, the mechanics of staking are changing, and the good news is that it’s all upside for the user.

In short, staking is much easier to manage (it’s all done from a web page which can set up the appropriate transaction, and you just need to approve in your Radix Wallet), it’s easier to understand when unstaked XRD will be available again, and the act of staking returns liquid tokens which you can freely transfer or make use of as you see fit.

Staking

Staking XRD no longer requires a special system call—it's nothing more than sending XRD to the stake() method on a validator component.

In order to stake, a user visits a web page dedicated to this activity. One will be included with Radix Dashboard (which in Babylon replaces Olympia’s Radix Explorer), but third-party staking sites are quite easy to create. The site will translate the user's staking intent to a transaction manifest transferring the desired amounts of XRD to one or more validator components.

When receiving XRD via the stake() method, validator components add it to their pool of staked XRD, and mint an appropriate quantity of their Liquid Stake Units (just like a standard LP token, for those familiar with the concept from Uniswap and other DeFi applications). These tokens are returned to the staker, and the Radix Wallet will be able to recognize these tokens and show their current redemption value in XRD.

Liquid Stake Units are normal fungible resources, and specific to the component which generated them. That is, tokens generated by Alice's validator will have a different resource address than the tokens generated by Bob's validator.

Liquid Stake Units contain metadata showing which validator component they are associated with (and vice versa). This metadata is locked and can not be altered, so it’s not possible to fake this association.

Unstaking

To unstake, a user simply sends a quantity of Liquid Stake Units to the appropriate validator component's unstake() method.

The validator component calculates the appropriate amount of XRD and moves it to a separate "unstaked" pool. It then burns the Liquid Stake Units, mints a non-fungible claim token, and returns it to the unstaker. The claim token has embedded data which details the expected amount of XRD it can be exchanged for, and the time after which it can be claimed (calculated using the network-wide unstaking delay). As long as the validator does not undergo a slashing event during the unstaking period, the amount of XRD it redeems for will be exactly as specified.

Once the unstaking period has passed, the claim token can be sent back to the validator component, which will burn it and return the appropriate amount of XRD from the "unstaked" pool.

The Radix Wallet will be able to recognize these claim tokens and warn the user when XRD is eligible to be claimed from one or more validators, and set up the appropriate transaction for approval, making this second step a snap.

Emissions

XRD is emitted at the end of each epoch by allocating it to the validator set, just as with Olympia.

The system will calculate the amount each validator is due, and use a system badge to call a method on each related validator component which simply deposits additional XRD into the “staked” pool, without affecting the supply of Liquid Stake Units. This effectively increases the value of all issued Liquid Stake Units for that validator. Validator fees are automatically taken at this time as well; the validator component simply funnels the appropriate percentage of the emissions to a separate “vault” (a container inside a component that holds resources), which can only be accessed by the holder of the validator owner badge.

This whole system is best illustrated by an example, so let’s walk through the steps.

A Practical Example

Alice’s validator component has 500 XRD currently staked to it, and 100 Liquid Stake Units (let’s shorten that to LSU here) held by various parties on the network. This means that each LSU is worth 5 XRD if unstaked (500 XRD / 100 supply = 5 XRD). Her validator fee is set at 50% (we’ll use this number to keep the arithmetic easy).

Bob comes in and stakes an additional 500 XRD. This brings the “staked” pool up to 1,000 XRD, and the contribution of 500 XRD represents 50% of the new total. Hence, the validator component will mint an additional 100 LSU and return them to Bob. This brings the total supply of LSU up to 200, of which Bob now has half. This makes sense, since his contribution makes up half the amount of XRD in the stake pool. Note that all the existing stakers are not impacted by this action…the value of one LSU is still 5 XRD if unstaked (1,000 XRD / 200 supply = 5 XRD).

Now let’s have a round of emissions, and again we’ll make the numbers artificially high for the sake of easy math.

At the end of the epoch, the network rules determine that Alice’s validator is due to earn 10 XRD from emissions. The system creates 10 XRD and calls the system-access-only deposit method on Alice’s validator component, sending in that bucket of XRD. The logic of the deposit method sees that her fee is set at 50%, so it takes 5 XRD and sets it aside in a separate vault, where Alice can claim it at any point in the future. The remaining 5 XRD goes to the “staked” pool, bringing the pool total up to 1,005 XRD.

The supply of LSU has not changed, but since there is more XRD in the pool, the value of each LSU associated with Alice’s validator goes up. The new value is 5.025 XRD per token (1,005 XRD / 200 supply = 5.025 XRD). Bob still has the same number of LSU as before (100), but if he unstakes it all he’ll receive 502.5 XRD (2.5 more than he initially staked).

If Bob does unstake everything, again this won’t impact the other stakers. 502.5 XRD will be moved to the “unstaked” pool (to be later claimed by Bob), and the 100 LSU he sent in will be burned. Alice’s validator component will then have 502.5 XRD (1,005 XRD - 502.5 XRD unstaked = 502.5 XRD), and a supply of 100 LSU (200 before unstake - 100 burned = 100). Each LSU will still be worth 5.025 XRD per token, as expected (502.5 XRD / 100 supply = 5.025 XRD).

No need to internalize that whole process! Suffice to say, Liquid Stake Units from validators which are earning emissions will earn their proportion of those rewards, regardless of where and how they are held, and the staking/unstaking actions of others on the same validator won’t impact the value.

Owner Stake

In Olympia, validator node-runners could designate a specific address as their personal account, and any XRD staked from that account would show up as part of the owner stake in the validator list—a public way to show that the owner had “skin in the game” and would suffer the same lack of emissions as their stakers if the node missed proposals.

The existence of Liquid Stake Units means the representation of stake is transferable, and so this same goal is achieved by allowing the owner to lock some or all of their stake to their node, if they so choose. The validator component includes a method available to the owner which will accept a deposit of Liquid Stake Units, preventing them from being transferrable and for which the owner must undergo a similar process to unstaking in order to withdraw them again (that is, they will issue a request to remove some number of them, those tokens will be placed in a holding vault, and they will receive a claim NFT. Then they must wait until a certain amount of time has passed before they can reclaim them. This delay will likely be the same as the network-wide unstaking delay, though this is not finalized).

The balance of these locked Liquid Stake Units in a validator component is the Babylon equivalent of “owner stake.” Naturally, such tokens continue to benefit from network emissions while they are held in the validator component, because the underlying pool of XRD is growing.

Q&A

Why not just have some universal “stXRD” shared across all validators?

Because validator fees, validator performance (which impacts emissions), whether or not a validator is in the active validator set, and slashing all mean that where XRD is staked matters. Don’t think of 1 Liquid Stake Unit as 1 staked XRD; that’s not what they represent. They represent your portion of the total XRD staked at the associated validator component. LSU are therefore non-fungible across validators.

So Liquid Stake Units are going to be completely fragmented, with every validator component issuing its own supply?

From the base network perspective, they have to be. However, in Scrypto it’s quite straightforward to set up a component which aggregates Liquid Stake Units from different validators and releases its own single stake token based on those holdings.

For example, a component could accept Liquid Stake Units, check the current XRD value with the associated validator component, and mint an appropriate amount of an aggregate token. Such a component could accept any Liquid Stake Unit, or the owner might be selective about which ones it accepted. For example, the component’s owner might decide to only accept the tokens associated with validators that they felt met a certain quality of service standard.

How can I distinguish between stake that I personally added to a validator and stake that I acquired through other means?

You can’t. There’s no longer a link between an amount of stake on a validator and a particular account. If knowing such a thing is important to you, and you participate in activities other than staking which result in you acquiring Liquid Stake Units, you’ll have to reconstruct that information from your transaction history, use separate accounts, or take advantage of a service which does it for you.

Wait, the XRD actually leaves my account when I stake…is this safe?

Yes. The behavior of the validator component which receives the XRD is defined within the Radix Engine, and its logic can not be modified by node-runners or other users. Additionally, validator components exist in a separate address space which is easily recognizable to both humans and tools, and it’s impossible to put user-created components into this same address space to try to masquerade as a real validator component.

Will there still be a validator list that I can see, with all the various details, so I can make staking decisions?

Of course! It’ll be even better, because it’s easy for the page to also set up the staking transaction for you—you won’t have to copy/paste from the web page to your wallet like you did in Olympia when you wanted to stake. You’ll just review the transaction in your wallet and sign.

Further reading:

‍