Scaling up with conditional basic income
Introduction With the launch of the replicated security functionality from the Lambda upgrade on March 15th, the Cosmos Hub has the technical capacity to establish itself as a key social and economic Hub of the Interchain. However, replicated security has a critical issue: validators are going to incur costs for running consumer chains, and consumer chains are going to need time to generate meaningful revenue. This essay explores how ATOM holders might choose to leverage existing social, fiscal, or technological resources to mitigate these concerns. We believe that feedback from the community is critical to discover a solution that addresses the concerns raised in this essay , and we intend to develop this work into a signaling proposal within the coming weeks in accordance with that feedback. This work is presented by Lexa Michaelides (Hypha Co-op) and Abra Tusz (ICF), with appreciation to Udit Vira (Hypha Co-op) and Thyborg (Informal Systems) for the conversations and shared research leading to this analysis. The characteristics of Replicated Security Replicated security has the potential to drive immense value to ATOM stakeholders. Ultimately, long-lasting value will…
Excerpt (1196 of 15366 characters). Read the whole post on the forum ↗
As a smaller validator this discussion is a very important one. Many consumer chains would definitely hurt our sustainability. As it stands now our validating on the Hub is barely profitable. I think a UBI of some sort makes sense to cover expenses of new chains.
Well thought out @lexa. Perhaps consumer chains can help carry the burden somehow.
Our team recognizes the potential benefits of a UBI to help cover additional expenses associated with consumer chains. We have explored various strategies to address increased server costs and time management requirements, including raising commission rates.
Additionally, we hope that an “opt-out” provision can be [quickly] implemented for chains that fail to meet our team’s standards, as being obligated to run all consumer chains (under penalty of slashing) is less than ideal.
Ultimately, we support the concept of a UBI and appreciate your efforts to spark this discussion in the community 
You welcome all actually I support this proposal and it has been approved supporting voted by our community membership.
Thanks again for the fantastic work! There is a lot to talk about • I can’t wrap my head around the soft opt-out, I’ve been asking the definition of it a couple times already on a couple threads and it seems not matching this paper. From my understanding it was ONLY about protection bottom x validators based on cumulated VP from slashing and jailing running consumer chains to avoid additionnal costs. If it is in fact about allowing said validators to not run the chain and still get the same amount of rewards they would have gotten then I am all for UNTIL Stride and Neutron are running and we have a real feedsback on costs by bottom validators. In that 2nd version of it, I do not think it is a good idea to keep it long term for risks descibe in the essay (sibil). • Breaking ground section: The analysis of the problem is IMO right, it is delegations spread/VP. We simply can’t have such a difference between top validators and bottom one. Again my biais is that everything will eventually balance out by itself and we should all think about sustainability. I think that what is describe and the way it is heading is extremely dangerous and harmful. In no way we should even…
Excerpt (1199 of 3766 characters). Read the whole post on the forum ↗
We’ve been testing the soft opt-out on multiple recent Neutron testnets so it is extremely likely that mainnet will ship with it 
The current soft opt-out implementation merely protects the bottom 5% validators from getting slashed/jailed for not running the consumer node. They’re still considered « part of the set » but the chain does not send slashing/jailing packets against them. It doesn’t affect reward distribution either, so validators who opt not to run an additional node thanks to the soft opt-out still get rewards proportionally to their voting power.
This implementation is not meant to be permanent: a better implementation would be on the provider side and probably would affect the distribution of rewards, but it would most likely require a Hub upgrade, which is why the current implementation was preferred for now.
So with ICS v1 comes a new way to get slashed which is not to run consumer node as validator.
Not getting slashed = choice not to run the consumer chain.
Got it
Well no, at least, not right now. To get slashed, you would have to double sign on a consumer chain, then there would need to be a specific proposal type on the hub called an « equivocation proposal » that votes based on on-chain evidence to confirm that you should be slashed for double signing, and only then would you actually get slashed.
One of our goals at the Informal Systems Cosmos Hub team is to be open and responsive to feedback from the community on our work. For this reason, we aim to get all important governance proposals in front of the community on the governance forum well in advance of voting so that we can modify them with feedback received. We put up the draft Replicated Security proposal on the forum in mid-December 2022. Since then we have received a lot of feedback. This post deals with one piece of feedback in…
But yeah otherwise you’re correct, the soft opt-out removes penalties which returns choice to the validators.
Many thanks @lexa and @ala.tusz.am for your initiative and leadership to bring this very interesting and important essay for community discussion to find together the best solution to move forward. Here is my feedback and ideas: 1. Problem introduced by consumer chains • Consumer chains onboarded increase the overall costs for a large number of smaller validators, at least for a reasonable initial period until the revenue the consumer chains bring is higher than the costs. Without any actions, a large number of smaller validators would be quickly led to bankruptcy due to these large additional costs. This would lead to an even further centralization. Also, as mentioned the soft opt out is a solution from the consumer chain side, not the Cosmos Hut itself, if most consumer chains don’t add this soft opt out like Neutron then this solution wouldn’t work • Delegators care about maximizing rewards, they don’t care about reducing centralization as it is obvious from the current stake distribution in the Cosmos Hub. So delegators would be happy to onboard as many consumer chains as possible since they don’t cover any costs and just get the rewards. So we need to design a…
Excerpt (1194 of 5929 characters). Read the whole post on the forum ↗
A UBI model doesn’t seem appropriate in this context. At its core, the limited 175 slots to be an active validator is actually an open public competition.
What if we turn it around, and instead of subsidising, we asymmetrically incentivize the bottom 5%?
The consumer chain that applies for replicated security should be responsible for this incentive, and it should be part of their proposal.
They will then incentivize the bottom 5% much more than the rest of the active set, in order to get the validators to participate. The asymmetrical incentive could both be monetary and time-sensitive.
For example:
The bottom 5% gets 2x more rewards than the rest.
But for the first 6 months from launch of the cchain, they will get 3x more.
The soft opt-out feature is currently being tested - I would not be surprised if it is already going to be an option for consumer chains launching One thing that I want to point out to all respondents so far is that I am totally on-board with code-based solutions in the long-term! My heart lives in that ‘surveying the site’ section where we talk about code-based ideas for solving the problem over time. But no argument will convince me that the development work of designing, creating, and testing a new feature (new param, new way for a module to work, etc) is fast enough to address the issue I see with scaling up Replicated Security. I want something short-lived and renewable if need-be: Something like a 4 month tranche controlled by a trusted multisig until we actually have the information from seeing these consumer chains in action. We can’t possibly know what things will look like until it’s active, and I do not believe we can develop a code-based solution fast enough to protect our validator set. @gh0st - remember that the penalty for downtime on a consumer chain is jailing, not slashing! Not that this is necessarily a consolation if you are opposed to a project itself…
Excerpt (1197 of 5611 characters). Read the whole post on the forum ↗
Hi Lexa! In my ideal cosmos hub setup, there would be a re-delegating mechanism. Essentially there is a limit to how many delegations a validator can hold. Hence, for the surplus, the validator can re-delegate the delegation… except the validator can only re-delegate to other validators in the active set (+5 of the top in the inactive set). I would find this to be more of a long-term solution for the Hub-centric issue. On the consumer chain… The soft opt-out is a good solution… I agree it is fair that they are not penalised but I don’t see why validators who opt out should still get rewarded. As there is no real incentive to opt-in in the future and the validator is also rewarded for inaction, I cannot yet see how this is beneficial for the Hub or atom holders in the long-term. If we have a situation where validators #100- #175 aren’t willing to validate for consumer chains (because of the understandable cost issues), but inactive validators #175- #180 are willing to take the cash flow risk and provide this service… then I would like to encourage validators #175- #180 to be productive and contribute to the network security. But the dynamics of such situation would be…
Excerpt (1195 of 1302 characters). Read the whole post on the forum ↗
Hey!
Yes, this is my ideal vision as well! Strong re-delegation mechanism, voting power hard cap. Feels really clean to me, but long-term for sure.
As there is no real incentive to opt-in in the future and the validator is also rewarded for inaction, I cannot yet see how this is beneficial for the Hub or atom holders in the long-term.
I think it’s a strong business move to participate once it’s profitable. I would expect keen delegators to fully expect and pressure their validators to actually participate. To me, it seems long-term beneficial to the Hub because it improves our product offering and attracts more high quality consumer chains.
It is extremely frustrating to debate such important topics on a forum I do miss local meetups. • everything balances out nature part. I agree with what you are saying, my point is we should not have such a disruptive approach. Just observe nature’s ecosystems, everytime man touches it thinking it’s gonna fix it, it leads to more damage either ST/LT, the impact is always negative. Other parallel could be Adam Smith’s invisible hand theory in which at the end of the day if all the actors are acting out of personnal interest, it benefit wealthiness and common good. We should make use of that invisible hand which by nature keeps a natural balance by creating incentives such as the one I described without having strong, direct, hard to measure/balance/define impact such as the one you described. Surely yours have the benefit to be applied ST but it is taking additionnal risks and is not sustainable. The kind of proposal you are drafting would ‘yet’ again put power in the hands of few with a multisig etc… which again give a terrible look following past proposals which for some were total robbery. I know this one is not but if decentralization is what we want that’s not it.…
Excerpt (1198 of 2616 characters). Read the whole post on the forum ↗
Haha, I definitely do not think I could be this coherent in real time! Anyone debating this with me over a table would have to wait 30 min while I think quietly to myself lmao I don’t understand the criticism of ‘not sustainable’ when applied to a ST solution. It’s not supposed to be sustainable - it’s supposed to bridge the gap between an untenable circumstance and a LT solution. I am thinking about it like a patch while we go beneath the hood and work on something that fixes the core problem. Without knowing anything about the exact financial situation, I would rather not risk a LT solution arriving too late to make a difference when a patch is readily available. The problem only exists in a ST timeframe if we think about expending our validator set which puts the choice in our hands. The problems aren’t gonna magically appear tomorrow I disagree with these quite heartily. I’m anti-expansion, but this is a projected problem for validators currently in the set, not just ones who would be joining after an expansion. The problem of incurring an additional cost with few additional rewards is one that happens quite rapidly as well. Things may be monitored, but what do…
Excerpt (1199 of 3877 characters). Read the whole post on the forum ↗
lexa:Anyone debating this with me over a table would have to wait 30 min while I think quietly to myself lmao
Hahaha I’d discuss it small pieces at a time. Surely having a couple drinks while debating around the table would not help with growing headaches after 10s of minutes in 
On the whole it seems we share the same analysis of the problem which is kindda reconforting to me since I am just a small delegator without any bonds to any party.
I’ll keep an eye out for Ibra’s reaction and how this ST solution unfolds over time.
Edit: I would never think about reducing the validator set. First it would never pass. 2nd it goes against everything I said earlier about not having a direct impact and counting on the invisible 
New debate strat - tell my conversation partner that I need to think and give them an hour to get drunk before I respond lmao.
adintium: In my ideal cosmos hub setup, there would be a re-delegating mechanism. Essentially there is a limit to how many delegations a validator can hold. Hence, for the surplus, the validator can re-delegate the delegation… except the validator can only re-delegate to other validators in the active set (+5 of the top in the inactive set). I don’t think it’s about the numbers of delegations but more about the amount of delegations (VP). A simpler approach to what you are describing could be to just cap the max bounded tokens. Delegators would just have to delegate elsewhere since validators could be ‘full’. Allowing a validator to redelegate for it’s delegators is pretty risky, let’s say the cap is 5% VP but the validator is managing an extra 20% to redelegate because of the CAP, one single hack could have huge repercussions. But again I’d consider this die trying, survival mode type of measure and it goes against what I was describing earlier. adintium: As there is no real incentive to opt-in in the future and the validator is also rewarded for inaction, I cannot yet see how this is beneficial for the Hub or atom holders in the long-term. As…
Excerpt (1196 of 3222 characters). Read the whole post on the forum ↗
I appreciate the summary provided on the issue of validator funding and its potential negative impact on smaller validators. While I agree with the findings, I am not convinced that subsidizing costs and micromanaging the non-permission space is the best solution. If we were to subsidize the bottom 75 validators (5% VP) with a monthly cost of $400 for one consumer chain, the expense for a year would amount to a couple of million USD from the community pool. Given that more chains may join ICS and increase the subsidy burden, the tradeoff between subsidy and total benefit from the consumer chain may be a net negative. The urgency of the matter and the limited solutions available to address this problem are rightly pointed out by the OP. Therefore, it is advisable to work simultaneously on both short-term and long-term solutions. While a soft opt-out may be a short-term solution, it is not a reliable one and should not be solely relied upon. One potential solution that may be implemented is to set a maximum cap on delegations, which could redistribute voting power within 4-6 quarters. ( as previous attempts such as increasing the validator set, changing the staking dashboard…
Excerpt (1197 of 1747 characters). Read the whole post on the forum ↗
Thanks for opening this important conversation. Will support this.
Yes, of course it’s about the amount of delegation, not number of delegators. I don’t think there is any implementation in Cosmos that calculates active set inclusion based on the number of delegators, but happy to be proven wrong Simple cap on the max tokens is a good idea, but I guess popular validators can just spawn new nodes, and gobble more of the 175 active slots. The re-delegating idea definitely needs to be worked out more, but I think it may be interesting to model. As for inactive validators, I don’t mean inactive validators without any delegations, but if you look at the 175 set, you see there are sometimes shifts between no. 175 and no. 176, especially when there are some downtime and the active validator gets jailed. If a validator does NOT want to be in the active set, I think they can just turn off their machine, then they won’t be added into the active set. No one will force them into the active set then. About “financially stable”: There are fixed costs to running the node setup depending on each validator. Cosmos is a popular network and I sincerely doubt there will be a lack of validators who wouldn’t take the place of validators that will drop out.…
Excerpt (1194 of 1711 characters). Read the whole post on the forum ↗
@waqarmmirza - the expense for a year would amount to a couple of million USD from the community pool. Given that more chains may join ICS and increase the subsidy burden, the tradeoff between subsidy and total benefit from the consumer chain may be a net negative. My vision here is for a patch solution. I don’t think CBI should last for a year, let alone several. You’ve hit the nail on the head - it’s not a solely reliable solution and I don’t think it’s worth the effort to make a short-term solution into something perfect when we could implement it and then buy ourselves time to work out a sustainable one. A year is plenty of time to develop a longer term solution such as the others mentioned in the essay (including the max cap you’ve suggested, which we called a ‘voting power hard cap’). I think this solution holds more water than increasing the set size - I’m glad it sparks interest in you as well If I had to pick a number out of thin air, I think I would be more generous than 1% or 2% to start off - I would want to gradually reduce the hard cap and move slowly so we see how it impacts validator businesses. I could see us starting at 4.5% maybe, and then reducing…
Excerpt (1198 of 1805 characters). Read the whole post on the forum ↗
lexa: My vision here is for a patch solution. I don’t think CBI should last for a year, let alone several. You’ve hit the nail on the head - it’s not a solely reliable solution and I don’t think it’s worth the effort to make a short-term solution into something perfect when we could implement it and then buy ourselves time to work out a sustainable one. If I wasn’t clear earlier, I was talking about the subsidy for several consumer chains, not years. ~75 validators * ~400$ subsidy monthly * 6 months (hypothetical) * 5 consumer chains (again hypothetical = ~900K USD as I see it. lexa: A year is plenty of time to develop a longer-term solution such as the others mentioned in the essay (including the max cap you’ve suggested, which we called a ‘voting power hard cap’). I think this solution holds more water than increasing the set size - I’m glad it sparks interest in you as well It defiantly is an interesting idea, but we need to run multiple simulations to get to the magic number of voting power hard cap. Most of the variables are quantitative and we can derive the hard cap % mathematically. Also, I want to suggest another short-term solution that…
Excerpt (1198 of 1486 characters). Read the whole post on the forum ↗
I assume that running a validator at the bottom of the validator set is not profitable considering all operational costs. If we want to give bottom validators a chance to further develop their business i think more support is needed.
Therefore I would support a CBI for a limited time until other implemented mechanics bear fruit.
Furthermore i think there are still possibilities to increase decentralization without such drastical changes like a voting power hard cap. I think the chances of a negative impact (multiple nodes run by the same instituation) are relatively high.
The introduction of a staking transaction that lets you delegate to the validator set instead of a specific validator could help with better decentralization, especially if it would be possible to incentivize the use of it. It would also benefit delegators since they have lower risk regarding slashing.
Would love to hear your feedback.
waqarmmirza: If I wasn’t clear earlier, I was talking about the subsidy for several consumer chains, not years. ~75 validators * ~400$ subsidy monthly * 6 months (hypothetical) * 5 consumer chains (again hypothetical = ~900K USD as I see it. Ah gotcha, thanks for clarifying! It’s a fair hypothetical for sure and I’d only quibble with the idea of launching 5 consumer chains in 6 months. It’s a big chunk of money, but I would still imagine it allocated in tranches with plenty of opportunities to not dig ourselves in too deep if a longer term solution arises, or if earlier consumer chains become profitable quickly. Neutron is a brand new chain, but it looks like Stride is going to be second to the mark and that is an already well-established project. I don’t think asking the ICF for money is realistic. For one thing, I want the Hub to be less dependent on the foundation. I’m really happy they’ve done their delegation program and transparency report, but I think depending on ICF delegations to to let RS scale is the same sort of issue as depending on consumer chain side solutions - it’s not Hub-controlled, and the Hub would be vulnerable to a change in opinion from a…
Excerpt (1197 of 1443 characters). Read the whole post on the forum ↗
delegate to the validator set
That’s an interesting idea! It reminds me of Quicksilver’s rewards/risk socialization premise, which was the inspiration behind the longer term suggestion of integrating a liquid staking solution. When picking a single provider and depending on liquid staking, there are particular risks that might not exist if we introduce some sort of purely ATOM-based solution.
Almost like a soft-cap? So ATOM-holders could delegate to ‘the validator set’ and then a module would distribute them across any validator with less than the soft cap. People could still retain the right to delegate to any validator, but there could be a UI solution to encourage delegators to just choose ‘the validator set’ with an averaged commission and APR.
Yes people still should have the coice between delegating to the validator set and selecting their favourite validators.
I dont think a soft-cap is even necessary. Big validators are a very important part of the ecosystem and i wouldnt want to exclude them. Governance participation and commission might be reasonable filters though but more discussion would be needed to get the right parameters.
To bootstrap this “validator-set” delegation an increased APR for the users would be nice. Either through getting an increased portion of staking rewards distribution or an airdrop.
I am happy we are on the same page here. Let’s try to find a win-win solution for all the stakeholders. That are integral parts of the cosmos.
Didn’t realize until now that this is a thing.
lexa:Maybe most convincingly - I want a fast solution and the ICF is not going to be fast about moving delegations. No shade, just an honest view of a big organization trying to do 75 ‘delegate’ transactions with high security wallets
Hi all! Just catching up here. Thank you all for your questions and conversations – seems like there are a lot of good ideas floating around. I’ll add a bit on what I’ve read / seen above. @Cosmic_Validator – in response to your concerns about optimizing for modelling & not having human involvement , I generally agree with @lexa 's take that: lexa: good engineering takes time and we have two consumer chains looking to launch in the next few months. Engineering introduces delays as well, as we have to write specs, design a way to check all these criteria, build the feature, and thoroughly test it out. Developers are people - the dev process is just as full of delays as a multisig distribution. I would further add that I am not currently aware of a strong delegation program that is fully automated. Everything seems to be some combination of objective criteria with subjective weights allocated to that criteria based on an end-goal of the entity that is responsible for the delegation. As it relates to us, our interest is largely in ensuring that replicated security doesn’t jeopardize a healthy validator set that is aligned with the philosophy and values of…
Excerpt (1197 of 4390 characters). Read the whole post on the forum ↗
Hi ala.tusz.am: On the Hub, what we risk is some of our smaller, more active, and long-term validators being knocked out of the set (and thus losing their ability to participate in the network, a network which they have contributed a lot to) before there are viable solutions to the root problems. If we lose some of these validators, we lose a meaningful part of the Hub’s fragile culture. Maybe we could do a snapshot/poll to identify the validators that qualify as “smaller, more active and long-term”? If we are only taking the bottom 75 validators from the active set, I don’t think all 75 necessarily qualify under “smaller”. For example: Keplr wallet ( #106 ), Huobi ( #152 ), Cryptocom DeFi wallet ( #104 ). Maybe you can argue Keplr is small, but Huobi and Cryptocom probably aren’t. There are also a number of validators I would consider “professional”, for example HashQuark ( #101 ), Blockscape ( #127 ), Wetez ( #144 ) and DSRV ( #123 ). There is also stake.fish’s 2nd node on Cosmos: grant.fish ( #136 ) which has 100% commission because it’s for their grants program. Should they also qualify for the free pass? The incremental increase on their…
Excerpt (1186 of 1946 characters). Read the whole post on the forum ↗
Hi all! I’ve seen this problem debated ad nauseam elsewhere and it’s one I also am super passionate about seeing the ecosystem tackle. Thank you @lexa for your stellar work here and to everyone else for weighing in so thoughtfully. I am but a lowly hub delegator and you’ve inspired me to create an account and engage (more context at bottom since I’m new here). The problem (my POV): • validator incentives are imbalanced. • validator resources (funding, reputation, insider connections) are imbalanced. • delegator incentives are imbalanced. • delegation outcomes trend toward groupthink / centralization. • 7-figure barrier to entry values access to capital above all else. • Incumbents win, innovation is disincentivized & real economic value is left on the table. The most forward-thinking, sustainable solution I’ve seen discussed elsewhere, which I would love to see some chain implement and to hear your opinions on here is to directly tie VP% to dynamic, validator-specific minimum commission rates. More specifically, I’d envision… • Validators can utilize 0% commission only at the bottom of the active set. • A minimum floor is imposed for all validators on the…
Excerpt (1195 of 3779 characters). Read the whole post on the forum ↗
adintium: Maybe we could do a snapshot/poll to identify the validators that qualify as “smaller, more active and long-term”? Yeah, I think if the temp-check proposal passed, the next steps would be moving into a working group to do more research about exactly what type of criteria would be involved here. adintium: The above are just some examples to highlight my point, I’m not attacking any validators, just to be clear Yup, this clarity is super important! We want to ensure that the criteria (which have not been defined) is in line with the community’s goal. Your comments are a great step in that direction. adintium: By the way… if any validator from the bottom 75 would still like to validate the consumer chain, then technically they could, right? Essentially they would be able to validate without any jailing/slashing conditions? AFAIK, they could. adintium: So I guess if we implement it the way it is now, it would be up to each of the validator in the bottom 75 to show their social/community commitments then (if they can afford to), which the top 100 don’t have the privilege of and would need to validate regardless.…
Excerpt (1196 of 3755 characters). Read the whole post on the forum ↗
ala.tusz.am:temp-check proposal (something that gauges the sentiment) for the CBI aspect of this, and let’s keep a running thread to discuss the longer-term solutions?
I agree. We need to brainstorm on long-term solutions to the problem.
blacklodge: tainable solution I’ve seen discussed elsewhere, which I would love to see some chain implement and to hear your opinions on here is to directly tie VP% to dynamic, validator-specific minimum commission rates. I really like your vision. I also agreed and proposed new dynamic around tied to %VP. I do think it’s the best way to rebalance our current model. While having 0% comission available to bottom validators makes no sense since they definitely need any additional revenue, I do think there is a beneficial way for it. Let’s assume top validators won’t have access to that 0% or even enforced a higher min fee. Bottom validators could launch ‘0% campaigns’ for a limited period of time (ex couple months) to attract delegation from the top and also new comers’s delegation. My ‘original idea’ was only to higher the min commission for top validators thus allowing bottom validators to have another leverage to attract delegations but you are taking it a step further which tbh sounds great. I do think it’s the only sustainable way of doing things, but naturally counting on rebalance from our delegators instead of enforcing any direct VP hard cap, capital…
Excerpt (1196 of 1451 characters). Read the whole post on the forum ↗
Has there been any progress on this topic? As Stride nears becoming a consumer chain, validators in the bottom set will see their losses double. This problem is not limited to the bottom set, as other validators are also unlikely to earn anything from Neutron and Stride in the next few months. A solution that supports the costs of validators is becoming increasingly necessary and urgent.