Clusters: a set of chains that communicate with one another using trust minimized cross-chain communication (Ex: Ethereum rollups)
- Trust Minimized cross-chain communication: how chains within a cluster communicate
- Ex: Layer-2s on Ethereum
Trusted cross-chain Communication: how chains in separate clusters communicate
- Ex: Ethereum communicating or bridging to Avalanche
Inter Blockchain Communication (IBC): a generalized messaging protocol that allows for any Cosmos Zone to be interoperable with each other. Made up of many parts:
- Base layer- Tendermint BFT consensus chains
Transport layer
- permissionless relayers from source to destination chain
- Authentication layer
- light client verification
- Interface layer
- IBC Data packets
- Atomicity: for swapping tokens from different blockchains to be atomic, two sides of the trade must fulfill the predefined conditions before the trade is finalized or none at all.
- Ex: Alex wants to move 1 ETH from chain A to be chain B, which involves 2 transactions: subtract chain A for 1 ETH and increase chain B for 1 ETH. For it to be atomic, either both of these transactions must happen or none at all.
Full Node: they download and validate every transaction on the blockchain. Full nodes offer a lot of security guarantees because they can't be tricked into accepting blocks containing invalid transactions.
Light nodes: they only download block headers, not the whole block. They verify data using the state root in block headers. The key distinction from full nodes is that light nodes do not download or validate any of the transactions.
What does cross-chain messaging mean?
Today, you will often hear the term ‘cross-chain messaging’ but mainly what it is referring to are ways for one blockchain to communicate with another blockchain. There are many ecosystems today with Ethereum and its layer-2 roadmap, layer-0 protocols such as Cosmos/Polkadot/Avalanche, and other layer-1s such as Solana. There are many reasons why a single blockchain cannot infinitely scale, so a multichain world will exist and they will all need to have some way to communicate.
Of course, there are many implementations of how to do this communication - all of which have varying security, composability and scalability tradeoffs. As Celestia elegantly put it, many of these ecosystems form clusters - a set of chains that communicate with one another using trust minimized cross-chain communication. An example of this can be seen with Ethereum and the layer-2 space - they can do state verification using trust minimized tactics such as fraud proofs, validity proofs or directly verifying transactions. Given the Ethereum rollup space is a cluster, other clusters can include Cosmos, Polkadot or even Solana. This brings us to the multibillion-dollar question - how will these separate clusters communicate? The answer lies in some form of trusted cross-chain communication.
Hence, we can breakdown cross-chain communication into two categories:
- Trust Minimized cross-chain communication
- Intra-cluster communication: how chains within a cluster communicate
- Trusted cross-chain communication (what we will be covering in this report)
- Inter-cluster communication: how chains in separate clusters communicate

To understand the need for trusted cross-chain messaging protocols and the ability to connect clusters, let's revisit trust minimized communication and rollups.
Trust Minimized cross-chain communication
Rollups on Ethereum do not need to trust an honest majority assumption to ensure state verification. Through fraud proofs or validity proofs, rollups are able to ensure the atomicity of deposits/withdrawals because Ethereum checks the transaction validity of the rollups. Hence, this type of communication for Optimistic rollups relies on an honest minority assumption for liveness - only 1 relayer/aggregator needs to post the rollup blocks onto the parent chain. Whereas validity proofs ensure that the new state can be immediately relied upon and used, given the blockchain will always reflect the correct L2 state.
Trusted Cross-chain Communication
Outside of trust minimized communication within a specific cluster, clusters will still need to communicate with each other. For instance, the Ethereum rollup space will need some way to communicate with Solana, Cosmos or Avalanche. Today, there is a huge demand for this cross-chain interoperability and it is often facilitated through trusted validator/multisig setups. However, many of these bridge setups are highly centralized and insecure compared to trust-minimized bridging for rollups. As seen with Ronin, many of the bridges are sitting honeypots for malicious actors. Validator bridges aren't necessarily bad, they just require a high level of OpSec to work properly and it requires lots of coordination efforts between many parties to ensure security.
Below, we can see a top-down overview of bridging volume from Ethereum mainnet using the bridge builder dashboard. With $166b in total volume and over 12,800 depositors using these bridges in the last week, inter-cluster communication will only become more important as the multichain world plays out.

Generalized Messaging Protocols
Many projects have built out generic messaging protocols that address inter-cluster communication (trusted cross-chain communication). These very generic protocols are very simple at the base level but allow for many higher-level implementations to compose on top of it. Some of these applications built atop of these protocols can be bridges, cross-chain yield farming, NFT lending, and much more. Currently, most of these cross-chain messaging protocols are best known for their cross-chain bridging apps.
Although the market demands them, the addressable market of these generalized messaging protocols is much larger as they can enable NFT transfers, better cryptography, and much more. Hence, we can look no further than the extremely high valuations of LayerZero, Axelar, and Wormhole to get a sense of how large this market is.
Each messaging protocol makes certain tradeoffs, whether that be the security of the bridge itself, the relayer model, or the overall level of decentralization. Trusted cross-chain communication is still very early and many of the mentioned protocols are working on decentralizing their design and making for an easier UX to move across chains. Note that these are not specific bridge implementations but generic cross-chain messaging layers for apps to build on top of.
As it stands today, these are some of the implementations working on things beyond bridging (note there are others not covered like Composable Finance, Nomad, etc.):
IBC
Light client implementation on source/destination chain
Relayers are trustless, they only send the opaque packets of data
Axelar
Axelar has 43 validators at the time of writing (Proof of Stake)
Highly centralized token distribution and validator stake
Wormhole
Wormhole has 19 guardians (Proof of Authority)
Highly centralized and closed-off governance
LayerZero
Trusted relayer/oracle model
Some unaudited/unverified contracts
Again, these are some of the features that demonstrate the level of trustlessness each protocol at the time of writing. However, with new updates, the level of decentralization can certainly change as certain points of centralization are addressed.
Cross-chain Stack
To better understand the cross-chain space, one needs to assess the actual interoperability stack and the 4 different layers that make it up. This report will use the Inter Blockchain Communication (IBC) protocol as an example to illustrate each layer of the stack. This will lay out the foundation of cross-chain communication and later show us the different design approaches and the tradeoffs between the discussed projects.
To recap, IBC has light clients at the bottom level of the stack. If chain A and chain B want to communicate with each other, they run light clients of each other’s chain to evaluate each other's state. On top of these clients are connections, which use the security of the clients to actually link the two chains. These connections are generalized, meaning that any single chain can have thousands of connections with any other IBC-enabled chains. On top of these connections, exist channels. Channels are application-specific ways for chains to be interoperable. IBC has multiple applications that serve different purposes, all of which require their own channel:
- ICS20
- basic token transfers
- Interchain Accounts
- a chain can control accounts on another chain (composability)
- CosmWasm
- Cross contract communication
Each of these applications cannot operate over the same channel so they will have their own designated channels. Theoretically, there can be an infinite number of channels that live on top of a single connection between 2 chains. However, this requires specific relayer infrastructure in place and increases in complexity the more chains a Zone is connected to. There are some initiatives to resolve this, including this proposal to have the Cosmos Hub act as a middleware relayer service (relay as a service). This highlights the complexity of relayer infrastructure for many applications or chains that want to be interconnected with everyone. Given tokens sent over IBC are path-dependent, it is likely to assume a hub and spoke model.
IBC Limitations
Now that the report has broken down IBC into each separate layer, why can't IBC be the protocol to serve as the trusted cross-chain communication method for all chains? The limitation boils down to the transport and authentication layer described above, which involves using fully on-chain light clients for the communicating chains - this implementation makes it extremely expensive to run a light client on Ethereum and other EVM compatible chains. This limits the total addressable market for how many chains can adopt the IBC messaging standard to just Tendermint chains (for now). There are other direct implementations of IBC, where people are working on writing light clients for other consensus protocols such as Polkadot and NEAR but a reality where IBC connects every chain is still far away at this point in time.
Another limitation is that IBC only works for deterministic finality chains (i.e. only PoS chains) so it automatically excludes probabilistic finality chains such as Bitcoin. Finally, IBC does not scale so easily in a world with 1000s of app chains. For example, if there were 1000 chains, then it would mean 1000* (1000-1) = 999,000 individual relay channels. Thus, it seems likely there will be a cross-chain hub to route transactions across all chains. Whether it be the Cosmos Hub, or any of the solutions mentioned below is beyond the scope of this, but it is to highlight there will be a large demand for cross-chain hubs to bring together a multichain world. Now that IBC has been defined and its current reach, where does that leave the other generalized cross-chain messaging protocols?
Again, the focus of the report is on generalistic cross-chain messaging protocols, not just cross-chain bridges. Rather, these protocols are generic standards that can have multiple applications to live on top of them - of course, this encompasses bridges but the scope of these protocols is much larger.
For this reason, we have excluded THORChain and other cross-chain bridges that are focused strictly on bridging. Although they will support synths and other DeFi primitives on top of them, they address a different market than generic cross-chain messaging protocols. A clear distinction between THORChain and things like LayerZero or IBC is that it is more trustless as it does not need an oracle or relayer given that it requires a full node for each connected chain. Thus, it is also more computationally expensive and it is also not addressing the broader market as the mentioned cross-chain protocols which make different tradeoffs.

Above, you can see the key structural differences between the covered cross-chain protocols and generic bridges such as THORChain (middle image) and LayerZero (right image). These tradeoffs are abstracted away at the user interface, where users will either prioritize security or faster finality. This boils down to the multi-billion dollar question, will the best UX win with non-ideal tradeoffs or will the market ultimately value security? Below, we will go over a high-level overview of each protocol broken down by design, UX and security as they stand today. Then, we will go over each protocol more in-depth.
Wormhole
Wormhole is a generic messaging layer that uses a Proof of Authority multisig network to connect 9+ chains today. The backbone of the entire Wormhole ecosystem comes down to the core layer, which is made up of the core contracts on each chain and the Guardian network. Any messages that come through the core contracts must be observed and signed by the Guardian network.
The PoA network has 19 Guardians today, which can be thought of as validators in the PoA system. Guardians simply attest transactions on Wormhole and 2/3rds of them must produce an attestation in order to reach consensus. Once consensus is reached, the attestation will be sent to the specific blockchain to execute the transaction or the specific contract. These guardians will observe every blockchain that Wormhole integrates. The core contracts on each chain will observe the Guardian signatures as the authentication of a given message.
2/3rd of guardians must observe and sign a message for a message to be considered valid. Honest majority assumption - the messages are only as secure as the Guardians signing/approving a message.
The set of Guardians are very well-known validators in the space, which provides good liveness guarantees. However, ⅓ of the Guardians would have to collude in order to censor transactions moving through Wormhole. Again, these Guardians are well known so there is also a centralization and censorship risk for users. Also, most of the development and funding is bootstrapped by Jump Capital, which is a US-based company.
Currently, Wormhole gives you attestations when you bridge to redeem on the target chain. This is a bit clunky but the team has mostly built out a relayer network (pending audits) to streamline this process. The relayers would be subsidized by fees paid by the users bridging and would further automate the relaying and redemptions in the background.
They have no direct plans for monetization of the protocol itself but they have raised multiple rounds so far.

Concerns
Wormhole faces smart contract risk like any other protocol. They were notably exploited for 120k ETH but have since refunded the bridge from Jump Capital. They are currently undergoing a few audits and have a $10m bug bounty on Immunefi to mitigate risks.
Additionally, the Guardian set is highly centralized and it has a very closed-off governance structure. Additionally, they have upgradable contracts and they have not stated any plans for decentralizing governance or the Guardian set.
Traction
- $4b TVL
- $22.8b of outbound volume
- 726k transactions
Wormhole is already the de-facto bridge for Solana. Most wrapped tokens on Solana are Wormhole canonical assets such as Wormhole ETH which is just listed as ETH.
Features
- Portal token bridge
- NFT transfers
Future Integrations
Contract Controlled Transfers: cross-chain contract calls
Fungibility and Wormhole’s dominant canonical token representations have network effects (better exit liquidity on existing chains)
- All tokens are fungible with one another - no need for multihop trades (incur those fees)
- Ex: 1 click swaps for any token to another token on another chain (feels like a CEX)
- CosmWasm bridge for NFTs (finalizing audits)
- Module for minting Cosmos native tokens with CW-20 tokens
- ICS integration on top of Wormhole (Cosmos interchain standards for IBC)
- Integration with Osmosis for bridging over Solana assets
- Borrow/lending
- Pyth oracle data
- Cross-chain ICO infrastructure
Other integrations include building out a Cosmos chain for accounting and governance (not for bridging).
Team
Wormhole is backed by Jump, who is one of the top VCs, builders and market makers in the traditional finance and crypto space. They acquired Chorus One, who was a very early contributor to the entire Cosmos ecosystem and are extremely qualified builders in the space - particularly with infrastructure such as Wormhole which has been in production for over a year now.
Axelar
Axelar is a transport layer that allows for cross-chain composability between any chains. It is built on the Cosmos SDK so it has a set of validators that maintain the network and execute transactions. Axelar’s core infrastructure has 2 layers:
The Network
Consists of Cosmos validators (43 validators but 20 control 100% of the voting power at the time of writing)
The validators read/write the operations to gateway accounts deployed on each connected chain. They vote and attest those transactions on the target chains
Gateways
- Smart contracts deployed on each connected chain
Gateways and the Axelar network communicate via relayers who monitor the gateway contracts and relay the transactions over to the Axelar network. Relayers are not trusted for the safety of the network, in fact, 1 relayer can maintain the liveness of the protocol.
Application Layer
Given the Axelar Network and the gateways make up the core infrastructure layer, where does that leave the application layer? The Axelar developer tools sit on top of the validators and gateways and exist as a set of APIs that allow developers to access the tools and infrastructure needed to go cross-chain. The APIs allow developers to lock/unlock, transfer assets, execute contract calls, and handle any request between any 2 chains.
To see a visualization of the technology stack, check out the image below. We see the user-facing applications down to the read/write logic of the Axelar validators.
Core infrastructure
- Axelar Network
- Gateway Contracts
Application layer
- Axelar dev tools (SDK/APIs)

Axelar is built on the Cosmos SDK and secured via Tendermint BFT consensus. Thus it shares similar liveness and security guarantees as any other Cosmos chain (67% corruption threshold). However, the validator set is relatively centralized with 20 validators controlling 100% of the stake. Thus, it faces censorship risk given all of the validators are well-known entities.
Another key consideration is the token distribution of AXL - the AXL token governs the chain. It is highly centralized with investors owning nearly 30% of the total supply and the company owning 30% of the token supply. It is currently a majority VC-backed chain with linearly vesting over the first 2 years.

To visualize the workflow for the user interacting with Axelar, reference the image below.

Concerns
They currently have contract upgradeability and a corporate relayer - this means unaudited code can be pushed by the team and they are dependent on subsidized relaying at the time of writing. For these upgradeable contracts, some of them have admin functionality which poses a systematic risk for every connected chain. For example, if an Axelar developer gets his/her Metamask hacked, then it could jeopardize the protocol's canonical funds. Further, all of the tokens on Axelar are held by certain admins, although we do not know who they are. According to the founder, this will be changed shortly such that the validator set needs to co-sign on any upgrade of the contracts. For a more direct and informal view on this, check out the discussion here where it poses the assumption of North Korea attempting to hack your bridge.
For users to bridge funds, they incur 2 different fees:
- Contract creation
- Contract destruction
Given the expensive nature of Ethereum gas prices, these fees can add up. For example, check the transactions here. This brings us to our next issue - Axelar only charges a $20.50 standard fee today, so who incurs the extra gas costs? There is no clear answer as this might be incurred by the VCs which seems unsustainable in the long run. They can further optimize their contracts but this is an issue with their fee structure as it stands today. However, the expensive fees are only applicable to the Ethereum mainnet, contracts on other chains are much cheaper.
Traction
- $4b TVL
- $22.8b of outbound volume
- 200k transactions
- Facilitated nearly 20,000 IBC transfers and over $115 million in IBC volume
They just became the default canonical bridge for Osmosis Zone, the most dominant DEX on Cosmos. This puts Axelar in a good position to take advantage of the IBC ecosystem given the immense amount of liquidity found in Osmosis. Additionally, they have integrated most EVM chains, Osmosis and the flows can be visualized here. Finally, they can connect to any other Cosmos chain over IBC such as Juno, Secret Network and the rest mentioned here.
Features and future Integrations
- 11 chains connected
- IBC enabled by default
- Shared security via the Cosmos Hub or other chains (in addition to their validator set)
18 different teams are working on Axelar to deploy their applications. Some of the applications include the following:
- Cross-chain lending using NFTs as collateral.
- Cross-chain dex aggregators
- Cross-chain NFT marketplaces
- Bridge aggregators
- Multichain wallets with DeFi features
- Multichain privacy services
- Multichain decentralized guilds for play-to-earn
- Cross-chain fan communities for artists
- Cross-chain escrow services
- Cross-chain NFT collections
- Natively cross-chain stablecoins
For instance, someone can build a platform that hosts NFTs on multiple chains. This would allow users to buy an NFT minted on another chain without having to move assets across separate chains. Hence, generalized cross-chain messaging systems will allow for super-apps connecting the multichain world. Again, the market for this is enormous as this abstracts away all of the complexity known to crypto today from a single application.
Team
They have 27 builders on the team coming from a very diverse backgrounds in cryptography and distributed systems. Many are renowned researchers and early contributors to other layer-1 chains such as Algorand. They also have significant backing and support from the Osmosis team to natively integrate the Satellite bridge into their front end.
LayerZero

To better understand what LayerZero is, let's take a look at what a communication flow for a cross-chain transaction would look like in practice.
LayerZero is able to bring cross-chain communication by building atop of a primitive they call ‘valid delivery’. This communication enables cross-chain token transfers or any arbitrary data by providing 2 guarantees (as shown in the above flow). The series of steps shown in the diagram above will be referenced throughout the rest of this section. The 2 guarantees of valid delivery include the following:
- Every message sent over the network is coupled with a transaction on the sender chain.
- A message is delivered to the receiver if and only if the associated transaction is valid and has been committed on the sender-side chain.
Note, the only requirement to ensure ‘valid delivery’ is that every message sent using the LayerZero protocol, requires the Oracle and Relayer to be independent of each other.
LayerZero Components
We explained what LayerZero enables and defined the primitive of ‘valid delivery’ but let's dive into the components of LayerZero. It is made up of multiple components - Endpoints, an Oracle and a Relayer. We will cover each core component below starting with Endpoints.
Endpoints
Going back to Figure 4 above, one can see that the LayerZero Endpoints are the user-facing interface (Steps 1 and 13). They are made up of four modules: Communicator, Validator, Network and Libraries (not shown). The Endpoint’s core functionality revolves around the Communicator, Validator and Network, while each new chain is added as an additional Library. This ensures a modular design that enables LayerZero to add new chains without modifying the Endpoint’s core modules.
Endpoints are currently implemented as a series of smart contracts on each chain that is included in the network. The workflow is as follows for a cross-chain transaction:
Sender: Messages are sent down the stack on the sender side; Communicator -> Validator -> Network (Steps 2-3)
Receiver: Then the messages are sent up the stack on the recipient side; Network -> Validator -> Communicator (Steps 9 and 12)
As mentioned before, each new chain can be added by extending Libraries. These Libraries are auxiliary smart contracts that define the communication standards for a given chain. Each chain in the network has its own Library and each Endpoint keeps a copy of every library. Hence, for any two chains to communicate, they only need their respective libraries on both ends.
Given that Endpoints exist as smart contracts running on multiple layer 1 chains, how does it ensure scalability without incurring prohibitive costs? For example, running a light client for Ethereum would incur millions in fees. The answer can be found in the design of their light client, which is designed to be ultra-light and called the Ultra Light Node (ULN). It does this by delegating the tasks of fetching the necessary cross-chain headers and transaction proofs to off-chain entities- the Relayer and the Oracle. It streams block headers on-demand from the Oracle, which is an implicit way to reach the desired full header sync state through a more efficient off-chain entity (Step 8). The submitted header will be cross verified with the transaction proof submitted by the Relayer (Step 11). In short, it enables the security of a light node with the cost effectiveness of middle chains.
Oracle
The oracle is used to read a block header from one chain (Step 6)and send it to another chain (Step 8). This can be any 3rd party service but they intend to use Chainlink amongst other oracles. Currently, they do not use Chainlink today but have plans to in the future.
Relayer
An off-chain service that functions similar to the Oracle. Rather than fetching block headers, it fetches the proof for a specified transaction (Step 7). Relayers are permissionless in their model.
Security
Again, ‘valid delivery’ is ensured by making the Oracle and Relayer independent by design. This allows for LayerZero to remain lightweight in design and ensure the security of the protocol. In order for an attack to take place, it would require both the oracle network and the relayer to be compromised or colluded.
However, what if the Relayer and the Oracle network are the same entity and they are colluding together by agreeing on everything? The worst case security of this configuration is the equivalent to the best case security of the chosen oracle. For example, if Chainlink is used as the oracle, the worst case is the oracle and the relayer are the exact same entity. This still has the base case security as being as secure as the Chainlink DON, which has its own trust assumptions. Building an entire cross-chain infrastructure based on Chainlink's oracles which are relatively centralized through a 3-of-20 multisig as pointed out here can be vulnerable to attacks that Axelar and Wormhole do not face as they either run full nodes of each connected chain or light clients. The 20 keys do not necessarily mean that there are 20 unique individuals, which means that if 3 of these keys are acting malicious, they can cause a black swan liquidation event. Thus, the multisig could potentially switch the aggregator to another that might have incorrect data and push through incorrect prices throughout all applications using it.
Of course, this can lead to mass liquidations across the board. Given most DeFi protocols use Chainlink as the de facto oracle, all of them would be susceptible to this trust assumption. Some chains, however, point out this risk such as Compound, which uses a time-weighted average price from Uniswap as a sanity check on asset prices reported by Chainlink. Although most of DeFi builds on such a primitive, is this the most secure way of building out cross-chain infrastructure? Wormhole offers a Proof of Authority assumption that uses guardians as the cross-chain oracles which run full nodes on each of the connected chains. Similarly, Axelar ensures their validator set runs full nodes or light clients on each of their connected chains. Hence, LayerZero puts a lot of its trust on Chainlink, whereas Wormhole and Axelar require their validators/guardians to run full or light nodes of each connected chain
Concerns
Like most other cross-chain protocols, LayerZero’s relayer stack is a pivotal part of the cross-chain functionality. Running relayers is another piece of infrastructure that dApps will be required to maintain in order to access the cross-chain functionality of LayerZero. As seen with IBC, this is hard to incentivize given there are no economic incentives for anyone to run a relayer. Unlike IBC, where they have permissionless pairwise relayers, LayerZero’s relayers have varying trust assumptions alongside their oracles. Similar to IBC, the LayerZero relayers can be anyone as long as they fulfill the implementation requirements - pass a tx proof from the source to the destination chain. LayerZero can of course offer incentives through a potential token to incentivize a more decentralized relayer infrastructure but this has yet to be announced. Given this, it seems likely that many dapps will either use LayerZero’s own trusted relayers or have Chainlink run both the oracle and relayer functions. To recap, relayers can be anything - a series of nodes, a project’s multi-sig, a distributed system or something else.
Although not mentioned in this report, this may bring up a question on why dapps won't just deploy on Chainlink’s cross-chain implementation, CCIP, that provides the same functionality and has an extra anti-fraud network (assumption is it is even more secure). Due to limited information, the report will leave this out until further releases from Chainlink. However, there is a network effect and first mover advantages given the lindy effect for the canonical assets embedded into an ecosystem.
Further, most of the contracts are verified for LayerZero. However, some are not. In contrast, IBC leaves trust assumptions up to the validator set security whereas LayerZero leaves trust to the relayer and oracle of each dApp. For a Dapp on LayerZero, each will have varying security assumptions as described by the founder in the Discord:

If an app chooses to use their own oracle (not Chainlink) and it colludes with the relayer, then the risk is compartmentalized to the specific application, not the LayerZero protocol. One can think of this design as effectively reducing the blast radius of risk to the specific dApps. This phenomenon can also be seen with IBC. If a chain decides to be interoperable with another chain, then it is susceptible to the security of that chain. Although differing on the security assumptions, it shows how the blast radius is effectively minimized. Unlike this design, if a centralized bridge like the Avalanche Bridge is hacked, every wrapped asset on Avalanche is effectively backed by nothing - compartmentalized risk vs systematic risk.
Current Features and Future Integrations
- Cross-chain bridging
- Omnichain NFTs
- Perpetual platforms
- New applications launching on top of LayerZero
- Using Chainlink as the default oracle (as seen on testnet)
- Integrate ICS standards (IBC standards)
- Integrate non-EVM chains such as Terra, Solana and other Tendermint chains
- Verify more of their contracts
- 3rd party audits
Team
Very diverse team of engineers coming from top web 2 and web 3 companies who are backed by the biggest VCs today. They come from a diverse background as ex-founders of AI companies, poker, blockchain startups and much more.
Key Takeaways
- The cross-chain design space is still very early and the report laid out the top protocols tackling the trusted cross-chain communication space (no mention of CCIP given limited information)
First mover advantage is powerful - fungibility and canonical token representations have lindy. Once a bridge’s wrapped tokens are embedded in an ecosystem (See Wormhole assets on Solana) it is hard to move away from them
- However, token representation isn't the only factor in who wins the bridging wars. Cross-chain calls are an interesting design space that can tap into significant network effects. This can be seen with the Interchain Accounts module on IBC which allows for composability of the EVM across sovereign blockchains.
- A failed example of first mover advantage can point to something like Ren who was first to connect to all chains but has seen poor adoption
- Many of these protocols mentioned are in their infancy phases and the cross-chain bridging wars will only become more apparent as the multichain thesis plays out
- Whichever trusted cross-chain protocol wins this battle, will serve one of the largest markets in crypto. Hence, this narrative will only strengthen as we move forward into a modular world full of 100s to 1,000s of blockchains.