Delphi Labs: Why we focus R&D on the Cosmos ecosystem

Delphi Labs is Delphi’s protocol research and development arm, with a team of about 50 people working on building new Web3 primitives. Previously the team focused on researching and developing protocols on Terra . After Terra collapsed, Delphi Labs was faced with a major decision about where to focus our builders’ work.

As Terra’s debacle demonstrated the potential downsides of building on the wrong platform, we wanted to make sure we took our time, learned our lessons, and made the right choices about where we’ll be working to move forward. Our goal is to study each major L1/L2, current and upcoming, understand their pros and cons, and find out where the next most exciting DeFi frontier is.

Before we begin, it is important to stress that this article should not be viewed as an absolute judgment on which ecosystem is best, but rather on which ecosystem is best for us subjectively in the context of our particular background, vision and values analyze.

In the first part, we outlined these design constraints, along with the platform points we hope to optimize. In the second part, we analyze each platform against these requirements and explain why we ultimately decided to choose the Cosmos ecosystem .

It’s been a heuristic process, and this post is our attempt to open-source our findings from this research in the hope that they might be helpful to others in the field. We welcome feedback and criticism from the community to stress test our ideas and make sure we haven’t missed anything.

Part 1 – Delphi Labs’ own design constraints

While we try to start drills from the blank as much as possible, Labs ‘ existing context, vision, and values ​​limit our decision space. This includes our focus on DeFi and our vision for how to build it, our views on the direction of multi-chain and space development, and the resulting emphasis on cross-chain .

Born for DeFi

There are many different kinds of Web3 protocols and products, each of which faces different design constraints when choosing the right platform to build on. Delphi Labs’ R&D efforts are primarily focused on DeFi protocols, as this is the vertical we are most interested in and best fits our team’s existing background and skill set.

We have been thinking deeply in this field for a long time, starting our research in 2018 to cover DeFi, and investing in Ventures in 2019 . We also had the privilege of consulting world-class DeFi pioneers for many years before Labs officially launched as a separate Delphi division. This is the area we think we know best, so we approached the entire walkthrough from that perspective.

DeFi repackaging

We do not believe that the ultimate DeFi user experience is to use a separate protocol for each function (spot trading, lending, leveraged trading, yield farming, derivatives, etc.) . We believe this will be repackaged into a single, vertically integrated UX that looks more like CEX.

Specifically, the DeFi credit line provided by Mars can facilitate the creation of a “universal DeFi credit account” that users can use to leverage interactions with whitelisted DeFi applications with a single account-level LTV.

This recreates a “sub-account”-like experience on a centralized exchange , while maintaining the advantages of decentralization, such as non-custodial, censorship-resistant, and integration of key DeFi primitives. This requires speed and synchronous composability (we believe that an experience based on asynchronous cross-chain contract calls will never be able to compete with CEX), as well as a vibrant ecosystem that facilitates integration and liquidity.

This is our best guess at what the DeFi end-game experience might look like, so we wanted to make sure we picked an ecosystem that would foster that vision.

Field Trends We See

There are two extreme views on the endgame for cryptocurrencies . The first is that all activities will be centralized in a common execution environment (ie “stand-alone” mode ). The second is that there will be a large number of specialized execution environments, each with their own designs and tradeoffs (i.e. “multi-chain” mode ). Clearly, there are various points of view between these two extremes.

Ultimately, we think the key trade-off here is between the simultaneous composability offered by a single machine and the benefits of specialization. Our view is that projects will increasingly choose to specialize, with the result that the crypto space will be multi-chain. In this section, we explain why we think this is the case.

We see three main benefits of specialization: lower/more predictable costs, customizability, and sovereign independence.

Lower/more predictable resource costs

Our basic assumption is that the demand for block space, similar to the demand for computation, is elastic; the cheaper the block space, the more different types of computation can be moved on-chain. This means that no matter how fast a monolithic chain is, demand for block space can outstrip supply, and costs can rise over time.

In addition to this, applications on a monolithic chain are constantly competing for block space with all other applications on the chain. This can lead to network congestion that disrupts the user experience through extremely high fees or chain downtime.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

ETH transfers over $500/tx during Otherdeeds minting

Overall, this means that dApps on a monolithic chain will:

a) Costs increase over time as more activity moves on-chain

b) face greater uncertainty in resource cost as it depends on block space demand by other dApps

While some dApps may be willing to accept these tradeoffs in exchange for the benefits of rapid prototyping, simultaneous composability, and ecosystem network effects, we do not believe the tradeoffs make sense for many applications.

An example of this is gaming, which is an area we’re particularly excited about. Certainty around resource costs will become even more important as games bring more and more economies and ultimately the game logic itself onto the chain.

If a popular NFT causes the tx cost to soar or the chain stops due to mint, users cannot continue to play the game. That’s a high cost, especially considering that games are largely siloed ecosystems , and the gains from composability are minimal.

While a monolithic chain can continue to scale block space vertically, this doesn’t really solve the problem, as the demand for block space will continue to increase and applications are still competing with each other for that block space. Dedicated application chains provide a free market solution that allows block space to be broken down horizontally by applications , thus ensuring a high level of data localization.


All applications launched on a monolithic blockchain inherit and must accept a series of design decisions, including the platform’s consensus model, security , runtime, memory pools, virtual machines, and more. In contrast, an application-specific chain can be tailored across all components of its stack, optimized for that specific application or category. As Paradigm ‘s Dan Robinson and Charlie Noyes tell us:

“Blockchain protocol design is ambiguous. There is no single “correct” conclusion about scalability or security. Features like trusted neutrality cannot be fully defined. Today, application platforms pursue these design decisions statically set point”

To see how customizability benefits, we can look at a few examples.

Optimization for space tradeoffs: Instead of accepting the decentralization-security-scalability choice of a given platform, an application-specific chain can adapt its scalability trilemma to the needs of that application. Games may be less concerned with decentralization/security, so can be run by smaller and/or permissioned validator sets with higher hardware requirements to improve performance. For example, DeFi Kingdoms (Crabada) started out as a smart contract dApp on Avalanche C-Chain and eventually moved to its own subnet, sacrificing security for cheaper gas.

State machine customization:

The platform can customize all aspects of its state machine, including mempool, transaction propagation, ordering of block tx, staking reward distribution, execution model, precompilation, fees, and more. A few examples:

  • The order of exchanges on THORChain is determined by the exchange queue logic baked into the state machine. The swap that incurs the highest fee is always at the front of the queue. THORChain nodes do not have the ability to reorder exchanges.
  • The Injective order book can be settled by automatically running a batch auction for each block to minimize MEV.
  • Osmosis will add threshold encryption to mitigate “bad MEVs” (such as sandwich attacks), while internalizing “good MEVs”: the protocol will be able to arbitrage its own pools and stream profits to OSMO stakers.
  • Osmosis allows users to pay tx fees on any token trade on their DEX . It also allows it to be bundled into the exchange fee, further simplifying the user body.
  • dYdX charges swap fees on transactions, not gas fees on txs.
  • Test custom charging mode:
  • Custom MEV Solutions:

Performance/scalability optimizations: Solana , Sui , Aptos , Fuel, Injective, Osmosis, Sei, etc. utilize parallel execution to process transactions that do not involve the same state (i.e. separate transaction pairs/pools), greatly improving scalability.

  • Validators undertake additional services

The NFT-focused chain Stargaze has validators that support IPFS pinning services, making it easier to upload NFT data on IPFS.

Injective includes a validator-protected Ethereum bridge, ensuring that the economic security of the bridge is the same as the economic security of the chain.

  • Memory pool/consensus customization
  • Sommelier is experimenting with a novel DAG-based mempool design that provides availability and causality guarantees and reduces the work required for consensus algorithms; a breakthrough first adopted by fast monoliths such as Aptos and Sui.
  • dYdX is enabling its nodes to perform off-chain computations and on-chain transaction settlements by running an order book matching engine. This enables greater scalability.
  • ABCI++ is a tool that adds programmability to every step of the Tendermint consensus process. Celestia uses ABCI++ to incorporate erasure coding as part of its block production process .


  • Secret Network is a general-purpose default private smart contract platform that leverages hardware to keep data secure and anonymous by using Intel SGX enclaves in a Trusted Execution Environment (TEE).
  • Penumbra is another blockchain that is private by default but focuses more on DeFi and governance, and uses cryptography with Secret Network’s reliance on hardware (Intel SGX) for privacy. Penumbra uses Tendermint and connects via IBC, but replaces the Cosmos SDK with its own custom Rust implementation . They are integrating threshold encryption directly into consensus, which will allow them to do things like shield swap.

Value capture: In any blockchain, applications pass value to the underlying protocol in the form of fees and MEVs, or more precisely to the underlying gas/fee tokens. In the long run, we believe that the largest dApps are likely to be larger than any single L1 , spanning multiple L1s/rollups, compounding liquidity/brand/user experience, etc. network effects. They will also have user relationships that will allow them to eventually vertically integrate into their own specialized L1 and internalize fee revenue/MEV leakage (i.e. dYdX). This level of specialization unifies the interests of the application and the underlying layers (execution, settlement, consensus) under one unified token.


A key difference between smart contracts and Lisk is that the latter are independently sovereign, while the former are not. The governance of smart contracts ultimately depends on the governance of the blockchain. This introduces platform risk, where new features/upgrades on the underlying blockchain may compromise the user experience of smart contracts, and in some cases even break them.

The importance of sovereignty also becomes apparent during software breaches; if the underlying chain is not persuaded to fork , the exploited DApp cannot be recovered through the fork, which would be an impossible improvement except in special cases.

Disadvantages of specialization

Specialization also has some major disadvantages:

  • Cost – Launching a standalone chain is more time-consuming/expensive than simply deploying a smart contract on an existing chain, requires more development skills, mustering validators, and adds additional infrastructure complexity (index retrieval, wallets , browsing device, etc.).
  • Lack of synchronous composability – On a monolithic chain, all applications run on a shared state machine and thus benefit from synchronous, atomic composability. Interchain infrastructure currently cannot facilitate this, introducing additional trust assumptions in any case.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

In terms of cost, while private chains have never been as easy to deploy as smart contracts on existing chains, we believe that the gap has narrowed and is likely to continue to narrow as the technology matures and developments such as Interchain Security come online.

The real downside is the loss of synchronous composability . We are already seeing the benefits of the growth of DeFi driven by token re-collateralization on Ethereum, and there may be a long list of yet-to-be-discovered use cases for permissionless compositionality.

While this is important, there are two important rebuttals here.

First, we believe that only a few applications truly benefit from synchronous composability. These are primarily DeFi use cases for which token re-collateralization is arguably critical (e.g. yield farming). That said, even in DeFi, it can be argued whether simultaneous syntheticity is really necessary, and the success of dYdX is proof. For most other DApps, we believe that asynchronous composability is feasible as long as there are powerful cross-chain tools to port assets and make the user experience of interacting with different DApps seamless.

Second, specialization does not necessarily mean deploying a single application on a chain, but rather a cluster of applications that work well together or facilitate specific use cases. For example, while Osmosis is often seen as an AMM chain, it is developing into a DeFi chain with many different dApps (money markets, stablecoins, vaults, etc.) deployed on it . We believe that applications that benefit from composability will naturally tend to cluster on specialized chains, effectively allowing dApps that require it to “opt-in” to composability.

For these reasons, we expect all activity not to agglomerate on a single monomer chain, but to evolve into a network of interconnected specialized chains/rollups organized around specific use cases.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

Cross-chain architecture

In summary, we believe that while the DeFi application layer has the potential to be re-aggregated, the blockchain layer will be further fragmented, with dApp teams/communities increasingly opting to deploy their own proprietary application chains. However, we believe it is unlikely that each of these chains will spin off their own DeFi ecosystem because: a) it forces each chain to rebuild the entire DeFi ecosystem, which is a difficult task; b) leads to liquidity Fragmented and sub-optimal user experience.

Instead, we believe there will be some DeFi-focused hubs, with a particular application chain deploying its token/economy in one or more of these DeFi hubs. An analogy we use to visualize is that specialized LidChains are suburbs, and bridges provide the transport layer, connecting these suburbs with financial centers in urban centers (i.e. DeFi Central Chains).

Given that composability is critical to the aforementioned rebundling UX experience, and one does not want to bet on one chain, we expect winning DeFi dApps to be deployed on several winning DeFi hubs, increasing cross-chain adoption Liquidity/Brand/UX network effects. So we want to make sure we spend some time exploring the architecture and which ecosystems are most likely to facilitate this.

As of now, cross-chain applications follow two main approaches:

  1. Standalone deployments that do not communicate with each other (eg Aave , Uniswap , Sushi, Curve ). This means that the dApp lives natively on every chain it is deployed on and can be synthesized in sync with all native primitives. However, this also led to liquidity fragmentation and poor user experience, as traders/borrowers received sub-optimal execution and LPs had to manually move capital to optimize utilization.
  2. Deploy a unified Lisk with all liquidity on it (e.g. Thorchain, Osmosis). This is more efficient capital, but means that it cannot be combined in sync with dApps on other chains.

Delphi Labs is currently exploring a third way where application instances will be deployed on multiple chains (sentries), but connected by leveraging a coordination layer to facilitate communication and distribution of liquidity between the outposts. You can read more about how we think this third strategy works on Mars here [1].

If successful, this will improve the performance of LPs (deposit once, earn fees on all integrated chains), improve execution for traders/borrowers, and allow these two primitives to be synthesized in sync 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 provide a good user experience for advanced traders).

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

Requirements for the platform

All in all, our constraints are:

  1. We focus on DeFi applications
  2. We believe DeFi will be repackaged into an integrated experience
  3. We believe that the world will become more and more chained, and DeFi applications should architect themselves so that they can be natively deployed on multiple chains.

Based on these limitations, there are some key platform requirements:

  • Speed: While it will never be as fast as CEX, it should ideally be as close as possible. Block time will determine how much worse the experience is compared to CEX. Faster block times improve capital efficiency by allowing for faster oracle updates, liquidations, and higher leverage. While this is not required, faster block times and high throughput can also enable on-chain order books, providing users with a better trading user experience.
  • Ecosystem: Aside from being non-custodial and permissionless, the biggest advantage of a DeFi super application over CEX is composability and the number of integrations it can offer. While CEX is limited to its own product, the app can integrate with any DeFi primitive, allowing users to cross margin LP positions, vaults, farming, staking positions, NFTs, and more. As part of this, on-chain liquidity is also important as it directly affects the trading experience.

While speed and ecosystem are the main requirements, there are several other factors that are important when choosing the right platform:

  • Decentralization : Compared to CEX, the main difference of super applications is decentralization, i.e. non-custodial, permissionless and censorship resistant. Decentralization is a heavy term, but ultimately any chain we deploy needs to have strong security and liveness guarantees. Many Rollups and chains achieve low latency, but it usually comes at the expense of one or both. Our assessment of centralization is subjective, but ultimately takes into account factors such as centralization failure points, resilience to regulatory attacks, governance/stake concentration, number of nodes, number of independent entities contributing to development, etc.
  • Cross-chain interoperability: To realize the vision of the cross-chain architecture described earlier, the chain needs a mature, reliable, and trust-minimized cross-chain messaging and asset bridge infrastructure. Without this, instances would not be able to communicate with each other, or would only be able to communicate while exposing the entire system to additional risks.
  • Technology maturity: As we have seen with Solana and other chains , especially those based on brand new experimental innovations , immature technology can lead to bumps and risks in the development process, such as downtime for early adopters . Downtime is very problematic for an application characterized by leverage (as liquidations need to happen in a timely manner), and adding technical risk is often undesirable when building an already complex protocol.
  • Portability of code: While this was not the main factor in our analysis, we also considered the portability of code written for a specific platform. Ecosystems with niche languages ​​or virtual machines cost more because if that ecosystem fails, the code cannot be ported elsewhere.

Part II – Choosing an Ecosystem

Ecosystem Comparison

When looking at the blockchain space, we consider a variety of different ecosystems, where one ecosystem may contain clusters of multiple domains, such as Cosmos zones, Avalanche subnets or Ethereum Rollups, or independent chains such as Near or Solana ). While this may seem like comparing apples and oranges, it seems like a natural approach when narrowing down your options.

We then compared each option based on the factors given in Section 1, and a summary of our comparisons is presented in the table below.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

As we take a closer look at each ecosystem, we’ll expand on some of the motivations behind our rankings.

Ethereum L1

Let’s start with the Ethereum base layer. Today, the Ethereum base layer meets the greatest demand for block space and liquidity. As Ethereum moves towards a rollup-centric world, more rollup activity will focus on Ethereum, further cementing Ethereum’s position as a liquidity center.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

From our perspective, the biggest advantages of migrating to Ethereum L1 are:

  • Ecosystem – Ethereum L1 has the largest and most developed dApp ecosystem, as well as the highest liquidity, allowing massive integration of potential credit account functionality.
  • EVM Network Effects – Ethereum has the largest developer community and can strengthen its ecosystem moat by ensuring the ecosystem continues to grow faster than other products.
  • Decentralized – Ethereum is arguably the most decentralized L1 of all the major carriers. Ethereum has multiple clients developed by independent teams, with the most diverse clients in L1. It also has the highest economic security, it is the most proven, and has a social consensus that supports minimal changes at the base layer.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

The biggest downside is speed/cost . Blocks around 12 seconds make it extremely difficult to provide high leverage and often hurts the trading experience, especially when inclusion in these blocks is often competitive. High gas costs drive an inefficient liquidation model that works against users. All of these result in a poor user trading experience.

While EVM currently dominates the smart contract development market, we have noticed increasing competition in the virtual machine space, such as SeaLevel, CosmWasm, MoveVM, and FuelVM. We expect this competition to put the network effects of EVM to the test.


As a base layer, Ethereum sacrifices speed for elasticity, aiming to provide a fast user experience with Rollup.

Rollups promise Ethereum-level security at lower cost and a faster user experience, but that always comes with tradeoffs. Unlike L1, where no one knows the final order of txs until consensus is reached, Rollups can have a single privileged actor (called an orderer) with full discretion over the order of txs. This allows rollups to strike a balance between user experience and decentralization, relying on L1’s censorship resistance and finality while providing instant confirmation.

While this balance is more useful for the trading experience we wish to provide, relying on a centralized orderer is not ideal, as a potential orderer outage could disrupt the user experience. In the case of Mars, outages pose a significant risk, as the protocol could accumulate bad debt during the downtime. While Rollup plans to decentralize these sorters:

(i) almost all teams have delayed it in their roadmaps, (ii) decentralized orderers will increase the confirmation delay that can be provided to users because a quorum of orderers is required instead of a single orderer. inherent delay.

There are also issues with interoperability. Rollups have an exit time, which adds complexity to any low-latency bridge (risks that need to be assessed and covered challenges). In general, cross-chain infrastructure lags behind alternatives, resulting in Rollup currently considered unsuitable for what we believe to be the best cross-chain architecture.


The extended execution capability of shared state is related to the choice of VM and execution model. The first generation ORUs on Ethereum, such as Optimism and Arbitrum , value EVM compatibility/equivalence. While they can leverage existing Ethereum tools, they also inherit the limitations of geth.

For this reason, we are unlikely to see them reach tps (≈50 tps) that are orders of magnitude higher than L1 geth forks (like Polygon or BSC).

In fact, this partly explains why Arbitrum is pursuing the multi-rollup vision, with Arbitrum One and Arbitrum Nova being the first. In a multi-Rollup world, bridging plays a key role. Unfortunately, the design space for Rollup bridges is still immature.

Existing bridging capabilities do not go beyond simple token transfers, L1 call data is still expensive (although future Ethereum developments such as EIP-4488 could alleviate this issue), ORU latency will continue to be a challenge for general-purpose cross-chain applications . Again, this is a problem for us given our views on the best cross-chain architecture.

On the positive side, a major advantage of EVM ORUs is that they can easily leverage Ethereum’s liquidity and community to bootstrap their DeFi ecosystem. Optimism and Arbitrum already have billions of dollars in TVL, and their blue-chip protocols like Aave, Uniswap, Curve, Synthetix , and GMX have driven user adoption.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

On the other hand, the infrastructure for Rollup is still immature. While ORUs have large TVLs, few of them (including Optimism and Arbitrum) have permissionless fraud proofs in production and thus do not minimize trust. While we have every confidence that Rollup will make it happen, it will require a lot of engineering effort and time.

While EVM compatibility makes sense for ORU given the portability of the existing Ethereum ecosystem, it does not benefit all existing protocols that may wish to pursue a cross-chain strategy.

We also see alternative L1 and ZK rollups potentially attracting ORU usage as alternative rollup technologies develop and new builders with no EVM experience enter the field at risk.

So, while relatively high scalability, TVL, and capacity are attractive, poor connectivity, centralization risks, and an uncertain future combine to prevent adoption of this option.

ZK Rollups

Like many, we believe that ZK proofs are the core pillar technology of the blockchain end game. At the heart of every scaling solution is cost-effective validation. ZK proofs allow anyone to prove the complete integrity of an execution (without additional assumptions), making it very useful as a safe, efficient bridge between discrete systems. Today we observe this in the form of ZK-rollups.

In recent years, incentives to push the boundaries of zero-knowledge technology have increased dramatically. Still, it’s hard to predict how soon ZK rollups will gain significant market share. The ZK field is still in its infancy , with some players in various stages of preparation – mainly Starkware, zkSync , and Polygon.

Starkware has been preparing for ZK technology for some time, but offers their StarkEx product as a software vendor. StarkEx is not the open, general-purpose platform we expect in this space, but the technology itself is excellent [2], as evidenced by its adoption by some of the most used dApps such as dYdX, Immutable, etc. However, dYdX recently announced that they are moving from StarkEx to the Cosmos Lisk, mainly due to concerns about decentralization.

StarkNet is a recently launched permissionless open platform based on Starkware technology. Production-ready and provides synchronous composability with other StarkNet dApps. But just launched, its community, infrastructure and DeFi ecosystem are immature – for example, the canonical Ethereum<>Starknet bridge called StarkGate (built by the Starkware team) has deposit limits, and StarkNet’s liquidity is negligible Does not count (about 650 ETH). Like other Rollups, StarkNet relies on a centralized sorter and plans to decentralize over time. [3]

Given that applications built in Cairo (Starkware’s language) offer limited portability, this presents an adoption risk if this proves to be a losing bet. The Warp team at Nethermind is developing a Solidity to Cairo translator, so Solidity could potentially be used in place of Cairo, which of course provides more options and tools.

Many ZK-EVMs [4] such as Polygon Hermez , Scroll and zkSync 2.0 make different trade-offs in terms of speed <> EVM compatibility. While it is exciting to witness their progress, they are still unreleased products and the timing of their future roadmap is uncertain.

Finally, we note that all ZK rollups rely on a new technology that is highly complex and only really understood by very limited domain experts. We believe that this increases the likelihood of software implementation bugs and other unforeseen circumstances that could negatively impact complex DeFi dapps and also makes it harder for us to extrapolate their progress.

While we appreciate the potential of ZK technology to be the ultimate technology and will be watching its progress closely, the above concerns and general issues with Rollup led us to decide not to build there at this time.

Modularity (Celestia Rollups)

As we outlined in Part 1, we see the future as multichain, with many application chains, generic chains, and hybrid chains, each with different tradeoffs and customizations. This facilitates modular blockchain development stacks such as those offered by Cosmos’ Tendermint and Polkadot ‘s Substrate. These provide a collection of reusable and customizable components for creating new blockchains via the SDK.

Celestia approaches modular blockchains from a different perspective, decoupling execution from data, providing only a base layer of data availability and ordering. This enables Celestia to provide security for Rollup/Lisk in a highly scalable manner. It also means that Celestia is only focusing on one element of the blockchain stack, which may be more effective than the all-purpose glue approach.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

This solves a major problem with Cosmos – requiring each chain to have its own set of validators – which requires a lot of time and effort and is not feasible for many dApps. It also splits the consensus security of each chain, resulting in a low security budget at the end. Interchain security from Cosmos is another option, but it is not permissionless; requires mutual consent of the Hub and the consumer chain, and is not a scalable solution; the Hub’s validators require additional resources to verify the consumer chain. While this might be a good temporary solution, it’s unlikely to be the end result.

The user-facing side of the Celestia network is its execution layer; notable projects in progress include Cevmos, Sovereign Labs, and Fuel V2. Fuel V2 seems to be the closest project to the finish, but it’s still very early days. Fuel V2 uses the UTXO data model and a brand new virtual machine to promise fast and scalable execution. While we like their design choices and will pay close attention to them, the technical risks they pose, we think, are too great for the applications we might work on.

As with other new ecosystems, the cost of moving to a new and largely untested language, coupled with UTXO’s new paradigm, is considerable. We also have path dependencies on specific execution environments, and another Celestia Rollup in the future may be more successful in attracting adoption. There is also a risk that future Ethereum development (such as EIP-4844) will reduce the need for Celestia’s primary data availability use case.

While this sounds pessimistic, we are actually very optimistic about the future of modular blockchain networks. We see Celestia’s sovereign Rollup as a potential successor, or possibly the eventual expansion path for Cosmos-based chains. While these technologies are not ready yet, they represent a huge potential mid-term solution while also preparing for a modular future. Celestia is certainly an ecosystem we will be watching closely.

polka dots

Polkadot’s mission has always been to have heterogeneous execution environments (parachains) with shared security. While this was a unique goal for Polkadot when it started this mission, given the existence of Rollups, this is no longer the case.

That said, one of Polkadot’s unique strengths is the years of effort and effort it took to develop its cross-chain messaging protocol, XCMP (similar to Cosmos’ IBC). XCMP is not fully functional yet, but once it is out, it will play a key role in interoperability, creating cross-chain applications.

Substrate and Cumulus are SDKs provided by the Polkadot team for creating parachain-compatible blockchains. To become a parachain, you don’t need to build with Substrate/Cumulus, and you don’t have to force a chain created with Substrate to be a parachain.

However, only parachains can interoperate. Since there is a maximum number of parachain slots, only successful bids through the auction process can become parachains. This means that Polkadot’s interoperability requires sacrificing sovereignty, and its parachain status can theoretically be revoked at any time. In contrast, Cosmos’ approach of providing optional interoperability modules without any connection to a central chain is our preferred approach.

Polkadot scores highly on decentralization, with 996[5] validators, a diverse and thriving developer community, and multiple independent clients[6].

Despite the technology and large development community [7], user adoption on Polkadot is not impressive.

Currently, the top three parachains — Acala , Moonbeam and Parallel — have a combined liquidity of $150 million, well behind their competitors. This has also taken a hit recently, as the largest stablecoin, aUSD, lost its peg after a free-minting bug on the Acala parachain.

In terms of scalability, we mark Polkadot as ahead of many ecosystems, but behind Ethereum and Celestia. While Polkadot employs scaling techniques such as data availability sampling and dispute protocols, validators are still interested in performing state transitions for parachains (or parathreads), which limits their scalability. The same motivation applies to our scalability rankings for Near.

Overall, despite the positives, we don’t think Polkadot has any significant advantages over Cosmos or Rollup of DeFi dApps, and it does have some relative disadvantages.

High-speed monolithic chains (e.g. Solana and Now Sui, Aptos, etc.)

The all-in-one-place approach that monolithic chains take is certainly appealing to developers. Rather than creating a new application chain, it is much easier to build a dApp as a collection of smart contracts at multiple levels: the development cost of writing smart contracts is much lower than writing application logic at the chain level; Contracts do not need to bootstrap new validators; existing wallets and infrastructure can be used; generally, it is easier to attract users when building on existing chains by leveraging existing communities.

Composition with other applications on the same chain is also much easier than trying to do composition asynchronously across bridges. So, despite contradicting our multi-chain vision, fast monolithic applications are really something we have carefully considered.


Ethereum was the original monolith, but it quickly became crowded. Solana is able to be the first trusted high-throughput chain to achieve sub-second block times – the lowest of any production chain. It does this while remaining decentralized, with 1972 validators and a strong Nakamoto coefficient compared to other PoS chains.

Many of these validators appear to be unprofitable without the Solana Foundation subsidy, so it remains to be seen how that will fare once the subsidy ends. Jump also recently announced that they will be developing a standalone Solana client called Firedancer, an important first step towards increasing validator diversity.

Solana has attracted a strong ecosystem of projects and $1.5 billion in TVL, making it the #1 TVL among non-EVM compliant chains. The developer experience, initially considered difficult, has improved significantly with the introduction of the SeaLevel framework Anchor.

Solana has also managed to grow a meaningful and differentiated developer ecosystem, which we believe is arguably tied for the top three with Ethereum and Cosmos. This has also resulted in a differentiated 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 applications, and as such has a rich DeFi ecosystem with many AMMs, money markets, perps, and other DeFi products (including great ones like Mango).

While this opens up a lot of potential integrations, the flip side is that it is also a fairly crowded space with a large number of competitive DeFi dApps relative to the number of users/TVL. There is also a risk of further fragmentation given the launch of fast monolithic challenger chains like Sui and Aptos.

The biggest challenge Solana has faced lately has been network outages. As mentioned earlier, for some DeFi projects, downtime is risky, because liquidation cannot take effect during the downtime, and the protocol will accumulate bad debts.

The root cause of chain halts is that cheap operations expose the network to malicious attacks. As a workaround, Solana implemented priority fees. The uncertainty of these issues and when they will be fully resolved highlights the risks of adopting new technologies for DeFi applications, such as those we contribute.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

Accurate resource pricing remains a challenge for all permissionless blockchains. Today, blockchains have a single market for fees, where all resources (I/O, storage, compute, bandwidth, etc.) are metered in the same abstraction called gas. This makes it challenging to accurately price operations relative to each other.

Ultimately, Solana (and others) will implement localized fee markets so that congestion in a particular dApp doesn’t compromise the user experience for everyone else. We are closely following this development and its impact on Solana.

Overall, while Solana has faced a lot of criticism (often unfairly) for being unstable, centralized, difficult to build, etc., we were impressed with the Solana Labs team and ecosystem’s ability to improve in these areas. Solana relatively achieves credible decentralization from multiple elements, and the development experience has also been improved. We also believe that stability will be a matter of the past and soon forgotten.

However, given the upcoming competition from fast monoliths from challengers like Sui and Aptos, bridges requiring additional trust assumptions, and the fact that monolith theory generally doesn’t fit our multi-chain vision, we don’t think Solana makes sense at this stage.

Aptos Sum Sui

Both Aptos and Sui aim to maximize network throughput per node, similar to Solana, but with very different technical approaches. One of the core ideas of this design seeks to optimize the mempool propagation layer by distributing the DAG of transactions and guaranteeing availability.

Both have the potential to surpass the performance of a single validator through internal sharding of validators and homogeneous state sharding. Internal sharding means that the validator does not need to scale vertically, increasing its gauge to match the gauge of the network, but it can spawn additional machines behind the load balancer and shard state as if it were a single node. This basically solves a problem with Solana that the validator specification would be a performance bottleneck and gracefully scales.

These ideas are promising and seem likely to yield some of the lowest latency and highest throughput in the L1 blockchain space. This is interesting to us because the more performant and scalable a monolith is, the less obvious the need for new chains. However, given our general optimism about Web3, we still feel that the need for a broad range of use cases will spill over into new specialized chains, leading to the multi-chain architecture we outline.

Another advantage of these chains is that they use the Move language (or in the case of Sui, the Move variant). Our initial experiments with Move on these chains were very promising [8], and parallelization was elegantly demonstrated. Therefore, we do not expect that the development experience of smart contracts will not be a significant disadvantage compared to other ecosystems using new languages, especially given that there is some time for development patterns to emerge. This is thanks in part to the fact that Move has been in development since Facebook ‘s Libra (where many development teams come from).

These chains end up with similar drawbacks to other new technologies we’ve considered – immature DeFi ecosystems, communities, connectivity and huge technical risks make them unsuitable for migrating projects with existing communities and in other ecosystems technology choices made. As a counterpoint, MoveVM and variants may be used across multiple chains, which does provide some optionality if migration is required. They may become appropriate as they develop and bridges are developed, and we’ll definitely be watching them closely.


Polygon PoS fills a much-needed void by becoming Ethereum’s go-to sidechain due to a late listing on Ethereum’s Rollup-centric roadmap. Polygon is very fast, with an average block time of around two seconds. Combined with a very strong ecosystem, it does meet our two main requirements for building a good DeFi experience.

These factors are largely due to the effectiveness of the Polygon team in business development and capital deployment, enabling it to gain significant market share while solidifying the EVM legacy. In the EVM space, Polygon is second only to BSC in capturing Ethereum users and has a very rich DeFi and gaming/NFT ecosystem and $2B TVL.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

As usual, these pros do come with cons. In the past, Polygon has undergone a deep reorganization many times, resulting in a poor user experience. Additionally, we noticed that governance decisions in Polygon are sometimes opaque and centralized. An example of this is the decision by the core team [9] to significantly increase the gas price by a factor of 30, which seems to have been proposed without much involvement from the community.

It is worth noting that becoming a validator on Polygon is not currently a permissionless process. The purpose of Polygon is to conduct periodic auctions where anyone can replace existing validators by staking a higher amount.

However, since reaching the 100-node maximum cap, the auction has not been held, and currently the only way for anyone to become a validator is if one or more of the existing validators unstake. The last community proposal [10] addresses this issue by outlining mechanisms for the network to self-regulate; an important step in the network’s plan to gradually decentralize.

Last but not least, the security of the ecosystem depends on a small committee controlling billions of dollars through a canonical Ethereum<>Polygon PoS bridge.

On the other hand, we see Polygon as an ecosystem, not a chain. The core team has invested significant resources to build new scaling solutions, including ZK rollups Hermez, Miden, Zero, DA Layer Polygon Avail, and more. We especially spent some time researching ZK technology and were very impressed with our findings.

Polygon Edge is also promising and very close to our proprietary Lisk vision, although the technology is still in its infancy and connectivity between supernets is an open issue. Overall, given its existing adoption, superior BD, and the technical prowess of its upcoming ecosystem, Polygon has the second highest score in our rankings, and we might see it as a competitive choice for EVM-based DeFi dApps .

However, the current trust assumptions of bridges and current PoS chains are the main factors in our decision that it is not the best place to build at the moment.


The main difference of Near is its dynamic sharding architecture. The goal of this design is to keep users and developers from having to know which shard they are on. Instead, validators dynamically (every 12 hours or so) determine which tx will be grouped together based on statistical analysis, effectively adding/removing shards in a seamless manner. Sound like science fiction? Maybe, but it’s a uniquely ambitious vision, so it deserves credit.

This architecture enables very competitive scalability with a block time of 1.3 seconds. It manages to do this while maintaining acceptable decentralization, currently has around 100 nodes, and plans to make verification more inclusive through “chunk-only producers” [11], which will significantly reduce hardware requirements .

However, this architecture does have some drawbacks. Smart contracts must communicate using asynchronous mode, as they are not guaranteed to be part of the same shard. In fact, even today, application developers must perform asynchronous smart contract calls when Near is running on a single shard.

DeFi applications often require precise coordination of many contracts, and asynchrony can introduce additional complexity, failure modes, and finalization time. For example, liquidation involves at least 3 different smart contracts (money market, oracle, and exchange) working together. Asynchrony between these components introduces additional delays and security assumptions that can affect market solvency.

Near communities and ecosystems are not as robust as others, and there are currently few ways to integrate with the DeFi ecosystem. That said, the Near team has a strong vision and has been aggressively executing it, raising an $800 million[12] ecosystem fund, and actively investing in BD, they’ve managed to attract some strong applications[12] 13].

Near built an EVM compatibility layer called Aurora, which accounted for about half of the activity. This increases the portability of EVM-based dApps. It also has a trustless ethereum bridge called Rainbow that creates a strong connection to ethereum, although connections to other ecosystems are currently lacking.

Overall, the complexities introduced by asynchronous calls, especially for highly composable DeFi applications, combined with the existing small ecosystem, lead us to view this as a short-term option – although we will keep an eye on the ecosystem future progress of the system.


Architecturally, Avalanche is very similar to Cosmos, with multiple interoperating domains (subnets instead of zones). Just like a Cosmos zone, a subnet is a sovereign network with its own security. This architecture provides a smoother way for dApps to start with smart contracts, build communities, and once mature enough, become further customizable subnets.

As smart contracts migrate to subnets, they also relieve congestion on the main network, thereby reducing fees. We saw an example in P2E game DeFi Kingdoms launching its own subnet. This makes us feel like this is a healthy way for the ecosystem to grow.

The downside of Avalanche is that it is a relatively new ecosystem. As a result, existing cross-subnet capabilities, infrastructure tools, and development communities remain immature.

Avalanche’s competitive advantage lies in its novel consensus. Unlike others, Avalanche’s consensus can accept a large number of validators without degrading consensus performance. Today, Avalanche’s main network is run by more than 1000 consensus nodes [14] while maintaining an impressive 1-2 second block finalization.

However, when it comes to censorship (not accompanied by a high Nakamoto coefficient) resistance and/or decentralization, the effectiveness of the number of consensus nodes is debatable. Ultimately, the influence of each validator depends on the weight of its stake. In a permissionless setting, stake is usually concentrated in the hands of a few people due to the tendency towards centralization [15]. Due to the lack of careful measures of MEV and accountability, we found that the number of consensus nodes is not a very useful measure of decentralization.


Best described as an ecosystem of interoperable blockchains, Cosmos is a network of blockchains connected using the IBC protocol.

As mentioned in Part 1, we expect to see a shift towards dedicated or application-specific chains due to the benefits of customizability. However, it would not be feasible to require each chain to design and implement consensus, storage, networking, etc. from scratch. The Cosmos SDK is a set of customizable modules that together act as a template for creating new blockchains, reducing the development effort for many dApps.

Substrate from Polkadot offers a similar toolkit, but from our conversations it seems to be generally considered harder to use than the Cosmos SDK, and there are far fewer Lisks in production than the Cosmos SDK. As mentioned earlier in the Polkadot section, interoperability only applies to parachains, whereas Cosmos chains can interoperate directly without the involvement or approval of the Cosmos Hub.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

IBC (Inter-Chain Communication Protocol) is an interoperability protocol for transferring arbitrary data between arbitrary state machines (blockchains). While any final blockchain can implement IBC and join the Cosmos network in the future, the only production implementation ready is as a set of Cosmos-SDK modules.

IBC is trust-minimized, just like two IBC-enabled chains need third-party relayers, it only needs relays

  1. The signature of the source chain validator to prove the block header, and
  2. The merkle proof, together with the block header, proves that a certain tx exists in the block of the source chain. None of this can be faked.

We think the IBC’s assumption of trust is a huge advantage . Most bridges work by bringing in one or more different stakeholder groups and relaying messages between two chains, creating additional trust assumptions and attack vectors. IBC only needs to trust the chain being connected. Given that cross-chain messaging is at the heart of the cross-chain architecture we are exploring, ensuring trust minimization in the bridge is a key consideration for us.

IBC provides more than just messaging.

Cross-chain accounts is a new feature that allows a blockchain to control accounts on another chain through IBC. With IA, the multi-chain user experience is greatly simplified. Instead of opening multiple accounts across chains, moving tokens between them, paying fees in different denominations, users will be able to use dApps across different chains from one account.

For cross-chain projects, this feature will allow for example governance on a central chain to control smart contracts on connected chains.

There are also cross-chain queries, which allow one chain to query the state of another chain. However, these features are still immature and not fully ready for production use, but when they are, will significantly widen the design space for cross-chain applications.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

Despite its technological advantages, the Cosmos ecosystem is still small, with a TVL of less than $1 billion [16], most of which is on-chain without CosmWasm or IBC support.

The DeFi space on Cosmos is currently undergoing a major shift. As written in the introduction, Terra, the largest chain in Cosmos, recently collapsed, causing most of the assets in Cosmos to be destroyed or flee. Terra is both a blessing and a curse for the Cosmos.

While the Terra crash hit the Cosmos ecosystem harder than any other ecosystem, it also brought with it a large community of enthusiastic users and developers, many of whom have now decided to stick around.

We’ve seen Terra projects like Kujira and Apollo commit to launching Lisk, while others relaunch as smart contracts on existing chains, such as Levana on Juno and the upcoming Vortex (formerly Retrograde) on Sei Network.

In addition to the former Terra project, other large projects have seen the benefits of Cosmos, with dYdX being the most notable. Still, liquidity in the ecosystem is currently developing, so working on building Cosmos is a bet on future growth.

Delphi Labs: Why do we focus our research and development on the Cosmos ecosystem?

As for speed, block times vary from chain to chain and depend on a series of tradeoffs, such as the number and geographic distribution of validators. Historically, a fully decentralized Cosmos chain has typically had a block time of about 6 seconds, which is pretty average.

However, newer chains are improving on this, such as Evmos and Injective achieving block times of ~2 seconds on globally distributed validator sets, while Sei achieved ~1 second block times on testnet.

Talking to the Tendermint team, there seems to be a lot of room for improvement via storage and consensus optimizations – sub-second block times appear to be feasible for some applications in the near future.

Additionally, the modularity of Cosmos is an advantage here, with independent teams able to improve consensus on their own. An example here is Optimint [17] developed by the Celestia team, which will implement an ABCI compliant Rollup on Celestia, providing a potential future scalability path for the Cosmos chain.

As for decentralization, the number of validators on the Cosmos chain is much lower than on Solana and Ethereum PoS networks. However, we believe that the number of validators is not actually a good measure of decentralization. Instead, we prefer to look at the Nakamoto coefficient (the number of colluding entities required to censor a transaction), which is 7-10 for most Cosmos chains, 2 for Ethereum 2.0, and 31 for Solana.

One of the great things about Cosmos is the high degree of decentralization of the core development, with multiple independently funded teams dedicated to contributing to the core development. Informal, Strangelove, Interchain Gmbh, All in Bits, Confio, Regen Network, and others are all working to contribute parts of the Cosmos core codebase, while others such as Quicksilver, P2P, and SimplyVC are also working to contribute peripheral components such as ICQ.

Conclusion: Cosmos

After considering the options we have summarized above, we have decided that the best approach is to focus our R&D efforts on the Cosmos ecosystem.

As mentioned in Part 1, we believe that this space will increasingly fragment into a mesh network of general-purpose smart contract chains and specialized application chains connected by trust-minimizing bridges. In such a world, multiple DeFi hubs will emerge, each with their own tradeoffs, ecosystems, and communities. department

Well-architected DeFi dApps deployed on multiple platforms will benefit from liquidity and other network effects that will make it difficult for native DeFi dApps to compete. We believe that Cosmos is best positioned to benefit from the growing number of Lisks and support state-of-the-art cross-chain architectures.

Additionally, it is fast enough to enable seamlessly integrated DeFi UX with order books, high leverage, and fast trade execution. At the same time, we believe it is sufficiently decentralized to provide strong security, liveness, and censorship-resistant guarantees, especially compared to many of the alternatives we considered, which are newer and therefore more centralized vector.

Its biggest weakness is the ecosystem, the current TVL is lower than a single ETH L2. Related to this, Cosmos also lacks hype, funding, and dissemination, likely due to the lack of a modeled L1 token to come together. While we believe the influx of projects from the Terra debacle and the growing number of specialized Lisks will be somewhat remedial, there is no denying that we are betting on future ecosystem growth. This remains the biggest risk to the universe and our theory.

For these reasons, we will focus on the Cosmos ecosystem for the foreseeable future. That said, we are not cosmic extremists (except Larry), so we will continue to actively research and monitor other ecosystems. Below are some areas we will be paying close attention to, suggesting that our paper may be revised.

Growth of Monolithic Chains Relative to Lisks: If most interesting dApps are deployed on monolithic chains and never move to their own execution environment, then this will invalidate our argument. After all, the current cost of deploying an application chain is much higher than the cost of deploying a smart contract on a monolith, and the composability, branding, and user experience advantages of the popular universal chain are also strong.

Furthermore, things like orphan state auctions [18] can make monoliths more competitive in terms of resource cost and predictability. We will keep an eye on the fastest monomer chains and reconsider our paper if we see signs of this happening.

Emergence of trustless bridges: In our analysis, we ignored many chains due to weak connectivity, meaning they either lacked bridging infrastructure entirely, or the existing infrastructure was immature and/or had poor trust Suppose.

That said, there are multiple well-funded, great teams working on bridge solutions, which we believe will improve over time. We’ll keep an eye on this to see if there’s anything comparable to IBC in terms of trust assumptions, or if IBC (chain agnostic) spreads outside of Cosmos. We will also pay particular attention to connections between specialized execution environments, such as Avalanche subnets and Polygon supernets, as they best fit our multichain theory.

Maturity of high-potential but current high-risk technologies: Throughout the process, we looked at several emerging technologies that have the potential to be a class-leading endgame, especially in the rollup space – ZKRollup and Celestia Rollup, especially Fuel V2. We will keep an eye on this and look to deploy once we believe the risk is minimized.

All in all, this report takes us down a different rabbit hole, and we’re more bullish than ever on the future of the field. There are multiple well-funded and talented teams working on order-of-magnitude improvements in scalability, connectivity, and DX/UX. Collectively, these improvements will enable entirely new cross-chain DeFi applications, which we believe will help drive more on-chain activity.

While we put considerable effort into studying each ecosystem and ensuring the accuracy of our analyses, we are sure to miss something given the breadth of material covered. If you think we have, we welcome you to contact us.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-09-10 11:12
Next 2022-09-10 11:13

Related articles