What Are Intents? The Future of Cross-L2 Bridging Explained

Intent-based bridging is an architecture where a user states the outcome they want — "I have 1,000 USDC on Arbitrum and want it on Base" — and independent, competing "solvers" fill that request immediately from their own liquidity, settling the underlying cross-chain transfer among themselves afterward, rather than the user waiting on a traditional lock-and-mint or burn-and-mint bridge transaction to fully process across chains.

This flips the usual bridging sequence. A classic bridge processes a transfer step by step in real time — lock on the source chain, verify, mint or release on the destination chain — with the user waiting for each step. An intents system separates "what the user wants" from "how it gets fulfilled," letting a solver front the destination-chain funds instantly and worry about the underlying settlement afterward.

How a typical intents-based transfer works

1. A user signs an intent specifying the asset, amount, source chain, and destination chain (and often a maximum acceptable fee or minimum acceptable output).
2. A network of solvers — independent market participants who hold liquidity across multiple chains — compete to fill this intent, typically via an auction or first-to-fill mechanism.
3. The winning solver sends the destination-chain asset to the user immediately, from their own pre-positioned liquidity, well before the underlying source-chain transaction is even necessarily finalized.
4. The solver then reclaims the equivalent value from the source chain through the protocol's settlement mechanism, which typically relies on a dispute or verification window to prevent solvers from claiming funds without actually having fulfilled the user's intent honestly.

Across is one of the best-known examples of this design in production, and similar intent-based approaches have spread to other bridging and even trading contexts as the model has proven effective.

Why this can be faster than classic bridges

The key insight is that the slowest part of a classic bridge is usually the cross-chain verification step — waiting for a message, a fraud-proof window, or a validity-proof check before the destination chain can safely release funds. Intents-based systems remove the user from that critical path entirely: the solver takes on the waiting and settlement risk, because they have both the liquidity and the incentive (their fee) to do so, and because they can rely on their own risk assessment of the specific route rather than the protocol enforcing full verification before every single transfer.

This is conceptually similar to how third-party liquidity bridges have long offered faster transfers than native rollup withdrawals (see our piece on moving liquidity across L2s) — but intents-based systems formalize this into a competitive marketplace of solvers rather than relying on a single bridge operator's liquidity, which can improve both speed and pricing through competition.

What secures the solver's reimbursement

The mechanism that lets a solver confidently front funds instantly, and still get repaid honestly later, is the real engineering core of any intents system. Common approaches include a dispute window during which anyone can challenge a solver's claim that they fulfilled an intent correctly (similar in spirit to the fraud-proof model discussed in our challenge period explainer), backed by a bond the solver forfeits if they're found to have claimed funds without actually delivering. This shifts most of the cross-chain verification burden off the user's critical path and onto a specialized, professionally-incentivized solver network instead.

Model	User waits for	Who bears verification risk
Classic lock-and-mint bridge	Full cross-chain verification	User, until verification completes
Intents-based bridge	Solver's immediate fulfillment	Solver, backed by bond and dispute window

Trade-offs and risks to understand

Intents-based bridging isn't risk-free just because it's fast. Key things worth checking about any specific implementation: How is the solver network secured — bonds, reputation, both? What happens in periods of low solver liquidity for a specific route — does the intent simply go unfilled, or fill at a worse price? Is the underlying settlement/dispute mechanism actually live and adversarially tested, or does the system still rely on a small, semi-trusted solver set in practice? These are the same categories of due diligence that apply to any bridge, just applied to a newer architecture.

Why this matters for the broader L2 ecosystem

As the number of rollups grows, the practical usability of a multi-chain ecosystem depends heavily on how fast and cheap it is to move value between them. Intents-based architectures are one of the more promising answers to this fragmentation problem, alongside efforts like shared sequencing and unified liquidity layers — see our broader how L2 tokens work and cross-chain messaging pieces for how these pieces fit together across the ecosystem.

Bottom line

Intents-based bridging speeds up cross-L2 transfers by letting competing solvers front liquidity immediately and settle the underlying verification afterward, rather than making users wait through the full cross-chain confirmation process themselves. It's a genuinely useful innovation for reducing L2 fragmentation friction, but it still depends on solver bonding, dispute mechanisms, and available liquidity being sound — evaluate any specific implementation on those terms before routing large transfers through it.