Implement Copy-Staking for Stride’s Osmosis Delegations

Proposal Discussion
1

This proposal would restructure Stride’s delegation program on Osmosis to deprecate the existing Stride delegation process in favor of copy-staking. The full proposal, with a description of how the proposed copy-staking model will work as well as the benefits and tradeoffs, is outlined below.

Background

Stride governance has the final say on all aspects of the host-chain delegation process, selecting the means by which validators on host-zones like Osmosis are chosen to receive delegations as well as how tokens delegated with Stride are divided up amongst the chosen set.

Historically, Stride governance has elected to utilize a council process to manage delegations on Osmosis. At a high level, this process selects Osmosis validators for Stride delegations by:

  • Employing a council of 5 volunteers approved by Osmosis governance to evaluate and score validators based on a variety of on-chain and off-chain criteria
  • Aggregating and averaging the scores for each validator
  • Selecting the highest scoring 8 validators from each quartile of the active set by voting power to receive delegations from Stride.

This process serves to help decentralize the voting power on Osmosis and improve the health of the chain by distributing LST delegations amongst highly performant validators.

The council process, however, assumes that the Osmosis community wants liquid staking providers to be opinionated delegators. While some chain communities will undoubtedly prefer LSPs to play an active role in decentralizing the chain via their delegations, an obvious tradeoff to this model is that delegation decisions for tokens staked with a LSP are made by the LSP’s users rather than by the host-chain’s users.

Some chains may prefer a delegation model in which the LSP takes a neutral approach to making delegations, opting instead to preserve the existing staking dynamics between a chain’s validators and its community of stakers. This is where copy-staking comes into play.

Stride’s Copy-Staking Model

Thanks to a recent software upgrade, Stride can now delegate to Osmosis’s entire set of 150 validators, making copy-staking a viable model for Stride’s OSMO delegations on Osmosis.

Copy-staking works exactly as it sounds. Stride “copies” the delegation preferences of the host-chain’s community by delegating to all validators in the active set according to existing stake weight. Stride’s existing delegations to any validator are not included in the stake weight calculations.

For example, if the rank 1 validator has 5% of a chain’s existing delegations after subtracting any existing Stride delegations, 5% of all tokens liquid staked with Stride will be delegated to that validator. If the rank 2 validator has 4% of delegations, Stride will delegate 4% to that validator, and so on. As stake weight across the set changes over time, Stride’s delegations will also change accordingly.

Stride adjusts copy-staking delegation weights on a monthly basis. In a future upgrade it will be possible to rebalance delegation weights continuously as organic stake weight changes.

Copy-Staking can be considered a truly neutral approach to LST delegations because it preserves the existing power dynamic between stakers and validators. If a validator consistently behaves in a manner that doesn’t align with a chain’s community of stakeholders, those stakeholders can redelegate away from that validator and reduce that validator’s vote power. In turn, Stride will reduce the allocation to that validator to match the validator’s new vote power.

By emulating the delegation preferences of a chain’s stakers, liquid staking protocols like Stride can also preserve the chain’s existing governance dynamics by preventing any one validator (or any subset of validators) from having more voting power than they otherwise would without liquid staking delegations.

Stride is the first liquid staking provider in the Cosmos Ecosystem to offer this neutral solution to its host chains. Copy staking is already in place for stTIA and stDYM delegations. The purpose of this proposal is to determine whether Stride’s OSMO delegations should also transition from the existing council model to the more neutral copy-staking model.

Implementation Details

Governance proposals will go live on both the Stride and Osmosis chains to approve the transition to copy-staking. If both proposals pass, Stride will transition its OSMO delegations to a copy-staking model by delegating across the entire active set of 150 validators according to existing stake weight for each validator with the following limited exceptions:

  • Validators with greater than 10% commission will be excluded from delegations
  • Centralized exchange validators will be excluded from delegations
  • Delegations will be capped at 10% for validators with greater than 10% vote power. For example, a validator with 11% vote power will only receive 10% of Stride’s delegations. The remaining 1% will be distributed proportionally to remaining validators according to existing stake-weight. Currently, this provision would not affect Osmosis because the rank 1 validator only has 6% of vote power.
  • The bottom 5% of validators in the active set (8 validators in total) will be excluded from delegations
  • All OSMO currently delegated to a validator by Stride will be excluded when calculating existing stake weight

The purpose for these exclusions is to keep liquid staking costs low and eliminate potential risk vectors associated with a copy-staking delegation model. Stake that would have gone to a validator excluded from delegations under these exceptions will be redistributed amongst the remaining validators according to existing stake weight.

Final Thoughts

Copy-staking represents Stride’s commitment to more closely align with the needs and wishes of its host-zones. While some chains will continue to prefer the existing Stride delegation process, copy-staking gives chains the opportunity to opt-in to a more neutral delegation model.

Given how active Osmosis’s governance community is, Osmosis is a prime candidate for copy-staking. A copy-staking model will allow for the existing voting dynamics, built by the delegation habits of Osmosis’s community of stakers over time, to be preserved.

1 Like
2

As a strong supporter of preserving host chain token stakers rights with regards to governance, I agree with this proposal being put to a vote.

In the current model, Stride aligned validators have an incentive to maximise their individual outcomes through their voting on Osmosis proposals. This proposal makes the Stride governance impact closer to neutral from the perspective of Osmosis.

The exceptions seem reasonable and represent a balance between decentralisation and neutrality.

Idealogically, I don’t agree with the 10% cap, since if Osmosis delegators by their delegations indicate that they want some validators to have >10% then so be it, but as you rightly point out that is hypothetical.

Is the bottom 5% rule to prevent validators getting bumped out of the active set impacting stOsmo yield or to prevent unnatural active set barriers against incumbent validators?

I agree with excluding existing Stride delegations - this actively returns neutrality and is a very well thought out nuance. Unfortunately this puts it against some validators interests, but not much can be done. I think its too much to expect those validators to abstain.

The proposal is about allowing Osmo holders to determine if they want neutrality or external management impacting VP.

Regardless of outcome, the choice in this proposal is important, as before it was the choice between impacting VP or not having an LST.

1 Like
3

Hey @Cman_Crypto thanks for the thoughtful reply here! To answer your questions:

The reason for this cap is mostly that it prevents copy-staking from being used as a mechanism to make it cheaper to perform a consensus attack on the host-chain. In practice this would require LSPs like Stride to have a much larger share of voting power to have any actual impact, but imo it’s good to have these safety rails in place nonetheless.

The former. It’s not really about yield so much as complexity in administering redelegations. The bottom 5% of the validator set is usually the most volatile, and delegating to them might lead to Stride bumping into issues with the Cosmos SDK’s redelegation rules if we frequently have to redelegate from validators that fall in active

The amount of stake impacted by this particular rule is quite small (roughly 0.04% of vote power). From a yield perspective it’s also important for chains that trust Stride with POL to not have that POL continuously falling out of the active set, though this is less of a concern given the small amount of stake actually impacted.

2 Likes
4

I am a little bit torn on this one.

On the one hand I totally agree that having a neutral approach has the best chance to achieve a fair distribution in terms of governance and associated risks of biased voting on certain proposals. We have seen examples of that and it wasn’t pretty.
What are the experiences from the chains where copy-staking is already active?

On the other hand we know we have a problem with centralisation of voting power in the ecosystem and the current form of Stride delegations gave a chance of smaller performant validators to stand out. That will disappear in this proposed format. It will be sensitive to airdrop-promising validators (which are excluded in the other format) and other cheap tactics of reaping in delegations. I am aware that any automated format will not be able to tackle this, which is a step back from what we have right now.

1 Like
5

Hey Leo! Thanks for the reply.

I think you’re outlining the tradeoff space pretty well. Stride’s current council delegation process is highly curated, and actually has a meaningful impact on stake weight distribution, helping to decentralize the chain overall in terms of vote power. It also does a good job of recognizing off-chain contributions (content creation, BD Efforts, infrastructure operation, relayers, etc).

But at the same time the process is subjective, relies on the 5 council members’ decisions, and puts delegation decisions firmly in Stride’s hands. Non-liquid staking delegators may have a good reason for delegating the way that they do, and arguably LSPs like Stride, pStake, Quicksilver, etc disrupt that existing dynamic.

Copy-staking allows for those existing dynamics to be preserved, and is as close as we can get to LSP neutrality. The key thing that is preserved here is the dynamic by which a delegator can redelegate away from a validator and reduce their vote power if the delegator disagrees with the way that a validator is acting (voting against Osmosis’s interest, raising commission, going down, etc).

All existing liquid staking mechanisms (including Stride’s existing council process), disrupt this power dynamic. If the LSP gets enough vote power, the validators care less about keeping delegators happy and care more about keeping the LSP happy. This can lead to perverse incentives.

Though copy-staking of course does have its own tradeoffs, as you’ve pointed out. Delegators are themselves imperfect, and this often leads to a top-heavy valset. Copy-staking says that this is ok as long as the host-chain delegators are the ones who choose.

Imo, whichever delegation mechanism we go with, the important thing is that Stride is giving Osmosis the choice of delegation mechanism, something that no other LSP currently does. Whether this proposal passes or not, it’s all about giving the host-zone the choice :slight_smile:

6

Thanks for the response!

I can surely relate why this post is being brought forwards, however, that does not necessarily mean I agree with it :stuck_out_tongue:
At this point in time I am ok with a slight bias in LST-providers in terms of VP distribution.

With respect to governance it is a bit more difficult. It is completely true that the tendency might be to keep the LST provider happy. However, we have seen a fair share of political voting in the past already, also on other topics than LST related. In essence a validator should always vote with the effects for the chain at the very first place; but that is not always happening.

I am curious how this will look when it goes on chain. I have not decided how to vote yet.

7

I just wanted to add to this, whilst I appreciate that there is a perceived right and wrong in these matters - at the end of the day, Osmo stakers are the ones that decide where their stake goes. To delegate to CEX validators or to contribute towards centralization is their right, despite the perceived wrongness of doing so.

I think it’s summed up well below:

This proposal questions whether it is Stride’s place to determine what Osmo stakers or the Osmosis chain wants. I think we all agree subjectively that more decentralisation is better, but for me the question is, is this up to Stride to do or should this be handled by other mechanisms.

I know the counter argument is that by liquid staking with Stride, Osmo holders are indicating that they want Stride to do these things, but the current alternative is to either not liquid stake or to liquid stake with a competing provider (and that’s another discussion around LSP support on Osmosis) and so that’s why I think this proposal is important for both Stride and Osmosis.

8

Voicing my support for this proposal.
While the current model is a decentralizing force on the chain, it also biases towards the validators selected by the council rather than spreading this evenly.

With the expansion to a wider set of validators, the question becomes whether Stride should allocate to all validators evenly or use a copy-staking model.

This mechanism of Filtered Copy Staking allows Stride to maintain a good return in stOSMO by omitting high commission fee validators and those at wish of dropping out of the set.

Personally, I think that the 10% limit is too high and that the stake should be biased further down the set, but as Cman previously raised the opposite then I think lowering it would probably be contentious!

A copy staking model trusts the market to decide on which validators should be selected. I think that the market for staking is heavily prone to display and bribery biases since performance is not as visible on frontends. I would prefer that we bias towards performance and contribution rather than the current market trends, but perhaps the solution to that is making validator performance and contribution more visible across the main staking interfaces rather than attempting to manipulate the filters on delegations.

2 Likes
9

The latter is needed anyways, but the difficult part is what needs to be included.
Since for example Cosmostation has / had a graph of Github activity for projects, but that was tainted as well. Since a couple of projects develop on own hidden repos and publish in one go. That has less commits as results, but yields the same end result.

So it is really difficult to achieve imo.

A small bias towards the lower end of the set can work, but it is similar to what we initially tried with the fee bias tried in an early prop on Osmosis (Mintscan), but that was downvoted massively :stuck_out_tongue:

Maybe the times are getting different though, not sure.

1 Like
10

Chill Validation disagrees with copy-staking.

Liquid staking is a huge opportunity to delegate to smaller validators who do just as much to validate as larger vote power validators.

The argument that some validators do more for RPC/API/IBC is valid to an extent. However often this argument is weak since some validators already get grants for those efforts.

Centralizing vote power as a reward for contributions goes counter to decentralization.

Pushing off the opportunity to improve the vote power balance because it could be another project that does this ignores the opportunity Stride has to do things better.

The current way stride does delegations can always improve. Abandoning these efforts in to copy what less informed delegators does not demonstrate the full capability of Stride.

Stride should take the opportunity to stake to more validators as a way to increase balance and diversity. Not reenforce the current centralized distribution.

3 Likes
11

I can appreciate this viewpoint!

But I just want to make a quick note:

Stride isn’t proposing to implement copy-staking to reward large validators or express an opinion that large validators do more for the ecosystem than smaller validators.

Copy-staking simply says that LSTs shouldn’t be the ones to choose how stake weight distribution is decided amongst validators.

Arguably, this is what the current liquid staking models of Stride, pstake, and quicksilver do. They centralize vote power based on subjective contribution criteria that are chosen by the LSPs and/or the LSPs users.

12

Copy-staking simply says that LSTs shouldn’t be the ones to choose how stake weight distribution is decided amongst validators.

We think Stride should take the opportunity to improve the decentralization of stake weight. Copy-Stake does not help decentralization.

Arguably, this is what the current liquid staking models of Stride, pstake, and quicksilver do. They centralize vote power based on subjective contribution criteria that are chosen by the LSPs and/or the LSPs users.

We would prefer to see additional ways to address the issue.

Here’s an example:
30% of LS Weight allocated to Copy-Staking
70% of LS Weight allocated for Decentralization

There can be many more ways to address the issue. However, we do not agree with 100% Copy-Staking and entirely ignoring the centralization problem.

13

Do Stride have any dashboards that show the distribution of stake itself and the impact on decentralisation?

I had a spreadsheet a while ago, which is now very out of date, that I could update… but would be interesting to see this in the stats at

as well as potentially being able to compare what would happen if different variables were changed.

Pushing the voting power cap down would be the way to retain copy staking methodology whilst using stOSMO as a force of decentralisation.

1 Like