State
#
Constants#
LIDO_VERSIONThis byte specifies the version of the Solido state.
#
LIDO_CONSTANT_HEADER_SIZEThis defines the size of the header of the Solido state.
The header size should be equivalent to the following:
- the size of the version byte
- the size of the manager and st_sol_mint public keys
- the size of the st_sol_total_shares which is an stLamports struct
- the size of the sol_reserve_authority_bump_seed and the deposit_authority_bump_seed
#
LIDO_CONSTANT_FEE_SIZEThis defines the size of the fee section of the Lido state.
This should be equivalent to the following:
- the size of the FeeDistribution struct
- the size of the FeeRecipients struct
#
Types#
ValidatorsThe validators type uses the AccountMap struct and the Validator struct to create a helper type to assist in dealing with the collection of validators needed for the Soldio state.
#
MaintainersThe Maintainers type leverages a type alias, AccountSet, for an AccountMap with a unit type.
#
Structs#
LidoThis is the main structure for maintaining the Solido state.
#
Implemented functions on Lido#
calculate_sizeThis function calculates the size of the Solido state if it had the maximum number of validators and maintainers.
#
calc_pool_tokens_for_depositThis function calculates the correct amount of pool tokens, stSOL, for a given stake deposit in SOL.
#
is_initializedChecks if the instance of Solido has already been initialized.
#
check_mint_is_st_sol_mintConfirms that the passed mint account is indeed Solido's expected stSOL mint.
#
check_is_st_sol_accountConfirms that the given account is an SPL token account with our stSOL mint as mint.
#
check_managerChecks if the passed manager is the same as the one stored in the state
#
check_maintainerChecks if the passed maintainer belong to the list of maintainers
#
get_reserve_accountThis function returns the address of the reserve account, i.e. the account where SOL gets deposited to.
#
check_reserve_authorityConfirms that the reserve authority passed does in fact belong to this Solido instance.
#
ValidatorThe validator struct maintains the data regarding each validator that is required to generate staking accounts and maintain the fees due.
#
Implemented functions on Validator#
find_stake_account_addressThis function finds a stake account associated with a given validator vote account.
This function wraps the Solana
Pubkey::find_program_address
. That function tries to find a valid program address and its corresponding bump seed which must be passed as an additional seed when callinginvoke_signed
. The processes of finding a valid program address is by trial and error,and even though it is deterministic given a set of inputs it can take a variable amount of time to succeed across different inputs. This means that when called from an on-chain program it may incur a variable amount of the program's compute budget. Programs that are meant to be very performant may not want to use this function because it could take a considerable amount of time. Also, programs that area already at risk of exceeding their compute budget should also call this with care since there is a chance that the program's budget may be occasionally exceeded.
Additional Note: The underlying Solana program function will panic in the very unlikely event that the additional seed could not be found.
#
FeeDistributionThe FeeDistribution struct simply maintains the ratios of distribution between the treasury, developer (Chorus One), and the validators.
#
FeeRecipientsThe FeeRecipients struct is another simple struct that holds the Pubkey addresses of the treasury and developer (Chorus One) accounts that will receive fees.