Obol DVT on Cosmos

Hey guys, this is Mikey Lee from Cosmostation - Cosmostation is an enterprise-level crypto infrastructure company operating validator nodes and building user interfaces for ~70 networks and 500k+ users globally. Since 2018, we’ve been building tools like Mintscan block explorer, Cosmostation browser extension wallet, and Cosmostation Mobile (iOS & Android) and have been helping protocols scale by providing these protocol infrastructure services.

Cosmostation has been collaborating with Obol as one of the distributed validators since the beginning of this year. Today, with the experience & knowledge earned during the operation, I’d like to explore how DVT can be introduced into the Cosmos Interchain ecosystem and suggest a potential use case for Obol DVT in addressing the stake centralization problem.

In the dynamic world of the proof-of-stake blockchain industry, Cosmos stands out as an ecosystem with one of the most diverse, active validator sets throughout the entire crypto scene. At the same time, we face an issue of stake centralization that threatens the true decentralization of Cosmos. In this article, we will explore a potential solution to this problem–implementing Distributed Validator Technology by the Obol Network into the Cosmos validator set.


Cosmos and DVT
Obol is currently focusing on implementing DVT on Ethereum mainnet, but in the longer term, DVT is a concept applicable for any Proof of Stake network with multiple validators, i.e. Cosmos. In this article, I will be focusing on the issue of Cosmos’ stake centralization and see how DVT can help solve it.

Before getting to the point, let’s first look at how Cosmos fundamentally differs from Ethereum. Ethereum and Cosmos are built on 2 different types of PoS mechanisms.

On Ethereum’s proof-of-stake based consensus mechanism, it takes approximately 15 minutes for a block to finalize. The effective balance of each validator is capped at 32 ETH, setting the limit on voting power and computational requirements for each node. When the chain is not finalizing, non-participating validators receive increasingly large penalties–this design allows for the network to restore itself in an event where large numbers of validators fail.

Cosmos, on the other hand, has instant finality - the chain halts if validators do not reach consensus, but it ensures the finality of each block once it’s made. Unlike Ethereum, Cosmos does not put a cap on the amount of effective stake a single validator can have, and each Cosmos chain can be configured to cap the number of active validators–there is a lesser number of validators on Cosmos than on Ethereum.

The implications of stake centralization on Cosmos and Ethereum are not quite the same because of these differences.

Problem: Stake Centralization
Now with the basic concepts of Cosmos and Ethereum staking explained, let’s look into the problem we have at Cosmos: stake centralization (low Nakamoto Coefficient). If you look at Mintscan’s validator page, you’ll see that the top 8 validators hold more than 33.33% of the entire network’s stake (36.19% at the time of this writing). Of course, Ethereum also has an extremely concentrated stake: Lido, one of the most prominent liquid staking providers on the Beacon chain, is now live with 31.99% of the total network stake. However, Lido has its stake almost evenly split with 30 separate pool operators, which means that the actual stake is distributed among many parties.

Attempts to solve the problem
For Cosmos, centralization in stake has always been a concern, and there have been some attempts to solve this problem:

Increasing the validator set could lower the minimum amount of assets required to join the validator set. However, this does not affect the Nakamoto Coefficient.

We could also implement a soft cap or a hard cap on the validator stake system. This could split one giant validator, increase the total number of validators, and mitigate the single-validator centralization risk. However, the entity behind the split validators would still be the same single party. Also, this could potentially increase the average required capital to become an active validator.

Risk in Replicated & Mesh Security
On top of stake centralization, we also have to consider the replicated/mesh security narratives. For those of you who’re not familiar, replicated security & mesh security allow a blockchain to leverage another blockchain’s validator set to “borrow” the level of security (for Ethereum folks: similar to EigenLayer). The incentive mechanism behind this is to borrow the security from a chain with bigger, higher TVL and incentivizing the validators with the additional work they have to perform to validate the extra network. At the same time, replicated security instantly doubles (more or less) the potential threat to the chain’s security as the centralized voting power of certain validators on the provider chain gets equally projected on the consumer chain with the replicated security implementation. This would only make the stake centralization problem even worse. Imagine that the top few validators go offline. Not only will the parent chain halt, but all the children chains would go off accordingly. In short, replicated security replicates security but also replicates the potential risks associated with stake centralization.

What DVT can do in Cosmos
So, now what? TL;DR: Distributed Validator Technology (DVT) can be utilized to solve the stake centralization problem in Cosmos by distributing the top validators’ stake. With DVT, the top validators can split their stake, thereby reducing the concentration of voting power and increasing the decentralization of the network. In a perfect world, the top 8 validators on Cosmos would integrate DVT into their operation to split their stake. By doing so, they would be able to mitigate risks associated with stake centralization and enhance the overall resilience of the network. This could distribute the clogged, centralized voting power and create a healthier and more robust ecosystem.

However, one of the challenges in implementing DVT in Cosmos is establishing practical incentives for larger players, such as centralized exchanges, to adopt DVT. Currently, there is little visible motivation for these entities to split their stake and allocate additional hardware costs to implement DVT. In order to encourage the participation of larger validators, deeper research and discussion are necessary to develop an incentivization model that aligns with their interests.


DVT has a great potential to bring significant growth to the Cosmos Interchain ecosystem with its stake distribution model. Still, as mentioned above, there are no obvious incentives for big validators to implement DVT. Further exploration of the potential benefits, risks, and economic incentives of implementing DVT in Cosmos is crucial - the community, along with researchers and developers, needs to create compelling use cases, and incentivize large validators to support DVT. I believe that Cosmos can leverage DVT as a powerful tool to boost decentralization and security, so let’s continue to discuss, explore the possibilities and work together to create a more decentralized and robust Cosmos.


Hey Mikey

Thanks for initiating this discussion. Glad you bring this up. I do believe there is a huge value add in applying DVT on Cosmos to further decentralize its voting power within a limited validator set. We must make it more resilient, way more resilient than it is today. With the current Cosmos design it will be rather difficult though. As you said, there is no incentive for top players to adapt DVT.

So what could be done to change this:
Modifying the tokenomics where more inflation flows to DVT generated/ran validators. Yes, this requires deep changes on the Cosmos-SDK but would have a direct, positive effect. DVT validators could be registered through on-chain governance and all registered validators get additional “rewards/inflation”. Additionally, consumer chains can also favor DVT registered validators in rewards, since they also do benefit from a more resilient provider chain.

Another thing to keep in mind is latency. While producing blocks with sharded keys might be doable on the Hub with 6s block time, I doubt we’ll see good performance on consumer chains with lower block times (like Neutron). So this as well, requires further engineering on the Cosmos-SDK side.

It would be interesting to know how the Cosmos community in general stands to this. If the sentiment is rather positive, we must check who has the resources to develop a POC rather sooner than later (as it will take a lot of testing time). One thing to develop is a charon-like middleware by Obol, and Cosmos-SDK modifications by entities like ICF, Informal Systems or even Notional.