Stake Yield Throttling Proposal/Discussion

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

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).

Throttle Function

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

  1. 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)
  2. 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.

Alternative Designs

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:

  1. Selection of the threshold
  2. 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:

https://solana.shinyapps.io/throttle_estimation/

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.

5 Likes

Thank you @eric for yet another brilliant proposal to help solana network be(come) a censorship resistant with a broad(er) distribution of its stake across a larger number of validator nodes.

A lot to comprehend here – Yield Throttling > Throttle Function > Stake Distribution > Stake-o-Matic > Yield Throttling Estimator

Allocating some cycles this week to fully go through this proposal

1 Like

Do we increase censorship resistance if instead of one, validators run multiple nodes?

IMO the positive effects of yield throttling, to a certain degree, depend on entities limiting themselves to operating one validator. I think Polkadot’s NPoS demonstrated that validators quickly accept the shift of incentives and spin up multiple validators to accommodate more stake. If you are planning to validate a Substrate based chain (Polkadot, Kusama, Edgeware), operating multiple validators is the standard. Zug Capital is currently operating 19 (!) out of 197 Polkadot validators. To some degree, one entity running multiple validators even obscures the fact that lots of stake is concentrated at one entity - it’s simply less noticeable. So we should not expect hesitation to spin up multiple validators. It just depends whether you want to work around the issues for profit or leave money on the table for everyone else to the point where you’re being penalized with no recourse. The result could be that operators have much higher operational expenses with marginal benefit for censorship resistance. Given that spinning up multiple Solana validators is more expensive than in other networks, cumulative costs to operate the Solana network could skyrocket.

From my experience, the only thing that had a limiting effect on validator stake concentration is some form of self-bond. Tezos has been doing this somewhat effectively - validators need to put up ~1/10 of their overall delegated stake. Avalanche launched yesterday with a parameter that is limiting the amount of stake a validator can accommodate to ~5x the self-bond. We delayed/canceled our Avalanche validator as a consequence, indicating that the 5x parameter might be too low (https://twitter.com/StakingFac/status/1308134553043820545). Self-bond as a concept is interesting as validators need to grow their commitment to accept more stake.

What about a combination of yield throttling and self-bond? Validators below the yield throttling threshold don’t need a self-bond. Validators above the threshold will need to provide a self-bond to negate the effects of yield throttling. That way, validators that want to commit to the Solana ecosystem in a more substantial way than staking 0.1% can do so. But instead of continually leaking capital in the form of hardware and operational costs for X validating nodes that sit in the same DC anyway, they need to buy and lock SOL creating a much better alignment of incentives as a consequence.

This is just me thinking out loud… anyway, thanks a ton @eric for kicking this off in such a high quality manner.

2 Likes

validators quickly accept the shift of incentives and spin up multiple validators to accommodate more stake

Right, so the risk here is the illusion of security vs actual security. E.g. if the multiple validators from one entity don’t have good key opsec.

But the interesting point to me is that you, Staking Facilities, as a validator know this:

I think this is where Stake-o-Matic (aka a delegation bot) comes in. If you, SF, were running a Stake-o-Matic, you would flag these 19 Zug Capital validators as low_quality, or maybe a group of validators would keep a curated list of probable sybil nodes and assign probability_sybil (or something) based on insider-baseball knowledge, etc.

These 19 pseudo-independent nodes would therefore be unlikely to attract much if any stake from the delegation bots and the harmonious balance of mother nature would be restored.

From the other perspective (e.g. Zug Capital’s perspective). They would look at the potential throttling and have four choices

  1. Do nothing
  2. Spin up a bunch of psuedo-secure nodes
  3. Spin up a bunch of quality nodes
  4. Re-allocate stake from their own node to a delegation bot (w/ the explicit additional incentive of a Foundation match, or an intrinsic additional incentive of spreading stake out to quality nodes and increasing the value/security of the network)

My argument above is that option 2 should be discouraged with a healthy stake-o-matic system. Then, ignoring option 1, the validator has an economic choice between options 3 and 4. So then option 4 acts as a pressure release valve if your assumption about prohibitive validation costs are correct (which I would argue against anyway :slight_smile:)

As for self-bond, I’ll give it some more thought. Am I understanding it correctly that the ‘self-bond’ is the amount exposed to slashing?

TBH - my working assumption while thinking through this stuff 100% slashing exposure in the long run (there are other threads on this though). In this world, quality definitions in delegation bot algorithms become premium, and pseudo-secure nodes become even more radioactive.

Hi Eric thank you for this technically proficient and thorough proposal.

As mentioned previously we (LunaNova) fully support increasing censorship resistance by increased stake distribution. We see Stake-O-Matic enabling and rewarding distribution of stake whereas Yield Throttling is attempting to punish concentration of stake; they therefore can be complementary. However, we believe the challenge here is to get the overall balance right and are concerned that yield throttling to the degree mentioned may have undesirable consequences.

Before articulating our concerns we have a few questions to ensure we have understood how this is intended to work:

  1. Is there an overall limit on delegations the Solana Foundation will match (nominally at 15% for the percentage of SOL that is matched in the proposal)?

  2. With a hypothetical yield throttle point of 100,000 SOL, if an existing validator has 1million SOL delegated from external sources for example, if they redelegate (via Stake-O-Matic) the excess 900,000 to 9+ other validators does this escape throttling on their tokens completely so full yield can return to their delegators?
    (Here reliance on the Solana Foundation’s matching means a focus shift: validators need to be able to select other competent validators to redelegate to in order to not lose their external delegations.)

  3. In the situation where, using Stake-O-Matic, Validator A delegates to B and B in turn delegates to C does B also qualify for the matching from the foundation?

  4. In questions 3, what happens if A and B are the same entity running multiple nodes?

  5. If there are too few nodes to provide full yield on all the delegations, what happens to the excess yield after throttling? Is this burnt, donated to the foundation or something else?

Thanks for the questions Mike, see my answers below, but keep in mind that this is a WIP and I hope discussions like this help shape the design. I.e. my thoughts/answers are just that, still in the exploratory phase here.

  1. Is there an overall limit on delegations the Solana Foundation will match (nominally at 15% for the percentage of SOL that is matched in the proposal)?

I can see the matching happening in one of two ways

  1. The Foundation agrees to some fixed % (e.g. 15%). Each contribution to a SoM delegation bot gets matched by that amount. This is what is described in the SoM matching thread. The exact amount would follow from the considerations outlined there.
  2. SoM matching funds come from a ‘matching pool’. This pool is seeded by the Foundation with a fixed amount of SOL, and is equally distributed across all SoM delegations. This would be more complicated, but would have similar incentives as inflation rewards: few participants leads to high matching which increases the participants until some economic stability is reached.
    WDYT?

if they redelegate (via Stake-O-Matic) the excess 900,000 to 9+ other validators does this escape throttling on their tokens completely so full yield can return to their delegators?

That’s correct. The yield throttling is only applied to single nodes. In the case you describe, a validator would likely be motivated to re-delegate via a delegation bot (SoM) even without a match from the Foundation.

Your point on competent validators is one of the appealing considerations toward building a healthy SoM ecosystem - it will not only redistribute stake but do it in a way that emphasizes quality and security of the expanding validator set.

  1. In the situation where, using Stake-O-Matic, Validator A delegates to B and B in turn delegates to C does B also qualify for the matching from the foundation?
  2. In questions 3, what happens if A and B are the same entity running multiple nodes?

In the current design / SoM arrangement where it is the stake-authority that is transferred to the SoM ‘manager’, there wouldn’t be anything stopping this necessarily. The original owner of the stake-account would always retain withdraw-authority so could always pull back the delegation.

However, the team is currently working on a SoM pool contract, in which this passing of the stake-authority would go the way of the dodo, from what I understand. With this contract, joining a SoM pool would be similar to delegating to a validator, it would also return a SoM pool token, which has interesting implications I think.

More info on this to come, so I’m not sure I can give you a satisfactory answer until our underlying SoM design and implementation gets sorted out a bit more.

  1. If there are too few nodes to provide full yield on all the delegations, what happens to the excess yield after throttling? Is this burnt, donated to the foundation or something else?

What if it was used for SoM matching!? This is an idea that I think is cool, but I haven’t run any numbers around it. In this scenario, throttled yields would go to a pool that is used for the matching portion of SoM delegations. Rather than the Foundation providing a fixed % match for every SoM contribution, maybe it could be a variable % based on the distribution of the ‘throttle overflow pool’ across all SoM delegations per epoch. I don’t know if this has legs yet but I’m looking forward to digging in more.

Alternatively, yeah, burnt or Grant pool maybe? What do you think?

This is a really hard problem imho.

Cardano is dominated by a few people running many nodes. It’s not a secret, you can see it in the node names. Cardano is yield throttled but no bond.

Obviously bonds (slashable or not) limit number of pools an entity can make, but they can still create a bunch if they have a lot of funds.

You really want to limit people to running one pool.

Maybe something like a bond linked to an anonymous unique identity.

Bonds are linked to a set of 10 fingerprints, only one bond per set of fingerprints allowed.

I’m gonna read and try to understand Eric’s design proposals.

Thanks @G1715 (Smith). One thing to keep in mind when reading the throttling proposal is the impact of a healthy delegation bot (stake-o-matic) ecosystem. Maybe I should have proposed them both as one system, because I think of them as pretty simpatico to produce the overall outcome desired.
The idea of bonds has come up a lot now and tbh I still don’t quite see how they would help that much. Guess I have to think about it some more.

I don’t think bonds really help. Just means you need a certain amount of capital and commitment to the network to run a node. It’s perhaps more of a barrier to entry than anything.

Yea, I get it – the stake-o-matic needs to be doing it’s thing, it’s part of a whole.

I’ve read through, but it’s hard to know if theory will work, honestly cannot say. Cardano spent more than a year modelling incentives, and I’m not sure it’s bought them much tbh. And I don’t think many people on this forum can really help you much.

Probably the fastest way to know, is just to suck it and see.

Just start applying Foundation rewards as you think right, and see what pops out… if there is one thing I have learned in my life is that people respond to real money… sure they have all kinds of ideas and principals, but once there is real money on the table, you are gonna see it.

Hi Eric, Thank you for a comprehensive response to my questions.

Firstly let me acknowledge that there is no black and white/ right answer here and that we will need to move towards the best answers we can get via analysis, community engagement and experimentation (on Testnet).

The points you make are very interesting, with regard to your questions:

  • We think that having a dynamic level of SOM matching is intriguing but it does add another layer of complexity because it will have a direct influence on the profitability of a node and therefore SOL price will need to be factored in. Greater complexity could lead to unintended consequences and so we would be wary about introducing it in the initial stages.

  • Of the options for excess SOL after throttling: burning Sol will reduce token supply and using it for grants should improve the protocol, making it more attractive and potentially increasing demand, both of which support SOL price. However the SOM pool concept sounds good; using the SOL saved through yield throttling to fund the SOM stake matching pool could lead to a virtuous cycle whereby both the Yield Throttling and the SOM stake matching work even more closely together to drive the desired behaviour. The only cautionary note is ensuring the right balance between sufficient and competent validators, which is discussed below. There is no reason why all three options could not be used provided they are managed.

I indicated in my original response that we have some concerns; these revolve around attempting to run yield throttling targeting 1000 validators, certainly in the initial stages, because of a real danger that you quickly push the network towards a mix of the following:

  1. Large players running multiple nodes in a way that may be impossible to distinguish them which would be the very opposite of censorship resistance.
    and
  2. Very small players, who get no benefit from attracting extra delegations due to yield throttling, not receiving much reward. They will then be focused on running the cheapest possible operation, unlikely to invest in proper security procedures and also may not seek out geographically separate infrastructure. This could represent an intrinsic risk to network stability.

We think it would be better to start with a much higher threshold than 0.1% of active stake. This would ensure we still have an ecosystem where smaller players are encouraged to develop good practices because there is still the headroom to attract external delegations that can bring more revenue. This higher threshold still tackles the real problem of limiting the attractiveness of further delegations to validators with large stakes, reducing the average amount staked on a single node and enlarging the validator Nakamoto coefficient.

One promising strategy could be to manage the yield throttling target so that it aims to spread delegation evenly among the approximate number of quality nodes already present in the network. A yield throttling threshold that targets more nodes than the current number of quality nodes will inevitably lead to the network getting flooded by cheap nodes in the same way TdS has been flooded by Hetzner nodes and represents an existential threat to the network. Instead it should be made clear that the yield throttling threshold (%) will be adjusted as people bring quality nodes online, motivating people to roll out good infrastructure. If there is a concern that the Foundation is unable to accurately assess the number of quality nodes we could devise some way to take the average of validators’ votes about how many quality nodes they believe there are.

One of the dangers of a low yield throttling threshold (%) and a network flooded with cheap nodes is that responsible operators refraining from delegating to the poor nodes will return a lower yield to their delegators, who will in turn simply withdraw their stake and delegate to someone providing higher short-term returns by having no qualms about delegating to low quality nodes. In this scenario it will be the overall network that will suffer and you will drive out good validators.

We may want to design the yield throttling implementation so that the threshold can be adjusted both up and down dynamically. Consider encountering a black-swan event which reveals a huge quantity of below-par nodes that, for example, may not be running hardware able to cope with a large increase in network load. We would want the system to be encouraging people to pull their delegations back to capable nodes by increasing the throttle threshold(%) until poor performers have upgraded or been replaced by higher quality validators.

Just a quick point on the self-bond concept which has been discussed. We think it is interesting but don’t see it as the right fit for Solana. It creates too high a barrier of entry for smaller players. Ideally smaller validators should be able to attract a decent amount of delegations by just investing in good infrastructure and operational procedures: they should not be artificially crippled by a lack of access to capital.

1 Like

Hi Mike,

Again thank you for this level of engagement! Be forewarned, many of my answers below boil down to “SoM might fix this”. I think these two proposals: SoM + yield throttling are dependent on each other. When trying to find the “quality vs quantity” Pareto frontier, I think SoM might provide the “quality” pressure while throttling leans on the “quantity” side. The throttling design, as proposed above, was made to be pervasive but not draconian (i.e. a lot, if not all, of the validators may feel the pressure, but the pressure isn’t suffocating).

See my responses below and let me know what you think!

SoM… adds another layer of complexity because it will have a direct influence on the profitability of a node and therefore SOL price will need to be factored in.

The way I’m thinking about it, a node can still operate as a traditional validator and collect direct delegations if they want. In this case, they might be on the receiving end of some delegation bots (SoMs), but not necessarily managing their own. If there is a healthy delegation bot ecosystem, I think those nodes would want to ‘keep up’ with the leading quality metrics / SoM-lists though, which is what we’re betting on here.

excess SOL from throttling… There is no reason why all three options could not be used provided they are managed

True, except for increased complexity (operational, if nothing else). Burning has an interesting side-effect that it actually softens the ‘impact’ of throttling, because it benefits all token-holders to burn those tokens. Regarding using the throttle excess for SoM matching pool: I need to put more time into thinking about how the matching step might actually work. I’m waiting a bit to see how the pool contract that the team is working on turns out (I think I mentioned this on the call), because it will change the SoM delegation dynamics a bit I think. Then my guess is that matching (from throttled excess or Foundation treasury) might start out being fairly manual and we gradually learn if a ‘virtuous cycle’ form yield throttling is achievable.

  1. Large players running multiple nodes in a way that may be impossible to distinguish them which would be the very opposite of censorship resistance. and
  2. Very small players, who get no benefit from attracting extra delegations due to yield throttling, not receiving much reward. They will then be focused on running the cheapest possible operation, unlikely to invest in proper security procedures and also may not seek out geographically separate infrastructure. This could represent an intrinsic risk to network stability.

What would be helpful for me here is to understand if you think this will still be the case even with a healthy stake-o-matic ecosystem. I 100% agree that a simple application of yield throttling, as described above, will fall short and likely lead to these issues.

I think SoM may provide the appropriate level of checks and balances, but I’d loved to be challenged on that assumption. At the roundtable last week, someone asked about priority between inflation, throttling and SoM. My answer was inflation > SoM > throttling. Inflation is necessary and I think throttling (to this extend) only works with SoM.

We think it would be better to start with a much higher threshold than 0.1% of active stake.

If we use the yielded tokens to subsidize/match SoM contracts, then the actual amount throttled only matters to the degree that we want to incentivize folks toward running SoMs. I.e. the throttled yields aren’t lost, they are just redirected.

What I’d like to focus on now is how much a SoM matching pool might fluctuate as a function of throttle threshold level (e.g. 0.1% of active stake vs 0.5% of active stake vs…). I see a path to quantify the SoM side of the equation (more matching -> more SoM incentive), but I think the opposite side that you are calling out here (higher threshold -> higher pressure to cheaply sybil) is going to have to be a bit more subjective.

One promising strategy could be to manage the yield throttling target so that it aims to spread delegation evenly among the approximate number of quality nodes already present in the network.
This is an interesting idea, but I think we do want something that stretches the network to decentralize. What this is describing actually sounds more like SoM. SoMs, as curated by validators, should be letting network metrics and validator marketplace dynamics resolve the Pareto boundary between decentralization and quality. That’s the hope at least.

One of the dangers of a low yield throttling threshold (%) and a network flooded with cheap nodes is that responsible operators refraining from delegating to the poor nodes will return a lower yield to their delegators, who will in turn simply withdraw their stake and delegate to someone providing higher short-term returns by having no qualms about delegating to low quality nodes. In this scenario it will be the overall network that will suffer and you will drive out good validators.

Has delegator yield been observed to be a big driver of delegator migration in other networks? I.e. setting yielding aside, the degree of this risk should be observable in ‘yield shopping’ by token-holders in other networks, I’d be interested to get a sense of how big of an impact these yield difference might make.

Apologies for being a broken record but I see SoMs as addressing this issue in two ways

  1. By creating a SoM pool a responsible validator can recoup throttled yields through curated SoM lists and the matched contributions (a delegator might be abstracted from this so only sees that validator X has total returns Y where Y would be a combination of throttled yields from their own node and yields from the SoM),
  2. The responsible validator’s SoM list would, presumably, not include the irresponsible validators. Other responsible validators would also either use an agreed upon ‘quality’ list or create their own, which would exclude low-quality, cheap, insecure nodes. The assumption here is that if anyone can identify these nodes, it is is the validators themselves.

Also, keep in mind that when slashing is enabled, the stakes are higher for delegators and I think security rises on the list of priorities for validator selection and will dampen much of the stake flight risk toward cheap, insecure nodes.

We would want the system to be encouraging people to pull their delegations back to capable nodes by increasing the throttle threshold(%) until poor performers have upgraded or been replaced by higher quality validators.

You can guess what I’m going to say here. SoM lists do this :). Instead of tweaking throttle thresholds, I think ‘quality’ SoM lists created and maintained by the validator community will be able to adjust quicker and more dynamically than adjusting inflation parameters.

self-bond / access

What if the self-bond amount roughly equalled the amount that we’re subsidizing for running on TdS for ~two months?

I’m not sure how useful this is for this discussion, but here’s a simple effective yield calculator that you can play with to see how changing the yield throttle might impact how a node might want to redistribute stake across multiple nodes. TBH - my guess is that this tool would need a lot of work to make it practically useful. Also, it obviously neglects the SoM dynamics discussed above. But it might be helpful to give a general sense of scale.

Hi Eric,

Thanks for your response.

I agree that SOM and yield throttling could provide important quality and quantity pressures. It is because of yield throttling’s affect on quality that we wanted to be particularly careful.

It is very interesting that you see bots as the engine of SOM, heavily reliant on good validator objective metrics. We wholeheartedly support objective metrics as the driver for stake distribution.

What would be helpful for me here is to understand if you think this will still be the case even with a healthy stake-o-matic ecosystem. I 100% agree that a simple application of yield throttling, as described above, will fall short and likely lead to these issues.

Yes, I do think there is a risk that this still could be the case even with a healthy Stake-o-matic ecosystem if the target number of nodes is simply too high. Many participants will primarily be motivated by money and so yield chasing may be their overriding aim. This may result in a network with participants deploying multiple low-quality nodes to provide higher total yields, undermining a healthy Stake-O-Matic ecosystem. Relying on nodes wanting to keep up with the leading quality metrics list will only work if this becomes popular; but this may not be the case.

We should test this behaviour as best we possibly can on Testnet (though it will not really be possible to simulate some of this without real funds at stake), at a minimum we should ensure a roll-back plan in place before SOM and yield throttling is deployed, just in case we see negative consequences.

Good objective metrics should help SOM identify nodes without the required rigour and robustness but we think the yield-throttling target still needs to be focused on the number of quality nodes.

Using yielded tokens to match SOM contracts as the primary driver rather than the other way round (i.e. throttling percent is a function of SOM demand rather than vice-versa) sounds like a good idea. There is one proviso and that is that we may need to be careful about the right incentive for SOM. Too large may cause instability. Too small may not cultivate the behaviour we require.

Whether delegated yield is a big driver of delegator migration is a good question. It is something worth studying properly, however I do think it would be wrong to assume that yield percentage has no influence. The way node operators can directly influence delegators is through commission. From my observations of this a commission that tends to 0% seems to arouse suspicion, whereas commission greater than say 10% can be a disincentive.

I think you are right about slashing limiting the delegation flight risk to cheaper less secure nodes but I fear that people may not pay much attention to this until some people get burnt badly.

With regards to self-bonding, a small self-bond could be helpful in that it would disincentivize someone spinning up loads of cheap nodes to attract excess SOM delegations with an aim of later destabilizing the network. However, we would need to get the balance right, as it would be a shame to deter good-quality validators if they couldn’t afford the minimum amount of tokens on top of their hardware and co-location costs. If a self-bond is adopted we think that the delegations a node can receive should not be restricted by the size of self-bond.

Finally thank you for the yield calculator, I like it! It does a great job of modelling sensitivity to yield threshold and a range of parameters.