Stake-o-Matic Delegation Matching Program

Update 11/23: The details of this post are a bit outdated. The delegation strategy outlined here will not, initially be the primary delegation strategy of the Foundation. The initial primary delegation strategy of the Foundation is outlined here:

The “stake-o-matic” work is currently focusing on the development of the “stake-pool” contract. Ongoing development of stake pools, and the implications toward staking derivatives and auto-delegation scripts (“stake-o-matics”) can be discussed in the #token-stake-pool Discord channel.

We’d like to informally announce the Solana Foundation’s proposed delegation token matching program we’re calling the Stake-o-Matic Delegation Matching Program (“Stake-o-Match”?).

The Foundation is committed to using its token treasury for the development and growth of the Solana protocol. A major focus of this commitment is toward efforts that lead to increased decentralization and censorship resistance of the network. We hope that the “Stake-o-Matic” (SoM) token matching program will comprise a large part of those efforts.

As being actively discussed here, a metric of interest when discussing censorship resistance on proof-of-stake networks is the minimum number of distinct nodes that hold stake adding up to 33%. The SoM token matching program has been designed to provide appropriate incentives and tools such that this metric should naturally increase along with the growth of the network.

With this announcement, we’d like to encourage the community to start exploring the stake-o-matic script and kick off a discussion about the program. In the coming weeks we will provide more details about deploying and testing stake-o-matics on the Tour de SOL network!

Keep in mind that this is likely to be the main avenue for Solana Foundation delegations, so the earlier you can start exploring SoM and becoming comfortable designing and deploying them the better!

The Program, tl;dr -

The Solana Foundation will match every delegation, up to a specified percent, that a validator delegates through their own instance of the stake-o-matic program.

Stake-o-matic programs are staking scripts that automatically split and delegate tokens from a master stake account across a number of whitelisted validator nodes. The designer of each stake-o-matic implementation (you!) should optimize it in a way such that the distribution of stake increases network censorship resistance and stake decentralization.

As an example: Validator A has 1000 SOL delegated to herself from token holders. She decides to take 500 SOL and delegate it, through her modified stake-o-matic program, to other validators on the network. The Solana Foundation will match the stake-o-matic delegations up to a specified percentage. Validator A can configure her stake-o-matic program to dynamically select a group of validators to delegate to based on any quality characteristics that Validator A wants (e.g. uptime, performance, security ‘score’, commission, slashing ‘risk’, etc).

For this example, let’s assume a 15% token match, validator-level yield of 10%, that Validator A has a 10% commission set for her validator, and that all validators delegated through Validator A’s stake-o-matic also charge a 10% commission. This example is illustrated in the figure below.

Therefore, as can be seen in the figure, Validator A’s total earnings, by taking advantage of the SoM matching program, is 11.75 SOL. This should be compared to her earnings without the program. I.e. If Validator A staked the 1000 SOL herself, she’d earn 10% (commission) on the 10% yield, resulting in 10 SOL.

In this toy example, the SoM Foundation matching program has increased her earnings by 17.5% and helped increase the decentralization and censorship resistance of the Solana network at the same time. As we’ll see below, the program creates incentives for the SoM to dynamically allocate delegations to many quality nodes that retain reasonable rates while at the same time increasing the overall network value through the fortification of censorship resistance and security through stake decentralization.

While the matching program has been designed to make the act of stake decentralization economically beneficial - the real goal of this program is to make censorship resistance the flagship value proposition of the Solana Network (ridiculously fast performance aside). We want to build a culture and community that values decentralization above all else, so using programs such as stake-o-matic to ensure flat stake distributions becomes a no-brainer as it adds tangible value to the network and aligns with the communities’ values.

The Stake-o-Matic script

Solana’s stake-o-matic is a script that helps manage delegation of multiple stakes from a central source. The Solana Foundation currently has an instance of stake-o-matic deployed on Mainnet Beta that is actively managing around 75M SOL of delegations. This deployed instance of this program employs the following rules:

  1. All non-delinquent validators receive 50,000 SOL stake
  2. Additionally, non-delinquent validators that have produced a block in 75% of their slots in the previous epoch receive bonus stake of 500,000 SOL

These rules are examples of how a stake-o-matic can be programmed to manage the stakes that it is granted access to. More generally, however, stake-o-matics can deliver stakes given any number of node qualities such as historical performance, current stake, perceived slashing risk, or any other variable that might be indicative of validator quality.

By encouraging all validators to create and deploy their own instances of stake-o-matic, the Solana Foundation hopes to foster a protocol culture that values and measures censorship resistance through a network-wide system of dynamically optimized stake assignments.


Let’s revisit our initial example of Validator A, but generalize it with the following parameters

  • Initial amount of SOL delegated from token holders to Validator A (V_{A}): \bf{SOL_{\text{initial}}}
  • Instance of SoM as configured by V_{A}: \bf{\text{SoM}_{A}}
  • Amount of SOL_{\text{initial}} sent to \text{SoM}_{A}: \bf{SOL_{\text{SoM}}}
  • Validator-level yield: \bf{Y}
  • Percent of SOL_{\text{SoM}} that is matched by Solana Foundation: \bf{P_{\text{match}}}
  • VA commission rate: \bf{C_{A}}
  • Number of validators delegated SOL from SoM: \bf{N_{\text{SoM}}}
  • Average commission rate of validators delegated SOL from SoM: \bf{C_{\text{SoM}}}

We can then express some key metrics for consideration.

Validator earnings without using SoM matching program (E_{\text{No SoM}}):

Validators earn a portion of the yield produced from the delegations staked to their node, as specified by their commission rate. So

E_{\text{No SoM}}= SOL_{\text{initial}}\times Y\times C_{A}

Validator earnings using SoM matching program (E_{\text{SoM}}):

In this case, we assume that the validator splits it’s total holdings SOL_{\text{initial}} between it’s own node and the SoM. The SOL that is dedicated to SoM is matched by the Foundation to some percentage P_{\text{match}} all of which earns a yield Y. Assuming an average commission rate of the SoM delegated validators, C_{\text{SoM}}, V_{A}'s earnings come from the yield on the matched portion of the SoM delegation less the average commission rate of the SoM validators. Additionally, V_{A} has to return yield to its delegators, presumably with the commission rate that it has set for its own node accounted for. I.e. A delegator of V_A should expect yield returns minus the commission as quoted by V_A.

\begin{align*} E_{\text{SoM}} = ~&SOL_{\text{SoM}}\times (1 + P_{\text{match}}) \times Y\times(1-C_{\text{SoM}}) \\ &~~~~~~~~~~~~~~~- SOL_{\text{SoM}}\times Y\times(1-C_A) \\\\ = ~&SOL_{\text{SoM}}\times Y\times \left( \left(1+P_{\text{match}})(1-C_{ \text{SoM}})-(1-C_A)\right) \right) \end{align*}

For the program to be of any economic interest to a validator, we expect:

E_{\text{SoM}} \geq E_{\text{No SoM}}


\begin{align*} SOL_{\text{SoM}}\times Y\times \left( (1+P_{\text{match}})(1-C_{\text{SoM}})-(1-C_A) \right) &\geq \\SOL_{\text{initial}}\times Y\times C_A \\\\ \left( (1+P_{\text{match}})\times (1-C_{\text{SoM}})-(1-C_A)\right) &\geq C_A \\\\ (1+P_{\text{match}})\times (1-C_{\text{SoM}}) &\geq 1 \\ \end{align*}

Which simplifies to:

C_{\text{SoM}} \leq \frac{P_{\text{match}}}{(1 + P_{\text{match}})}

This constraint suggests bounds for the average commission of validators chosen by stake-o-matic such that the program is profitable for V_A. Very roughly we can see this satisfied for most C_{\text{SoM}} < P_{\text{match}}, and generally should incentivize validators who are participating in the program to keep reasonable commission rates.

More intuitively, a validator should find it profitable to participate in the SoM matching program when the collective yields generated from the matched delegations to validators through the SoM less the commissions from those validators and what it has to return to its delegators (i.e. the yield minus the validator’s commissions on the un-matched portion of the SoM distribution) is greater than what it would earn staking the delegations to its own validator.

We can quickly consider a second, loose, constraint. That is that a validator participating in the program will have an incentive to spread the matched SoM delegation across multiple validators to avoid any single or small group of validators, i.e. potential competitor validation services, from earning too much yield. We refer to this ‘constraint’ below as the ‘relative profit consideration’.

We can consider a validator setting a lower limit to the proportion of revenue that they generate via the SoM matching program as compared to any single validator that the stake-o-matic selects. E.g. a validator might want to ensure that their earnings are at least 2x any single validator they delegate to with matched funds. If we refer to this factors as F, or the “earnings multiple”, we can then set the additional earnings that a validator earns from the SoM matching program greater than or equal to any individual validator earnings:

\begin{align*} SOL_{\text{SoM}}\times &P_{\text{match}}\times Y\times (1 -C_{\text{SoM}}) \geq \\ &\frac{F\times SOL_{\text{SoM}}\times C_{\text{SoM}}\times Y\times (1+P_{\text{match}})}{N_{\text{SoM}}} \end{align*}

Where N_{\text{SoM}} is the number of validators that the SoM distributes the matched stake across. This can be re-written to express the minimum N_{\text{SoM}} by which a validator can be confident in what he/she feels like is an equitable yield distribution:

N_{\text{SoM}} \geq F\times \frac{C_{\text{SoM}}\times(1 +P_{\text{match}})} {P_{\text{match}}\times (1 -C_{\text{SoM}})}

This minimum value of N_{\text{SoM}} is plotted below for a varying amount of Foundation matching and example “earning multiples” (F):

As demonstrated in the figure, depending on the amount of Foundation matching and the participating validator’s relative profit considerations, the SoM matching program should encourage a broad re-distribution of stake across the nodes of the Solana network.

It should be intuitive that, under this consideration, there is benefit to distributing the matched stake across as many nodes as the initiating validator feels comfortable with (i.e. as many nodes that satisfy his or her other conditions to be included in their SoM distributions).

Program Timeline and Details

The Solana Foundation intends that the Stake-o-Matic matching program will be its primary token delegation mechanism. We’d like our validators to be fully comfortable with the details of the program and running their own Stake-o-Matic services before inflation is enabled and rewards are distributed.

Additionally, we’d like time to explore the various dynamics of a network with multiple, dynamic, stake-o-matic systems running at the same time. This will help us uncover any technical or economic unforeseen bugs and byproducts of this complex system. Having adequate time to see stake-o-matics in the wild will also help us explore TBD qualification criteria for the matching program such as minimum number of nodes necessarily staked from SoM as well as the Foundation matching rate.

For these reasons, we’re encouraging validators to start exploring and playing with their own stake-o-matic scripts. For now, let’s keep the discussion in this thread (rather than Discord). More information about how we will be incorporating stake-o-matics in Tour de SOL will be coming soon!

Edit/Update: @G1715 has created a useful walk-through of his experience with SoM here. Well worth a read!


:face_with_monocle: I study the materials, delve into them.

1 Like

Great post @eric thanks …I might have to give this a 2nd | 3rd read to get comfy w/ the formulas

Two Takeway for Self :

  • Delegation via SoM is certainly a valid approach to explore how we can achieve further decentralisation of the network, nodes, and digital assets

  • Keen to run a SoM in TdS to document the playbook and run one in MB

Sidebar: Given some node operators prefer keeping their host machine(s) clean, I might start working on containerising SoM for the purposes of portability, ease of use, and wider adoption by our community

1 Like

Eric, this is pretty amazing! I will take some time to digest and provide more detailed comments later. This weekend, I am working on enhancements to that should fit pretty well with your objectives.


Eric, It sounds great!! Even in its original form, this will contribute to the decentralization of stakes. It will take a little longer to study this fully.


I like the out of the box concept. As others mentioned it probably requires a few reads =).

What about making something similar available to normal users as well. It can be pre configured (or maybe customize able) scripts/pools where they can delegate to. The difference is that they don’t get the extra stake but just a way to optimize over multiple nodes. Combine that with decreasing rewards on size per validator to promote more decentralization (as suggested in other thread).

As mentioned in the other thread it’s probably a good idea to have also some staking to the smaller validators to make sure they cover operational costs. Maybe with something similar that is currently running. Since most have some rewards you could require for example a 10K SOL direct delegation (and a max/decreasing stake as well since its for smaller validators) and then make it dependent on other parameters like max 10% commission (or make that a formula as well), uptime etc. The bonus stake would build up exponentially in a year or so and if possible rewards would be locked for an amount of time and only be released if after that time the validator has been and is still functioning honestly&properly. You can also limit this to the current validator pool so you are sure it’s people who are dedicated to the project and not some people trying to attack the network (and maybe combine that with a number so if existing validators would leave others might fill that position).

Hey, Eric! Thanks for sharing. Looks good. High level speaking, the SoM incentivises the “whales” players to distribute their delegations. Which is great for an increased decentralization and censorship resistance of the network.

It would be good to understand how the reverse flow will work, what additional operations are required, technically speaking, assuming that “Token Holder” decides to un-delegate its holdings from “Validator A”. Hope it makes sense.

Adrian |

I think it would be great to get some tooling around SoM. If you, or anyone else, is interested in making a proposal to work on SoM - let’s chat! The Foundation would love to support these efforts.

1 Like

What about making something similar available to normal users as well.
Agreed, I think it would be interesting if the Foundation built one of these (or someone built it for the Foundation). Basically a front-end to a simple SoM, with delegation parameters (i.e. how it decides where delegations go) decided by vote.

1 Like

It would be good to understand how the reverse flow will work, what additional operations are required, technically speaking, assuming that “Token Holder” decides to un-delegate its holdings from “Validator A”.

Lots of technical details still to be hashed out, but I think this would work like any other un-staking. I guess Validator A will have to manage token ‘liquidity’ between it’s self-staked delegations and the SoM delegations. But if Validator A unstakes from SoM, the Foundation matching will unstake with it.

1 Like

Hi @eric …thanks for this …i would love to explore what can be built something like solana-backend-as-a-service (sBaaS) …and see how we can make it available for various sets of users and front end applications that chooses to integrate with it ?!

  • SoM for Validators
  • SoM for Investors
  • SoM for Users
  • SoM for Wallets
  • SoM for Dapps

Let me know what you think ?!

Hi Eric,

Regarding my contribution to the “tooling,” I have three objectives for

  1. a place for validators to check high-level performance & scores against other validators,
  2. a place for investors/delegators to find potential delegation partners, & most relevant to this thread,
  3. an API with data points to feed into a stake bot!

See the “Validators” API endpoints here ( for details.

P.S. There is a discussion thread at Validator Performance Metrics regarding the metrics.

@dominic :point_up_2:t2:

If I am understanding you correctly, you want validators to make their own version of this rust program:

I like optimistic people :slight_smile:

It is nice to see the innovation to improve censorship resistance of the network. I might have missed some details on the SoM program, how would this be perceived by the token holders, would he realized that his stake delegated to Validator A is being routed to other Validator instead? Most importantly, if slashing happens in the SoM program, would validator A be responsible for picking the wrong validator in the SoM list?

For the math, I have a question about the the simplified incentive equation below.
\[ C_A \leq \frac{P_{\text{match}}}{(1 + P_{\text{match}})} \]
What’s the rationale for it to change from C_SoM in the previous equation to C_A?

Also, as long as the equation above holds, I guess it is the most economical to send all SOL_initial to SOL_SoM. Is that what the solana team wants everyone to do? Is there any hurdle that keep validators from sending everything to SoM, apart for the investment of developing a good SoM script?

I believe in you! :slight_smile:

1 Like

would he realized that his stake delegated to Validator A is being routed to other Validator instead?

Yeah, I think the token holders should opt-in to the SoM program of a given validator (maybe it offers slightly higher yields?). Basically giving the stake authority to the validator to enable SoM to split and re-stake.

What’s the rationale for it to change from C_SoM in the previous equation to C_A?

Good catch, I think that should have been C_SoM because we’re talking about what the average commission rate of the validators that SoM chooses such that the program makes sense to V_A. Fixing now!

If I am understanding you correctly, you want validators to make their own version of this rust program:

I’d also love to support someone with a grant to build some UI tooling around that script too. Something more plug & play. I see the script as a starting point with lots of versions going live in the wild


OK, I read the code of the stake-o-matic… it’s a fixed validator list… each validator has two stake-accounts (baseline and bonus) and once they are funded, they are funded forever… all it does it delegate or undelegate the two accounts depending on the performance.

So if you give a validator a bonus one time, and they never get it again, the stake is going to be sitting out there forever doing zip – right? That’s the only thing I thought was a bit suspect. Because you won’t earn rewards on that, right? It’s fine for the foundation to do that – you don’t care about rewards – but a holder totally will… So we have to write a SOM that is also withdrawing deactivated stake and redistributing, right? And I think that would be pretty complicated.

Something I don’t get, how are you guys going to know we are delegating via a stake-o-matic? And how are you going to ‘match’ against our stake-o-matic? I assumed we will be running these stake-o-matic programs, but perhaps the foundation will run them? I’m kind of confused, I can see how I can run it for my own staker account, I just crontab it to run near the end of every epoch. But then how would the matching from the foundation work?

I may have made some incorrect assumptions here, let me know.

So if you give a validator a bonus one time, and they never get it again, the stake is going to be sitting out there forever doing zip – right? … So we have to write a SOM that is also withdrawing deactivated stake and redistributing, right?

Actually, SoM does have code to deactivate stake based on a node underperforming based on the quality threshold or going delinquent.

Something I don’t get, how are you guys going to know we are delegating via a stake-o-matic? And how are you going to ‘match’ against our stake-o-matic?

TBD, it might involve a SoM pool registry or something like that.

I may have made some incorrect assumptions here, let me know.

Keep the questions coming! Lots of details to work out still.