Validator onboarding
This page is aimed at validators who want to join Lido for Solana.
Note for validators
If you have already been admitted by the LNOSG, please continue to Setting up a vote account below.
#
Validator admissionThe set of validators who participate in Lido for Solana (“Solido”) is managed by the Lido Node Operator Subgovernance Group (LNOSG), which is part of the Lido DAO. The Lido Node Operators Notion page contains further information about the current operators, and how to apply.
After approval from the LNOSG, the steps to onboard a validator to Solido are:
- The validator sets up a new identity account and vote account for use with Solido.
- A multisig owner creates a multisig transaction to propose adding the vote account to the validator set.
- The other multisig owners approve this transaction and execute it. At this point, admission of the validator should already have been approved by the LNOSG; the multisig owners merely ratify and execute the decision, they do not make an independent decision about which validators to admit.
- Once the validator is part of the Solido validator set, the Solido maintenance daemon will automatically rebalance the stake and delegate to the new validator. In version 1, only new deposits can be staked with new validators; we plan to add active rebalancing in a later version.
- Some validators are expected to operate an instance of the maintenance daemon.
The remainder of this page goes over step 1 in detail. For steps 2 and 3, see the multisig guide instead.
#
Setting up a vote accountSolido requires validators to use a dedicated identity and vote account for use with Solido. See the commission page for the rationale behind the separate vote account. A separate identity account is needed to clarify that the vote account is part of Solido, to distinguish it from the validator’s public public vote account.
We will assume that you are familiar with setting up a Solana vote
account, and that you have created a new vote account keypair and
identity keypair. For simplicity, we’ll asume they are in files in
~/.config/solana
below, but Solana supports hardware wallets as well.
We need to create an vote account with 100% commission, and the withdraw
authority set to Solido, so first we need to know the withdraw authority.
Assuming solido
is configured, show-authorities
will print the
withdraw authority:
For the mainnet-beta deployment shown above, the withdraw authority is
GgrQiJ8s2pfHsfMbEFtNcejnzLegzZ16c9XtJ2X2FpuF
.
info
Because the authority addresses are derived from the program and instance
addresses, show-authorities
can compute them even when the program has not yet
been deployed, as long as the address where it will be deployed is known. For
existing instances, show-solido
will also show the authorities, and more
information about the instance.
Create a new vote account with that authority and 100% commission, and confirm:
In this case, EAsHKTdxL9GELqQatEFFe3mbSBcbxyEiA8yoPihGhoM6
is the vote account
address, which we need for the final step.
#
Configuring the validator identityAs a validator, you now have two or more vote accounts:
- A public one that anybody can delegate to.
- One for Lido for Solana with 100% commission, that only the Solido program is expected to delegate to.
To distinguish these two in validator lists such as
https://solanabeach.io/validators, we ask you to use a separate validator
identity account for the Solido vote account. Set the name of your validator to
“Lido / «your-name»” with solana validator-info
, and link
your Keybase account. For example, for Chorus One, we would run
Then upload the public key of your identity account to Keybase, as described in this Solana guide.
note
Be sure to fund the identity account as well, as it pays for the votes.
#
Setting up a fee accountIn addition to the vote account, we need an SPL token account that can hold
stSOL, to receive validation fees. For this we need to know the stSOL mint
address. For an existing instance, we can use show-solido
to confirm, but for
mainnet-beta prior to initialization, show-solido
cannot show anything yet.
Instead, we created the SPL token mint ahead of time, and we will initialize the
instance with this mint address. The mint address for mainnet-beta is listed
on the deployments page. For an existing instance,
show-solido
displays the mint address:
Create an account, and make it owned by an account that you have the private key
for (6S21...
in the example below):
This created stSOL account 3gD74tkT4NAnzUT5SsiYTV5HPgML4wnjjxrxfpjaFXHk
,
which we also need for the final step.
#
Setting up a maintainer accountThis step is only needed for the validators who operate an instance of the maintenance daemon. If you are not on that list, you can skip this step.
We need to have an account for the maintenance daemon. The daemon needs to be
able to sign with this account programmatically, so it is recommended to create
a new account for this purpose, and to make sure it never contains a lot of
funds; 1.0Â SOL should be plenty to run the daemon for many months. In this
example, we’ll use account F5HwubK4v7VKazPXzRhdvHqA3MmJR5yXDoC8mXeMpdDw
.
#
Final onboarding stepPlease share the vote account, stSOL account, and if applicable, your maintainer account, with the multisig members by filling out this form. Chorus One will then prepare a multisig transaction to add your vote account to the Solido instance, and the multisig members will batch-approve these transactions periodically.
After your vote account has been added to the instance, the maintenance bot will automatically delegate new deposits to your vote account.