Below we discuss a validator yield throttling mechanism which reduces yields from nodes with stake above a threshold determined by a target level of censorship resistance. Dovetailing with the recently proposed Stake-o-Matic matching program, this design is motivated by the desire to make censorship resistance and broad stake distribution a defining feature of the Solana network. Currently on our Tour de SOL testnet, the minimum number of nodes that holds >33% of the stake is over 100, while retaining the throughput and latency performance that Solana is known for.
This is the metric we want to maximize: the minimum number of nodes to reach stake superminority. This proposal arose out of many of the discussions on censorship resistance with our community. We think the yield throttling proposal below, or something similar, is another step toward maximizing censorship resistance without compromising performance.
Yield throttling is the programmatic reduction of staking rewards (validator-level yield) for all stake above a threshold stake amount which is determined by a target amount of censorship resistance on the network. In this regards, ‘censorship resistance’ is defined as above and considered the security provided by increasing the number of independent nodes that would have to be compromised to threaten the network (i.e. the minimum set that hold >33% of stake). Specifically, we’d like to consider a reduction in yield for all stake on a single validator node that is greater than 0.1% of the total active stake on the network. The target of 0.1% active stake can equivalently be thought of as targeting a network with 1000 equally staked nodes. The reduction in stake applies to all yields from stake amounts above this threshold (i.e. not a progressive reduction) and to none of the stake below and at the threshold. A simple yield throttling function is described below which linearly reduces a validator’s yields on stake above the threshold in such a way that 50% of those yields are throttled when the amount of stake on the node >= 10X the threshold amount (e.g. 1% of total active stake in the case of a 0.1% threshold).
As described above, the throttle function has been designed to provide a disincentive to nodes from collecting disproportionate stake. Without being draconian, the reduction in staking yield should increase with the amount of stake on a node. Additionally, the functional form should be simple. Nodes should be able to easily calculate the degree of throttling that might occur under certain staking configurations, and plan their strategies accordingly.
The throttle function proposed is a simple linear percentage decrease in validator yields on stake above a threshold, as a function of amount of node stake over that threshold. The theshold is a stake amount that is determined by the global stake distribution (e.g. the median or in this proposal 1% of total active stake). As stake on a single node increases above the benchmark amount, that node’s yield for stake above the benchmark is decreased according to the throttle function. The percent in decrease (‘throttling’) increases until it reaches 50% at 10X the benchmark stake amount, after which the yield from all stake above the benchmark are reduced by 50%. Below a ‘yield throttle factor’ is shown for the described throttle function. The yield throttle factor is the fractional reduction of yields above threshold stake:
The plot above shows how validator yield is throttled as a function of the node stake relative to a generic threshold stake amount. Below we explore the impact of setting this threshold to equal 0.1% of the active stake on the network. I.e. throttling will only impact the amount of stake on a single node above 0.1% of the total active stake and that throttling is applied as a linear function of the amount of stake on that node, up to 10X the threshold (1%). To illustrate, we can use the current (as of early Sept 2020) stake distribution on Mainnet-Beta as an example.
Applying yield throttle to the current stake distribution as an example
The stake distribution from Mainnet Beta was sampled on 9/18/2020 for this example. Keep in mind that this distribution is quite unique at the moment for two main reasons
- Inflation is yet to be enabled on Mainnet Beta and therefore the pressure for token holders to stake is still low. We expect the current stake distribution to change significantly by the time inflation is enabled (by end of year)
- The Foundation is currently providing 550k SOL delegation through its Stake-o-Matic program. You can see that many folks have accepted this delegation with little or zero additional stake on their nodes.
Albeit temporary and highly skewed, using this stake distribution as an example should still be useful and a bit more interesting than a simulated distribution.
Below is shown the current relative stake distribution along with a ranked distribution of relative node stake. Note the log transformation of the x-axis of relative stake histogram to highlight differences at the low end of the distribution:
As mentioned above and seen in the plots, the delegations from the Solana Foundation are quite prominent and currently represents about half (49%) of the active stake on the network. The intention is to reduce the per-node stake delegation amount from the Foundation prior to enabling network inflation. Out of hesistation to simulate, guess or model the impact of point 1 above, it is still worth addressing point 2 as the analysis here will be significantly impacted by the assumptions around these delegations.
To determine what Foundation delegation values would be useful in this exercise, i.e. what the delegations will be reduced to, we asumme that the total amount of Solana delegation currently distributed is a fixed amount and then consider the targeted scenario of the network comprised of 1000 equally staked nodes. The total amount of Foundation delegation currently on the network is around 70M SOL, which would result in a per-node delgation of 70k tokens on a 1000 node network. Ideally, this delegation alone wouldn’t lead to throttling, which would be the case if 70k < 0.1% of the active stake which would be the case in the scenario of 1000 nodes. With the current number of nodes on the network, however, nodes with just the Foundation delegation alone will still be subjected to yield throttling as designed. This out-of-the-gate throttling is by design and part of the purpose of this analysis is to expose this feature and allow validators time for planning to address this (e.g. spin up more nodes, setup their Stake-o-Matics) if they are concerned by the impact.
For simplicity (round numbers), we’ll reduce Foundation delegation going forward in this analysis from 550k SOL per node, to 100k SOL (10k base, 90k bonus) based on the above consideration. This is roughly the reduction that should be expected before inflation is enabled on mainnet. The adjusted stake distributions then can be shown as:
We calculate that, for this analysis with reduced Foundation delegation, 0.1% of the total active stake (83.3M SOL) is about 83,000 SOL. The plots above are shown again but with the 0.1% threshold demarcated.
The above suggest that, given the current stake distribution and after the expected Foundation delegation reduction, roughly ~69% of nodes, ~99% of network stake, are expected to experience some level of throttling. Again, this is highlighting the current stake concentration on a few nodes.
As mentioned above, yield throttling is applied only stake above the throttle threshold as a function of amount of stake over the threshold. To get a sense of the impact of the yield throttle, we can look at the fraction of total stake above the threshold, shown here:
From this plot, we can see that, given the current stake distribution and estimated adjustment to the Foundation delegations, ~99% of total stake yield will be throttled by some amount (>= 0.1% total stake, as marked by 1x threshold with the red dotted line) and ~84% of total stake yield will be throttled the maximum amount of 50% (>= 10X the 0.1% amount, as marked by the 10x threshold with the blue dotted line).
The picture becomes clearer looking at the fraction of nodes that would experience throttling given the current stake distribution.
Here we see the stake concentration clearly as the ~99% of total stake at 1X the throttle threshold corresponds to ~69% of nodes, and the ~84% of stake undergoing 50% throttle is centralized on ~9% of nodes. It is also clear that the majority of nodes are only slightly (< 1.5X) above the threshold. This is due to the 100k SOL Foundation delegation, splitting that delegation alone across >1 node would remove any throttling on this stake. We see that only ~12% of nodes hold more than 2X the threshold amount (i.e. 0.2% of total stake) so the majority of throttled stake can be mitigated by a minority of network nodes.
We can restrict our focus to just those nodes with stakes above the 0.1% threshold to further investigate the yield throttling mechanism. We can consider the “effective stake” of a validator as the amount of unthrottled stake that would yield the same amount of rewards as the validator’s stake after throttling. Keep in mind that stake on a node that is below the throttling threshold (i.e. the 0.1% total stake) is not impacted by the throttling, only the stake above the threshold is subject to throttling, as described above. So a node’s ‘effective stake’ will equal its actual stake for all nodes with stake up to and equal the throttling threshold. For a node staked beyond the throttling threshold of the network, its effective stake is calculated as:
Effective Stake = Threshold + (Node Stake - Threshold) X Throttle_Fn(Node Stake, Threshold)
With this, we can look at the impact of yield throttling on current nodes above the threshold. Below we plot Effective Stake/Activated Stake vs Activated Stake for the current nodes on the network with stake above the threshold, again note the log-scaled x-axis.
Each point on the graph above is a node on the network would be currently staked above the 0.1% total stake threshold. The y-axis represents the effective reduction in total stake, and therefore total yields, due to throttling. The total throttling effect never fully reaches 50% because a node’s stake up to 0.1% of total stake (i.e. the throttle threshold) full yield rewards.
Making use of the throttled yield via Stake-o-Matic matching
Solana has a predetermined inflation schedule. While the specific numbers are TBD, we expect ~8-10% inflation when first enabled, dropping ~10% per year until it reaches a long term emmission rate of ~1.5%. Validator yields are a result of these issuances being distributed to validator nodes in proportion to the amount of SOL staked on each node. Without yield throttling, an 8% global inflation, with 80% of the total SOL supply staked, would lead to an 10% validator yield. In other words, staked SOL would earn an 10% annual interest rate for those given parameters.
However the yield throttling mechanism, as described above, suggests that inflation issuances aren’t fully distributed in proportion to validator stake, but to validator effective stake. Because the sum of effective stake does not equal the total stake on the network, this means that there will be ‘un-delivered’ inflation issuances after each round of inflation distributions. There are a number of options available for what to do with these ‘leftover’ tokens, such as directing them to Foundation treasury, burning them or redistributing them to lower-staked nodes. Each option introduces complex incentives and dynamics.
One option under consideration is to use the throttled (extra) tokens to fund the token-matching portion of our Stake-o-Matic program. As described here, the Solana Foundation is proposing a program to match all funds that are used in Stake-o-Matic pools, up to a certain percent. This is another effort to re-distribute stake across the network. It would be ideal if the long-term economic incentives of the Stake-o-Matic program were built into the ecosystem itself, rather than a Foundation managed program.
It may be possible, for example, for a validator that is staked over the throttle threshold, to recoup a portion of all throttled yields by diverting stakes into a matched Stake-o-Matic program.
The current Stake-o-Matic proposal suggests a flat % match, from the Foundation treasury, for each delegation through a Stake-o-Matic (e.g. 15%). A variable matching rate based on the size of a throttled token pool is something under current research.
While we’ve outlined a specific throttle design here: 0.1% total stake threshold, linear throttle reducing yields to 50% at and above 10X the threshold. There are many approaches that might still be considered. This overall design can be thought of in two pieces:
- Selection of the threshold
- Seelction of throttle parameters
Alternative designs: 1. Selection of threshold
One alternative to a threshold defined by a percentage of total stake is a threshold selected as a quantile of node-stake as observed on the network. Examples of this threshold calculation would be taking the median of 66% quantile value, and applying a threshold function above that value. With this ranked selection design, there will always be nodes above the threshold. Outside of a network of exactly equal stakes, there will always be a rank of nodes that can be established.
While this alternative design loses the clarity of the fixed percentage, e.g. being able to set a fixed target of nodes (1% threshold targets 100 equally-staked nodes, 0.1% threshold targets 1000 nodes), it provides an environment where nodes are under constant pressure to split their stake across many nodes in relation to other nodes.
Alternative designs: 2. Selection of throttle parameters
The throttle parameters proposed in the above design are a linear function of the amount of stake above the threshold stake (a 50% throttle cap at 10X threshold). There are many alternative design choices available to these parameters. The throttle could be non-linear, steeper/faster, shallower/slower, no-cap, progressive vs total. It could also be a function of node rank above the threshold, rather than the stake-distance from the threshold. In this scenario, throttling is applied based on how many nodes are in between the threshold and any given node. While this might add dynamism as discussed with ranked threshold selection, there are a number of edge cases (e.g. one node above the threshold) that might lead to prohibitive complications.
Yield Throttling Estimator
We’ve created a tool to estimate yield-throttling given the current state of the network and some assumptions on the Foundation’s delegation strategy:
Note: This tool estimates the reduction of yields (e.g. ‘effective yield’ or ‘effective stake’), not the expected yields themselves. Information on inflation parameters and expected validator-level yields will be circulated in advance of enabling inflation.