.png)
Solana employs a Proof-of-Stake (PoS) consensus algorithm where a designated leader, chosen for each slot, produces a new block. The leader schedule is randomly determined before the start of each epoch, a fixed period comprising multiple slots. Leaders generate a Proof-of-History (PoH) sequence (a series of cryptographic hashes where each hash is computed from the previous hash and a counter) to order transactions and prove the passage of time. Transactions are bundled into entries within a block, timestamped by the PoH sequence, and the block is finalized when the leader completes its slot, allowing the next leader to build upon it. A slot is optimistically confirmed when validators representing two-thirds of the total stake vote on it or its descendants, signaling broad network agreement.
When forks arise (situations where multiple conflicting chains exist), validators must decide which fork to support through their votes. Each vote commits a validator to a fork, and lockout rules restrict them from voting on conflicting forks for a duration. Solana’s fork choice rule governs when a validator can switch to another fork, ensuring the network converges on a single, canonical chain.
In the Agave client, the Tower struct, defined within the core/src/consensus.rs file, serves as the central data structure for managing a validator’s voting state. It plays a pivotal role in tracking the validator’s voting history, enforcing lockout rules to prevent conflicting votes, and facilitating decisions about which fork to follow in the presence of chain splits. Within the Tower, a vote_state field (implemented as a VoteState object from the solana-vote-program crate) maintains a detailed record of all votes cast by the validator along with their associated lockout periods, ensuring adherence to consensus rules. The struct also keeps track of the most recent vote through its last_vote field, capturing the latest transaction submitted by the validator. Additionally, the Tower includes threshold_depth and threshold_size parameters, which define the criteria for confirming slots; by default, these are set to a depth of 8 slots and a stake threshold of two-thirds, respectively, determining the level of agreement required from the network.
When a validator needs to vote on a slot, it relies on the Tower’s record_bank_vote method to execute the process seamlessly. This method begins by extracting the slot number and its corresponding hash from a Bank object, which represents a snapshot of the ledger at that specific slot. It then constructs a Vote object encapsulating the slot and hash, formalizing the validator’s intent. Finally, it invokes record_bank_vote_and_update_lockouts, which in turn delegates to process_next_vote_slot to update the vote_state, ensuring that the new vote is recorded and lockout rules are applied accordingly.
Once a validator casts a vote on a slot in Solana, it becomes temporarily barred from voting on conflicting slots, a restriction governed by the 2^N lockout rule, which imposes an exponentially increasing duration with each subsequent vote. Initially, after a validator’s first vote ($N=1$), the lockout period spans $2^1 = 2$ slots, but with a second vote ($N=2$), the lockout for the first vote extends to $2^2 = 4$ slots, while the second vote introduces a new lockout of $2^1 = 2$ slots. More generally, after $N$ votes, the earliest vote in the sequence is locked out for $2^N$ slots, ensuring the validator remains committed to its chosen fork.
This mechanism is implemented within the process_next_vote_slot function, which is invoked by record_bank_vote to update the validator’s voting state. At the heart of this exponential lockout is the confirmation_count field, where each new vote increments the confirmation_count of prior votes. The confirmation_count is part of the Lockout struct, and it is used to determine the number of slot for which a vote is locked out as $2^\text{confirmation\_count}$.
To illustrate, consider a validator voting on slots 2 and 3 of a fork. With its first vote on slot 2, the confirmation_count is set to 1, resulting in a lockout of $2^1 = 2$ slots, meaning the validator is barred from voting on a conflicting fork until after slot 4. When it votes on slot 3, the confirmation_count for slot 2 increases to 2, extending its lockout to $2^2 = 4$ slots, or until slot 6, while slot 3 starts with a confirmation_count of 1, locking out until slot 5. Consequently, the validator cannot vote on a conflicting fork, such as slot 4 on a different chain, until after slot 6.
Fig. 1: Graphical representation of a validator V switching fork, with relative $2^N$ rule for lockouts.
Through this mechanism, Solana ensures that validators remain committed to their chosen fork for the duration of the lockout period, preventing double-voting or equivocation that could destabilize the network.
Validators in Solana’s consensus process sometimes miss voting on slots due to network delays or operational issues. As noted in SIMD-0033 (Timely Vote Credits), missing votes or submitting them late reduce rewards, prompting some validators to engage in backfilling, which is the retroactive voting on missed slots in a later transaction. For instance, a validator skipping slots 4 to 6 might vote on it at slot 7, claiming credits to maintain staking rewards and network contribution. However, Solana enforces strict ordering: the check_and_filter_proposed_vote_state function ensures slots in a vote transaction exceed the last voted slot in the VoteState, rejecting earlier slots with a VoteError::SlotsNotOrdered. This consensus-level check, executed on-chain, means that backfilling must advance the voting sequence, such as including slots 4 to 6 at slot 7, only if the last voted slot was 1 or earlier (see Fig. 1).
It is worth mentioning that, despite this practice appears healthy, improper backfilling can disrupt the network. When a validator backfills by voting on missed slots, each new vote extends the lockout period of earlier votes through Solana’s $2^N$ rule, deepening its commitment to the chosen fork. If these slots belong to a stale fork, the prolonged lockouts may prevent the validator from switching to the main chain, potentially delaying consensus if many validators are similarly affected, thus hindering the network’s ability to confirm new blocks.
To address this, Ashwin Sekar from Anza proposed SIMD-0218: Intermediate Vote Credits (IVC), which integrates backfilling into the protocol by crediting intermediate slots at the landing slot’s time. This controlled approach is meant to eliminate risky backfilling mods, ensuring liveness and fairness while allowing credit recovery.
Detecting backfilling in Solana poses a challenge because, as previously discussed, voting on past slots is not prohibited and can occur under normal circumstances, such as network delays or validator restarts. However, fluctuations in network-wide TVC effectiveness offer a lens to identify potential backfilling. A query obtained using Flipside reveals that TVC Effectiveness fluctuates over time, with a notable network-wide dip during epoch 786.
While a more significant dip occurred between Epochs 760 and 770, we focused on the more recent period due to the availability of granular internal TVC data, acknowledging that further investigation into historical valleys is warranted to fully understand network voting dynamics.
For this analysis, we focused on the date range between 2025-05-11 and 2025-05-15.
Fig. 2: Network TVC Effectiveness obtained using Flispide, cfr.here
Since Dune is the only data provider granting easy access to on-chain voting data, we developed a dashboard with the goal of detecting potential instances of the backfilling practice. Precisely, we developed two methods; however, both remain probabilistic, as backfilling cannot be definitively confirmed without direct access to the validator's intent.
The first method, dubbed the "Simple Mod", examines voting behaviour focusing on the relationship between the number of vote transactions signed by a validator in a single slot and the slot distance between the landing slot of those transactions and the slot of the recent block hash they reference. For example, if a validator submits 10 vote transactions in slot 110 with a recent block hash from slot 108, the distance is only 2 slots, significantly less than the number of transactions. This pattern suggests backfilling because the validator is likely catching up on missed slots in a burst: the short distance indicates the transactions were created in quick succession at slot 108, possibly to retroactively vote on slots 99 to 108, a common backfilling strategy to claim credits for earlier missed votes in a single submission, rather than voting incrementally as the chain progresses.
Fig. 3: N° of possible backfill detected using the “Simple Mod” model, cfr.here
Figure 3 shows the hourly aggregation of possible backfill detections using the “Simple Mod” method. We mainly have two peaks in the data: the first occurs at 00:00 on May 11, 2025, likely triggered by a widespread network issue or a collective validator restart, as the validators identified during this spike do not reappear in subsequent instances, suggesting a one-off event rather than sustained backfilling. The second peak, around 11:00 AM on May 13, captures a more persistent trend, involving the most frequently detected accounts across the dataset. By examining the frequency of these detections, we identified three validators consistently engaging in potential backfilling, indicating an active practice of retroactively voting on missed slots to maximize credits, alongside one validator exhibiting milder behavior, with fewer instances that suggest a less aggressive approach to catching up on voting gaps.
The second method, dubbed the "Elaborate Mod", takes a broader perspective, analyzing voting patterns to identify validators that consistently submit an unusually high number of vote transactions in single slots across multiple instances. We aggregated vote transactions hourly, flagging validators that submit more than 4 distinct vote transactions in a slot. We chose this threshold because, while a leader might include multiple vote transactions from a validator due to network latency or validator restarts, exceeding 4 votes in a single slot is unlikely under normal conditions where validators typically vote once per slot to advance the chain. We further refined the detection by requiring this behaviour to occur in over 10 distinct hourly intervals, reflecting that such frequent high-volume voting is less likely to stem from typical network operations. This pattern could indicate backfilling because validators engaging in this practice often batch votes for multiple missed slots into a single slot’s transactions, aiming to retroactively fill voting gaps.
Fig. 4: N° of possible backfill detected using the “Elaborate Mod” model, cfr.here
Figure 4 presents the hourly aggregation of possible backfill detections using the "Elaborate Mod" method, revealing a distinct pattern that complements the Simple Mod analysis. Unlike the dual peaks observed previously, this method identifies a single prominent peak around 11:00 AM on May 13, 2025, which aligns precisely with the second peak detected by the “Simple Mod”. The absence of the earlier peak from May 11 at 00:00 underscores the Elaborate Mod’s design, which reduces sensitivity to false positives caused by transient events, such as validator restarts or network-wide issues, focusing instead on sustained high-volume voting patterns indicative of deliberate backfilling. Notably, the Elaborate Mod detects a larger cohort of 120 validators engaging in potential backfilling, reflecting its broader scope in capturing consistent voting anomalies over time. Among these, the most prominent backfiller mirrors the primary validator identified by the “Simple Mod”.
Fig. 5: Vote credits earned out of the theoretical maximum, higher is better. Better vote effectiveness translates directly to higher APY for delegators. To make very subtle differences between validators more pronounced, we show the effectiveness over a 24h time window. This means that short events such as 5 minutes of downtime, can show up as a 24-hour long dip. Note the log scale!
Having identified potential backfillers, we now turn to assessing whether this practice might destabilize Solana’s consensus mechanism. As previously noted, improper backfilling can extend the lockout periods of stake committed to a stale fork, potentially slowing consensus by delaying validators’ ability to switch to the main chain. Figure 5 leverages internal data to provide a granular view of TVC effectiveness, tracking the performance of various validators. The purple validator, flagged as a backfiller by the “Elaborate Mod”, consistently outperforms others in TVC effectiveness under normal conditions, likely due to its aggressive credit recovery through backfilling. However, during vote-related disruptions (such as those coinciding with the May 13 peak) its effectiveness drops more sharply than that of vanilla validators, suggesting prolonged adherence to a wrong fork. This heightened sensitivity indicates that backfilling, while beneficial for credit accumulation, may amplify the risk of consensus delays if many validators on a stale fork face extended lockouts, raising questions about the broader safety of Solana’s consensus mechanism despite the validator’s overall performance advantage.
In this analysis, we focused on modifying the consensus to backfill missed vote opportunities. Improper backfilling can exacerbate vote lagging, strain network resources, and extend lockouts on stale forks, potentially delaying consensus.
We developed two methods to potentially detect validators involved in this practice, the “Simple Mod” and “Elaborate Mod”. Our data analysis from May 11 to May 15, 2025, highlighted periods of potential backfilling. The Simple Mod identified bursts of vote transactions exceeding the slot distance to their recent block hash. At the same time, the Elaborate Mod flagged validators consistently submitting high vote counts across multiple instances, detecting 120 validators with one primary backfiller overlapping between methods. Analysis of TVC effectiveness showed that while backfillers often outperform in credits, they face sharper drops during vote-related disruptions. This suggests prolonged adherence to wrong forks that could hinder consensus if widespread. The introduction of SIMD-0218 (Intermediate Vote Credits) offers a promising solution by formalizing backfilling within the protocol, mitigating risks like vote lagging while ensuring fair credit recovery. Nonetheless, the interplay between backfilling and consensus stability raises ongoing questions about Solana’s long-term resilience, warranting further investigation into network-wide voting patterns and their impact on liveness and fairness.
Written by Viswanadha Modali and Umberto Natale
The merge introduced slashing measures to prevent malicious validators from attacking the network. Slashing is triggered when a validator violates the Casper Finality Gadget (Casper FFG) rules or the LMD GHOST consensus. The former is needed to guarantee Ethereum’s economic finality, the latter is needed to solve the nothing-a-stake problem.
Precisely, validators are required to submit attestations which correctly identify the Casper FFG source, target and head of the chain. Violating the Casper FFG rule means that a validator makes two differing attestations for the same target checkpoint, or an attestation whose source and target votes "surround" those in another attestation from the same validator.
Additionally, if selected as a proposer, the validator would also be required to propose the block. Violating the LMD GHOST rules means that a validator proposes more than one distinct block at the same height, or attests to different head blocks, with the same source and target checkpoints.
In order to trigger a slashing event, the validator should try to attack the chain, or simply it’s running a misconfigured setup. The slashing amount corresponds to
where the numerator corresponds to the effective balance of a validator (i.e. the total amount of ETH a validator is staking that is effectively used within the consensus), while the denominator is a quotient dependent on the Beacon chain state.
Prior to Pectra, the effective balance of the node was 32 ETH, though the quotient historically changed. Precisely, the quotient was 128 post-merge, 64 in Altair, and 32 in Bellatrix. This 32 ETH quotient resulted in a slash that amounted to 1 ETH.
Once the validator is slashed, it is forced to enter the exit queue, and withdrawals are delayed by around 36 days (8192 epochs).
There is a second penalty that is applied, which corresponds to a correlation penalty - i.e. it is proportional to the stake that is committing the offence - and can be written as
where, in addition to the effective balance, we now also have the total stake that is committing an offence (the balance to be slashed) and the total stake. The slashing multiplier 3 was previously equal to 2 in Altair.
During the whole exit process, the validator also incurs additional penalties for missing attestations. Since the attestation penalties are very minimal compared to the previous one, for simplicity’s sake, we will focus on the major slash.
The Pectra upgrade, amongst many other things, changes the maximum effective balance of nodes from 32 ETH to 2048 ETH. With regards to slashing, the minimum slashing quotient is set to 4096, while the slashing multiplier remains the same as the Bellatrix one.
Another important point to note is that the ‘effective balance’, which was once a fixed number (32), is now variable. This provides node operators with a choice on how much ETH to allocate to each node; the amount of ETH allocated to each node will alter the slashing risk calculus. For example, if a validator chooses to continue with 32 ETH on their node, the slashing amount incurred will be 32/4096 = 0.008 ETH. In contrast, if they consolidate to the maximum limit of 2048 ETH, the slashing they incur will be significantly more, 2048/4096 = 0.5 ETH.
Also, for the correlation penalty, we have 3 * 32 / 1,069,029 = 0.00009 ETH for a small validator, and 3 * 2048 * 2048 / (32 * 1,069,029) = 0.36783 ETH for a validator with the max allowed effective balance. Here, 1,069,029 is the number of active validators at the time of writing.
In these risk calculations, we are primarily attributing slashing to misconfigurations. Hence, having more nodes does not exponentially scale up the incidence of slashing, as it is highly unlikely that in a 64-node setup, all 64 nodes are misconfigured.
The ideal set-up for any validator greatly depends on their priorities. The prime benefit of Pectra is that you can customize your set-up for different objectives. Below is a diagram of how the slashing amount scales as the ETH staked on that particular validator key increases. With 32 ETH nodes incurring a slashing penalty of 0.0078 ETH, and nodes with 2048 ETH on them incurring a slashing penalty of 0.5 ETH.
The only variable cost here is the cost of the infrastructure itself. But this isn’t substantial unless we are talking about many 1000s of validator keys. In most setups, one could run 100s of validator keys on a Kubernetes pod, and many pods could point at one beacon node. So, if optimized correctly, the infrastructure costs of running many 32 ETH validator keys might not be substantially higher than with fully consolidated sets.
A fair question to ask at this point would be, why consolidate at all? One strong advantage of partial consolidation is quick withdrawal. Prior to Pectra, all withdrawals happened on the consensus layer and required the exit of the 32 ETH validator, with the churn limit for such exits calculated as the maximum between the minimum churn limit per epoch (set by default to 4) and the number of active validators divided by 65,536. At the time of writing, this amounts to around 16 validators per epoch (i.e. 6m and 30s).
However, with Pectra you now have the option to partially withdraw funds from a validator and have the funds available to you instantly (within a few blocks). As opposed to exiting your validator, waiting for it to go through the exit queue, and waiting an additional 27h in withdrawal delay to get your ETH back. You can think of all balances above 32 ETH as balances that are available for instant unstaking.
This is now another option you have available with Pectra. For a higher slashing risk, you can have greatly increased liquidity on your staked ETH.
The Pectra upgrade transformed the ETH staking industry from a monolithic experience to one with a great degree of variability and choice. In the near future, validators and liquid staking providers will have bespoke offerings and vaults, allowing users to choose between maximizing ARR, maximizing liquidity, and minimizing staking risk. All of these different validation strategies will be directly linked to how node operators configure their setups and how effectively they maintain their ETH nodes.
In our previous article about Pectra, we mentioned that for our customers who want a 0x02 validator, Chorus One will implement a custom effective balance limit for 0x02 validators, set at 1910 ETH. This accounts for around 2 years of compounding rewards at a rate of 3.5% annualized, before reaching the 2048 ETH cap, allowing for sustained reward optimization.
Chorus One is actively researching various validation strategies now available with Pectra and is bringing this variety right to our delegators.
At Chorus One, we’ve been long time supporters of the Cosmos ecosystem: we were among the genesis validators for the Cosmos Hub and multiple other flagship appchains, contributed cutting edge research on topics such as MEV, actively participate in governance, and invested in over 20 Cosmos ecosystem projects through our venture arm such as Celestia, Osmosis, Anoma, Stride, Neutron.
The Cosmos vision resonated with many for different reasons. It offered a technology stack that empowered user and developer sovereignty, enabled a multichain yet interoperable ecosystem, and prioritized decentralization without compromising on security. Since its inception, each component of the Cosmos stack on a standalone basis could command multi-billion-dollar outcomes if properly commercialized:
Additionally, many ideas that are now widely recognized were first pioneered by the Cosmos ecosystem before gaining mainstream adoption.
However, the Cosmos Hub has been plagued with divided strategic direction, governance drama, little focus on driving value accrual and commercialisation, and slow iteration leading it to being outcompeted by its more agile, product-focused peers, that now have far exceeded the Hub in terms of performance, developer ecosystem, applications, and ultimately economic value creation.
Some initiatives didn’t get the results expected for the Hub, and one example is Interchain Security. Early on, we raised concerns that this model could lead to more centralization, and then explained the economic issues with Replicated Security. Alternatives like Mesh Security, Babylon, and EigenLayer have since entered the space, offering teams a wider range of shared security models to choose from. As a result, only two chains adopted ICS: Neutron and Stride. Recently, Neutron decided to leave ICS, leaving Stride as the only remaining ICS chain that will use Replicated Security from now on.
A major change in Cosmos was long overdue, and we believe it began with the acquisition of Skip Inc. The team rebranded as Interchain Labs, a subsidiary of the Interchain Foundation (ICF), now leading Cosmos’ product strategy, vision, and go-to-market efforts.
In this piece, we seek to present the bull case for what’s ahead for Cosmos, driven by a reformed focus on the Cosmos Hub and ATOM as the center of the ecosystem, internalized development across the Interchain Stack, and a north star centered around users and liquidity across Cosmos.
Between 2022 and 2024, the Cosmos Hub and the Cosmos ecosystem as a whole needed a breath of fresh air and a new team with both the execution skills and vision to revive the ecosystem and make it exciting again. More importantly, a team that was completely independent from the conflicts and divisions that were created within the ecosystem. It was time to leave politics behind and focus on uniting the community under one clear vision.
The team that brought this fresh and new vision is Skip. Co-founded by Maghnus Mareneck and Barry Plunkett in 2022, Skip became a key contributor in the Cosmos ecosystem by working on areas such as MEV and cross-chain interoperability. In just 2 years, the Skip team has made meaningful contributions to the ecosystem by building tools and software such as:
In December 2024, Skip was acquired by the Interchain Foundation, marking a historical moment for both Skip and the Cosmos ecosystem. Rebranded as Interchain Labs, Skip became a subsidiary responsible for driving product development, executing strategy, and accelerating ecosystem growth across Cosmos.
We see this as a bullish turning point in Cosmos for three reasons:
Skip’s new mandate is to position the Cosmos Hub as the primary growth engine and liquidity center of the ecosystem. This represents a significant shift in strategy, with ATOM evolving from a governance-focused token to the core asset underpinning value capture across the entire stack. At Chorus One, we’ve worked with Barry and Maghnus since the early Skip days as an investor and operator and saw Skip become a dominant player for MEV within Cosmos and a market leader in IBC transactions via Skip.go. We couldn’t think of a better team to drive the Cosmos Hub.
The Cosmos ecosystem relies heavily on IBC, its native protocol for blockchain interoperability. However, IBC has mainly been adopted by relatively homogeneous blockchains, most of which use CometBFT and the Cosmos SDK. Implementing IBC is complex, as it requires a light client, a connection handshake, and a channel handshake. This makes it especially difficult to integrate with environments like Ethereum, where strict gas metering adds additional constraints.
In March 2025, IBC v2 was announced. It simplifies cross-chain communication, reduces implementation complexity, and extends compatibility between chains. The main features we’re excited about with the integration of IBC v2 and the broader vision for the Cosmos Hub are:
With IBC v2, we believe the Cosmos Hub can become the main router for the entire Interchain. IBC Eureka is the upgrade that brings IBC v2 to the Cosmos Hub. It simplifies cross-chain connections by routing transactions between Cosmos and non-Cosmos chains through the Cosmos Hub.
IBC Eureka aims to increase demand for ATOM as it encourages routing via the Hub. In the future, one possible mechanism under discussion is using fees collected on these transactions to buy and burn ATOM, a model that could both reduce supply and create sustained demand. Although fees haven’t been decided yet, the framework establishes a foundation for potential value accrual to ATOM through real usage.
IBC currently is already a top 5 bridging solution by volume, with the most (119) connected chains, before establishing connections with major established ecosystems such as Ethereum and Solana. With this vision, the Cosmos Hub is becoming a central hub for the interchain economic activity, serving as a main Hub for bridging and competing directly with solutions like Wormhole or LayerZero.
Historically, Cosmos was plagued by user experience problems. Although its initial vision was to become a lightweight demonstration of the Cosmos stack, it also lacked features that other competitive alt-layer 1s have become known for, such as smart contract programmability, interoperability with external networks, high-performance throughput, and fast block times.
IBC v2 aims to address interoperability between Cosmos and exogenous chains. However, with the increased importance of Cosmos as a router for IBC, the hub itself also needs a native ecosystem to flourish and differentiate itself from its peers. The ICF recently funded the open-sourcing of evmOS, an Ethereum-compatible Layer 1 solution that allows developers to build EVM-powered blockchains utilizing the Cosmos SDK. The library will be renamed to Cosmos EVM, and maintained by Interchain Labs as the primary EVM-compatibility solution of the Interchain Stack. With this move, the Cosmos Hub now has a meaningfully viable path to becoming EVM-compatible and build a surrounding ecosystem, enabling and improving the IBC experience.
Lastly, the updated product direction will enable a focused approach on performance, catering to newly onboarded liquidity and users. The average block time of Cosmos Hub is currently ~5.5 seconds, and given the nature of interchain transactions often being cross-chain and requiring a minimum of 2 block confirmations, the average IBC transaction ends up being >20 seconds, which is a suboptimal user experience when the objective is for users have an abstracted experience when interacting with any Cosmos chain.
Optimizations can be done to CometBFT to reduce this to around 1 second or even less. With a 1-second block time, crosschain transactions can reach finality within 2 seconds, massively improving the interchain experience. We believe that this is the path Cosmos Hub will take, with a focus on performance in the near future.
As the Cosmos Hub advances toward becoming a service-oriented, multichain platform, a major priority is addressing the persistent challenge of liquidity fragmentation. While IBC enables seamless interoperability across chains, the Cosmos Hub still lacks a native trading layer that can handle efficient multichain liquidity routing.
Stride, a protocol recognised for its early success in liquid staking, has recently announced an expansion of its mission to address this critical infrastructure gap. With support from the Interchain Foundation, Stride is building a new DEX optimized for IBC Eureka, the native routing system of the Cosmos Hub. This new product will serve as the foundation for onboarding, bridging, and seamless asset movement across Cosmos and external ecosystems like Ethereum, Solana, and others.
Stride is purpose-built for multichain trading. It enables atomic swaps across networks without the need to bridge assets or switch wallets. The protocol supports all tokens, chains, and wallets integrated with IBC Eureka, and offers features like dynamic fees, permissionless hooks, and deep routing. Stride will also offer vertically integrated liquid staking, built-in vaults, and liquidity pools designed for both user flexibility and capital efficiency. The team already has 8 figures in liquidity commitments.
With this partnership, Stride is optimizing for the Cosmos:Go router, reinforcing its role as the Hub’s native liquidity router. In return, Stride has committed to sharing 20% of its protocol revenue with ATOM holders and building fully on the Cosmos Hub, while remaining independent and continuing to operate its existing products. This makes Stride both an economic and technical pillar in the Hub’s long-term roadmap, positioned to become a core DeFi player for Cosmos.
From a market perspective, the opportunity is large. Stride’s liquid staking product already serves over 136,000 users and secures significant value across multiple chains. By integrating liquid staking with its new DEX, and enabling features such as cross-selling, rehypothecation, and collateralized DeFi, Stride is expanding its total addressable market. Stride isn’t just launching a new product. It’s building key infrastructure that helps Cosmos Hub become the economic center of the multichain world.
The market has consistently shown that general-purpose Layer 1 blockchains are the primary drivers of value creation. Networks like Ethereum, Solana, Binance Chain, Sui, and, more recently, Hyperliquid have demonstrated that ecosystems with composability, programmability, and strong liquidity attract developers, users, and value accrual.
In Cosmos, a clear shift is emerging. The recent decision by Stride to deploy directly on the Cosmos Hub signals a new direction: some appchains are starting to rethink the need for sovereign infrastructure. Instead, they are exploring the benefits of building directly on the Hub’s upcoming permissionless VM layer, gaining access to shared liquidity, execution environments, and ATOM alignment without the overhead of maintaining an independent chain.
A recent example of this trend is Stargaze, a well-known NFT app chain. Discussions are underway to migrate Stargaze to the Cosmos Hub and convert STARS into ATOM. Such a move would align Stargaze more closely with the Cosmos Hub’s economic and governance layers, while bringing a Tier-1 Cosmos application to the Cosmos Hub. This direction, while ultimately subject to decentralized governance, reflects a growing recognition that Cosmos Hub-native applications could benefit from tighter integration and shared growth.
This marks a turning point for Cosmos. For years, teams were encouraged to launch sovereign chains. But in a competitive Layer 1 environment, fragmentation has become a liability. By consolidating applications on a unified execution layer, Cosmos Hub has the opportunity to increase activity on its L1, strengthen ATOM’s value capture, and present a more cohesive ecosystem to the broader crypto market.
With a permissionless VM, application migration, and deeper alignment through ATOM, the Cosmos Hub is becoming a competitive base layer capable of hosting top-tier applications and standing alongside the most successful general-purpose blockchains in the space.
Like many others, we were first drawn to Cosmos for its egalitarian vision: a multichain, interoperable future that prioritizes user and developer sovereignty, permissionlessness, and trust minimization. Like any emerging technology, it faced setbacks and challenges over the years. But behind the politics and drama was a tech stack that stayed true to the core values of decentralization. We couldn’t be more excited to support Barry, Maghnus, and the Interchain Labs team, along with teams like Stride, as Cosmos embarks on its next chapter, led by none other than the first stewards of its technology: Cosmos Hub and ATOM.
Earn more by staking with Chorus One — trusted by institutions since 2018 for secure, research-backed PoS rewards.
🔗 Stake Your $INIT
Cosmos has been a pioneer in envisioning a multichain world where different blockchains can interact and communicate with each other. This vision was built around infrastructure such as the Cosmos SDK, a framework for building custom blockchains, and the IBC protocol, which facilitates interoperability between chains. This innovation laid the foundation for the Appchain thesis, where applications operate on their own blockchains, allowing for greater flexibility, sovereignty, and value capture. This initial Cosmos vision also inspired teams like Optimism, which applied similar ideas to create an ecosystem of Ethereum Layer 2s based on the OP stack.
Initia is an evolution of both the Cosmos and Ethereum/Optimism visions, introducing a new perspective on the Appchain and Multichain world, and presenting an Appchain 2.0 vision. Initia aims to offer applications all the benefits of a Layer 1 blockchain, such as flexibility, sovereignty and value capture, while overcoming challenges like technical complexities and poor user experience. Initia achieves this by providing a unified, intuitive, and interconnected platform of rollups, which will be explored further in this article.
As mentioned, Initia’s value proposition is to simplify and enhance the Multichain experience by creating a unified, interconnected ecosystem of rollups. This approach allows for seamless interaction across the various Initia Rollups (also called Interwoven Rollups, or just Rollups) and provides the benefits of Layer 1 blockchains without their associated drawbacks. Let’s take a closer look at the Initia architecture.
It is the core layer of the Initia ecosystem. The Layer 1 is based on the Cosmos SDK and uses CometBFT as its consensus mechanism. Initia uses Move for smart contracts, and its implementation of the Move Virtual Machine introduces a key innovation by tightly integrating it with the Cosmos SDK. This integration allows developers to directly call Cosmos SDK functions such as sending IBC transfers or performing interchain account actions within Move smart contracts.
IBC is the standard messaging protocol across the Cosmos ecosystem. By embedding it into the Move environment, Initia removes the need to create new Cosmos modules for these capabilities. Instead, some of this logic can now be handled within Move, allowing for more flexible and modular development.
At the Layer 1 level, Initia also includes the LayerZero module, which plays a critical role in enabling interoperability. This module acts as an endpoint, allowing communication with any other chain that supports LayerZero.
Initia Layer 1 has a system to protect assets and validate operations across its Rollups. Here’s how it works:
Initia introduces two key modules that work closely together: the DEX module and the Enshrined Liquidity module. The DEX module is a built-in decentralized exchange that allows users to trade using balancer-style pools and stableswap pools. By embedding this functionality directly into the chain, Initia provides native infrastructure for liquidity and trading without relying on external smart contracts.
Complementing this is the Enshrined Liquidity system. In Initia’s design, the native token, INIT, serves both as the governance asset and the staking token, then the stakers earn rewards generated through inflation. This inflationary payout represents the network’s security budget.
The challenge with this model is that a significant percentage of the token supply is locked into staking solely to secure the network, often without contributing to liquidity or broader ecosystem utility. Initia addresses this inefficiency by connecting staking and liquidity through the Enshrined Liquidity system, creating a more productive and aligned use of token capital.
With Enshrined Liquidity, users can stake whitelisted LP tokens on Initia from the built-in DEX module directly with validators. These LP tokens represent trading pairs such as INIT/USDC or INIT/ETH. Any trading pair on the DEX where INIT makes up more than 50% of the weight can be approved for Enshrined Liquidity via governance, and each pair can be assigned a specific reward weight.
For example, if the INIT/USDC pair is allocated 60% of the staking rewards and the INIT/ETH pair receives 40%, these LP tokens become the main way rewards are distributed. This system turns Initia’s Layer 1 into a deep liquidity hub that supports the entire ecosystem, including all Rollups built on top of it.
Interwoven Rollups are application-specific rollups built on top of Initia Layer 1. They are connected to the L1 through the OPinit Bridge, which enables seamless communication between the two layers via two Cosmos SDK modules: the OPhost Module, integrated into Initia L1, and the OPchild Module, embedded in each rollup. The OPhost Module manages rollup state, including sequencer information, and is responsible for creating, updating, and finalizing bridges and L2 output proposals. On the rollup side, the OPchild Module handles operator management, executes messages from Initia L1, and processes oracle price updates. Coordination between the two modules is handled by the OPinit Bot Executor, which ensures efficient and secure cross-layer operations. Unlike traditional Rollups, Interwoven Rollups can operate with anywhere from 1 to 100 sequencers. The Initia team recommends 1 to 5 for best performance, with the system capable of supporting up to 10,000 transactions per second with low latency.
Each rollup on Initia uses the Cosmos SDK for its application layer, but modules like staking and governance are usually excluded to streamline development. Governance is instead handled through smart contracts, removing the need for a native token. Each rollup supports fraud proofs: if a sequencer acts maliciously, validators can use Celestia data to confirm the issue and fork the chain if necessary.
One rollup on Initia can choose a different VM and has the choice between MoveVM, WasmVM, and EVM. This gives developers flexibility to choose the best stack for their use case. The LayerZero module is also implemented as a Cosmos SDK module instead of a Move smart contract, because relying solely on Move would limit compatibility. By embedding LayerZero messaging at the Cosmos SDK level, Initia ensures that all Rollups, regardless of their VM, support messaging from the moment they launch. This design enables smooth communication between Initia Layer 1, Rollups, and external chains.
Beyond its architecture, Initia simplifies go-to-market for Rollups by providing shared infrastructure like bridging, oracles, stablecoins, and wallet integrations. This reduces the operational load and helps Interwoven Rollups launch faster.
As previously mentioned, Initia provides native bridging support through the LayerZero module, which is integrated directly into every rollup. This enables seamless, out-of-the-box interoperability with all other LayerZero-enabled chains, including other Interwoven Rollups.
In parallel, IBC is also supported, allowing Cosmos-style communication and token transfers between chains, including Interwoven Rollups. However, there are key differences in how these systems operate. While LayerZero can be implemented directly across all Interwoven Rollups with no structural limitations, IBC has some trade-offs. Direct IBC connections between every Initia’s rollup would create complex dependencies that don’t scale well. In contrast, LayerZero supports omnichain fungible tokens, allowing tokens to be burned on one chain and minted on another for a smooth, unified experience.
To improve IBC usability, Initia uses its Layer 1 as a routing hub. When tokens are bridged in, they first arrive on the Initia Layer 1, which then sends them to the destination rollup. This approach ensures consistent token origin and avoids unnecessary wrapping. For example, moving a token from rollup-1 to rollup-2 goes through Layer 1, preventing duplication and maintaining liquidity. This is made possible by custom hooks on Layer 1 that can interact with contracts across all Rollups.
One of the key challenges with Ethereum Layer 2s is the poor user experience when withdrawing assets back to mainnet, which often involves a 7-day delay due to optimistic rollup security assumptions. Initia solves this with Minitswap, a mechanism that enables near-instant transfers between Rollups and the Initia Layer 1, typically completed in seconds.
While Initia’s OP bridge allows fast deposits from L1 to one rollup, withdrawals would normally face the same 7-day delay. IBC offers fast transfers in both directions, but without a withdrawal delay, it introduces security risks, especially if a rollup uses a single sequencer: a malicious sequencer could double-spend and instantly bridge assets out via IBC.
Minitswap avoids this by using a liquidity pool model. Instead of bridging, users swap tokens between L1 and rollup versions, enabling instant transfers. Pools consist of 50% INIT and are restricted to whitelisted Rollups.
To ensure safety and efficiency, the system includes:
Minitswap pools will be incentivized. Liquidity providers receive LP tokens that can be staked for rewards, integrating with Initia’s broader staking system.
The Initia Layer 1 uses Connect from Skip, a built-in oracle system powered by the Initia validator set. Validators fetch real-time price data from sources like CoinGecko and Binance, then reach consensus on these prices as part of block production. This data is embedded directly into each block and made natively available on-chain.
Developers on Initia can access reliable price feeds without needing external oracles. The same pricing data is also relayed to all Rollups, using the same structure as on Layer 1 and updated every 2 seconds. This setup is ideal for high-frequency applications like lending, trading, or derivatives, providing fast and consistent price data across the entire ecosystem.
Noble is a Cosmos based chain that offers native USDC with CCTP support. This creates a nice on-ramp for Initia. Users can send USDC from Ethereum or Solana to Noble, then transfer it via IBC to Initia Layer 1 and on to any rollup. The full process can be completed with a single transaction signed on the source chain, and this can be done using IBC Eureka.
The Vested Interest Program (VIP) is Initia’s incentive system designed to align rollup teams, users, and operators through long-term participation. It distributes INIT token rewards over time based on activity and commitment.
To qualify, Rollups must be approved by Initia Layer 1 governance. Once approved, rewards are based on factors like INIT locked and overall performance, and are shared with users and operators for actions like trading and providing liquidity.
The system is composed of two reward pools:
After calculating rewards for each rollup, they are further distributed to users according to a scoring system created by the rollup team.
Source: docs.initia.xyz
Rewards are issued as escrowed INIT tokens (esINIT), which are initially non-transferable. Participants can either convert these tokens into regular INIT tokens through a vesting process, which requires meeting certain performance criteria, or lock them in a staking position. This approach incentivizes meaningful contributions and ensures sustained engagement in the network’s growth and success.
Users can unlock $esINIT based on continued engagement. For example, if a user earns $1,000 in $esINIT in Epoch 1 (a two-week cycle) through activity such as trading, they must maintain similar engagement in Epoch 2 to:
Boosting efficiency with Enshrined Liquidity, users can also use their $esINIT into Enshrined Liquidity, which:
This approach makes reward distribution highly efficient and helps each rollup incentivize the exact behavior it values, while maintaining alignment with the overall Initia economy.
On Initia L1, block rewards are distributed to stakers who have staked INIT or whitelisted LP tokens with validators. However, not all staked tokens receive rewards equally, each token has a reward weight, which determines how much of the total block rewards it gets.
It works as follows:
Let’s say there are three whitelisted staking options:
Total Reward Weights = 50 + 30 + 20 = 100
If the total block rewards per block = 1000 INIT, then:
Rewards are proportionally split based on the assigned weights.
MilkyWay - a modular staking portal, from liquid staking to restaking marketplace and beyond.
Rena - the first TEE abstraction middleware supercharging verifiable AI use cases.
Echelon - a debt-driven Move app chain built on Initia. Echelon Chain is purpose built to be the debt engine of the interwoven modular economy.
Kamigotchi - onchain pet-idle rpg, by @asph0d37. On-chain game in the modular space
Contro - the chain for ultrafair DEXes powered by revolutionary GLOB p2p markets.
Blackwing - a modular blockchain that enables liquidation-free leverage trading for long-tail assets via a novel construct called Limitless Pools.
Rave - RAVE’s quanto perpetuals redefine not only perpetuals, but also tokens themselves by providing composable DeFi instruments.
Infinity Ground - revolutionizing AI entertainment with advanced models for mini-games, memes, and interactive stories.
Inertia - Inertia presents a new consolidated DeFi platform that integrates various assets from fragmented mainnets into one platform.
Civita - the first on-chain gamified social experiment for global domination.
Intergaze by Stargaze - the launchpad and marketplace for interwoven NFTs.
Battle for Blockchain - on-chain strategy game, set in the world of culinaris.
Lunch - the all-in-one finance app, focused on bridging Web2 to Web3.
Embr - igniting everlasting memes.
Zaar - the rollup where degeneracy comes to play.
Lazy Chain - Celestine Sloths Chain
Cabal - convex-like product built around Initia VIP
Owning both the Layer 1 and rollup systems under a unified architecture allows Initia to make coordinated trade-offs that are not possible in ecosystems like Ethereum’s rollup landscape. On Ethereum, independent and competing entities each bring their own infrastructure, incentives, and priorities. This fragmentation limits the ecosystem’s ability to fully realize network effects. As a result, many Rollups end up being parasitic, capturing value without meaningfully contributing to the base layer or broader ecosystem.
Initia takes a unified approach. All components, including Layer 1, data availability, messaging, and virtual machines, operate on a shared foundation. This alignment allows the INIT economy to grow as a whole rather than in isolated parts.
Initia works like a federal system. Rollups function as independent states with room to innovate, while Initia L1 provides shared infrastructure such as monetary policy (VIP), bridging, and governance. The system is designed so that everyone has a vested interest in the growth of Initia as a whole.
.png)
