The Bridges Are Dead, Long Live The Bridges!

The multi-chain thesis has been alive for years now. We saw a first application-driven manifestation of it in 2021 (albeit not a perfect one), and a suite of bridging solutions followed in order to facilitate the rotatooors, arbitragooors, sybilooors, and all the other colorful characters. There have been pragmatic decisions made to facilitate the gold rush.

Interoperability is a spectrum, and can be interpreted in different ways depending on the architecture of it, as well as the use case. For that reason, multi-chain, cross-chain, interchain, omnichain and other buzzwords have been thrown around indiscriminately. Most participants in the dialogue can no longer discern these concepts from one another. We aren’t sure if we do in all cases.

We saw more than one bridging trilemma outlined and then being solved (guess it is no longer a trilemma). We see that users care about different aspects of bridging (or don’t care at all), developers are weighing the trade-offs for applications and, of course, there is no consensus on what the best design is.

Being the casual observers of the space and investors with a decade-long view, we want to make a case for Generalized Messaging Protocols and look at their architecture, as well as discuss how the applications leveraging these protocols could look like.

Quick Recap On Bridges Falling Apart

Source: Armed Forces of Ukraine

It should be noted that bridges are not the native interoperability solution of blockchains. Instead, they’re trying to fill the gap between two blockchain states, and cater to the user demand for cheap and affordable blockspace. Admittedly, this comes with its own set of trade-offs for users, as ecosystem incentives offered across different blockchains can be quickly eaten into by bridging fees, slippage and gas.

The problem list with bridges is lengthy and has been discussed in a myriad of mediums. The vast majority of bridges today are either trusted or trust-minimized. We want to emphasize several most obvious risk categories, although a more technically-nuanced mind could put together a three piece Medium post dedicated to this topic alone:

• Proof-of-authority bridges stand solely on trust. When bridge validators don’t have staked collateral, a bridge becomes a custodial system (worse than CEX because there is no claim on assets to be made in the event of an exploit);
• Consensus exploits/failures at the bridge level. This could lead to loss of funds held by the bridge, and anyone holding wrapped assets collateralized by the bridge;
• Chains connected by a bridge do not have a shared state – instead, it is fractured. Wrapped assets on chain B might run into trouble if chain A is under 51% attack and transactions are reverted. In this case, chain B assets are no longer fully collateralized. System is only as strong as its weakest link;
• Wrapped assets are inferior forms of collateral in DeFi and could present systemic risk. Most bridges wrap tokens into synthetic assets that are effectively an IOU on assets parked at the bridge: - If wrapped assets are widely used as collateral in DeFi but depeg for whatever reason – this could result in a wave of liquidations; - Every wrapped form of a single asset competes for liquidity which ultimately results in fragmentation and worse execution prices for users; - Some wrapped assets require an external oracle for pricing, which is another vector of risk.
• Trust-minimized bridges have at least one centralizing agent. While these bridges aim to become fully decentralized progressively, trust-minimization implies that there is at least one centralizing agent in the system – e.g. oracle, watcher, relayer – that could pose risk to the system if it fails to function properly;
• Smart contract risk. As seen with the recent attack on Wormhole, consensus is not the sole attack vector. Smart contracts can be exploited to produce forged signatures that validators accept, resulting in minting of wrapped tokens without providing the underlying collateral. And that doesn’t even account for all the other smart contract exploit vectors we’re unaware of.

This Is What We Believe In

Let’s start by stating the obvious: there are too many bridges. Most of them have been built to accommodate the immediate needs of DeFi users as layer-1 szn unfolded. Most of the externally-verified bridges do not differ meaningfully from one another, and definitely do not offer a superior value proposition to users when compared to the next closest competitor. On a long enough timeline, the survival rate for every bridge drops to zero, but some bridges have been built to be more resilient than the others.

Second, we think Generalized Messaging Protocols are a more fundamental piece of infrastructure compared to token bridges. Serving use cases such as cross-chain identity, governance, DeFi will go a long way, and become the defendable moat of these protocols. We think bridges are in the business of network effects, and Generalized Messaging Protocols are in the best spot to capture them. Expect a convergence towards 2-3 dominant protocols that are permissionless and have the best balance of trade-offs (outlined in the next section below), while a wider disparity of applications will be built on top of them (e.g. token bridges).

Effective Altruism – Shilling The Bags Of Others

Not enough people are able to discern generalized messaging from token bridges. We view the former as the underlying communication channel that can support transfer of data and smart contract calls. On top of this infrastructure, applications, including token bridges, can then be built. This type of framing should address some of the noisy debates within the bridge narrative.

Communication between blockchains that speak in different languages and formats without an intermediary is impossible. Some of these messaging formats today are built to support homogeneous communication (IBC in Cosmos, XCM in Polkadot), while heterogeneous communication is not well developed yet. There are a plethora of reasons that include development difficulty, security, latency.

To cut it short, Generalized Messaging Protocols are all making trade-offs and betting on the winning set of features. It is then up to the app developers building on top of these protocols to choose the design that is most optimal for their application. We see the main debates around trade-offs as follows:

• Security design. Relying on a third-party consensus (e.g. Wormhole) vs not (e.g. Nomad);
• Sovereign consensus / zones. Having a customizable security design that allows additional layers of security for applications and isolated failures (e.g. Abacus) vs a global security model (e.g. Axelar);
• Cost of messaging. Some design mechanisms, like optimistic fraud proofs (e.g. Nomad) are much cheaper to implement than others, like light clients (IBC);
• Latency. Messaging between two different states introduces latency. It depends on block times as well as verification design. For example, LayerZero’s approach would have a faster finality compared to Nomad due to its optimistic assumptions and the associated 30 minute fraud period. Latency can lead to information leakage, just-in-time attacks as well as other forms of MEV – all of which today are totally left out of any discussion on interoperability.

There is also an open question around the token value capture of these protocols. While a proof-of-stake model is fairly intuitive and familiar, if there are application-native tokens being staked for sovereign security purposes in addition to the protocol’s own token, the value could leak from protocol token to the application token. That being said, proof-of-stake mechanisms will accrue value, as there will be demand for throughput and consensus.

Protocols that will not have a proof-of-stake model are probably yet to decide on their token value capture as it is less intuitive. In general, we think messaging protocols / bridges don’t have a well defined business model yet despite multi-billion dollar valuations attached to them. As an example, Cosmos IBC, which can be likened to TCP/IP, has a perfect product-market-fit but doesn’t require a dedicated token (instead, the execution burden is on the validators of chains connecting via IBC).

Lastly, messaging protocols are only as useful as the existing demand for multi-chain blockspace and cross-chain communication. Their direction depends on both the fate of alternative layer-1s and the layer-2s building on top of Ethereum.

Heterogeneous Interoperability Solutions

Axelar

_Axelar has an external-validation design. At its core, there is a proof-of-stake blockchain with a validator set running full nodes or light clients of the connected chains. _

Axelar supports generalized messaging across multiple EVM environments, as well as Cosmos-based chains. Validators observe the connected chains, report and reach consensus on their state, and then produce and route messages across them. Each validator is not required to run a node for every supported chain, thereby allowing a greater number of chains to be supported.

Each chain that Axelar connects has a Gateway contract deployed. This contract is used to receive and send messages between Axelar and the external blockchain. Axelar validators jointly hold a key that controls this contract (proportional to AXL token staked), and messages/transactions get passed only if validators’ vote to do so reaches a required threshold.

Source: Axelar documentation

The way application developers can connect to Axelar’s network is through a set of APIs that allow it to make requests to the network and call functions to different connected chains through the Gateway contract. The relayer level is permissionless – application developers can build their own version of relayer services, instead of using Axelar’s default relayer.

Overall, this architecture eases developer experience (there is no need to build proprietary bridging solutions), however, application security is effectively outsourced to Axelar’s consensus (a single point of failure). Also, as all activity passes through Axelar’s chain, it has to become scalable enough to continuously meet the demand, or else it will turn into a throughput bottleneck.

An interesting use case possible with design like Axelar’s could be atomic transactions on two chains. This is because Axelar consensus could be used to sequence the events and set conditions for executing the transactions. In practice, this might be complicated because two asynchronous environments are constantly changing their state, and the atomic swap guarantee at Axelar’s consensus level could fail.

Abacus

Abacus has an external-validation design. Validators stake ABC tokens on each chain where they sign messages, and can be slashed trustlessly if they misbehave.

Abacus Network allows messaging across EVM blockchains while ensuring that state and validators’ stake sits in the same location – thereby allowing trustless slashing and attaching economic cost to fraud. The network has inbox and outbox on each chain that’s connected, where applications send and receive data. Validators sign the messages in the outbox, while Processors observe and process messages hitting the inbox.

Censorship-resistance properties are strengthened, as validators cannot selectively pick and choose the messages they want to sign. Instead, the validator is signing a checkpoint, which is a merkle root, that contains all messages from all applications of a connected chain. Most of other messaging protocols sign individual messages which are easier to censor.

Source: Abacus documentation

The Abacus model allows app developers to attach conditions to their inbox under which incoming data is accepted – effectively putting another security layer called sovereign consensus. This gives developers security guarantees that are native to their application, but not to others using Abacus. Application’s native token could be used by application-specific validation, and thus create additional utility for the governance tokens.

While protocol itself is primarily a tool for developers (maintaining a single application code across multiple chains, designing sovereign consensus), it also yields benefit for end-users via improved security. Following launch, teams building on top of Abacus will have use cases that allow cross-chain lending, position management from a single source of truth or moving computation to a cheaper layer while settling back to the desired chain.

Nomad

Nomad has an optimistic approach to bridging via fraud proofs. Optimistic design assumes a sent message to be valid, unless someone proves otherwise. Updaters sign messages on the origin chain, and then are subjected to a 30 minute fraud period as well as possible bond slashing.

The optimistic communication design of Nomad is a trust-minimized approach. It allows applications on EVM chains to send messages by using the Updater who signs them. The fraud by Updater is allowed, but it is costly (Updater’s bond can be slashed), it is public (Watchers can compare the delivered message against the intended message in the merkle tree), and can be rejected (before the end of the 30 minutes fraud period that applies to all messages).

A smart contract on the origin chain (Home) gathers and manages the message tree, and holds the Updater’s bond, whereas the contract on the destination chain manages replica of the message and dispatches received messages to end-recipients.

Source: Nomad documentation

The optimistic design removes validators from the architecture (system becomes more trustless), while also minimizing the cost structure compared to light-client bridges (which are secure but very expensive). This achieves a balance between cost and security – instead of observing the whole chain, Agents in Nomad’s design only work with very specific bits of the chain – merkle trees containing the messages.

The Watcher list today is permissioned (ran by the team) in order to avoid a protocol halt, where Watchers could spam it by submitting false challenges at no economic cost, and prevent all the transactions from coming through. To make the Watcher set permissionless and decentralize it, a Watcher fee could be introduced that would make it economically irrational to submit false challenges.

Perhaps the most significant trade-off made by Nomad is the 30 minute optimistic fraud period, which applies to and prolongs execution of all messages. That being said, as protocol matures and strengthens the incentive mechanisms for Watchers, the fraud period could be shortened; else, specific applications using Nomad could choose the fraud period that’s most suitable to them (low value exchange could be done using a shorter fraud period).

Nomad is already exploring several interesting use cases:

• Cross-chain governance for Uniswap: establishing governance process on a single chain, and implementing it across multiple chains via a standardized smart contract solution;
• Asset bridging in partnership with Connext: cutting short the 30 minute fraud period by directly tapping into liquidity pools set up by Connext bridge on different chains. Liquidity providers are taking the optimistic fraud risk, and get compensated via fees paid by users using the bridge;
• Recurring cross-chain payments for Superfluid: paying subscriptions, salaries, rewards.

LayerZero

_ LayerZero is a messaging protocol that connects a set of smart contracts (Endpoints) on different blockchains via relayer and oracle. _

LayerZero allows arbitrary passage of data between the connected chains. While it currently supports EVM chains, other chains – Solana, Cosmos, Polkadot – could be added in the future. The protocol has a set of smart contracts deployed on every connected chain (a so-called Endpoint). It serves the purpose of allowing users to send and receive messages using the network. This is a lighter approach compared to say IBC, because light clients are not required to run, and cost of the network is variable as opposed to fixed.

Endpoints are connected by a relayer and an oracle. After interaction with the Endpoint on the origin chain, a relayer sends transaction proof to the destination chain, while an oracle sends the block header. The Endpoint on the destination chain verifies the received transaction proof in conjunction with the block header to validate the message. Both relayer and oracle are paid per transaction by the user interacting with Endpoint on the origin chain.

Source: LayerZero whitepaper

The key assumption, and a potential risk vector, in this model is that the relayer and oracle will not collude by providing fraudulent proofs and blockheaders to the destination chain.

• LayerZero currently runs the default relayer, although it will be open-sourced so that any application can run its own relayer for enhanced security (assuming it doesn’t want to collude with the oracle against itself);
• Chainlink is the intended go-to oracle, but it is not without its risks, as it effectively introduces a 3rd party consensus for LayerZero. For the time being, oracle function is performed by FTX/Sequoia/Polygon as Chainlink is not ready to support the protocol yet.

We can think of having a custom, i.e. application-specific, relayer as an additional level of security that applications might want to have to isolate themselves from being dependent on Chainlink’s input. However, running a relayer might not make sense for the majority of the teams, and they would simply opt for LayerZero’s default relayer.

An application leveraging LayerZero’s messaging protocol is Stargate – released by LayerZero’s team – which is essentially a cross-chain DEX for native, pairwise assets. On every chain there is a pool of liquidity into which LPs provide tokens, and where Stargate bridge taps into. However, instead of maintaining a single liquidity pool between the two chains, Stargate is able to unify them and allow bi-directional transfers.

Wormhole

Wormhole has an external-validation design, however, validators (guardians) don’t have a bond. Validators run a full node of each connected chain.

Each blockchain connected by Wormhole (6 EVM chains plus Solana, Oasis and Kusama’s Karura) has a Core Contract deployed by Wormhole. By running a node on every chain, Wormhole’s Guardians observe the state and see the incoming messages. Thereafter, a message is verified by reaching a consensus on Wormhole, and relayed to the destination chain’s Core Contract. Messages are wrapped and received in a so called VAA format (verifiable action approval) which simply allows messaging composability across all connected chains.

All 19 Guardians of Wormhole observe every single chain, and consensus requires at least ⅔ of them to verify a message. Guardians are the participants who have vested interest not only in the Solana’s but other ecosystems as well (e.g. validators), and are trusted not to collude against the users using the protocol. Given there is no bond staked by Guardians, it can be seen as a Proof-of-authority system. The relayers who pass along the messages to the destination chains can be permissionless and application-specific. A longer term vision for Wormhole is to combine zero-knowledge proofs and light clients into a so-called system of compressed light client proofs, where consensus on the state of connected chains can be reached trustlessly and at a minimal cost.

There are two extensions on top of the underlying messaging protocol today: the Token Bridge and the NFT Bridge. Both of them custody the assets on the source chain, and issue wrapped assets on the receiving chain.

Wormhole powers several applications, including Pyth oracle, which can use Wormhole to send on-chain price data from Solana to other blockchains. The reverse would not be practical given the differences in block time.

Source: Pyth

Homogeneous Interoperability Solutions

Cross-Chain Message Passing (XCMP)

XCMP is a natively-verified messaging protocol – messages are ultimately signed by the validators who simultaneously secure the chains exchanging messages.

XCMP has been built to facilitate communication between parachains (layer-1 equivalents) on Polkadot. The protocol uses a specific messaging structure called cross-consensus message format (XCM), into which XCMP messages are wrapped. Messages are exchanged between collators – full nodes of both the main chain and their specific parachain that convey the state transition.

After the smart contract on parachain A has been triggered, the collators of that parachain will put messages into the outbound queue (and indicate a destination parachain B). Collators of parachain B are actively scanning for inbound messages, and once they find one, it is put into an inbound queue for processing. This is when a new block can be proposed by a collator on parachain B, and when validators reach consensus that messaging took place (as they’re able to read both inbound and outbound messages on both chains).

Source: Demodyfi

Worth noting that for security purposes, a parachain can indicate which other parachains it wants to communicate with by opening a communication channel, and indicating the conditions under which the inbound messages are processed.

XCMP allows protocols to move beyond passing of data – instead, smart contracts can execute another smart contract on a different chain. This assumes that the chains in question share the same implementation through Polkadot’s Substrate blockchain framework and use the same pallets. XCMP is a walled garden in that sense – it’s functional within the Polkadot ecosystem, but not outside of it.

Inter-Blockchain Communication (IBC) and Interchain Accounts

IBC is a natively-verified messaging protocol – every connected chain runs light clients of the counterparty chains, and doesn’t require an external consensus to verify state.

IBC, just like Polkadot’s XCM, is a format for communication. Blockhains built using Cosmos SDK and Tendermint consensus can use IBC to connect to other chains in the Cosmos ecosystem. Because the IBC is based on light clients, chains can continuously agree on the state of other blockchains by verifying their block headers.

While the light client approach is very expensive to maintain, it is by far the most secure design today (compared to heterogeneous messaging protocols) assuming that you trust the consensus of the two chains communicating via IBC. Besides the light clients, IBC requires (permissionless) relayers that transport the data packets (token transfers, smart contract calls, etc.) across two blockchains in the supported format.

Source: ibcprotocol.org

Interchain Accounts, the recent feature that leverages IBC, allows users to perform actions on the destination chain while being on the origin chain without requiring a manual token transfer. That includes casting governance votes, liquidity transfers, staking etc. – users get to remotely control an account that sits on a different blockchain. Such cross-chain communication requires mutual channel(s) to be set-up by the two chains, which effectively allows governance of both chains to choose which parties they want to exchange messages with.

Every Cosmos SDK/Tendermint chain has to opt-in to this system and accept the overhead of operating the light clients for every other chain within the IBC. While the IBC model doesn’t preclude non-Cosmos SDK chains from joining it, they have to effectively be accepted into it, and become a part of the security model and technology stack.

Turning Bridges On Their Head – Chainflip

Although not a messaging protocol, and not a bridge, we feel like Chainflip is worth covering here. You can think of it as a decentralized exchange for native token swaps across all supported chains, with its own validator set (consensus) in the middle of it. The business case is to replicate the experience and business model of a centralized exchange for spot trading, but on-chain and in a permissionless manner. Chainflip was built in direct response to Thorchain and its base swap asset (RUNE) model.

Chainflip will have its own proof-of-stake blockchain and 150 permissionless validators who run full nodes or light clients of all connected chains. Validators will observe the chains, reach consensus and move funds by swapping tokens using a multi-party computation system. The protocol effectively has a relayer and oracle built into its design, making the architecture usable for generalized messaging as well, but the team has decided against that in order to optimize the protocol for spot trading.

Chainflip is structured in two layers: settlement and accounting:

• The settlement layer is native to every chain, and is where all of the native tokens are held.
• The accounting layer tracks balances, processes events, and executes cross-chain transfer instructions. It also keeps a virtual AMM for all pairs, and tracks assets of liquidity providers.

As swaps are executed, the virtual balances are updated until the swap has been completed, and assets are paid out to users as a native payout on the receiving chain. In other words, this architecture allows users to deposit tokens to vault on chain A, and withdraw swapped tokens from vault on chain B.

Source: Chainflip documentation

As liquidity providers, users will be able to provide collateral in any supported (native) token, and participate in the preferred liquidity pools. The AMM itself is based on the JIT (Just In Time) design, which specifically encourages market makers to compete to win liquidity fees by providing the best prices they can on incoming trades – which is ultimately a benefit for the users. Trades are known to all market makers ahead of time due to the inherent latency of cross-chain interactions.

Application developers will be able to use Chainflip by calling through a websocket or JSON RPC to any public endpoint on the Chainflip network. After the network is told to prepare a swap to a receiving chain and the indicated wallet, the application will receive back a unique deposit address that when deposited to, will automatically initiate that swap for the user.

Tying It All Together

In this section we look at use cases of cross-chain applications – NFTs / Gaming, Governance, Identity / Reputation and DeFi. For these apps to become chain-agnostic, they first need to connect to APIs or smart contracts deployed by Generalized Messaging Protocols.

Another way to go about this is for app developers to use an SDK like Biconomy’s. Essentially, Biconomy would build its own bridge infrastructure that leverages a Generalized Messaging Protocol on the back-end, and then abstract away cross-chain transfers like NFT purchases or gas token swaps.

NFTs / Gaming

This category could leverage Generalized Messaging Protocols in the following ways:

• NFT x DeFi. Borrowing against NFT in a chain-agnostic way – loan and collateral would sit on different blockchains;
• Cross-chain NFT utility. Own an NFT (e.g. PFP or a gaming item) on chain A, and access its utility on every other chain;
• Optimize chain choice for holding NFTs and in-game experience. This means moving the game to a higher throughput environment, while holding NFTs on a blockchain with the best security guarantees;
• Whitelisting and bounty programs. Instead of random off-chain tasks for whitelisting, projects could create a bounty for actions across various chains for people to go collect pieces from (almost like a game). A fully completed puzzle would allow them to mint an NFT on Ethereum.

In general, we think gaming interoperability is rather overhyped because game balancing becomes an issue once you split it into several environments, and the space overall is in the nascent phase where everybody is developing in their own silos.

As for NFT x DeFi, this category first has to find a product-market-fit on a single chain, where there is currently way more supply of products than demand for them.

Governance

Cross-chain voting would allow communities to organize and implement governance while being dispersed across several chains. Essentially, voting would be happening on every chain and then sent to a single chain of choice where count takes place. Then, governance decisions would be passed for implementation as a message to every chain where the app sits.

Alternatively, voting could happen on a single chain, but would allow the DAO to control the contracts living on other chains.

Another cross-chain use case for DAOs is using Generalized Messaging Protocols to redirect the fee accrual from all chains where the app is deployed back into the treasury of the main chain.

Identity / Reputation

This is perhaps the most exciting aspect of cross-chain composability, albeit the one furthest out, as there is no form of unified and expressed identity on a single blockchain even today.

Apps leveraging Generalized Messaging Protocols would be able to:

• Issue loans taking into consideration creditworthiness across multiple chains (higher credit score = more favorable terms);
• Provide gated access control to content or data (assuming you meet eligibility criteria based on on-chain activity across several chains);
• Issue attestations based on multi-chain activity;
• Aggregate and measure social capital (e.g. engagement of followers) from web3 social platforms across all chains.

Just like DeFi suffers from liquidity fragmentation, identity represented in the form of a wallet address is also incomplete when scattered across several blockchains.

DeFi

DeFi apps, as outlined by several protocol teams, are wide-ranging. It essentially abstracts away all the intermediary transactions and gas in order to access the yield opportunities on other chains.

The immediate ideas are:

• Cross-chain perpetual futures. Rage Trade aims to create the most liquid ETH/USD perpetual futures market using Uniswap V3 and LayerZero in the following way: - Allow liquidity providers in other DeFi primitives (AMM, money markets, other derivatives applications) to deposit their yield-bearing tokens to Rage Trade’s contract on the origin chain (Avalanche, Ethereum L1, Polygon, BSC, Arbitrum); - On the back of LayerZero’s messaging protocol, use these origin chain deposits to provide concentrated liquidity for ETH/USDC pair on top of Uniswap V3 in the home chain (Arbitrum). Assets are provided in 80/20 ratio, where 80% of deposit is kept in the original position, and 20% is used to provide ETH/USDC liquidity; - Use LayerZero’s Stargate to settle account PnL in USD terms across origin chains; - The end result: 1) liquidity providers are enticed to provide their yield-bearing tokens because 80/20 strategy is superior from yield perspective; 2) enhanced liquidity for ETH/USDC pair because liquidity provision is aggregated across chains.

Source: Rage Trade documentation

• Cross-chain lending and borrowing. Use collateral sitting on chain A to borrow on chain B, instead of wrapping the collateral and forcing it across chains;
• Cross-chain DEX (or a DEX aggregator). Interchangeable liquidity on all connected chains – it could be Stargate or Chainflip-like, or a CLOB;
• Cross-chain yield aggregation. Access all yield farming opportunities from a single chain.

Looking Ahead

At a high level, we can envision two extreme outcomes of the cross-chain future. The idealist version would allow us to operate across different ecosystems seamlessly, hopping across different spheres without compromising security and self-custody. The realist version resembles something close to how the internet is structured today – open areas run into gated gardens; different environments have varying degrees of security and sovereignty.

In the upcoming years we will probably continue forcing interoperability à la Bed of Procrustes. However, the early works of teams like Abacus, Nomad and others suggest that we could lean towards an outcome where cross-chain communication is conditional and security is customizable in order to avoid far-reaching fallouts in the event of a failure. There is value in connectivity, but separation and choice must be preserved.

As an industry, we’ve only scratched the surface of cross-chain composability. For the large part, the focus has been on developing token bridges which was the most obvious use case following alt layer-1 launches. We think that during the next 12 months we will see some of the theoretical application ideas outlined in this article coming to life. If you’re a developer already building cross-chain apps or have ideas for novel use cases – you know where to find us.

Disclosure: Zee Prime has invested in Biconomy, Polkadot and Rage Trade.