Every cross-chain swap in DeFi's first era looked roughly the same. You locked assets in a bridge contract on the source chain, waited for a relayer to prove the lock to the destination chain, and received a minted representation on the other side. It worked. It also hid a pile of trust assumptions, UX gaps, and failure modes that cost users real money. The debate around intents vs bridges is less about technical purity and more about which design is finally ready to put those failure modes to bed.

This article walks the architectural comparison end to end. Why lock-and-mint became the default, what changed when intent-based execution appeared, how intents abstract away the bridge step, and where the UX and security trade-offs actually net out. Where we say "bridge" we mean the primitive — the lock-and-mint mechanism — not any particular product.

In 2020-2022, the only way to move a token across chains was to freeze it somewhere and mint an IOU somewhere else. AMMs were the dominant liquidity venue, and AMMs can't price a token that doesn't exist natively on their chain. So: lock USDC on Ethereum, mint wrapped-USDC on Avalanche, swap the wrapped asset against a local pool, hope the wrapper stays pegged.

The design made sense given the constraints. Blockchain bridges could be built with familiar primitives — multisigs, light clients, relayers — and they solved a real problem. A developer just wanted users from chain A to be able to use their app on chain B, and lock-and-mint was the least-invasive way to do it.

The cost was paid in three places. First, security assumptions stacked: users trusted the bridge's validator set, the relayer's honesty, and the uptime of the attestation layer. Published bridge taxonomies distinguish native, external, and optimistic verifiers, and each class has its own risk profile. Second, UX degraded as soon as anything went wrong — a paused bridge meant locked funds with no clear unlock path. Third, liquidity fragmented across wrappers (USDC.e vs canonical USDC) and every chain had to negotiate its own bridge trust model. Eco's breakdown of USDC.e vs native USDC captures the wrapper fragmentation problem well.

The shift to intent-based execution started when protocol designers realized users didn't actually want to "bridge." They wanted a specific outcome — I have 10,000 USDC on Arbitrum; I want 9,990 USDT on Base in the next minute — and the bridge step was just an implementation detail of meeting that outcome. The Paradigm intents writeup is the canonical public statement of that shift: express the outcome, not the path.

An intent encodes the outcome as a signed message. The user specifies inputs, outputs, constraints, and a deadline. A solver reads the intent, figures out how to fulfill it, and posts collateral guaranteeing the fill. If you've never seen the mechanism in action, the pillar explainer on intents and solvers walks through the handshake step by step.

The subtle but important difference is who bears the execution risk. In a lock-and-mint flow, the user signs a bridge transaction and owns every downstream failure — bridge pauses, wrapper depegs, chain reorgs. In an intent flow, the user signs the outcome; the solver owns the path. If the solver can't deliver, collateral is slashed and the user is made whole. The risk has been priced, bonded, and moved off the user's balance sheet.

An intent doesn't eliminate bridges. It delegates them. Solvers still use bridges, messaging protocols, and settlement rails internally — they just do it behind the intent envelope, and the protocol-level standard ERC-7683 formalizes how the intent envelope travels across chains.

Concretely, when a user signs a Base-to-Arbitrum stablecoin intent on a network like Eco Routes, the solver might pick a Hyperlane Route for the messaging layer, use an onchain AMM to cover spot exposure, and settle through a native route for final delivery. The user never sees any of it. The solver chose the path that gives the best execution and put up collateral against the fill.

This changes the bridge from a user-facing product to an internal rail. Bridges still exist, still matter, and still need to be safe. But they are now wholesale infrastructure — solvers integrate them, price them, and abstract them away from the user. Eco's piece on multi-source liquidity networking describes how solvers compose several rails into a single execution path.

The honest answer is that intents shift where the risk lives, not whether it exists. A careful comparison helps.

In a lock-and-mint flow, the user trusts the bridge's validator set for as long as they hold the wrapped asset. A compromise of the validator set compromises every user's wrapped balance. Historical incidents across the industry are well-documented in public post-mortems — most of DeFi's largest losses came from this category.

In an intent flow, the user trusts the collateral and slashing logic for the duration of a single fill — typically seconds. After settlement, the user holds native assets and has no residual exposure. The attack surface is bounded to the in-flight intent, not to an entire liquidity pool. The difference matters: independent security reviews of intent protocols focus on the collateral lifecycle rather than a long-lived validator set, which is a materially tighter scope.

This is a meaningful structural improvement. But it does push complexity into solver economics. Is the collateral sufficient? Is slashing credible? Are failed fills actually refunded atomically? These questions are the new due-diligence list. Eco's guide to intent settlement layers breaks down how different networks answer them, and the short version is: bonded solvers with onchain slashing and transparent reserve accounting are the gold standard.

Ask a DeFi native to bridge tokens and they'll click through a flow that requires wallet approvals, gas on the destination chain, a bridge-specific receipt page, and a manual check that the funds arrived. Ask the same person to sign an intent and they'll sign once. The solver handles gas on both ends, the settlement confirms into the destination address, and the receipt is just an onchain transaction.

For stablecoin flows specifically, swapping across chains in 2026 looks nothing like it did two years ago. A single signed intent replaces a bridge, a swap, and often a gas top-up. For teams that need it, the same primitive scales to OTC sizes via RFQ solvers — see the institutional stablecoin RFQ coverage for how that composes with the retail flow.

The UX win is not that intents are prettier. It's that they collapse a multi-step workflow into a single signature without changing the user's security posture. That's rare in DeFi. The ERC-7683 specification formalizes the signed intent format, which means signatures from one wallet should verify consistently across every intent-aware network — portability that bridges never had.

Lock-and-mint isn't going away. Two use cases keep it alive.

First, canonical asset issuance. When a chain wants to host a native-feeling version of USDC, USDT, or ETH, the underlying mechanism is still lock-and-mint — just with the issuer's blessing. The difference is that the wrapper has a real backstop. Circle's Cross-Chain Transfer Protocol is a clean example — burn on source, mint on destination, no wrapper risk because the issuer controls both ends.

Second, long-tail assets. An intent flow needs a solver willing to price and fill the intent. For a stablecoin across 15 chains, that market exists. For a long-tail token, it often doesn't — so lock-and-mint remains the fallback. Eco's guide to crypto bridges compared is a useful reference for teams still evaluating wholesale rails for their specific asset set.

For mainstream stablecoin flows — which is the vast majority of cross-chain volume — lock-and-mint as a user-facing primitive is done. The intent layer is the new default.

If you're a developer evaluating the shift, the right question is not "intents vs bridges" in the abstract. It's "what does my integration look like under each model?"

Under lock-and-mint, you integrate a bridge per destination chain, maintain a routing table, monitor each bridge's liveness, and build custom refund flows for when something stalls. You also make security decisions on behalf of your users every time you pick a bridge.

Under intent-based routing, you integrate an execution layer once. You write code that signs intents and reads settlement events. The protocol handles solver selection, bridge choice, and failure handling. Eco's Routes product overview covers what that integration surface actually looks like, and the walkthrough for publishing your first intent is about as compressed as the code gets.

This is not a marketing pitch for one vendor — it's the structural pattern. Whether you use Eco, a competing intent protocol, or roll your own, the integration shape is the same: one interface, signed outcomes, solver-managed execution.

One of the more interesting recent developments is how agent frameworks and treasury backends are adopting intents as their cross-chain primitive. An AI agent that needs to pay a vendor on Polygon from a USDC reserve on Base can't sensibly pick a bridge — the agent doesn't have opinions about message-passing topologies. But the agent can sign an intent. The intent model gives the agent a deterministic interface: inputs, outputs, deadline. Eco's pieces on AI agents for stablecoin treasury and cross-chain agentic payments describe how this composes with broader agent frameworks.

The same logic applies to backend services. A payroll runner, a vendor-payout engine, or a rebalancer all need a clean API surface to cross chains. Under lock-and-mint, each service has to manage a router, a bridge, and refund logic. Under intents, the service issues signed messages and reads settlement events — a much cleaner internal contract. The Eco developer documentation walks through the integration surface for both patterns.

Imagine a treasury team that holds USDC across Ethereum, Arbitrum, Base, and Optimism, and needs to consolidate to one chain for a monthly accounting close. Under lock-and-mint, this is a four-bridge operation. Each bridge has its own approval, gas requirements, timing, and receipt. The team's engineer babysits the run, handles three refund flows that trigger because a bridge paused mid-operation, and files a reconciliation ticket.

Under intent-based routing, the team signs four intents. Solvers pick up the orders, settle atomically, and the consolidated balance lands on the target chain within minutes. The reconciliation ticket is one onchain event log. Eco's writeup on stablecoin treasury netting and the broader treasury orchestration problem both build out what this looks like at scale.

The scenario generalizes. Any workflow that involves multiple cross-chain steps is a candidate for intent collapse. Payroll, vendor payouts, liquidity rebalancing, agent-driven settlement — all of them read cleaner under an intent model than under a stack of bridges.

What's the core difference between intents and bridges? Bridges are a lock-and-mint mechanism: users deposit assets on one chain and receive wrapped representations on another. Intents are signed outcomes: users specify what they want and a solver network competes to deliver it atomically, with collateral backing the fill.

Are intents more secure than bridges? Intents shrink the trust window to seconds and bound the user's exposure to a single in-flight transaction. Bridges require ongoing trust in a validator set for as long as users hold wrapped assets. Both models need careful implementation, but intents structurally reduce long-lived attack surface.

Do intents eliminate bridges entirely? No — solvers still use bridges internally for messaging and settlement. What changes is that bridges become wholesale infrastructure hidden behind the intent envelope, instead of a user-facing product with its own UX and failure modes.

What about gas on the destination chain? Under intent-based execution, the solver pays destination gas and prices it into the quote. The user signs once on the source chain and receives native assets on the destination chain without needing a separate gas top-up. This is part of why intent flows feel simpler.

When should I still use lock-and-mint? Canonical asset issuance (where the token issuer controls both ends, like CCTP) and long-tail assets with no solver market. For mainstream stablecoin flows, intent-based execution is the better default.