General-Purpose vs App-Specific Guide for Application Developers

Evaluating tradeoffs of general-purpose and application-specific infrastructures for applications from eight perspectives - How would you pick, anons?

Dec 09, 2022

Introduction

Over conversations with application developers, I often get the question, “There are so many L1s, L2s, app-chains, and even app-specific rollups, what infrastructure should I build with?” Selecting infrastructure is one of the most important architectural decision for applications builders since so many trade-offs around performance, throughput, MEV, UX, liquidity fragmentations, value accrual models, and interoperability with other applications are contingent upon this decision. In this article, we will evaluate tradeoffs of general-purpose and application-specific infrastructures for applications from eight perspectives: fee models, atomicity, sovereignty, liquidity cohesiveness, cross-chain interoperability, MEV, value accrual, and security. I hope this article can give application developers a framework to think through this architectural decision thoroughly and direct developers to areas that need further research.

Before I dive in, I will offer a few quick definitions to different infrastructure types:

General-purpose chain: Blockchain that is Turing-complete and can run arbitrary programs
- Eg. Ethereum, Solana, Avalanche
General-purpose rollup: Smart contract platform that leverages zero-knowledge proofs or fraud proofs to scale blockchain. General-purpose rollup is also Turing-complete and supports running arbitrary programs. They post all transaction call data to the underlying L1 such that the L1 serves as the data availability and consensus layer.
- Eg. Scroll, zkSync, Starkware, Polygon Hermez
Application-specific chain: Blockchain that is specifically designed for the use of one application. Right now, most application-specific chains are built with cosmos-SDK, using tendermint as the consensus layer, using ABCI as the interface between application layer and consensus layer, and leveraging IBC for interchain message passing
- Eg. Osmosis, Penumbra, Injective, Juno Network (mostly cosmos ecosystem)
Application-specific rollup: Rollup that is specifically designed for the use of one application. Right now, most application-specific rollups are run on single server and have single sequencer to execute all transactions. They rely on fraud proofs to ensure the integrity of state transitions. They post all transaction call data to the underlying L1 such that the L1 serves as the data availability and consensus layer.
- Eg. Constellation Labs, Stackr Labs

1. Fee Model

Fee models are mechanisms that price and manage the supply and demand of scarce resources in the stack. In case of gas fee model, the scarce resource is blockspace, and users pay gas to compensate miners as well as bid for blockspace.

However, having users pay gas in native tokens is a significant UX friction. Ideally, for the best UX, applications want to allow users to pay gas in any token they prefer or even subsidize gas so that users don’t need to pay gas at all. From application developers’ perspective, gas payments transfer part of the value created by the application to the underlying protocol layer and MEV exploiters. Ideally, application developers want to mitigate this transfer of value as much as possible without sacrificing security. This way, applications can provide the best price to users and accrue all the value created by the application layer.

Essentially gas fee model wants to achieve two purposes: anti-spam and incentivizing validators. When adjusting the fee models for the best UX and the least value leakage, applications are facing three constraints:

1/ keeping validators incentivized
2/ sustainable P&L for applications regardless of other applications’ transaction volume
3/ anti-spam for applications and validators

With gas subsidy or not, gas fee models need to ensure that:

cost of txn for end-users > benefits that validators receive from including the transaction into the block > costs for validators to supply the blockspace > 0

If the first predicate were to flip, validators would have incentives to “wash-transact” and farm the rewards. If the second predicate were to flip, validators wouldn’t have incentives to stay in the network. It’s worth noting that cost of txn is not limited to gas payments to validators; it can also include swap fees, application usage fees, costs of MEVs etc. Benefits that validators receive also include gas fees, gas tips, block rewards, and MEV profits.

App-chains that function as exchanges allow users to pay gas in non-native tokens or subsidizing gas. Exchanges such as Osmosis and dydx allow users to pay gas in any token trading on the DEX and bundle transaction fees into swap fees to further smooth the UX. App-chains can also subsidize gas for users by paying validators directly from a separate pool of capital as long as the equation highlighted above is satisfied. Osmosis has done this in its early days. For app-chains that aren’t exchanges, it’s impossible to let users pay gas in any token and convert other tokens into the native token in one atomic transaction. However, app-chains can obtain trading pairs price data from oracles, denote prices, and accept payments in selected tokens beyond the native token.

App-specific rollups that optimize for performance, such as those supported by Constellation Labs, typically operate on single sequencers. The gas fee consists of two parts: call data fee paid to L1s, which is the majority of total gas fee, and rollup operation fee. While call data fee is fixed, rollup operation fee varies based on the level of network congestion. Application developers can ask end-users to only pay a fraction of the real cost and subsidize the fixed cost to provide better UX. For the part that’s paid by end-users, users can pay the fee in any token that’s whitelisted by the application developers. The rollup will then get token prices from oracles and settle the gas payment in non-native tokens.

Applications on EVM-based general-purpose chains can rely on ERC-4337 account abstractions to improve the fee model UX. With account abstraction, users can deposit ERC-20 tokens into paymaster and let paymaster pay future gas fees denoted in eth till the deposit runs out. Applications can also subsidize gas through paymasters to further smoothen the user experience. However, subsidizing gas for users often doesn’t make economic sense for applications on general-purpose chains because gas fees fluctuate significantly based on volume of the entire chain. Applications would often pay for the congestion brought by other applications to their “shared space”. For example, if gas fee is really high during a popular NFT mint on ethereum, Uniswap wouldn’t want to pay thousands of dollar in gas for customers who pay 2-digit swap fees. Thus, it’s only sustainable for applications to subsidize gas for either high-value transactions from which they gain usage fees that far exceeds the gas fee or times at which volume and gas are low. This type of subsidy brings convenience but little to no meaningful price advantages for users.

For general-purpose rollups, both StarkNet and zkSync are launching native account abstraction designs that are very similar to EIP-4337. However, for applications on general-purpose rollups, subsidizing gas for users also only make economic sense for applications when gas fee remains low or become negligible when comparing to swap fees or application usage fees.

2. Synchronous Composability / Atomicity

In the context of blockchain, atomicity refers to bundled transactions such that all transactions within a bundle must be valid for the bundle to be accepted. Transactions within a bundle either all or none goes through within one block.

If your application needs Flashloans or other multi-application atomic calls, it’s better to build on general-purpose chains pre-sharding. Sharding will disrupt the atomicity of ethereum. If Flashloans are not a complementary good for your application, the lack of atomicity shouldn’t be a concern if you want to choose the application-specific route.

For general-purpose chains, applications are synchronous on each chain pre-sharding. Thus, general-purpose chains have full atomicity across all applications within the chain. The most direct use-case of this atomicity is Flashloans. Users can borrow instant liquidity, call contracts of multiple applications to run arbitrage strategies, and execute these transactions only if the liquidity is returned by the end of the block. Flashloans democratize arbitrage since users don’t need upfront capital to run arbitrage strategies. However, Flashloans have also brought many issues such as market manipulations through borrowing and lending protocols.

Sharding disrupts the atomicity of Ethereum because shards are asynchronous. As sharding unfolds in ethereum’s roadmap, cross-shard transactions can still happen quickly but asynchronously using the “locking” approach of cross-shard transactions. Workflows of the form “do something on shard A that will soon have an effect on actions on shard B” will be easy; but workflows of the form “do something on shard A, then do something on shard B, then do more things on shard C based on the results of things on shard A and B, all atomically within a single transaction” will not be natively supported. This is where the “yanking” approach of cross-shard transactions comes in. To execute multiple actions within one atomic transaction would first require yanking the contract to one shard and then performing the entire operation synchronously on one shard.

Chains are asynchronous, and it’s impossible to do cross-chain atomic calls due to the asynchronicity. Thus, for app-chains, atomicity is restricted to one specific application. It’s impossible to have Flashloans or any transaction that requires atomic calls of multiple applications. However, since most existing applications don’t leverage multi-app atomicity outside of Flashloans, the lack of multi-app atomicity typically shouldn’t be the determining factor for not choosing the app-chain infrastructure.

3. Sovereignty

Sovereignty refers to the capability of an application to fork permissionlessly without compromising security. Forking here refers to effective forking that’s agreed upon by the majority of validators, so forking Ethereum with minority agreement doesn’t count. Sovereignty is very useful under extreme circumstances such as hacks or malicious market manipulations. ****

In essence, sovereignty is determined by how incentive-aligned various parties in the stack are. My hot take is that sovereignty is a very important feature to consider if you are building liquidity-heavy applications. App-chains inherit the highest level of sovereignty.

General-purpose chains give applications the least amount of sovereignty because validators of the underlying chain are only partially incentive-aligned with any specific application. While applications inherit the strong security of the underlying L1 chain like Ethereum, the most horrendous hacks thus far, such as Compound’s $150 million hack and Wormhole’s $326 million hack, are smart contract bug-exploits rather than malicious fork of the underlying chain. When these application-level exploits happen, the lack of application-sovereignty limits remedies that application-governance can implement. Since validators’ incentives aren’t strongly aligned with any specific application, it’s difficult to coordinate a fork with sufficient support from validators. Moreover, for Defi applications that heavily rely upon centralized assets such as Tether or USDC, the fork is mostly unfunctional unless it can obtain the recognition from centralized assets’ issuers.

Smart contract rollups are forkable, but the decision over what is the canonical chain is made by smart contracts on the underlying L1. Smart contract rollups only handle execution and rely on the underlying L1 to handle consensus, data availability, and settlement. zkEVM scaling solutions such as Scroll and zkSync are general-purpose smart contract rollups.

In contrast to smart contract rollups, sovereign rollups handle both settlement and execution instead of just execution. Sovereign rollups don’t depend on decisions of the underlying L1 for meaningful forking. However, in reality, applications benefit little from this level of sovereignty if the rollup is a general-purpose rollup or if the application is highly dependent upon centralized assets. For robust general-purpose rollups that support multiple applications, it’s difficult to coordinate nodes to support a fork for one application at the cost of forgoing all transactions that other applications have correctly settled during the coordination period.

App-specific rollups trade sovereignty for security and performance. App-specific rollups, similar to applications built on general-purpose chains, inherit very little sovereignty. For app-specific rollups that are settled on ethereum to roll back states, it requires support and coordination from the majority of ethereum validators — which in practice is impossible for any application to obtain. Given that app-specific rollups are often run on single validator and sovereignty is only useful under extreme circumstances such as a hack, it’s fair to say that sovereignty is worth to be given up in order to ensure security.

App-specific chains can leverage governance to fork states under extreme circumstances such as liquidity drains or hacks. This is due to the fact that all validators are significantly incentive-aligned with the success of the application. If validators of an app-chain agree upon the maliciousness of a transaction, even if it’s not a hack but simply an exploit of the mechanism design such as airdrops farming, validators can collectively decide on what’s the best for the chain. Thus, the threshold of rolling back states under extreme circumstances is much lower for app-specific chains than that of other infrastructure options.

You might be wondering, with the ease of rolling back states for app-chains, does it imply that app-chains are less secure than general-purpose chains and rollups? Not necessarily. With the same amount of token staked, app-chains, with pBFT-based tendermint consensus mechanism and interchain security, are more secure. I will dive deeper into this in Section 8: Security.

4. Liquidity Cohesiveness

In terms of bootstrapping liquidity for applications, liquidity can easily and securely flow in and out of app-chains that’s connected to IBC. Liquidity from each chain / rollup can also easily and securely flow in and out of any application on that chain / rollup.

If an application values interoperability with other applications, especially those built on chains that are hard to bridge from tendermint-based app-chains, more than avoiding liquidity and volume fragmentation, building on general-purpose chains and rollups is more ideal from this perspective.

There are two major approaches to building multi-chain applications. The first approach is to deploy the application separately on each chain / rollup and let each deployment easily interoperate with other applications on each chain. However, liquidity on one deployment is not contributing to the pool depth of another deployment. Thus, this approach allows each deployment to have interoperability with applications in various ecosystems but also causes liquidity fragmentations and capital inefficiency for the application.

The second approach of building multi-chain applications is to deploy an app-chain which can aggregate all liquidity. This makes the application more capital efficient but also forces it to rely on cross-chain messaging protocols for interoperability with other applications.

5. Cross-Chain Interoperability

Applications built on the same chain are interoperable with each other. The challenging part, whether you want to build with the general-purpose or the app-specific stack, is cross-chain interoperability. In this section, I will lay out tradeoffs of four approaches to interoperability: light-client, permissionless-validator, permissioned-validator, and optimistic.

If your application mainly requires cross-chain interoperability with app-chains, building app-chain and use IBC for cross-chain interoperability is the optimal route. If your application also needs interoperability with applications on general-purpose chains / rollups, the impossible triangle for cross-ecosystem interoperability is security, speed, and cost. However, there is room for improvement in the optimistic approach that could potentially break the impossible triangle.

Generally speaking, cross-chain interoperability solutions are divided by whether chains connected have instant and deterministic finality or probabilistic finality.

1. With Instant and Deterministic Finality: Tendermint-based chain <> Tendermint-based chain

IBC takes the consensus-light-client approach and is the gold-standard of trust-minimized cross-chain messaging protocol for blockchains with instant and deterministic finality. IBC effectively eliminates the need of a trusted third party or validator set for app-chains and thus is the most secure way of cross-chain messaging for app-chains. App-chains that are implementing the tendermint consensus mechanism with Cosmos SDK can be directly plugged into the IBC protocol. Two app-chains that are interested in having a connection with one another will have a governance proposal on the destination chain to reach protocol-level agreements on ICS parameters. ICS parameters are module specifications of IBC transactions. With relayers relaying block headers between light clients on the two chains, Destination Chain A can run light client that verifies the state of Source Chain B through Source Chain B’s block header. The security assumption of cross-chain messaging then lies within consensus of the two connected chains, nothing more.

However, IBC is not the silver bullet of interoperability for all circumstances. Two types of chains cannot be bridged through IBC: PoW chains with probabilistic finality and chains that don’t store consensus in block headers. For example, ethereum with proof-of-work consensus relies on the fork choice rule to reach consensus, which means that the longest chain is the canonical chain. Thus, the consensus is not captured by any block data, making it impossible for light client on another chain to securely verify the state of ethereum. However, with ethereum shifting away from proof-of-work, it will also transition to Casper FFG consensus mechanism with slow and absolute finality, which provides finality for every 2 epochs (approximately 13 minutes).

2. With Slow and Absolute Finality: Tendermint-based chain / EVM-chain / Alt-L1 <> EVM-chain

You might wonder, with Ethereum 2.0’s absolute finality, can we run light client on ethereum to verify the state of tendermint-based chains? This is difficult and expensive. First, it requires writing tendermint light client in solidity. Plus, the light-client approach has a detrimental disadvantage: it’s compute-intensive. This is not a problem on app-chains since compute is cheap on app-chains. However, it becomes prohibitively expensive on general-purpose chains and rollups. Moreover, it requires verification of hundreds of ed25519 signatures in solidity, which incurs prohibitively expensive gas fee if being run on ethereum.

With the consensus-light-client approach being impossible, here comes the validator-based approach. Axelar is an interoperability protocol that is taking the permissionless validator approach. Cross-chain messages are verified using a threshold-signature scheme. It’s currently supporting most EVM-chains and all Tendermint-based chains. It allows anyone to stake funds and run validators for the interoperability protocol. However, worth to note that Axelar is only secure when the economic value on connected chains stay within the limits of 51% of value staked by Axelar validators. Otherwise, Axelar validators have incentives to collude and steal funds from the chains. Moreover, Axelar has an inverse relationship between security and speed: the more validators added to the Axelar network, meaning the more secure, the longer it takes to gossip the message among all validators. Right now, it takes ~8min to bridge through Axelar. Axelar can also be expensive when volume between two networks is low since end-users amortize the costs of incentivizing validators to stay around. As of right now, the relayer gas fee amounts to ~$21 USD to bridge between Ethereum and other chains. This price is reasonable for infrequent cross-chain assets transfer but prohibitive for frequent cross-chain transfers.

In contrast to Axelar’s permissionless approach, Wormhole takes the permissioned validator approach. It’s supporting most EVM-chains and Alt-L1 chains. Essentially, it has a permissioned network of guardians and a permissionless network of relayers. There are 19 guardians that run full nodes for each of the supported chains and listen to messages from the wormhole contract on each supported chain. Instead of trusting that validators will behave rationally based on their economic incentives, Wormhole is placing more social trust on the selected guardians. However, it’s not only trusting the selected guardians to not act maliciously but also trusting that they will keep the validator keys safe from malicious actors. Some argue that this approach is putting too much trust on the selected validators. For example, the hacks of Ronin bridge, which costs an approximately $625 million loss of funds, was due to compromises of validator keys through malicious social engineering.

If you are building an application with high-value liquidity and the trust assumption on the interoperability protocol validators seem too risky, another alternative is the optimistic approach of interoperability. Optimistic interoperability protocols rely on off-chain entities, aka watchers or disputers, to monitor messages being passed across chains and ensure protocol security. Watchers or disputers are compensated for correct disputes and punished for wrong ones. The optimistic approach imposes less trust assumption on third parties because it only needs one honest watcher/disputer to survive any attack, including invalid message proofs, malicious relayers or validators on source chains. The optimistic approach tends to be cheaper than the validator approach since end-users don’t need to pay incentives to keep validators around.

The current downside of the optimistic approach, based on existing set-ups, is that users need to wait till the dispute period ends, which drags down user experience and prevents frequent cross-chain transfers. However, security of an optimistic system is not directly related to the length of the dispute period. Security is related to the number of honest disputers and the level of difficulty of malicious party to censor dispute transactions. The more decentralized the destination chain, the more difficult it is to censor dispute. Meanwhile, the dispute period should be set with the amount transferred in mind instead of setting an arbitrary length.

6. MEV

MEV counts for a significant amount of on-chain activities. Based on data from Uniswap V3, 49.2% of transaction volume comes from MEV bots. Some MEV are benevolent. It’s very important to think of how MEV will benefit or hurt your application and make infrastructure decision accordingly. Generally speaking, arbitrage and liquidation are benevolent while sandwiching and front-running tend to be malicious.

From the perspective of minimizing malicious MEV for providing competitive prices and better user experience, app-specific is the more optimal route. While the app-chain stack allows application developers to customize mempool and transaction ordering mechanism but execute through validators, app-specific rollups give application developers full control over mechanism design and execution.

The form and amount of MEV depend on mempool design and transaction ordering mechanism of the chain. For chains with only public mempool, all pending transactions are visible to all nodes on the peer-to-peer network. This structure not only creates opportunities for malicious MEV such as sandwich attack but also incurs the risk of mempool spamming. On the other hand, private mempool creates a private communication channel between searchers and validators: Searchers can hide content of their transactions from other searchers till their transactions are included in a block. Private mempool mitigates the competition among searchers and redistribute leverage within the MEV supply chain from validators to top searchers. For chains with First-Come-First-Serve (FCFS) ordering mechanism, transactions submitted later cannot be executed before transactions submitted earlier. Thus, there’s little opportunities for sandwich attacks or front-running. For chains with tip-based ordering mechanism, such as that of Ethereum after EIP-1559, transactions submitted later can be executed earlier if the tip to validator is competitive.

For app-specific rollup running on single sequencer, application developers / rollup providers have full control over how and who capture MEV. App-specific rollups have private mempool and centralized transaction ordering determined by the rollup operator, which is either the application developers or rollup providers. App-specific chains allow application developers to customize mempool and transaction ordering mechanism but still have validators as executors of ordering. However, the chain can enforce ordering mechanism such as FCFS, by which validators consequentially have no control over the ordering.

For general purpose rollup, rollup developers determine the design of mempool and transaction ordering, and rollup operators execute the ordering. Application developers can choose which rollup to build on but don’t have any influence on the design of ordering mechanism or execution of transactions. For general-purpose chains, application developers have no influence over design or execution of transaction ordering.

Transactions on Cosmos-based app-chains are ordered by FCFS, which mitigates front-running and sandwiching MEV because these types of MEV require having later-submitted transactions executed before earlier-submitted transactions. However, back-running, arbitrage, and liquidation still exist under FCFS. These MEV leads to rush for MEV profits and spamming of the network. This market structure indicates that MEV profits eventually flow to searchers and hardware providers that searchers rely upon for their low latency infrastructure. Stakers, validators, and end-users have little leverage to benefit from the MEV profits with the current market structure. For example, data has shown that out of the approximately 7 million USD of accumulative MEV revenue on Osmosis, the network only receives $46K USD in transaction fees.

Skip Protocol is trying to solve this problem by having users submit transactions through Skip so that sophisticated searchers can pay Skip a competitive fee and have top of block execution without spamming the network. Meanwhile, Skip is configurable such that it filters out front-running and sandwich attack transactions and can trustlessly commit to MEV profit-sharing with end-users and validators. Skip Protocol has recently announced MEV-Satellite to publicize MEV revenue and facilitate profit-sharing with stakers, validators, and end-users. To learn more about how Skip’s vision is implemented, Skip Protocol’s proposal for turning MEV revenue into protocol revenue on Osmosis gives a thorough overview.

7. Value Accrual

Historically, it has been hard for tokens of DeFi projects deployed on general-purpose chains / rollups to directly accrual protocol value without infringing upon the risk of being categorized as securities. The joke that they are just “useless” governance token has some validity. On the other hand, tokens of application-specific chains can become utility tokens that validators stake to secure the chain and earn yield.

8. Security

This section only considers security of the network and thus excluding risks derived from smart contract bugs, bridging, and flashloans attacks. Chains with Proof-of-Work (PoW) or Proof-of-Stake (PoS) consensus mechanism are as secure as the cost of controlling 51% of the compute-power or staked tokens. Chains with Practical Byzantine Fault Tolerance (pBFT)-based consensus are as secure as the cost of controlling 2/3 of byzantine participants. While many argue that few app-chain would have total staked token value comparable to that of general-purpose chains, interchain security changes this.

Applications on general-purpose chains can leverage the security guarantees of the underlying chain and forgo all the work around bootstrapping validator sets and designing sustainable tokenomics that keeps validators incentivized.

Rollups, no matter general-purpose or app-specific, if satisfy the following requirements, are as secure as the underlying chain. For zk rollup, if it posts transaction-call-data and validity proof to the underlying L1 such that the L1 can verify the validity proof, it’s fair to say that the rollup inherits the security guarantee of the underlying L1. Similarly, for optimistic rollup, if it posts transaction-call-data to the underlying chain and has at least one honest watcher to run fraud proofs, the rollup is as secure as the underlying L1.

For app-chains built with cosmos-SDK, security guarantee comes with different flavors. Cosmos Hub, secured by 175 validators that stake ATOM, can be used towards securing or partially securing any chain in the Cosmos ecosystem. With interchain security, chains can be secured by a combination of validators from Cosmos Hub, chain-native validators, and validators from other chains. Depending on the composition of validators securing the chain, the chain can leverage Cosmos Hub to achieve high level of security without a large chain-native validator set. The chain is as secure as the cost of controlling 2/3 of byzantine participants.

Cosmos Hub currently doesn’t support permissionless deployment. Application developers need to submit governance proposals to Cosmos Hub in order to secure their chain with Cosmos Hub. Nonetheless, Cosmos Hub significantly lowers the barrier of entry of building an app-chain since application developers don’t need to bootstrap large validator sets to ensure security.

Conclusion

Applications have different features and priorities, and these eight metrics should be weighted case by case. Here’s a breakdown of how metrics are related to application features.

It’s worth noting that this is a very broad topic, and it’s impossible to cover all details related to these eight perspectives in depth without having this piece of writing being 300 pages long. Plus, there are perspectives beyond the eight listed here. Moreover, while general-purpose chains come in slightly different flavors, you probably find analysis in the article mostly focusing on Ethereum and its related development. Ethereum is a great lens for evaluating general-purpose chains though I acknowledge that its finality, scaling solutions, fee models, and other features can be very different from other general-purpose chains.

There is no strictly better option between app-specific and general-purpose, and there exists a lot more nuances than what this paper has covered. In general, the app-specific route brings heterogeneity and sovereignty to applications — allowing them to enhance security, user experience, and value accrual mechanisms based on specific needs. The general-purpose route excels at aggregating liquidity, synchronous composability, and interoperability. It’s also the easiest way for developers to build applications without the overhead of DevOps and bootstrapping validator sets although the app-specific route has continuing efforts to lower its barrier of entry for developers. While general-purpose infrastructures provide atomicity and interoperability within their ecosystems, app-specific route excels at interoperability within the Cosmos app-chain ecosystem but requires bridging infrastructures that’s under development and improvements for cross-ecosystem interoperability.

If you are building applications or have any thought on the topic, let’s chat! My twitter is @nicopei_eth. DM is open.

Reference

Special thanks to Lydia Hylton, Chris Hofmann, Richard Adjei, Felix Madutsa, Barry Plunkett, and Parker Jou for conversations, comments, and feedbacks on earlier versions of this post.

https://gateway.pinata.cloud/ipfs/QmWXkzM74FCiERdZ1WrU33cqdStUK9dz1A8oEvYcnBAHeo

https://github.com/wormhole-foundation/wormhole/blob/dev.v2/wormchain/design/roadmap.md#why-cosmos