Delphi Labs: Cosmos as the Optimal Choice Under a Specific Context, Vision, and Set of Values
TechFlow Selected TechFlow Selected
Delphi Labs: Cosmos as the Optimal Choice Under a Specific Context, Vision, and Set of Values
Analyze each ecosystem and explain the reasons for ultimately choosing Cosmos.
Navigating Web3 tides with focused insightsAuthor: Delphidigital
Translation: Hongjun Shuda - IBCL
Introduction
Delphi Labs is the protocol R&D arm of Delphi, a team of about 50 people dedicated to building new Web3 primitives. Previously, this team focused on researching and developing protocols on Terra. After the collapse of Terra, Delphi Labs faced a major decision about where our builders should focus their efforts.
Since the collapse of Terra highlighted the potential downsides of building on the wrong platform, we wanted to ensure we took time, learned lessons, and made the right choice about where to direct our efforts moving forward. Our goal was to research every major L1/L2, current or upcoming, understand their pros and cons, and identify where the next most exciting DeFi frontier lies.
Before we begin, it’s important to emphasize that this article should not be seen as an absolute judgment of which ecosystem is best, but rather a subjective analysis of which ecosystem best fits our specific background, vision, and values.
In Part One, we outline these design constraints and the platform characteristics we aim to optimize for.
In Part Two, we analyze each platform based on these criteria and explain why we ultimately decided to choose the Cosmos ecosystem.
This has been an enlightening process, and this article is our attempt to open-source the findings we’ve gained through this research, hoping they may be helpful to others in the space. We welcome feedback and criticism from the community to stress-test our thinking and ensure we haven’t missed anything.
Part One — Design Constraints of Delphi Labs
While we tried to approach this as blank-slate as possible, the existing background, vision, and values of Labs constrained our decision-making space. This includes our focus on DeFi and our vision for how it should be built, our view on multi-chain and the direction of the space, and the resulting emphasis on cross-chain interoperability.
Built for DeFi
There are many different kinds of Web3 protocols and products, each facing different design constraints when choosing the right platform to build on. Delphi Labs’ R&D work is primarily focused on DeFi protocols, as this is the vertical we are most passionate about and best aligns with our team’s existing background and skill set.
We have thought deeply about this space for years, starting research coverage on DeFi in 2018 and making investments via Ventures in 2019. Even before Labs was formally launched as a separate Delphi division, we had the privilege of consulting for world-class DeFi pioneers for several years. This is the domain we believe we know best, so we approached the entire exercise from this angle.
DeFi Re-packaged
We don’t believe the ultimate DeFi user experience will involve using separate protocols for each function (spot trading, lending, leveraged trading, yield farming, derivatives, etc.). We believe this will instead be re-packaged into a single, vertically integrated UX that looks more like a CEX.
Specifically, Mars' DeFi credit line could enable the creation of a "universal DeFi credit account," allowing users to leverage interactions with whitelisted DeFi applications across a single account with unified LTV.
This recreates a “sub-account”-like experience found in centralized exchanges while preserving the advantages of decentralization—such as non-custodial, censorship resistance, and integration with key DeFi primitives. This requires speed and synchronous composability (we believe experiences based on asynchronous cross-chain contract calls can never compete with CEXs), as well as a vibrant ecosystem that facilitates integration and liquidity.
This is our best guess at what the endgame DeFi experience might look like, so we want to ensure we choose an ecosystem that enables this vision.
Trends We See in the Space
There are two extreme views about the endgame of crypto. The first is that all activity will consolidate into one universal execution environment (i.e., the “monolithic” model). The second is that there will be a large number of specialized execution environments, each with its own design trade-offs (i.e., the “multi-chain” model). Clearly, there are various positions between these two extremes.
Ultimately, we believe the key trade-off here is between the synchronous composability offered by monoliths versus the benefits of specialization.
Our view is that projects will increasingly opt for specialization, resulting in a multi-chain crypto landscape. In this section, we’ll explain why we think this will happen.
We see three main benefits to specialization: lower/more predictable costs, customizability, and sovereignty.
Lower/More Predictable Resource Costs
Our basic assumption is that demand for blockspace, like demand for computing, is elastic—the cheaper blockspace is, the more types of computation can move on-chain. This means that no matter how fast a monolithic chain is, demand for blockspace may exceed supply, causing costs to rise over time.
Additionally, dApps on a monolithic chain constantly compete with all other applications on that chain for blockspace. This leads to network congestion, disrupting user experience through extremely high fees or even chain halts.
Ethereum transfers cost over $500/tx during the minting of Otherdeeds NFTs
Overall, this means dApps on monolithic chains will:
a) Face rising costs over time as more activity moves on-chain
b) Experience greater uncertainty in resource costs, as they depend on other dApps’ demand for blockspace
While some dApps may accept these trade-offs in exchange for the benefits of rapid prototyping, synchronous composability, and ecosystem network effects, we believe this trade-off doesn't make sense for many applications.
A prime example is gaming, a space we’re particularly excited about. As games increasingly move economies—and eventually game logic itself—on-chain, predictability around resource costs becomes increasingly important.
If popular NFT mints cause transaction costs to spike or halt the chain, users cannot continue playing the game.
This is a high cost, especially considering games are largely self-contained ecosystems that gain minimal benefit from composability.
While monolithic chains can continue scaling blockspace vertically, this doesn’t truly solve the problem, as demand for blockspace will keep growing and apps still compete for it. Application-specific chains offer a free-market solution, allowing blockspace to be horizontally partitioned among applications, ensuring high levels of data locality.
Customizability
All applications launched on a monolithic blockchain inherit and must accept a series of design decisions—including the platform's consensus model, security, runtime, mempool, virtual machine, etc. In contrast, application-specific chains can customize every component of their stack, optimizing for that specific app or category. As Paradigm’s Dan Robinson and Charlie Noyes told us:
“Blockchain protocol design is fuzzy. There’s no single ‘correct’ conclusion on scalability or security. Properties like trusted neutrality can’t be fully defined. Today, application platforms follow static setpoints on these design decisions.”
To understand the benefits of customizability, let’s look at several examples:
Optimization of the Scalability Trilemma:
Application-specific chains can tailor their approach to the scalability trilemma based on the app’s needs, rather than accepting the decentralization-security-scalability trade-off of a given platform. Games may care less about decentralization/security and thus can be run by smaller and/or permissioned validator sets with higher hardware requirements to boost performance. For example, DeFi Kingdoms (Crabada) started as a smart contract dApp on Avalanche’s C-Chain but eventually migrated to its own subnet, sacrificing security for cheaper gas.
State Machine Customization:
Platforms can customize every aspect of their state machine—including mempool, transaction propagation, block tx ordering, staking rewards distribution, execution model, precompiles, fees, etc. A few examples:
1. Fee Model Customization:
- Osmosis will add threshold encryption to mitigate “bad MEV” (e.g., sandwich attacks), while internalizing “good MEV”: the protocol will be able to arbitrage its own pools and route profits to OSMO stakers.Osmosis allows users to pay tx fees in any token traded on its DEX. It also allows bundling fees with swap fees, further streamlining the user experience.
- dYdX charges a swap fee instead of gas fees on transactions.
2. Custom MEV Solutions:
- THORChain's swap order is determined by a baked-in queue logic within the state machine. Swaps generating the highest fees always go first. THORChain nodes lack the ability to reorder swaps.
- Injective's order book can settle via batch auctions automatically run each block to minimize MEV.
Performance/Scalability Optimization:
- Solana, Sui, Aptos, Fuel, Injective, Osmosis, Sei, etc., use parallel execution to handle transactions that don’t involve the same state (i.e., separate trading pairs/pools), significantly improving scalability.
Validators Providing Additional Services:
- Stargaze, an NFT-focused chain, has validators supporting IPFS pinning services, making it easier to upload NFT data onto IPFS.
- Injective includes a validator-protected Ethereum bridge, ensuring the bridge’s economic security matches that of the chain.
Mempool/Consensus Customization:
- Sommelier is experimenting with a novel DAG-based mempool design that provides availability and causality guarantees while reducing the workload required by the consensus algorithm; this breakthrough was first adopted by fast monoliths like Aptos and Sui.
- dYdX runs its order book matching engine off-chain via nodes, settling trades on-chain. This achieves greater scalability.
- ABCI++ is a tool that adds programmability to every step of the Tendermint consensus process. Celestia uses ABCI++ to integrate erasure coding as part of its block production process.
Privacy:
- Secret Network is a general-purpose default-private smart contract platform that uses Intel SGX enclaves within Trusted Execution Environments (TEE) to leverage hardware for data security and anonymity.
- Penumbra is another default-private blockchain, focusing more on DeFi and governance, relying on cryptography rather than hardware (Intel SGX) for privacy like Secret Network. Penumbra uses Tendermint and connects via IBC, but replaces the Cosmos SDK with its own custom Rust implementation. They’re integrating threshold encryption directly into consensus, enabling actions like shielded swaps.
Value Capture:
- In any blockchain, applications pass value down to the underlying protocol in the form of fees and MEV—or more accurately, to the underlying gas/fee token. In the long run, we believe the largest dApps may grow larger than any single L1, spanning multiple L1s/rollups and compounding network effects like liquidity, brand, and UX. They will also own user relationships, enabling them to vertically integrate into their own specialized L1 and internalize fee revenue/MEV leakage (as dYdX did). This level of specialization unifies the interests of the application and the underlying layer (execution, settlement, consensus) under a single token.
Sovereignty
A key difference between smart contracts and application chains is that the latter possess independent sovereignty, while the former do not. Smart contract governance ultimately depends on the blockchain’s governance. This introduces platform risk—new features/upgrades on the base chain could degrade the user experience of a smart contract, or in some cases, even break it.
The importance of sovereignty also becomes evident during software exploits; unless the base chain forks, a compromised DApp cannot recover via a fork—a near-impossible hurdle except in special circumstances.
Drawbacks of Specialization
Specialization also has several major drawbacks:
-
Cost—Launching a standalone chain is more time-consuming and expensive than simply deploying a smart contract on an existing chain, requiring more development skills, gathering validators, and adding infrastructure complexity (indexers, wallets, explorers, etc.).
-
Lack of Synchronous Composability—On a monolithic chain, all applications run on a shared state machine, benefiting from synchronous, atomic composability. Inter-chain infrastructure currently cannot facilitate this and introduces additional trust assumptions regardless.
Regarding cost, while dedicated chains have never been as easy to deploy as smart contracts on existing chains, we believe the gap has narrowed significantly with maturing technology and the launch of developer initiatives like Interchain Security, and could continue to narrow.
The real drawback is the loss of synchronous composability. We’ve seen the benefits of rehypothecation-driven DeFi growth on Ethereum, and there’s likely a long list of undiscovered, permissionless composable use cases.
While this is important, there are two key counterarguments.
First, we believe only a few types of applications truly benefit from synchronous composability—mainly DeFi use cases where rehypothecation of tokens is arguably critical (e.g., yield farming). That said, even in DeFi, one could argue whether synchronous composability is truly necessary, as evidenced by dYdX’s success. For most other dApps, we believe asynchronous composability is viable as long as there are robust cross-chain tools to port assets and make interacting with different dApps seamless.
Second, specialization does not necessarily mean deploying a single application per chain, but rather clusters of applications that work well together or serve a specific use case.
For example, while Osmosis is often seen as just an AMM chain, it’s evolving into a broader DeFi chain hosting many different dApps (money markets, stablecoins, vaults, etc.). We believe applications benefiting from composability will naturally cluster on specialized chains, effectively allowing dApps that need it to "opt-in" to composability.
For these reasons, we expect activity won’t consolidate into a single monolithic chain, but rather evolve into a mesh of interconnected specialized chains/rollups, organized around specific use cases.
Cross-Chain Architecture
In summary, we believe that while the DeFi application layer may become re-aggregated, the blockchain layer will further fragment, with dApp teams/communities increasingly opting to deploy their own proprietary application chains.
However, we believe it’s unlikely that each of these chains will spin out their own DeFi ecosystem, because:
a) It forces each chain to rebuild the entire DeFi ecosystem—an extremely difficult task;
b) Leads to fragmented liquidity and suboptimal user experience.
Instead, we believe there will be a few DeFi-centric hubs, where specialized application chains deploy their tokens/economies on one or more of these DeFi hubs.
An analogy we use is that specialized application chains are suburbs, bridges provide the transport layer, connecting these suburbs to financial centers (i.e., DeFi hub chains) in city centers.
Given that composability is crucial for the re-bundled UX experience mentioned earlier, and we don’t want to bet everything on a single chain, we expect winning DeFi dApps will deploy across several winning DeFi hubs, increasing cross-chain liquidity, brand, and UX network effects. Thus, we wanted to ensure we spent time exploring architectures and which ecosystems best enable this.
So far, cross-chain applications follow two main approaches:
-
Independent deployments that don’t communicate with each other (e.g., Aave, Uniswap, Sushi, Curve). This means the dApp natively exists on each chain it deploys to and can synchronously compose with all native primitives. However, this also leads to liquidity fragmentation and poor user experience, as traders/borrowers receive suboptimal execution, and LPs must manually move capital to optimize utilization.
-
Deploy a unified application chain where all liquidity resides (e.g., Thorchain, Osmosis). This is more capital-efficient but means it cannot synchronously compose with dApps on other chains.
Delphi Labs is currently exploring a third way—application instances deployed across multiple chains (outposts), connected via a coordination layer that enables communication and liquidity allocation between outposts. You can read more about how we think this third strategy works for Mars [here]([1]).
If successful, this would improve LP performance (deposit once, earn fees across all integrated chains), enhance execution for traders/borrowers, and allow both primitives to synchronously compose with other dApps on-chain. This is especially important for the super-app vision, which relies on synchronous composability for both integration and speed (cross-chain contract calls are too slow to deliver a good experience for advanced traders).
Platform Requirements
In summary, our constraints are:
-
We focus on DeFi applications
-
We believe DeFi will be re-packaged into an integrated experience
-
We believe the world will become increasingly multi-chain, and DeFi apps should architect themselves to be natively deployable across multiple chains.
Based on these constraints, there are several key platform requirements:
-
Speed: While it will never be as fast as a CEX, ideally it should get as close as possible. Block time will determine how much worse the experience is compared to a CEX. Faster block times increase capital efficiency by enabling faster oracle updates, liquidations, and higher leverage. While not mandatory, faster block times and high throughput can also enable on-chain order books, providing a better trading experience.
-
Ecosystem: Beyond non-custodial and permissionless access, the biggest advantage of a DeFi super-app over a CEX is composability and the breadth of integrations it can offer. While CEXs are limited to their own products, the app can integrate with any DeFi primitive, allowing users to cross-margin LP positions, vaults, farming, staking positions, NFTs, etc. Liquidity on-chain is also important, as it directly impacts trading experience.
While speed and ecosystem are primary requirements, several other factors are important when selecting the right platform:
-
Decentralization: The key difference between a super-app and a CEX is decentralization—non-custodial, permissionless, and censorship-resistant. Decentralization is a loaded term, but ultimately any chain we deploy on must have strong security and liveness guarantees. Many rollups and chains achieve low latency, but often at the expense of one or both. Our assessment of decentralization is subjective, but ultimately considers factors like central points of failure, resilience to regulatory attacks, governance/stake concentration, number of nodes, and number of independent entities contributing to development.
-
Cross-chain interoperability: To realize the cross-chain architecture vision described above, the chain needs mature, reliable, and trust-minimized cross-chain messaging and asset bridge infrastructure. Without this, instances cannot communicate, or can only do so at the cost of exposing the entire system to additional risks.
-
Technical maturity: As we’ve seen with Solana and other chains—especially those based on new, experimental innovations—immature technology can lead to bumpy and risky development processes, including downtime for early adopters. Downtime is highly problematic for leveraged applications (because liquidations must occur promptly), and adding technical risk on top of already complex protocols is usually undesirable.
-
Code portability: While not a primary factor in our analysis, we also considered the portability of code written for a specific platform. Ecosystems with niche languages or VMs carry higher costs, as code cannot be easily ported elsewhere if the ecosystem fails.
Part Two — Choosing the Ecosystem
Ecosystem Comparison
When surveying the blockchain space, we considered various ecosystems, each potentially containing clusters of domains—such as Cosmos zones, Avalanche subnets, or Ethereum rollups—or standalone chains (e.g., Near or Solana). While this may seem like comparing apples and oranges, it felt like a natural approach when narrowing down choices.
We then compared each option based on the factors outlined in Part One, with our comparison summary shown in the table below.
As we examine each ecosystem in detail, we’ll expand on some of the motivations behind our rankings.
Ethereum L1
Let’s start with Ethereum’s base layer. Today, Ethereum L1 sees the highest demand for blockspace and liquidity.
As Ethereum transitions toward a rollup-centric world, more rollup activity will concentrate on Ethereum, further cementing its role as the liquidity hub.
From our perspective, the biggest advantages of migrating to Ethereum L1 are:
-
Ecosystem—Ethereum L1 has the largest and most developed dApp ecosystem and the highest liquidity, enabling numerous integrations for credit account functionality.
-
EVM Network Effects—Ethereum has the largest developer community, which can solidify its ecosystem moat by ensuring faster growth than competitors.
-
Decentralization—Ethereum is arguably the most decentralized L1 across all major contenders. It has multiple clients developed by independent teams, the most diverse client base among L1s, the highest economic security, the longest track record, and social consensus supporting minimal changes at the base layer.
The biggest downside is speed/cost. ~12-second blocks make offering high leverage extremely difficult and generally hurt the trading experience, especially when inclusion in blocks is competitive. High gas costs push inefficient liquidation models that disadvantage users. All of this results in a poorer user trading experience.
While EVM currently dominates the smart contract development market, we note increasing competition in the VM space—SeaLevel, CosmWasm, MoveVM, FuelVM. We expect this competition to test EVM’s network effects.
Rollups
As a base layer, Ethereum sacrifices speed for resilience, aiming to deliver fast UX via rollups.
Rollups promise Ethereum-level security with lower costs and faster UX, but always with trade-offs. Unlike L1s, where transaction finality order is unknown until consensus, rollups can have a single privileged actor (called a sequencer) with full control over transaction ordering. This allows rollups to balance UX and decentralization—offering instant confirmations while relying on L1’s censorship resistance and finality.
While this balance is more useful for the trading experience we aim to provide, relying on a centralized sequencer isn’t ideal—potential sequencer outages could disrupt UX. In Mars’ case, outages pose significant risk, as the protocol could accumulate bad debt during downtime. While rollups plan to decentralize sequencers:
(i) Almost all teams have delayed this in their roadmaps,
(ii) Decentralizing sequencers will increase confirmation latency due to the inherent delay of requiring quorum from a group rather than a single sequencer.
Interoperability is also problematic. Rollups have withdrawal periods, complicating any low-latency bridges (requiring risk assessment and challenge coverage). Generally, cross-chain infrastructure lags behind alternatives, making rollups currently unsuitable for the optimal cross-chain architecture we envision.
EVM ORUs
Scaling execution with shared state relates to choices around VM and execution model. First-gen ORUs on Ethereum, like Optimism and Arbitrum, prioritized EVM compatibility/equivalence. While they can leverage existing Ethereum tooling, they also inherit geth limitations.
For this reason, we’re unlikely to see them achieve more than an order-of-magnitude higher tps (~50 tps) than L1 geth forks like Polygon or BSC.
Indeed, this partly explains why Arbitrum is pursuing a multi-rollup vision, with Arbitrum One and Arbitrum Nova as the first. In a multi-rollup world, bridges play a crucial role. Unfortunately, rollup bridge design space remains immature.
Existing bridge functionality doesn’t go beyond simple token transfers, L1 calldata remains expensive (though future Ethereum upgrades like EIP-4488 could alleviate this), and ORU latency will remain a challenge for general-purpose cross-chain apps. Again, given our view on optimal cross-chain architecture, this is problematic for us.
On the positive side, a major advantage of EVM ORUs is their ability to easily leverage Ethereum’s liquidity and community to bootstrap their DeFi ecosystems. Optimism and Arbitrum already have tens of billions in TVL, driven by blue-chip protocols like Aave, Uniswap, Curve, Synthetix, and GMX.
On the other hand, rollup infrastructure remains immature. While ORUs have large TVL, almost none—including Optimism and Arbitrum—have permissionless fraud proofs in production, failing to minimize trust. While we’re confident rollups can deliver, it requires significant engineering effort and time.
Although EVM compatibility makes sense for ORUs given the portability of the existing Ethereum ecosystem, it doesn’t benefit all existing protocols that might want to pursue a cross-chain strategy.
We also see risks as alternative rollup technologies develop and new builders without EVM experience enter the space—alternative L1s and ZK rollups may draw usage away from ORUs.
Thus, despite relatively high scalability, TVL, and capacity being attractive, poor connectivity, centralization risks, and uncertain future collectively deter adoption of this option.
ZK Rollups
Like many, we believe ZK proofs are a core technological pillar of blockchain’s endgame. At the heart of every scaling solution is cost-effective verification. ZK proofs allow anyone to prove complete integrity of execution (without extra assumptions), making them highly useful for secure, efficient bridges between discrete systems. We observe this today in the form of ZK-rollups.
In recent years, incentives to push the boundaries of zero-knowledge tech have increased sharply. Still, it’s hard to predict how quickly ZK rollups can gain meaningful market share. The ZK space is still in its infancy, with players at different stages of readiness—primarily Starkware, zkSync, and Polygon.
Starkware has had ZK tech ready for a while, but offers their StarkEx product as a software vendor. StarkEx isn’t the open, general-purpose platform we’d expect in this space, but the tech itself is excellent ([2]), proven by adoption from some of the most used dApps (e.g., dYdX, Immutable, etc.). However, dYdX recently announced moving from StarkEx to a Cosmos app chain, mainly due to decentralization concerns.
StarkNet is a recently launched, permissionless, open platform based on Starkware tech. It’s production-ready and offers synchronous composability with other StarkNet dApps. But it’s just launching—its community, infrastructure, and DeFi ecosystem are immature. For example, StarkGate, the canonical Ethereum<>Starknet bridge built by Starkware, has deposit limits, and StarkNet’s liquidity is negligible (~650 ETH). Like other rollups, StarkNet relies on a centralized sequencer and plans to decentralize over time ([3]).
Considering applications built in Cairo (Starkware’s language) offer limited portability, this poses adoption risk if it turns out to be a losing bet. Nethermind’s Warp team is developing a Solidity-to-Cairo transpiler, so Solidity could potentially replace Cairo—providing more optionality and tooling.
Many ZK-EVMs ([4]) like Polygon Hermez, Scroll, and zkSync 2.0 make different trade-offs between speed and EVM compatibility. While watching their progress is exciting, they’re still unreleased products with uncertain timelines for future roadmaps.
Finally, we note all ZK rollups rely on highly complex, cutting-edge tech understood by only a very limited pool of domain experts. We believe this increases the likelihood of software bugs and unforeseen issues that could negatively impact complex DeFi dApps, making it harder for us to project their progress.
While we appreciate ZK tech’s potential as a final solution and will monitor its progress closely, the above concerns plus general rollup issues lead us to decide against building there now.
Modular (Celestia Rollups)
As outlined in Part 1, we see the future as multi-chain—with many app chains, general-purpose chains, and hybrids, each making different trade-offs and customizations. This favors modular blockchain development stacks like Cosmos’ Tendermint and Polkadot’s Substrate, which provide reusable, customizable components via SDKs for creating new blockchains.
Celestia takes a different approach to modular blockchains—decoupling execution from data, only providing a base layer for data availability and ordering. This allows Celestia to securely scale rollups/app chains in a highly scalable way. It also means Celestia focuses only on one element of the blockchain stack, potentially more efficient than a one-size-fits-all approach.
This solves a major issue in Cosmos—requiring each chain to have its own validator set—which demands significant time and effort, infeasible for many dApps.
It also fragments consensus security per chain, leading to low tail-end security budgets.
Cosmos’ Interchain Security is another option, but it’s not permissionless—it requires mutual agreement between Hub and consumer chain—and not scalable—the Hub’s validators need extra resources to validate consumer chains.
While this may be a good interim solution, it’s unlikely to be the endgame.
Celestia’s user-facing side is its execution layer; notable ongoing projects include Cevmos, Sovereign Labs, and Fuel V2.
Fuel V2 seems closest to completion, but it’s still very early. Fuel V2 uses a UTXO data model and a brand-new VM to promise fast, scalable execution. While we like their design choices and will monitor them closely, the technical risk they introduce feels too high for the kind of applications we might build.
Moving to a new, largely untested language, plus the cost of adopting a new paradigm like UTXO, is substantial.
We’d also become path-dependent on a specific execution environment, while another future Celestia rollup might succeed in attracting adoption. There’s also a risk that future Ethereum developments (e.g., EIP-4844) reduce the necessity of Celestia’s core data availability use case.
While this sounds pessimistic, we’re actually very optimistic about the future of modular blockchain networks. We see Celestia’s sovereign rollups as potential successors, or perhaps the ultimate scalability path for Cosmos-based chains. While these technologies aren’t ready yet, they represent a massive potential mid-term solution and prepare for a modular future. Celestia is undoubtedly an ecosystem we’ll watch closely.
Polkadot
Polkadot’s mission has always been to have heterogeneous execution environments (parachains) with shared security. While this was a unique goal when Polkadot began, it’s no longer the case given the existence of rollups.
That said, Polkadot has a unique advantage in spending years developing its cross-chain messaging protocol XCMP (similar to Cosmos’ IBC). XCMP isn’t fully operational yet, but once live, it will play a key role in interoperability, enabling cross-chain applications.
Substrate and Cumulus are SDKs provided by the Polkadot team for creating parachain-compatible blockchains. You don’t need to use Substrate/Cumulus to become a parachain, nor is using Substrate forced to become one.
However, only parachains can interoperate. Since there’s a cap on the number of parachain slots, becoming one requires winning an auction. This means Polkadot’s interoperability comes at the cost of sovereignty, theoretically revocable at any time. In contrast, Cosmos offers optional interoperability modules without requiring connection to a central chain—our preferred approach.
Polkadot scores highly on decentralization, with 996 ([5]) validators, a diverse and thriving developer community, and multiple independent clients ([6]).
Despite strong tech and a large dev community ([7]), user adoption on Polkadot hasn’t been impressive.
Currently, the top three parachains—Acala, Moonbeam, and Parallel—have combined liquidity of $150 million, far behind competitors. This was recently compounded when the largest stablecoin aUSD lost its peg after a free-mint bug on Acala’s parachain.
On scalability, we rate Polkadot ahead of many ecosystems but behind Ethereum and Celestia. While Polkadot employs scaling techniques like data availability sampling and dispute protocols, validators still need to be interested in the state transitions of parachains (or parathreads), limiting scalability. The same motivation applies to our scalability ranking of Near.
Overall, despite positives, we believe Polkadot holds no significant advantage over Cosmos or DeFi dApp rollups and indeed has some relative disadvantages.
High-Speed Monolithic Chains (e.g., Solana, Now Sui, Aptos, etc.)
The monolithic “everything-in-one-place” approach is certainly appealing to developers. Building a dApp as a collection of smart contracts is much easier than creating a new app chain on multiple levels: writing smart contracts is far less costly than writing application logic at the chain level; smart contracts on existing chains don’t need to bootstrap new validators; they can use existing wallets and infrastructure; and typically, it’s easier to attract users when building on an existing chain by leveraging its community.
Composing with other applications on the same chain is also much easier than trying to do so asynchronously across bridges. Therefore, despite conflicting with our multi-chain vision, fast monoliths were indeed something we carefully considered.
Solana
Ethereum was the original monolith, but quickly became crowded. Solana became the first credible high-throughput chain, achieving sub-second block times—the lowest among all production chains. It did so while maintaining decentralization, boasting 1972 validators and a strong Nakamoto coefficient compared to other PoS chains.
Many of these validators appear unprofitable without subsidies from the Solana Foundation, so how things will unfold post-subsidy remains to be seen. Jump recently announced they’re developing Firedancer, an independent Solana client—important first steps toward validator diversity.
Solana attracted a strong project ecosystem and $1.5 billion in TVL, making it the leader in non-EVM-compatible chains by TVL. Developer experience, initially seen as difficult, improved significantly with the introduction of the SeaLevel framework Anchor.
Solana also successfully cultivated a meaningful and differentiated developer ecosystem, arguably among the top three alongside Ethereum and Cosmos. This also led to a distinct culture, reflected in developers with more traditional/financial backgrounds and a thriving NFT ecosystem.
Solana’s cost and speed make it an attractive place to build DeFi apps, resulting in a rich DeFi ecosystem with many AMMs, money markets, perps, and other DeFi products (including excellent ones like Mango).
While this opens up many integration opportunities, the flip
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Delphi Digital
