How will validator management work on Babylon?

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.

Validator management is moving up the stack to the application level, with a clean separation between how the validator is configured (with regard to name, fees, etc.) and the actual running node. This has some important benefits, most notably:

Validator nodes no longer need a built-in wallet function with their own XRD balance and a special-purpose interface to interact with the ledger
Signing keys can be rotated at will, and are no longer restricted to a single key for life
Node-runners can take advantage of the full metadata system to provide additional information about their node
It’s significantly easier to have multiple people able to safely administer the validator settings, without needing access to the associated node
Scrypto components can easily perform validator-related actions such as staking and unstaking.

Creating a Validator Component

Node-runners wishing to act as validators begin by first getting a full node synchronized to the network.

With their node functional, the node-runner must then create their on-ledger “Validator component”. To do so, they visit a web page which can assist with this process and connect their Radix Wallet. The Radix Dashboard (which in Babylon replaces Olympia’s Radix Explorer) will include such a page, though the community is free to create others.

To create a validator component, two things are needed: the public key associated with the node, and a badge which will serve to authorize all administrator interactions with the component. The public key is easily viewed on the node itself, and can be copied over. For the badge, the node-runner can create a token specifically for this purpose (again, a page to facilitate such creation is present in Radix Dashboard), or they might choose to reuse one that they have already created for other purposes. Regardless of the node-runner’s decision, they can safely store the badge in a smart account, gaining the benefits of Babylon’s powerful account recovery model.

After filling in the public key and selecting the appropriate badge, the web page creates a transaction manifest which will create the validator component and sends it on to the node-runner’s wallet. The node-runner reviews and approves the transaction, paying the fee out of one of their accounts. Unlike Olympia, validator registration transactions (or any other configuration transactions) are not run from the node itself. The node no longer has an incorporated account which can hold tokens; all such actions are now run through the node-runner’s normal wallet.

Once the transaction is submitted and confirmed, the node-runner receives back the address of their shiny new validator component. They then go back and add this address to their node’s configuration file, and then restart the node. From this point on, the node will always represent itself as that address, regardless of what signing key it is configured to use.

Managing a Validator Component

With the validator component created, the node-runner is now able to manage the settings and actions that the network, and potential stakers, care about, such as:

Toggling whether or not the node is currently interested in acting as a validator
Setting or updating metadata like the name, URL, organizations it might be associated with, etc.
Changing the fee
Toggling whether or not additional stake should be accepted
Changing the signing key that should be associated with the validator (this takes effect in the next epoch)
Claiming accrued fees.

As with creation of the component, managing these settings is all easily accomplished through a web page, which will set up the correct transaction manifest to review and approve in the Radix Wallet. All of these actions require the presence of the owner badge which was initially specified, so the general public has no access.

More to Come

Additional information on the specifics of configuring and managing a validator will be added to the technical documentation in the months to come.

Further reading:-

‍