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 come from consumer chains that find product-market fit and generate meaningful activity on their chain. This value might flow to ATOM holders in the form of MEV, fees, and/or inflationary token rewards. The benefits to the Hub will increase as consumer chains attract more users, generate more activity, or provide important services in the Interchain.
Based on the design of replicated security, the history of economic growth and innovation, and characteristics of complex systems â we can make the following assumptions about the ATOM economic zone that will form around Replicated Security:
- It will take time for consumer chains to find product-market fit and generate meaningful activity
- The relationships between chains in the ATOM economic zone will be emergent (we cannot predict what relationships will develop)
- As more synergistic relationships develop in the ATOM economic zone, more value will be created
- On-boarding many chains (that meet a certain quality standard) and off-boarding those that donât succeed is likely to be a more effective strategy than trying to pick winners.
However, there are material limitations to the Cosmos Hubâs ability to on-board consumer chains. These limitations are that the validators that support Replicated Security bear all the costs for each additional consumer chain they run, and that these consumer chains need time to generate enough value to offset that cost.
Two perspectives: delegators and validators
From a short-term perspective, delegators have everything to gain and nothing to lose from onboarding new chains and reaping the immediate tangible benefits.
Tokens from consumer chains flow through the Hub in the following order:
- The Hub gets some tokens from consumer chains (e.g, 25% of fee revenue).
- Validators take commission on this (roughly 0-20%, with the majority below 10%), leaving the majority of the tokens as staking rewards for delegators.
- Delegators receive the remaining 90% (roughly) as staking rewards proportionate to their own stake.
While validators stand to benefit in proportion to their own staked ATOM (as well as commission on the stake delegated to them), they also incur an additional cost from running a new node for each consumer chain. Cost estimates in this area have been very hard to nail down because each validator runs their infrastructure differently, but estimates point to a range of about $300 - 800 per month.
These costs are incurred regardless of a validatorâs position in the Hubâs set, and while $800/month might not be a huge expense for the top 20 validators,it could make a large impact on a smaller validatorâs operating expenses.
In short, consumer chain rewards are expected to follow the same distribution model as the Hubâs block rewards: proportionate to stake. Combined with the awareness of how validators incur costs, this paints a telling picture of how smaller validators might struggle to support additional consumer chains without additional aid.
The self-reinforcing cycle of stake
To optimize for success, we need to encourage a Provider <> Consumer chain culture that allows strong chains and useful services to emerge. Projects which donât thrive might be offboarded (decreasing costs) and profitable chains may stick around and provide increasing revenue to the validator set, but it will take time to get there. This means that many chains may lease security from the Hub well before they are profitable for small validators, which are limited by the stake-weighted rewards they receive.
The discrepancy between large and small validators could increase as stake centralizes with the upper-half validators, who have access to a higher proportion of rewards. In the long-term, replicated security might address this by increasing the overall rewards coming into the Hub - but this only works if small validators manage to stay afloat as Replicated Security scales.
Hub culture depends on a healthy validator set
We need a strong, healthy culture in the Hub to foster the pioneering work being done by prospective consumer chains, and the validator set is a critical aspect of our culture. The Hub prides itself on having a high-quality validator set â itâs what makes us so attractive to potential consumer chain projects.
Voting power distribution is an additional point of appeal to consumer chains because it means less money is needed to be cost-covering for the smallest validators. When stake is evenly distributed, all validators might expect to receive approximately the same share of rewards, but if the top of the set receives 100x more rewards than the bottom, the rewards accruing at the top are consequently 100x higher than what is needed to be cost-covering.
We need a set that is decentralized in terms of voting power and infrastructure; is reachable and responsive to consumer chain concerns, such as upgrades; and familiar with the software as it develops.
We canât create this culture without mitigating systemic issues that threaten the health of our validator set. As things stand, we run the risk of big validators getting even bigger while smaller operators are pushed out of the business, and there is a limit to how much any individual validator can address the problem alone.
Surveying the site
In the long-term, balancing the stake distribution would allow validators to access rewards more uniformly and curb the self-perpetuating cycle of stake-weighted income. While the root of this problem is the distribution of stake on the Hub, this is not a problem that will be solved overnight.
Many ideas touching on this issue have been raised and explored already, and detailing out the next steps for any of them is beyond the scope of this work. Continuing to research and work on solutions like these is part of contributing to a rich solution space, and we present them here as a starting point for anyone interested in taking them up:
- Expanding the validator set, which allows validators to enter the set but which has not shown evidence of shifting the overall distribution of stake in the long-run.
- Establishing a minimum commission, which would force a minimum proportionate income for validators, but not address the top-heavy distribution of stake.
- UI solutions for encouraging staking with smaller validators and awareness of stake distribution, such as on Kujira.
- Implementing a voting power hard-cap, in which validators cannot receive delegations after hitting a given threshold of voting power. A similar solution has been implemented on Ethereum (where each validator has a maximum voting power of 32 ETH), though Ethereum does not cap the validator set size.
- Working with liquid staking providers and community owned treasuries to redistribute stake â this approach entails governance coordination between communities, liquid staking providers (and other entities that hold a lot of stake) to redistribute network stake more evenly in accordance with a set of conditions.
- Modifications to how the Distribution Module allocates staking rewards (e.g., Using additional criteria as opposed to strictly being stake-weighted).
Planning a solid foundation
Consumer chains will take time to find product-market fit but as Replicated Security scales, we need a way to bootstrap a dynamic network of consumer chains while maintaining a quality validator set. This means allowing small validators to access the upside of successful projects without unmanageable operating costs.
On the consumer chain side, something like the soft opt-out could address this - a lower percentage of validators (e.g., 5%) could be excused from running a particular chain while still receiving rewards. The last 5% of the validator set by voting power currently comprises 60 - 75 validators and letting them opt out would drastically reduce their costs.
However, this is a consumer chain fix, not one that the Hub controls. As Replicated Security scales, we need a Hub-centric solution that keeps our validator set healthy and decentralized enough to attract high quality consumer chain candidates.
Breaking ground
One method of support is subsidizing a base-level cost for validators that meet a certain set of criteria. This enables Cosmos Hub governance to shape the validator set by subsidizing smaller validators that perform their duties responsibly.
This solution would enable smaller validators that add value to the network to continue to operate, while longer-term issues such as stake distribution are addressed or consumer chains become more profitable.
Regardless of where funds come from, some criteria must also be identified to determine which validators receive a subsidy. Potential criteria include:
- Currently in the lower x% of the active set, as the intent is to produce a means for smaller members of the set to thrive rather than introducing new members or increasing rewards to larger operators.
- Currently running nodes for all Hub consumer chains, because this basic income is meant to support validators who are contributing to the Hubâs Replicated Security offering.
- Sufficiently high uptime.
- Quick upgrade operations both for the Hub and consumer chains.
- Reachable and responsive on Hub communication platforms such as Discord.
- Participation in feature testing and software feedback, such as by being active on Cosmos Hub testnets.
The subsidy could be created by changing how tokens from the Hubâs distribution module are allocated to validators, and this could apply to consumer chain revenue only, or include the Hubâs block rewards too. Instead of being 100% stake-weighted, a portion could be allocated to a subsidy which is distributed based on a set of criteria. However, this essay will focus on a much simpler and more immediate method which doesnât require additional engineering work. Funds for the subsidy could come directly from the Cosmos Hub Community Pool, or from a pool of money contributed up-front by consumer chains onboarding to the Hub. This situation has benefits and tradeoffs, which we examine below from the perspective of the Cosmos Hub as a provider chain.
This method currently entails:
- Deciding upon a set of criteria
- Using governance to delegate authority to a group of people to monitor validators against those criteria and dispense subsidies appropriately
- Making a community-pool-spend proposal on the Cosmos Hub to release funds to a multi-sig wallet that will dispense the subsidies
In the future, it may be possible to automate some aspects of the above process via smart-contracts, but that is outside of the scope of this essay. The major differentiator between the Community Pool option and the Distribution Module option is the source of funding; the differences in how they are implemented is a side effect of that.
The benefits of this approach are that it can be employed immediately, without having to negotiate with a counterparty or develop new code for the Hub. It also enables the Cosmos Hub community to have fine-grained control over the conditions for receiving conditional basic income.
The downside of this approach is that the subsidy comes at the cost of the provider chain, requires a hands-on and labor-intensive approach, and is more prone to capture due to the current state of DAO tooling. Additionally, this could create a certain amount of downward sell pressure against ATOM as operators need to liquidate tokens to cover costs, though itâs unclear what impact this would have, or if this is already something that occurs in regular validator operations.
Some open questions around this idea:
- How much money should be allocated to a conditional basic income program? How long should we expect to subsidize costs?
- What should the criteria be? How do we monitor and check them?
- Who could sit on this multisig? Are there conflicts of interest that we need to be aware of?
- How would conditional basic income interact with the soft-opt out? Does one preclude the other? Are there any synergies between the methods?
Structural support: sybil resistance
A major concern present alongside this solution is that large validators could split up into many smaller nodes to become eligible for conditional basic income. It is worth noting that this risk is also present in the soft-opt out methodology, which might enable mid-sized validators to split stake into smaller nodes to avoid the costs of running consumer chains but still reap the rewards.
In the short-term where a subsidy is human-controlled, the multisig responsible for evaluating validators would have to be aware of this risk.
This sybil behaviour becomes more problematic when there is no human step in the process. A fully automated rewards/subsidy system (or soft-opt out) could be gamed by a wealthy validator, and the highest risk is that of an individual whale with enough ATOM to keep several nodes in the set purely by self-delegation. However, in a community that values decentralization, there will likely be a strong watchdog culture which whistle blows on sybil behaviour and discourages delegations to a validator who did something like this. We believe that the intangible social cost of a Sybil attacks by a validator would be sufficiently high to dissuade validators from risking their reputation in order to offset the cost of running an additional node.
Conclusion
The above solutions are short-term but viable solutions to the centralizing-effects that replicated security might have on the Cosmos Hub validator set. It will take community effort and coordination to determine which solution (if any) it believes is most viable. Weâve put together these ideas as a way of exploring the problem space in a Hub-focused way, and plan to evolve it into a signalling proposal in accordance with community feedback in order to accommodate the needs of the growing ATOM economic zone and its stakeholders.
Ultimately, we would recommend that consumer chains also think about this problem as they come to launch on the Cosmos Hub.
I do miss local meetups.
