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:
- All non-delinquent validators receive 50,000 SOL stake
- 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.
Incentives
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
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.
For the program to be of any economic interest to a validator, we expect:
Or:
Which simplifies to:
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:
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:
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!
I study the materials, delve into them.
