CHIPs signaling phase: Vote Power Tax
This signaling proposal and the research prior to it were funded by the AADAO. The initial post outlining the concept and purpose of a “Vote Power tax” can be found here . In the initial post, we also propose a dynamic community pool tax, which is outside of the scope of this signaling proposal. Author: EffortCapital | Blockworks Research Summary The Vote Power Tax is an economic solution to multiple issues the Cosmos Hub is currently facing: • Concerns around validator economics as it relates to Interchain Security • Poor distribution of stake This tax would be equally distributed back to all validators as a subsidy (~6k+ ATOM/validator/yr) to keep all validators afloat as Interchain Security scales. At current ATOM prices, this tax alone should allow most validators to scale to ~5+ consumer chains assuming $600/mo/consumer chain OpEx. By making the Cosmos Hub more self-sustaining during this bootstrapping phase of ICS, it would lower the costs of security on consumer chains and potentially incentivize more chains to join the AEZ. The ICS Economics Problem While ICS is a great solution for bilateral alignment between the Cosmos Hub and Consumer Chains, the…
Excerpt (1195 of 11696 characters). Read the whole post on the forum ↗
Very interesting proposal! I need some more time to digest this and will give some more comprehensive thoughts later, but I have one question that comes to mind immediately: effortcapital: VPsb=Vote Power Self Bonded by a given validator In simple terms, this Vote Power tax takes the difference from the median Vote Power in the active set and the Vote Power of that given validator. It also gives the validator a chance to lower the Vote Power tax on their delegates by increasing the amount of self-bond to their validator. Does VPsb include tokens that are Validator Bonded for the purposes of meeting minimum LSM requirements? These are two separate bonding types, as far as I know, meaning that the same tokens can’t be both self-bonded and validator-bonded. Given that the validator is (in almost all cases) putting up both self-bond and validator-bond, not including validator-bonded tokens as part of VPsb creates an incentive for validators higher up in the set to self-bond vs validator-bond. This is potentially harmful to both LSPs and the validators themselves, and we may see movement by validators at the top of the set to shift validator-bonded tokens to a…
Excerpt (1196 of 1445 characters). Read the whole post on the forum ↗
effortcapital: Will Partial Set Security lead to further centralization of stake? In our opinion, the best thing for the Cosmos Hub is to ensure all validators in the active set have the financial ability to potentially opt into any consumer chain they want to support by elevating the baseline welfare of the entire active set. The higher the baseline welfare, the more consumer chains the active validator set can secure, which will create strong network effects for the Cosmos Hub. This is a very great point especially with PSS upcoming in the v17 upgrade. effortcapital: The reality is the Cosmos Hub’s security budget is more than enough to scale its ICS offering, but the poor distribution of stake has created a huge wealth gap in the active set. Chorus One did a great job quantifying the validator revenue gap in a quarterly research report here . The Vote Power Tax is a really powerful idea, many have tried over the years to solve the centralization issue on PoS blockchains without much success. However, the VP tax looks like it could work and if it does work and the decentralization of the Cosmos Hub greatly increases, then its value proposition also,…
Excerpt (1198 of 2786 characters). Read the whole post on the forum ↗
We are definitely supporting this proposition and hope to see it funded as soon as possible. In order to provide constructive feedback, we would note these points: • We hope to see this VP tax deployed along with the “cubic delegation” proposition you also suggested. These two make a good pair, and we invite you to start the process for this one in parallel. • • When you say, “The reality is the Cosmos Hub’s security budget is more than enough to scale its ICS offering,” well, this couldn’t be further from the truth. These models only account for infrastructure costs and are widely underestimated for a proper professional deployment, compounded by the fact that operators’ costs to run them properly are much higher than just server costs. We are tired of statements suggesting validators are overpaid; it’s simply not true. Still, the vote power tax is a necessary reform to better balance stake distribution. We just think misleading statements to present the reform could have been avoided! • • To address the limitations presented by the possibility of sybiling by either dividing into multiple smaller validators and/or self-bonding custodian funds for big exchange…
Excerpt (1195 of 3266 characters). Read the whole post on the forum ↗
hey @RoboMcGobo appreciate the feedback!
This was a question I received back in Cosmoverse. I’d like to better understand the differences in these two bond types. I’ve had high-level conversations with the Stride team and Informal team in the past about how exactly “validator bond” is different than self bond but tbh I don’t think I fully understand it.
If @aidan or @Riley or @jtremback could provide a thorough response here for all to see as to how they differ, that would be immensely helpful for myself and the community at large.
effortcapital:how exactly “validator bond” is different than self bond
There are some key differences. For example, self-bond can only be done with the validator owner account, and any partial amount of the available tokens can be used for the self-bond. In the case of the validator bond for liquid staking, any staker of that validator can contribute to the validator bond, but they cannot choose a partial amount but only the total staked amount to a validator from a specific wallet for the validator bond. Also, the normal self-stake amount of a validator doesn’t count towards validator bond, since validator bond is done via a different process. Also, if all the liquid staking capacity made available by a validator’s validator bond is utilized, validator bond delegated to that validator cannot be unbonded
Given these distinctions, it appears prudent to employ the “validator bond” as the preferred option for the intended votepower tax. This approach would address the concern raised by @RoboMcGobo. However, if all users can stake in this account, the original objective of the VP tax (encouraging validators to invest in the system) may be undermined. Is it feasible to track only self-delegated validator bonds without significantly increasing code complexity?
I think for the goal of the VP tax the traditional self-staked ATOM should be considered since it means own ATOM staked in own validator. If some validators are self-staking from other accounts they should inform/prove about this to reduce their VP tax and the same in the case of the validator bond for liquid staking. Basically, for the VP tax it is easy to see ATOM ownership by seeing self-staked ATOM from the validator owner account. Identifying ATOM ownership of validators self-staking from other accounts or contributing to their validator bond or to other validators bonds it is more complex. But it is in the interest of validators to inform/prove about all their ATOM to reduce their VP tax RoboMcGobo: Given that the validator is (in almost all cases) putting up both self-bond and validator-bond, not including validator-bonded tokens as part of VPsb creates an incentive for validators higher up in the set to self-bond vs validator-bond. Here it is important to mention that self-bonding can only be done from the validator owner account, but a validator bond could be composed of many stakers of that validator contributing to the validator bond, and not…
Excerpt (1190 of 1252 characters). Read the whole post on the forum ↗
We need to clarify the semantic to be 100% sure there is no misunderstanding.
Cosmic_Validator:Here it is important to mention that self-bonding can only be done from the validator owner account, but a validator bond could be composed of many stakers of that validator contributing to the validator bond, and not necessarily the validator having added all the validator bond
RoboMcGobo:These are two separate bonding types, as far as I know, meaning that the same tokens can’t be both self-bonded and validator-bonded
One of these two quotes must be incorrect.
Please correct us if we are wrong but this is what we seem to understand :
- Self-Bond = the amount of stake from the validator account that is bonded.
- Validator Bond = Self-Bond + any other staker’s bonds (not a classic delegation transaction, but a bonded delegation).
- Bonded tokens can only be unbonded if the amount exceeds the LSM capacity of that validator.
If correct, then Self-Bond is indeed what we would also recommend for the VPtax. Our previous question related exactly to this, can the chain easily discriminate the Self-Bond part the total Validator Bond ?
@zaki_iqlusion might also be able to provide some helpful context on the technical differences. To resolve this though: Govmos: One of these two quotes must be incorrect. Please correct us if we are wrong but this is what we seem to understand : • Self-Bond = the amount of stake from the validator account that is bonded. • Validator Bond = Self-Bond + any other staker’s bonds (not a classic delegation transaction, but a bonded delegation). • Bonded tokens can only be unbonded if the amount exceeds the LSM capacity of that validator. I think @Cosmic_Validator and I are both correct. Validator bond and self bond can not be done with the same tokens simultaneously (i don’t think @Cosmic_Validator was disputing this). But it’s definitely true that anyone can validator bond tokens, including people unaffiliated with the validator. However, in practice there’s no reason for anyone to validator bond on the validator’s behalf unless they’re affiliated with the validator. Additionally, most users won’t even have the option to validator bond because frontends don’t provide an option for this (nor do they realistically have a reason to do so). EDIT: to…
Excerpt (1195 of 1346 characters). Read the whole post on the forum ↗
Maybe to frame this a different way, self bond can only be done by the wallet that controls the validator node.
Validator bond can be done by any class of person affiliated with the validator. This can include the validator’s employees, shareholders, etc.
Validator bonding in this sense is kinda like an upgraded version of self-bonding that better represents the realities of most validators today.
In an ideal world, validator bonding would eventually replace self-bonding (or be merged into it somehow) because it’s a better representation of how much the validator has put at stake.
Govmos:Validator Bond = Self-Bond + any other staker’s bonds (not a classic delegation transaction, but a bonded delegation).
No, self-bond is self-staking tokens from the validator owner account. Validator bond is something different and not related to self-staking, meaning that self-staked tokens from validator owner account don’t count for validator bond. Then for the validator bond, it could be that the validator does a validator bond transaction for some amount of tokens, but also that other stakers of that validator contribute also to the validator bond. Validator bond and self-staking are two different things, the wording may seem confusing though.
Hey @govmos - appreciate the thorough response/feedback!
Im not necessarily against the idea of having an exponential tax past a certain threshold. My worry is this would further incentivize the largest validators to break up their stake. I don’t see a problem with a validator that self-owns >4% VP - to me that signifies they are aligned with the Cosmos Hub and I don’t know if we would want to penalize that kind of actor.
Many attempts have been made by other PoS/dPoS networks to try to prevent sybiling in the past and I think maintaining the self-bond ratio mechanism for any validator of any size is both the most neutral and right thing to do to prevent this kind of action taking place (despite low probability due to regulatory scrutiny - as you pointed out).
Ultimately would want the community to collectively decide how this VP tax should be implemented, but I’d personally like to keep the self-bond mechanism in place for any VP amount
We definitely have thought about that. Sybil is a possibility, but we shall never forget that the Cosmos Hub’s validator set is not just a stake ranking; it is a governed system, and reputation accounts for more than people may think. A big validator trying to evade this tax by rolling out a second validator would risk damaging its reputation. Moreover, this would force them to spin up another validator instance, which overall is still a positive for the network as it reduces the Nakamoto coefficient of the chain itself, which is the goal we tried to achieve with this proposition. effortcapital: I don’t see a problem with a validator that self-owns >4% VP - to me that signifies they are aligned with the Cosmos Hub Nevertheless, your remark is spot-on. A validator should be able to avoid this tax if they bond tokens. Therefore, we propose a modification to our initial suggestion: VotePowerTax = max (VPi - Median[VPs] - (VPsb^2/VPi), (100x(VPi-VPsb)/VPs - 4)^2 , 0%) This effectively deducts the self-bond of the validator from its vote power, so only the delegated stake is counted here. Only a validator with a high self-bond could therefore operate with…
Excerpt (1195 of 1968 characters). Read the whole post on the forum ↗
Based on the conversations on this forum, there seems to be agreement on the direction of this proposal. I would like to bring this proposal to an onchain vote as there has been nearly two months for stakeholders to comment/provide feedback. Before I bring this onchain, I will be editing the proposal to make the “self bond” portion of the VP tax equivalent to the SUM of Validator Bond (via the LSM) and the Self Bond. @RoboMcGobo For the VP tax to work long term, more strict slashing conditions will need to be put in place for validator bond and self bond compared to the remaining delegate stake so it disincentivizes validators that have full custody of their clients funds to put their funds at risk. A tiered slashing condition (one for self/validator bond and one for delegated portion of stake) is important to align validator and protocol interests long term. I will be including verbiage around tiered slashing conditions in the update of this proposal without explicitly stating what these slashing conditions should be - this will likely require further research in the future and maybe can be done in parallel by the team that ultimately brings the proposal to integrate the…
Excerpt (1199 of 1207 characters). Read the whole post on the forum ↗
Can you provide the full text of the proposal here before it goes on chain? Thanks.
All - I have updated the text accordingly and plan to move this proposal to an onchain vote next week.
effortcapital:For the VP tax to work long term, more strict slashing conditions will need to be put in place for validator bond and self bond compared to the remaining delegate stake so it disincentivizes validators that have full custody of their clients funds to put their funds at risk.
what solution was found for this? if coinbase self bonds their customers funds, your proposal only has a chilling effect on non-custodial centralization.
It would be hallarious if coinbase self bonded and while they were at it validator bonded to collect LSM delegations, further centralizing VP & making it far more difficult for non-custodial validators to do anything about it given the new VP tax
To be clear, this is final copy for proposal going on chain, correct?
The proposed on chain language lacks elements needed to establish meaningful signaling for implementation.
-
No clear timeline: The proposal fails to provide specific dates or milestones for implementation.
-
Undefined ownership: It doesn’t designate a specific individual or group responsible for leading the next steps.
-
Vague transition process: There’s no clear roadmap for moving from this signaling phase to actual implementation.
-
Unclear funding commitment: While AADAO is mentioned as a potential funder, there’s no firm commitment or budget estimate.
These omissions reduce the proposal’s clarity and limits its signaling mechanism. Instead, it reads more like a discussion starter than an actionable plan.
Imo, the signaling proposal must be inclusive of an actionable plan. The proposal text need not contain exhaustive reasoning as to why it should be implemented. An executive summary should suffice, and link to more comprehensive policy discussions here, instead.
so, very transparently (great job cosmos_Nanny) this RFP is unclear and not actionable. what are the next steps to accountability?
Appreciate the feedback and will postpone the vote going onchain by a few weeks based on your feedback and after having conversations with AADAO.
The original intent was to get the community in agreement on instituting a VP tax then figuring out the logistics around funding and execution (which is outside the scope of Blockworks Research’s mandate).
Im not sure if I will be able to answer all of your points around a transition process and funding commitment, but will attempt to figure this out with the parties involved.
Hi @effortcapital it has been not a few weeks but over 4 months, any updates?
The community needs clarity on whether the proposer intends to proceed with the current plan to fulfill the proposal or if the responsibility will fall to the community to champion the update without the initial proposer’s involvement. We are prepared to support the reactivation of this feature within the product roadmap for the Cosmos Hub. Given the significant organizational changes currently underway, providing this information is essential for effective planning and decision-making.
