Interop Still Sucks Because It Serves Chains, Not Users
Today in crypto, we find ourselves with a good old fashioned paradox. Bridges are now fast and reliable, but users are more frustrated than ever about fragmentation.
We’re building better and better bridges, but we’re optimizing for the wrong things. While these tech advancements are impressive, they only optimize specific metrics—like speed and liquidity—leaving the overall user experience stuck at a plateau, or what we call a “local maximum”:
The State of Interop in 2025
Today’s interoperability solutions are impressive technical feats:
LayerZero and Axelar’s multichain token standards can move any amount with zero slippage (minus fees) in 10-15 minutes.
Across and DeBridge’s intent-based bridges can move reasonably sized amounts in less than a few seconds.
Yet, if you spend a couple minutes on crypto twitter, you’ll see endless complaints from users and builders about fragmentation and bridging.
Why Builders and Users are Frustrated
Let’s say you want to interact with a dapp – let’s use Echo as an example. These are the steps you likely need to take:
Go to Echo, which happens to be deployed on Base.
You don’t have funds on Base, so you need to bridge there.
You need to find a bridge first, choose between a couple options and find its website (also make sure it’s not a phishing site)
Build your bridge transaction and send it.
Wait for finality.
Return to Echo and interact with it.
Note: Bridge widgets like LiFi exist so that you can do this without leaving an app, but they don’t remove the fundamental problem here: the number of steps and clicks it takes to get something done.
In Echo’s case, you may have missed out on an investment opportunity:
Builders are frustrated because their users need to bridge funds to interact with their dapp. The state of dapp development means you can choose from just a few suboptimal options:
deploy on 1 chain – sacrifice user experience
deploy on every chain – no network effects, difficult maintenance, bespoke modifications
rearchitect to be multichain – deal with finality, messaging protocols, delay mainnet by 6 months
Users are frustrated because of the amount of time and complexity required to get anything done.
The industry has been building interoperability solutions for 5+ years. To understand why these frustrations persist, we need to look back at how our current system evolved.
The Origins of Interoperability
By 2020, blockchain ecosystems were booming. Each ecosystem needed capital to grow, and there are only 2 ways to get capital into your ecosystem:
Create native value: attract asset issuers to your blockchain – new stablecoins, new token launches, etc. This way is difficult, and it requires creativity and time.
Attract capital from other ecosystems: draw capital from other chains into yours. This is easier, because the capital already exists – it just needs the right incentives.
Most blockchains pursued both strategies, but let’s focus on the latter. Take Avalanche for example: the Avalanche Foundation created a bridge that allowed users to lock $ETH and ERC20s on Ethereum and mint a wrapped version on the Avalanche C-Chain. If you bridged $ETH, you now have Avalanche($ETH), where parentheses represent a “wrapping”.
This was a smart way to quickly bootstrap liquidity for new ecosystems.
But as the blockchain ecosystem evolved, this system had unintended side effects. Wrapped tokens are, by nature, derivatives. If you now want to move your Avalanche($ETH) to Solana? Well now you wrap it again, and create Solana(Avalanche($ETH)). Multiply this across other ecosystems and it quickly becomes a tangled web of token derivatives. There are now 10 versions of $ETH on Solana. As a dapp developer, which one do you integrate?
Some teams saw the opportunity to solve this problem and attempted to unify assets. Rather than using ecosystem bridges, they created generalized bridges. These bridges standardized the wrapping process – now wormholeETH exists on every chain – but also spawned competing token standards like OFTs (LayerZero) or ITSs (Axelar). Which brings us back to the same problem: multiple derivatives that are supposed to represent a particular asset on each chain.
As the industry continued refining capital movement, teams like Across and Debridge recognized that these generalized bridges could be much faster. By introducing intent‑based bridges, they created a new bridge architecture leveraging sophisticated market makers to handle complexity like source chain finality and transaction inclusion. This accelerated asset transfers—delivering a better experience without sacrificing security.
Unfortunately, this is the local maximum: if we only keep building better bridges, we’re optimizing around the original reason for bridges – to attract capital to a new ecosystem – rather than what we should be optimizing for: user-centric actions that are fast and cheap.
We want to build systems that serve users, not ecosystems.
To break out of this local max, we must rethink user-centric interoperability from first principles.
First Principles: Latency & Clicks
If we want to build interoperability that is good for users, the principles we care about are:
Minimize latency: Web2 UX research shows that actions need to complete within 2 seconds of a click to retain 60% of users, and in less than 1 second to retain 90% of users.
Minimize clicks: 1-2 clicks to do something, max.
Under the constraints of decentralization and self-custody
The experience of going to an app, exiting the app, finding a bridge, approving, bridging, going back to the app, approving, interacting – is about 10 user clicks and 5-15 minutes.
In 2025, Omni is going to make this happen in 1 click and less than 1 second.
Jumping to the Global Max: [Generalized] Intents
Looking ahead in 2025, the breakthrough for sub-second actions in 1 click isn’t in building better bridges. The future lies in generalized intents. Rather than bridging intents or swapping intents, these are arbitrary cross chain actions like depositing collateral or buying an NFT. Under this model, dapps run on a single chain for simplicity, while their frontends offload user requests to sophisticated market makers (solvers) who execute actions on users’ behalf at ultra low latency – regardless of which chain those users have money on. This approach delivers the one-click, near-instant experience users need, all without leaving the dapp’s frontend.
Omni is now launching a Typescript SDK that allows users to interact with dapps via intents in 1 click and less than 1 second.
How do we achieve 1 click? EIP-7702. This upgrade allows EOAs (externally owned accounts, i.e. your wallet) to act as a smart contract wallet. Hence, a sophisticated party can act on your behalf on any chain with just a single signature from you – 1 click. The construction of the signature is complex, but you can do that through a frontend SDK, like the Omni SDK, whose alpha release is happening this week.
How can we achieve sub-second latency? The intent model brings us to about 2-3 seconds. To get below a second, we first recognize that the bottleneck is source chain transaction inclusion, and to solve that we must introduce off-chain mempools. Don’t worry – the “off-chain” component doesn’t mean we’re compromising on decentralization. You can read more about the model here. It just means the mempool will exist among solvers, removing the latency increase from source chain transaction inclusion. Even when the source chain is L1, there are ways to achieve <1s execution (primarily pre-commits and resource locks).
By combining EIP 7702, generalized intents, and offchain mempools, we can achieve arbitrary sub-second actions in 1 click.
Looking Forward: A New Paradigm for Dapps
This technology creates a new paradigm for how dapps can be built. Dapp developers no longer need to worry about “going multichain”, which was never what they cared about anyway. They simply care about building a product that all users can access. Dapp developers can focus on building a fantastic product on a single chain that users can access in real time from anywhere.
We are nearing a fundamental shift in how users interact with decentralized applications. A shift from in-your-face interoperability to an invisible experience that prioritizes latency, simplicity, and decentralization. Omni is pioneering this model with a few of our close build partners going live in late Q1 and early Q2.
If you are interested in being part of the gold standard for UX that pushes the industry out of this local maximum, feel free to reach out to me or the Omni team.