The brief history of crypto interop (WIP)

The blockchain ecosystem began with a single, isolated network — Bitcoin. As more chains emerged, the need for interoperability — the ability for different blockchains to communicate and exchange value — became clear. This post takes you through the pivotal moments in the history of crypto interoperability.

This post is technical, diving deep into each solution that emerged over time and offering a glimpse of what future technologies may look like. It’s not just a factual or research post; it’s also my opinions and experience about interoperability and crypto overall.

Bitcoin

Let’s step back and remember how it all started and how this problem was created at the first place. It began with Bitcoin in 2009. Once Bitcoin was live, for the first time in human history, we had a digital, non-replicable piece of information. Fast-forward to October 2011, just after 2 years of beign live - Bitcoin saw tremendous growth. In June 2011, it reached a $200M market cap (then quickly dropped to $30M). Block production became much more expensive than when it started. In 2010, just two leading zeros for calculating block hash was necessary, in 2011 it skyreocketed to 5-6 zeros. For the curious, now it’s 20 zeros.

Litecoin

The growth of Bitcoin hinted at multiple scalability issues that could arise if Bitcoin continued to grow. So, a couple of projects emerged. Welcome on stage Litecoin. Litecoin was launched in 2011 by Charlie Lee, a former Google engineer, as a “lite” version of Bitcoin. The main promise of Litecoin was that it could be faster and cheaper. Also it would be cheaper to mine for Miners.

Charlie Lee stated that Litecoin wasn’t meant to compete with or replace Bitcoin, but rather to act as “silver to Bitcoin’s gold.” It aimed to serve as a testing ground for innovations that could later be adopted by Bitcoin (e.g., SegWit, Lightning Network).

In short, Litecoin was created to help scale the Bitcoin.

How did the crypto space look like at that time? You had BTC as an asset on the Bitcoin network and LTC as an asset on the Litecoin network. These networks were sovereign, separate from each other, with different set of miners and neither knew the other asset existed elsewhere. And a simple question arose from this situation: if I have BTC, how do I get LTC? BIG QUESTION. No answer until 2013.

But what did people do? They just used CEXes (at that time, for example, Mt. Gox). You could deposit BTC, sell it for USD, then buy LTC and withdraw it to Litecoin. Nice! Would you be surprised that people in 2025 still use this exact flow when they need to do this kind of operation? Something is definitely off, but we’ll get to that later in the post. Now, let’s get back to the first technical solution that was proposed for this problem.

Atomic Swaps

In 2013, on May 2nd at 10:35 AM, a guy named Tier Nolan hit the submit button on the BitcoinTalk forum: “Alt chains and atomic transfers.” This was the first time a trustless, secure way was proposed for swapping Litecoin with Bitcoin.

So how it worked?

Let’s say Bob has 1 BTC and Alice has 10 LTC, and they want to exchange assets.

1. Bob generates some random data — a secret — and calculates HASH(secret)
2. He then creates a Bitcoin P2SH transaction with a script that allows spending that UTXO if the secret is provided (it compares with the hash, as Bitcoin scripting lets you calculate the hash), or, if a specified timelock expires, Bob can spend this UTXO to get his funds back.
3. Alice sees this transaction in Bitcoin, showing that Bob is willing to do an exchange with her. She copies HASH(secret) from Bob’s step 2 transaction and creates a transaction in the Litecoin network under the same condition, except now if the secret is provided, funds will go to Bob.
4. Once Bob observes this, he reveals the secret by making a public transaction to spend that UTXO in Litecoin.
5. As the secret becomes public, Alice uses this secret and spends the UTXO in the Bitcoin network.

As Litecoin supports almost the same Bitcoin scripting with all necessary components like comparing and calculating hashes, this worked. These scripts are also called HTLCs — Hash-Time Locked Contracts. The timelock component of this exchange is essential, as it gives each party appropriate time to act, and if they don’t act in time, parties can refund their assets. This clever idea, for the first time in human history, allowed cross-chain swaps between sovereign chains in a trustless manner. Parties don’t have to trust each other or any third party.

Lightning Network

After this idea, real-world implementations emerged. One of the greatest and most successful use cases of atomic swaps was the Lightning Network in 2015. With current terms, it’s the first and longest-running L2 on Bitcoin. The Lightning Network is an off-chain payment protocol that allows users to send and receive Bitcoin instantly, with low fees and a highly scalable architecture. It achieves this by creating payment channels — temporary smart contracts between two users that let them send funds back and forth without touching the blockchain for every transaction. Only the opening and closing of the channel are on-chain. Everything else happens off-chain. These opening and closing channel contracts are created with HTLC contracts.

Ethereum

So far, so good. We scratched the surface of the interoperability space, and now as we move forward, everything becomes way more complicated. So let’s dive in. Let’s fast forward one year to 2016, when the great and almighty Vitalik Buterin and his crew invented Ethereum. The curiosity for creating Ethereum was the idea: if we can now have a non-replicable, verifiable piece of information, it means that this information was somehow created.

In Bitcoin, that information was limited to UTXOs and some basic scripting. What if, instead of that basic scripting, we could have a fully functional programming language? And so, Solidity and Ethereum were born. With this innovation, Ethereum created a situation where new tokens could be easily generated within Ethereum itself (ERC20s). Interoperability and Atomic Swaps were pushed to the back burner and were no longer seen as important solutions, as you could create as many tokens as possible in Ethereum — in the same chain — and then use protocols like Uniswap to exchange them within Ethereum without any interoperability issues.

Additionally, centralized exchanges (CEXes) were on the rise, so if someone needed to exchange BTC for ETH, they could still do it through CEXes. In the same way, you could deposit BTC to a CEX, trade it for USDT, then for ETH, and withdraw it back. After a few years of tremendous success with Ethereum, it became evident that Ethereum needed to be scaled again. One chain was not enough; during peak times, the blockchain was getting congested and fees were skyrocketing. For a few folks in the space, including the co-founder of Ethereum (Gavin Wood), it became clear that one chain to rule them all was not going to work. So two independent projects were built around the same time: Polkadot and Cosmos. Both had a vision to enable the launching of new chains—presumably, each chain would be specialized for a specific application or use case.

Cosmos

Cosmos introduced the idea of Hubs and Zones. You would have a single blockchain HUB that would connect all Zones. Zones are separate, application-use-case-specific blockchains. They launched a Cosmos SDK, which allows you to launch your own network, with your own validators, tokens, customization, etc. On top of this, they introduced one of the greatest interoperability solutions: IBC. The core idea is that you can have sovereign chains, but these chains have a built-in interoperability solution (IBC). With IBC, each chain is required to run a light client for the other chains it wants to connect with. Running a Light Client is necessary so you can verify that something really happened on the other chain. Alternatively, you can connect to the Hub itself and only run a Light Client for the Hub. With this design, all chains can validate the Hub and route messages through the Hub. This simplifies the topology from O(n²) (direct links between all Zones) to O(n) (Zones only connect to Hubs). The latter is a core design decision built into Polkadot. In IBC (Inter-Blockchain Communication), you do not directly specify the destination chain by name in the message, like you would with an HTTP endpoint. Instead, the destination chain is implicitly defined by the channel and port you’re using. You can find a channel that you want to use from block explorers like mapofzones.

Polkadot

Polkadot introduced the idea of Relay Chains and Parachains. It looks similar at first to Cosmos, but it’s fundamentally different. The Relay Chain is a single settlement layer. Relay Chain Validators also validate all Parachains. Parachains don’t have the same freedom that Cosmos chains have in terms of their own architecture; Parachains must fit into the same architecture. This is because Relay Chain validators have to validate the parachain. So, with this design, you have a unified security infrastructure, where all chains have the same security and all cross-chain messages are validated by Relay Chain Validators. With Polkadot, you don’t have to think about this when you launch a parachain; everything is handled by Relay Chain Validators. They validate all the messages in the ‘core chain’ and send/read messages through the same settlement layer. Ethereum Layer 2 After these few years went by without any new innovation around interoperability, Ethereum and Solana didn’t need one. Polkadot and Cosmos introduced interoperability inside their sovereign networks; you could trade your ETH for SOL, or for BTC on CEXes. Everything was good until Ethereum L2s were introduced and gained adoption. It started in 2019 with Loopring, then in 2021 with Arbitrum and Optimism. Since then, dozens of interoperability protocols have emerged. We will walk through each of them, exploring their ideology, how they approach the problem, and of course, we will test and run them. The catalyst for these interoperability solutions was driven by the design of the Arbitrum and Optimism networks. At first, they saw tremendous growth, but their design introduced a big limitation (inconvenience): you could send your funds to Arbitrum trustlessly in a few minutes, but you had no ability to withdraw them instantly. You would send a withdrawal transaction, lock your funds for 7 days, and after that time, you could only claim your funds back in Ethereum. This was a massive problem and a huge opportunity for those who could deploy big liquidity, freeze the assets for 7 days, but give users their funds instantly, while at the same time charging them a fee. This created a big economic incentive for creating an interoperability protocol, and the first ones started emerging.

What is the CORE Problem of Interop?

As you can see from the Bitcoin and Litecoin examples, as well as the Cosmos and Polkadot designs, the core driver for interoperability solutions is solving the scalability issue, and the core problem with those solutions is: who verifies what?

To just get to the bottom of interoperability, it’s as simple as sending assets from one wallet to another wallet, but across different networks. So what is the question you ask about a blockchain when you are considering holding, buying, or using their infrastructure? What is the consensus mechanism of that blockchain? How many validators, how many miners, etc.? Once you are confident, you use the wallet and you do the transfers. With cross-chain transfers, now you have two sets of the same questions. You are operating in two different security zones. For example, for Bitcoin and Ethereum, those zones are similar, but for a long-tail chain or app chain versus Bitcoin, the security zones are different. So this is something you should consider. On top of that, you should ask about the actual transportation layer: what handles that cross-chain transfer, and what is the consensus? Let’s say for Bitcoin to Ethereum transfers, the security of that transfer should at least be at the same security level as Bitcoin and Ethereum transfers, right? Apparently, that’s not true. And there is a lot to unpack here. It means that in order to do a Bitcoin to Ethereum transfer, you are passing through a third zone, which has its own security attributes. Who is verifying the transactions, who is signing the them, what happens if… That’s why it’s a complicated topic. There are way too many solutions trying to solve this exact problem: what is the exact transportation mechanism? Who is governing this process? Because of the single chain, we have the answers. We know how miners work, how validators work, etc. But the same questions should be asked for an interoperability solution, as they effectively act as a cross-chain ledger. Who is governing the cross-chain transaction process? This question has raised billions of dollars and sparked dozens of solutions. This post will explore the majority of them and will try to answer the same exact question from different solutions’ perspectives.

Diving Deep

We will be exploring each interoperability protocol through 4 lenses:

• Participants - Who are the participants in a single bridging transaction from one chain to another? What parties are involved in the finalization of the transaction?
• Flow - What does the process look like end-to-end, from the user submitting a transaction to receiving funds in the destination chain?
• Security - How is the settlement done between chains? Who and what verifies what happened in the source and destination chains?
• Extendability - How extendable is the protocol? Can new networks be added? How easy is it? Are participants permissionless?

Alongside this, I will try to share my experience and some notes. I will present a flow chart to capture the basic idea of the protocol and will note with colors the actions done by specific participants or components.

• User - Person doing the cross-chain transaction
• Solver/Pool - Solver or Liquidity Pool or any participant who is front-running the liquidity
• Native - Any Native Component, Like L1->L2 bridge
• External - External component, decentralized file storage, separate network with validators, Oracles, etc.

Full list of the protocols covered in this post

• Multichain - A 21-node SMPC network that mints and burns wrapped tokens held in threshold-controlled vaults across chains.
• Wormhole - A 19-guardian validator network that signs verifiable action approvals (VAAs) to relay assets and messages between chains.
• Axelar - Cosmos-based PoS network whose validator set co-signs gateway contracts for programmable cross-chain messaging and token transfers.
• deBridge - A threshold-signature messaging and asset bridge secured by a staked validator set, with signatures permissionlessly relayed for final claim.
• ChainFlip - A native-asset AMM whose Substrate state chain and FROST-TSS vaults execute direct swaps without wrapping.
• THORChain - Bonded node network with TSS Asgard vaults and a RUNE-paired AMM that swaps native L1 assets directly.
• CCIP - Chainlink’s cross-chain protocol that moves tokens and messages via dual oracle networks and an independent risk-management guard
• Hyperbridge - Light client proof-aggregating Polkadot parachain that lets permissionless relayers deliver consensus-verified messages between any connected chain
• Stargate - A LayerZero-based bridge that taps unified liquidity pools and multi-attestation verifiers to deliver tokens.
• Everclear - A clearing layer that nets user intents and solver fills via Hyperlane, giving users instant payouts while balancing liquidity in a central hub.
• HOP - Rollup-centric bridge where bonders front hToken liquidity, AMMs swap to native assets, and the canonical bridges provide settlement.
• Connext V2 Protocol - A liquidity-network bridge that uses hashed-timelock atomic swaps and permissionless routers for fast, trust-minimized transfers across chains.
• Across - An optimistic bridge where relayers front funds instantly and UMA’s oracle later settles.
• Synapse - Optimistic bridge where collateral-posted relayers fulfill transfers immediately and guards can dispute within a challenge window.
• Meson - An atomic-Swap HTLC network allowing LPs to match stable-coin transfers between any chains with no validators and 3rd parties
• 1inch Fusion+ - Dutch-auction HTLC swaps filled by staked resolvers who atomically lock and release funds on both chains.
• Garden Finance - Intent-based HTLC network where staked solvers compete to fill swaps and face slashing if they fail to execute correctly.
• TRAIN Protocol - A permissionless cross-chain swaps protocol that uses atomic PreHTLC escrows and competitive solver auctions to enable trustless (trust-minimized) asset swaps between chains
• Centralized Bridges (Layerswap, Relay, Orbiter) - A single trusted party (the solver) receives user funds on the source chain and transfers equivalent assets from its own inventory on the destination chain.
• CCTP - Circle’s burn-and-mint bridge that lets native USDC move across chains by burning on the source chain and minting on the destination.
• LayerZero - Modular messaging layer that uses configurable decentralized verifier networks plus executors to deliver payloads.
• Hyperlane - “Choose-your-own-security” mailboxes where each app picks its interchain security module—multisig, staking, ZK, or custom—for permissionless messaging.

Multichain

A 21-node SMPC network that mints and burns wrapped tokens held in threshold-controlled vaults across chains.

On paper, Multichain was fairly decentralized, even more decentralized than all current interop protocols. 21 independent Nodes, if you wanted to do something bad with this design, you would need to CORRUPT 15 nodes. Sounds secure and highly non possible right? Right. Apparently, the CEO was arrested and the whole protocol’s operations were stopped. We at Layerswap also lost around 40 ETH in Multichain. We used them for a few routes for liquidity rebalancing and their operations were stopped, but their website was running. So we just did the transaction and it is stuck forever.

The Multichain case is a good reminder that any design that relies on a closed set of a few actors is inherently critical. And strangely enough, the multisigs were not that decentralized, but their website is still up and running without any notice that the protocol is halted. Sorry for the hatred here, but losing 40 ETH at your early-stage company leaves its marks.

Wormhole

A 19-guardian validator network that signs verifiable action approvals (VAAs) to relay assets and messages between chains.

Verified Action Approvals (VAAs) are Wormhole’s core messaging primitive. They are packets of cross-chain data emitted whenever a cross-chain application contract interacts with the Core Contract.

Wormhole is one of the longest-running x-messaging protocols. They sustained a horrible $300M hack and are one of the dominant players in the space.

Axelar

Cosmos-based PoS network whose validator set co-signs gateway contracts for programmable cross-chain messaging and token transfers.

With this design, as with Wormhole, adding a new chain is a big problem because all of your existing validators should run a light client for the new chain. So with each chain added to Axelar, every Axelar node operator becomes harder and more resource-expensive to run. Axelar actually addresses this problem with the Axelar Amplifier network, where you can add a network that core validators don’t need to verify. You add a network with its own verifiers. But I am not quite sure how the security of the messages coming from verifiers is adapted and matched with messages that are verified with ‘core’ validators.

deBridge

A threshold-signature messaging and asset bridge secured by a staked validator set, with signatures permissionlessly relayed for final claim.

ChainFlip

A native-asset AMM whose Substrate state chain and FROST-TSS vaults execute direct swaps without wrapping.

THORChain

Bonded node network with TSS Asgard vaults and a RUNE-paired AMM that swaps native L1 assets directly.

CCIP

Chainlink’s cross-chain protocol that moves tokens and messages via dual oracle networks and an independent risk-management guard.

Hyperbridge

Light client proof-aggregating Polkadot parachain that lets permissionless relayers deliver consensus-verified messages between any connected chain.

This bridge design has an interesting caveat. Contrary to different validator-based bridging, validators/relayers of this network do not need to run a full node / light client for any supported chain. Those runners are separate permissionless parties. Validators just have to create a light client contract and wait for relayers to fill in the data. This is a nice improvement in terms of scalability, but it comes with a trade-off.

Stargate

A LayerZero-based bridge that taps unified liquidity pools and multi-attestation verifiers to deliver tokens

Stargate has one of the deepest liqudities in the interop space. Works really neat and stable. They use 2 configured DVNs basically just 2 entity multisig, which I am not fun of and the technicall challange here is if they ramp up the security, lets say increase it to 4-8-12 DVNs the costs of the transaction would be skyrocketing and they will not be competetive in the market, considering that solutions like Layerswap and Relay, with a centralized (non-security) aproach are just attracting users - until something bad happens.

Everclear

A clearing layer that nets user intents and solver fills via Hyperlane, giving users instant payouts while balancing liquidity in a central hub.

HOP

Rollup-centric bridge where bonders front hToken liquidity, AMMs swap to native assets, and the canonical bridges provide settlement

Connext V2

A liquidity-network bridge that uses hashed-timelock atomic swaps and permissionless routers for fast, trust-minimized transfers across chains.

Mention that this project is discontinued. The reason from GitHub was rebalancing issues and solver liveness. And they didn’t expand more from EVMs.

Across

An optimistic bridge where relayers front funds instantly and UMA’s oracle later settles.

Anyone can technically run a relayer, but the majority of order flow is routed to exclusive Relayers, which the team has to confirm/allow to become a relayer.

Synapse

Optimistic bridge where collateral-posted relayers fulfill transfers immediately and guards can dispute within a challenge window.

Meson

Atomic-Swap HTLC network allowing LPs match stable-coin transfers between any chains with no validators and 3rd parties

I use this bridge really rarely, but I thought it’s good to mention them as they use Atomic Swap workflow as well. Their approach with Trusted verifier is default in their dApp so basically you trust someone not to steal your funds (if they collide with LP they can steal) which I am not fun of and it completly demolishes the buity of Atomic Swaps. Again this is decision to stay competetive in the market, because as you could see with pure atomic swaps User’s has to do 2 steps which noeone is fun of. As everythong things that the all problems with crypto is UX.

1inch Fusion+

Dutch-auction HTLC swaps filled by staked resolvers who atomically lock and release funds on both chains.

Garden Finance

Intent-based HTLC network where staked solvers compete to fill swaps and face slashing if they fail to execute correctly.

TRAIN

A permissionless cross-chain swaps protocol that uses atomic PreHTLC escrows and competitive solver auctions to enable trustless asset swaps between chains

I am the co-founder of this protocol. Take this with a bunch of salt.

Centralized Bridges

A single trusted party (the solver) receives user funds on the source chain and transfers equivalent assets from its own inventory on the destination chain

Oh boy. These players are kind of disruptive in this space. As with a centralized design you can is WAY easier to operate solver, way easier.

CCTP

Circle’s burn-and-mint bridge that lets native USDC move across chains by burning on the source chain and minting on the destination

LayerZero

Modular messaging layer that uses configurable decentralized verifier networks plus executors to deliver payloads.

Hyperlane

“Choose-your-own-security” mailboxes where each app picks its interchain security module—multisig, staking, ZK, or custom—for permissionless messaging.

–

As we get here, to quick recap is that interop is at really early early stages. All the solutions come with gigantic tradeoffs, often the ones that are not easily spotabble at surface, some of them are intentionally misleading, some of them have actually a good path forward, that can benefit the whole crypto ecosystems. Whatever it is, but we are right now in big experimental stage, where we will se what kind of projects can start striving. I almost think that whatever it was possible to try and explore, has been done, the question is how the existing solutions and how the crypto ecosystem will grow generally.