solana: Raise stake minimum delegation

From my data

• 97,722 accounts have an active stake below 0.001 SOL (1m lamports) and
• 116,060 accounts have an active stake below 0.01 SOL (10m lamports) and
• 138,685 accounts have an active stake below 0.1 SOL (100m lamports)
• 225,179 accounts have an active stake below 1 SOL (1bn lamports)

total stake accounts are 587,000

Setting a stake delegation of 0.1 SOL or even 0.01 SOL would also achieve a significant reduction with less of a burden on small users and be more future compatible for changes in the SOL price affecting people’s ability to create accounts meeting the min delegation.

1 SOL is arbitrary, as are all numbers, but sub-1 SOL accounts account for 38.3% of stakes, while sub 0.1 SOL accounts account for 23.5% of stakes, while being a 10x reduction in min delegation amount.

At the same time the underlying issue of rewards computation shouldn’t depend on us having to continuously artificially reduce the number of stake accounts somehow.

My vote is for 0.1 SOL = 100m lamports.

(Edited to add more data:

Everstake has 51k stakes with active stake <1 SOL, might be worth reaching out to Exodus about how they prompt users on stake creation.

Chorus and and stake.systems have 45k accounts between them which have an average active stake of < 0.05 SOL in aggregate. For Chorus the avg stake of these accounts is incredibly low at 0.029 SOL.

The top 4 validators by delegated stakes <1 SOL account for 113,500 stake accounts, or over 50% of all stakes below 1 SOL.

Top 50 validators sorted by no of accounts delegated with active stake < 1 SOL attached.

All numbers are on active (delegated) stake, and exclude rent exempt reserve and deactivated stake accounts.

For anyone wishing to parse the data themselves, solana stakes mostly times out due to inefficient encoding, this gPA call returns in ~15 seconds all accounts with parsed data:

curl https://ssc-dao.genesysgo.net/ -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getProgramAccounts", "params":["Stake11111111111111111111111111111111111111",{"encoding":"jsonParsed"}]}';

/end more data)

I ran some queries using the postgres accounts db plugin:

number of stake accounts:  506,580
number of stake pool accounts: 607

size of stake account:       200 bytes
size of stake pool account: 4008 bytes

stake account rent exempt minimum:      0.00228288 sol
stake pool account rent exempt minimum: 0.02878656 sol

number of stake accounts at minimum balance:   188
number of stake accounts <       0.01 sol:  65,723
number of stake accounts <       0.1  sol:  97,993
number of stake accounts <       1    sol: 151,536
number of stake accounts <      10    sol: 288,877
number of stake accounts <     100    sol: 401,489
number of stake accounts <   1,000    sol: 499,528
number of stake accounts <  10,000    sol: 502,783
number of stake accounts < 100,000    sol: 505,391

Running some queries with Geyser:

solana=> SELECT COUNT(*) FROM account WHERE owner = E'\\x06a1d8179137542a983437bdfe2a7ab2557f535c8a78722b68a49dc000000000' AND lamports < 1000000000;
count | 537899

solana=> SELECT COUNT(*) FROM account WHERE owner = E'\\x06a1d8179137542a983437bdfe2a7ab2557f535c8a78722b68a49dc000000000';
count | 587209

Number of stake accounts with lamports < 1 SOL = 537,899 Number of all stake accounts: 587,209 Percentage of stake accounts with lamports < 1 SOL is about 91.6%

I know you’re already taken the sysvar approach but what about making use of the new return value feature instead to get the minimum value? The stake program could have a get_minimum_delegation instruction which returns the value. I prefer this approach because it requires less work than setting up a new syscall to get the sysvar value.

How valuable—is it really—to raise the minimum delegation amount?

It’s valuable because it gives validators a way to limit the amount of epoch boundary calculations they need to do to deliver rewards to stakers (https://github.com/solana-labs/solana/issues/20384). I’m less worried about the account data size because rent fee adjustments can be made if account data gets too large. We just don’t have any knobs to turn if the number of stake delegations grows large at the moment.

How valuable is a true governance vote w.r.t. handling the raise?

Valuable because it’s up to the network to decide how staking economics change. Why do you bring this up? Implementation can make use of the feature proposal program as you’ve already outlined in the issue tasks.

How valuable is a new-style sysvar (one that’s not in an account)?

In my opinion, not too valuable. I’d prefer we move quicker to add the ability for the cluster to counteract excessive stake delegations without blocking on new runtime functionality like account-less sysvars.

Sysvar make sense, and one that is not supported by account passing, just .get()

A sysvar would be useful for programs (like stake pool programs) so they can read the current minimum balance from the cluster instead of hard coding it

Sorry the CLI isn’t very clear on this in its help text – if a split-stake operation is done, does it have to be to a new stake account? Or can it be into a stake account in the same state (active/not active) and delegation (either both not delegated, or both delegated to the same validator)?

If it must be a new stake account, then a minimum of 1 SOL in a stake account would mean that it’s not possible to split-stake off less than 1 SOL. I think this would be a big issue, because users who want to profit-take on their own schedule would be unable to do so.

a question that came up from a wallet team regarding what happens to existing stake accounts that are below the minimum stake threshold, recording here for posterity:

from @brooksprumo:

All existing stake accounts are grandfathered in. No accounts will change, there will be new checks in the instructions, which would prevent new delegations of < 1 SOL

and one that is not supported by account passing, just .get()

@jackcmay Does that mean not implementing Sysvar?

Yeah, I would implement get via impl_sysvar_get and not the Sysvar trait. This would be the first to do it so you might run into funnyness.

@t-nelson Is there an existing versioned struct somewhere already that I can look at/use as reference?

Nonce and vote accounts are both versioned https://github.com/solana-labs/solana/blob/ae76fe2bd74ab0b7ef579486f8034380ccdc7df2/sdk/program/src/nonce/state/mod.rs https://github.com/solana-labs/solana/blob/ae76fe2bd74ab0b7ef579486f8034380ccdc7df2/programs/vote/src/vote_state/vote_state_versions.rs

sysvar sgtm. i’d suggest that we avoid some of the pains of the past and think forward. assume we’ll extend it in the future, so wrap it in a versioned StakeProgramConfig struct.

Or is it possible to have a governance vote, and then change the constant after the fact? (I’m assuming ‘no’, but want to verify.)

It’s certainly possible but that’s not great. The stake program can check whether the feature is enabled itself actually, the bank doesn’t need to tell it. Such a feature could be enabled by the workflow that the feature-proposal program provides

You are proposing that people who have less than $1,400 (at the time of writing) don’t get to stake directly — they don’t get to make an independent choice of what validator they stake with? That sounds like it would be bad for censorship-resistance to me.

Of course it would be good for stake pools — indeed the high barrier to direct staking is one of the reasons that Lido is successful on Ethereum — but I think it’s important that users can make an independent choice if they want to.

Any limit can be reduced as code is improved to safely support more stake accounts

Would this need a governance vote too? If yes, how does that process work?

Probably with this: https://spl.solana.com/feature-proposal

Instead of a core contributor holding the private key for a feature activation, we can use a PDA from the feature proposal program.