Bridges Grew Up. I Learned This the Hard Way - and I’m Not Building the Next One Like the Last One
I’ve been building bridges long enough to stop being impressed by bridge architecture.
Don’t get me wrong: I still respect great engineering. But after years of shipping cross-chain systems, dealing with outages, liquidity shocks, user support tickets, I’ve learned something painfully simple: most bridges didn’t fail because they were technically weak. They failed because they were inconvenient in exactly the moments that mattered to users.
We spent a decade discussing how to move assets across chains. The industry treated “asset transfer” like the core problem. Meanwhile users were trying to move value - without being forced into an IOU, without discovering they landed broke on a chain with no gas, without having to learn the social rituals of finding a faucet, a friend, or a DEX with enough liquidity to unstick them.
This is not a generic “here’s what we’re excited about” blog post. It’s my attempt to tell the truth about how bridging evolved, why the market keeps swinging between extremes, and why Allbridge's next architecture is deliberately designed to be a hybrid.
And yes: I’m writing this right before I fly to a conference to talk about what we’re building. If you’re reading this as an investor or a power user, good. That’s exactly who I want in the room for this conversation.
The IOU Era:
When we started, the default bridge architecture was mint-and-burn: lock on one chain, mint a representation on another. In those early days, it felt inevitable. If you wanted to move value from Chain A to Chain B, you created an IOU token and called it “bridged.”
It worked - until the ecosystem scaled and the lie became obvious.
Wrapped assets looked like the original asset, but they weren’t the same thing. They lived under different contracts, inherited different trust assumptions, and, most importantly, they fractured liquidity in ways that users didn’t fully understand until it hurt.
Stablecoins made this painfully visible. If you’ve been around long enough, you remember the reality: “USDC” on one chain wasn’t necessarily the same “USDC” on another. Even worse, you could end up with a bridged version of a bridged version - the same ticker, multiple contract addresses, and no clean mental model for what’s canonical. In protocol terms, we could rationalize it. In user terms, it felt like walking into a bank and being told the same dollar bill has different meanings depending on which branch you visit.
That’s not a foundation for mass adoption. That’s how you train people to mistrust the entire multichain idea.
The UX Trap Nobody Wanted to Own: Arrival Is Harder Than Departure
There’s a moment every bridge user remembers. It’s almost a rite of passage. Your transfer goes through. Funds arrive. You exhale - and then you realize you can’t do anything. Because you have no gas on the destination chain.
The industry acted like this was a minor inconvenience. It wasn’t. It was a structural failure. A bridge that drops you into a new ecosystem without the ability to transact is like an airport that lands your plane but locks the doors and tells you to figure out the exit yourself.
Back then, ecosystems patched the problem with whatever they had. Gas issue was just one of several ways arrival transfer was hard to claim. On Solana, for example, stable-asset liquidity venues like Saber became critical infrastructure for moving between pegged assets and keeping flows usable. But even those patches created new dependency chains: liquidity sometimes wasn’t there, incentives had to be tuned, routing wasn’t always predictable, and ordinary users ended up depending on the existence of “a place to land” rather than on a bridge that actually solved the full journey.
That’s the point where I stopped thinking about bridging as “sending.” Bridging is a full UX lifecycle: sending, arriving, transacting, and recovering if something goes wrong. Anything less is a demo.
Why Non-EVM Chains Got Left Behind - and Why I Think That Was a Strategic Mistake
Most bridges in the market became EVM-first, and I understand why. It’s easier to ship quickly, it’s easier to hire for (the majority of devs knows Solidity), and it’s easier to reason about. Non-EVM integration means different tooling, different assumptions, and often a wider attack surface simply because the complexity is real.
But here’s the part people gloss over: non-EVM chains are where users often find the weird, the early, and the profitable. When the industry avoids these ecosystems, it doesn’t just reduce technical risk - it narrows opportunity. Users lose access to networks where yields, games, and communities can behave very differently from the EVM monoculture.
One reason I’m comfortable saying this out loud is because even the “unifying” standards acknowledge how messy cross-VM reality is. At Allbridge, we didn’t build our identity around avoiding complexity. We built it around handling it.
Liquidity Pools: The Hidden Tax of “Instant” Bridging
Liquidity pools were the next evolutionary step because they solved something users actually cared about: “I want the native asset on the other side, and I want it now.”
Pools made this possible and, for a while, felt like the right answer. But liquidity does not maintain itself: whether through incentives, arbitrage, idle capital, or spread, its cost ultimately shows up for users. Rebalancing via arbitrage may work mechanically, but it still depends on paid liquidity rather than free capital.
This is why the market started looking for alternatives that don’t require liquidity to be constantly rented.
Intents: Beautiful Theory in, Uncomfortable Reality
Intents were the industry’s attempt to break the “idle liquidity” problem. Conceptually, they’re elegant. Instead of forcing capital into pools, a user declares a desired outcome and a network of solvers competes to fulfill it - essentially turning execution into a marketplace.
I like this model. I respect it. And we’ve studied it seriously.
But intents come with a truth that doesn’t fit neatly into marketing decks: solvers fill orders when it’s profitable and they need to have enough capital on destination to make it happen. That’s not cynicism - it’s literally how the model is designed. Their documentation is unusually honest about this: solvers simulate orders and decide whether the spread covers all costs and operating expenses, and integrators have to configure orders to remain attractive .
So the real trade-off becomes clear: intents can be cheaper and more capital-efficient, but you’re introducing a dependency on market conditions and solver appetite. Many users will accept that. But there’s a large class of users - especially moving size or operating time-sensitive flows - who want a guaranteed transfer, not “wait until a market maker likes the deal.”
That’s why I don’t believe intents “replace” pools. They complement them.
Stablecoins Won Value Transfer - and That Led to CCTP and OFT
Once you see the history clearly, you notice a pattern: bridges tried to move “assets,” but users mostly wanted to move “value.” And for value transfer, stablecoins are hard to beat.
They’re predictable. They’re liquid. They’re understood. They reduce volatility at the exact moment users care about certainty.
That’s why CCTP and OFT weren’t a trend - they were the inevitable endpoint of the stablecoin story.
Circle’s CCTP describes itself in plain terms: native 1:1 USDC transfers across chains via burn-and-mint, without relying on liquidity pools or third-party fillers.
USDT’s OFT model is framed differently but follows a similar goal: treating USDT as a single fungible asset represented consistently across multiple chains.
If you’ve ever lived through wrapped-asset fragmentation, these ideas feel like relief.
The Catch: These Rails Compete, and Users Lose Flexibility
And here’s the nuance I still don’t see discussed often enough.
This isn’t really about CCTP competing with OFT at a protocol level. It’s about something much more fundamental.
USDC and USDT live in different worlds. They serve different users, different liquidity flows, and different regulatory and market realities - and they are extremely unlikely to ever merge into a single, unified system.
In practice, CCTP and OFT simply reflect this split. They are not designed to interoperate, because the assets behind them are not designed to become one. Each rail optimizes for its own stablecoin universe, its own ecosystems, and its own definition of “native.”
The limitation appears the moment a user restricts themselves to only one of these worlds. If you operate purely inside CCTP, you inevitably lose access to chains that sit outside USDC’s native footprint.That trade-off is acceptable only if your vision of multichain comfortably fits inside a single stablecoin universe. It breaks down the moment you care about real breadth - across EVM and non-EVM chains, across different ecosystems, and across different types of users.
This is exactly where our approach at Allbridge comes from. We’re proud of the name for a reason: all-bridge means all chains. We don’t ask users to choose between CCTP and OFT. We use both. And where neither rail exists yet, we extend coverage with liquidity pools and intent-based fulfillment. The goal isn’t ideological consistency - it’s practical access. One place, one flow, minimal cost, and maximum reach across the entire multichain landscape.
Allbridge Next: I’m Building “And,” Not “Or”
So here’s my thesis, stated bluntly: the next generation of bridging isn’t a single architecture. It’s a routing brain that chooses the best architecture for the route, the asset, the chain pair, the user’s preference, and the market’s current state.
In Allbridge Next, we’re building a hybrid system on purpose.
When CCTP is available, we use it - because native burn-and-mint USDC is one of the cleanest answers the market has produced . When OFT routes make sense, we use USDT which is easily convertible to USDT - so you can get USDT TRC20 from your favourite OTC desk. When neither is available, we don’t pretend the transfer should fail - we fall back to liquidity pools and intent-style fulfillment to preserve reliability and coverage if we do not have enough liquidity ourselves. And when users want more than “bridge,” we treat bridging as part of a bigger job: swapping, routing, arriving with gas, and being able to act immediately.
Privacy: Definitely Not Optional Anymore
Now let’s talk about the part most bridge teams avoid because it’s politically uncomfortable: privacy.
For years, “privacy” was treated as a niche feature - a philosophical argument. That’s not where we are anymore. Physical security risks for crypto users are rising, especially for anyone with visible on-chain wealth. This isn’t paranoia; there have been real kidnappings and violent extortion cases targeting people connected to crypto wealth in various parts of the world.
I don’t believe in tools that solve crime by making everyone invisible - or by putting everyone under a spotlight.
What I find compelling - and what the industry is actively experimenting with - are models like Privacy Pools.
Our direction is aligned with that philosophy: privacy as a user protection layer that doesn’t destroy compliance and doesn’t require users to become criminals just to regain basic financial dignity.
In Allbridge Next, “private mode” is not a separate product. It’s a routing option. High-level, the idea is simple: if a user opts into private routing, the transfer can be routed through a dedicated pool where a commitment is recorded, then later withdrawn using a proof, revealing only what must be revealed to complete the transfer while keeping the public chain from becoming a map of your relationships. In the model we’re exploring, a relayer can hold sender/recipient context off-chain so that legitimate investigations remain possible when required - but that context doesn’t need to be broadcast to the entire internet by default.
That’s the line I care about: protect normal users without building a playground for the worst ones.
Gas Orchestration, Finalization, and “Bridging That Feels Like One Chain”
The feature nobody brags about at conferences is often the thing users love the most: convenience that removes friction they didn’t even know how to name.
Destination gas, fee abstraction, automated finalisation, and safer routing are no longer differentiators - they’re requirements. Without them, multichain still feels like a sequence of rituals rather than a single coherent experience.
My blunt view is this: if bridging still feels like a technical ritual, we failed. Bridges should feel like an app, not like an expedition.
The Next Six Months: What I’m Actually Building (Not What I’m Promising)
I don’t want to end this with a hand-wavy “we’re excited.” I want to end it with what you can hold me accountable for.
Over the next six months, my priorities are straightforward:
- Make stablecoin routing feel native
- Guarantee reliability beyond the supported rail set, by keeping pool + intent fallbacks for chains and routes where native routes don’t exist, while being honest about the solver economics and designing around them .
- Treat “bridge + swap” as the default, because users rarely want a bridge; they want the outcome.
- Ship privacy as a responsible option, rooted in the direction the industry is already validating
- Keep non-EVM a first-class citizen, because multichain is bigger than the EVM comfort zone - and because I think the market underestimates the opportunity there.
And I’m going to build as publicly as is reasonable. Not because it’s fashionable, but because I want power users to see the progress, challenge the assumptions, and become part of the feedback loop that makes this kind of infrastructure actually good.
A Provocative Ending, Since You Asked For One
If you think bridges are solved, you’re either new here or you’re only bridging on easy mode.
If you think the future is one architecture, one rail, one ecosystem - I’m betting against you.
And if you’re an investor looking for a “bridge narrative,” I’m not selling one. I’m building the thing users actually need: a system that chooses the right primitive per route, per asset, per moment - and does it without asking users to become liquidity engineers.
I’ll be in the room soon. If this post irritated you a little, perfect. That’s usually where honest conversations begin.
