Intent-Based Swap vs Bridges: How Modern Cross-Chain Actually Works

Every cross-chain product runs one (or a blend) of four mechanisms beneath it. In one sentence each:

• Lock-and-mint — the original asset is locked in a custody contract on the source chain and a wrapped 1:1 IOU is minted on the destination chain; reverse the flow by burning the wrapper to unlock the original.
• Burn-and-mint (canonical) — the asset's own minting authority (an issuer like Circle, or a rollup's official bridge) burns the token on the source chain and re-mints the genuine native asset on the destination, with no third-party wrapper.
• Liquidity network — native assets are pre-funded in pools on both chains; you deposit into the source pool and receive the real native asset out of the destination pool, no IOU minted.
• Intent-based — you sign a desired outcome ("give me at least X of token Y on chain Z"), and competing solvers bid to fill it, advancing the destination asset from their own inventory.

The single most useful literacy fact: only lock-and-mint always creates a wrapped token. Burn-and-mint canonical rails, liquidity networks, and intent swaps all hand you the native or canonical asset. That one distinction changes who you're trusting and what an attacker can steal. Everything below expands each mechanism; the comparison table puts them side by side. (All figures sampled 2026-06-26.)

Lock-and-mint is the classic bridge and the source of every "wrapped" token you've seen. The original asset is escrowed in a custody contract on the source chain, and an equal amount of a synthetic representation is minted on the destination chain. The supply of the wrapped token equals the locked collateral, so the wrapper is an IOU redeemable against the reserve.

The canonical example is WBTC. You send BTC to a merchant, the merchant asks the custodian (BitGo) to lock the BTC, and an equivalent amount of WBTC (an ERC-20) is minted on Ethereum; redemption burns the WBTC and releases the BTC. Governance runs through a wBTC DAO multisig. That means WBTC carries explicit BitGo counterparty risk — the wrapper is only as sound as the entity holding the lock. The same pattern produces "wrapped ETH" on non-Ethereum chains through third-party bridges such as Portal / Wormhole minting wETH on Solana.

Who holds the lock varies by design and defines the trust model: a centralized custodian or multisig (WBTC), an MPC key set (Multichain used MPC nodes), a validator or guardian signature set (Wormhole guardians), or — rarely — a light client with native validation. Whatever the design, the locked reserve is a single concentrated pool of value. That is the honeypot: compromise the lock authority (its keys, its signatures, or the contract itself) and an attacker can mint unbacked wrappers or drain the reserve. This is exactly the class of failure covered in the bridge-hacks section. When you hold WBTC or a bridged wETH, your real question is "who can move the lock, and is the reserve auditable?" — which is the same custody question the custodial vs non-custodial guide works through for swaps.

Burn-and-mint looks superficially like lock-and-mint — a token disappears on one side and appears on the other — but the minting authority is different, and that difference is the whole point. Here the asset's own issuer, or a chain's official bridge, does the minting. No independent third party creates a branded IOU.

Circle CCTP is the cleanest case. You burn USDC in the CCTP contract on the source chain (irreversible and on-chain verifiable); Circle's attestation service observes the burn and issues a signed attestation authorizing an equal mint; that attestation is submitted to the destination CCTP contract, which mints native USDC. There is no liquidity pool, no third-party filler, and no wrapper — the USDC you receive is fungible with regular Circle issuance. CCTP V2 is the canonical rail across 13+ chains (Ethereum, Base, Arbitrum, Optimism, Polygon PoS, Avalanche, Solana, Sui) as of Q2 2026 (sampled 2026-06-26).

This is the literacy point most guides miss: canonical USDC (via CCTP) is not the same asset as third-party bridged USDC (e.g. USDC.e). The bridged version is an IOU that is only as good as the bridge that minted it and is not interchangeable with native issuance. The same split appears with rollups: an Arbitrum, Optimism, or Base official bridge locks your ETH on L1 and credits the canonical L2 representation (deposits land in roughly 10-15 minutes), but withdrawing L2->L1 must wait through the ~7-day optimistic-rollup fraud-proof window before the L1 escrow releases. Canonical rails trade speed for correctness and fungibility — the right tool when the asset has an issuer-run rail. If you're choosing which USDT network to end up on rather than which USDC rail to use, the USDT network decision guide covers that split, and moving USDT ERC20 to TRC20 is a different problem than a CCTP mint entirely.

A liquidity network skips minting entirely. Native assets are pre-funded into pools on both (or all) chains by liquidity providers. You deposit the native asset into the source pool and receive the native asset out of the destination pool — you get the real destination-chain token from existing inventory, not a wrapper. (Some designs, like Hop, route through an internal canonical h-token, but your final output is still the native asset via an AMM swap.)

Slippage on these bridges comes from pool imbalance. A large transfer draws down the destination pool relative to the source, and AMM or bonding-curve pricing charges more as the pool empties. Independent per-chain pools (Hop-style) hit high slippage on large trades; unified-liquidity designs like Stargate (LayerZero) use a Delta algorithm with soft partitions to share and rebalance liquidity across chains and price large transfers more tightly. As a directional figure, a $1M USDC transfer via Stargate can pay roughly 15-50 bps in pool-imbalance fees (secondary-source estimate, sampled 2026-06-26). LP economics are the flip side: LPs deposit native assets and earn per-transfer fees, which is where a chunk of your cost goes — the same spread-and-fee stack broken down in the 5-layer fee stack guide.

Across shows how blurry the line has become. It uses single-sided pools plus bonded relayers plus a UMA optimistic oracle, models its capital fee on Aave lending rates (roughly the interest on a ~7-day loan of the asset), and markets itself as slippage-free with fills typically in 1-2 minutes. Crucially, Across frames each deposit as a user intent filled by competing relayers who supply destination liquidity from inventory and get reimbursed after an optimistic ~1-hour dispute window — which is the intent model built on a liquidity-network base. Hop, by contrast, has shrunk to a small-transfer niche (TVL reportedly ~$3M by 2026, sampled 2026-06-26).

The intent model inverts the usual flow. Instead of signing a specific execution path, you sign a desired outcome: "I want at least amount_out of token Y on chain Z." A network of solvers (also called relayers or fillers) competes to satisfy that intent. The winning solver delivers the destination asset to you up front, out of its own inventory, and is later reimbursed from your deposited source funds after settlement. Because the solver committed to a fixed amount_out, the solver — not you — absorbs execution slippage and short-term price drift. You either receive the signed amount or, on non-fill, get your deposit refunded.

Concretely, NEAR Intents (1Click) works like this: the Solver Bus forwards your quote request to all connected solvers and waits up to 3000ms (~3 seconds), then returns every available quote. Each quote carries a quote_hash, the assets and amounts, and a min_deadline_ms — the minimum time the solver must honor its offer, default 60,000ms (1 minute). The docs note that a shorter min_deadline_ms can yield a better price, because the solver is exposed to less price-drift risk while its quote stands. You accept a quote, sign the intent referencing its quote_hash, and an on-chain NEAR Verifier contract verifies and settles (status runs PENDING -> TX_BROADCASTED -> SETTLED). Relay is the sibling relayer/intent model: a relayer advances capital on the destination immediately, then rebalances in the background; funds flow through a non-upgradable Depository contract, and only a registered Allocator can authorize withdrawals, each tagged with a nonce and expiration. Relay's permit validity defaults to ~600s (10 minutes) per its /quote API (this exact value appears in API search results but was not confirmed verbatim on the primary Depository docs — treat as indicative, sampled 2026-06-26).

Because the solver delivers the native or canonical asset from inventory, no wrapped IOU is minted and there is no shared locked-collateral reserve. A solver may internally rebalance using canonical rails like CCTP, but that is invisible to your outcome. This is exactly the model UpSwap rides — it aggregates NEAR Intents and Relay (the intent + relayer rails) behind a non-custodial deposit-address flow, so it inherits the solver-fill attack surface rather than a locked reserve. Its coverage spans 24+ chains, 111+ tokens, 166 chain-token combinations. If a swap stalls between the deposit and the fill, the failure modes are the ones in the stuck-pending troubleshooting guide — and note that neither intents nor bridges can undo an address you typed wrong yourself, which the wrong-network recovery matrix and the address-poisoning guide both stress. Popular intent-routed pairs include ETH to SOL and BTC to ETH, where no single canonical rail exists.

Read down the columns for a single mechanism, or across a row to compare on one axis. Every cell reflects the fact pack sampled 2026-06-26.

One extra dimension worth naming: honeypot size. A lock-mint reserve grows with adoption and becomes a bigger target over time; a liquidity network's pooled LP funds are a standing target sized to volume; the intent model keeps value transient in solver inventory and short-lived escrow, so there is minimal permanent locked reserve to attack.

Bridges did not get hacked because bridging is inherently reckless; they got hacked because the dominant design — lock-and-mint — concentrates value in one place. Chainalysis attributed roughly $2B stolen across 13 bridge hacks in 2022, about 69% of all crypto stolen that year (sampled 2026-06-26). The named incidents split cleanly into two root-cause classes: key/custody compromise and smart-contract / verification bugs.

Notice what every one of these is: a compromise of the bridge contract or the custody layer holding the locked reserve. That is a fundamentally different attack surface than the intent model. In an intent swap there is no large permanent reserve to drain — value is transient in solver inventory and short-lived escrow. The realistic worst case for a user is solver non-fill, which triggers a refund, not a silent loss of custodied funds. Where those funds sit during a failed swap, and whether you can recover them, is exactly the terrain of the custody-and-failure guide.

Cross-chain literacy is only half the safety picture; the other half is knowing who to trust when something goes wrong. Before you act on any "support" contact, read this — support impersonation drains more funds than most protocol bugs.

This matters because the intent + relayer model UpSwap rides is non-custodial: nobody at UpSwap can move your funds, reverse a transfer, or "unlock" a swap for you, so any "support agent" offering to do that is a scam by construction. For real self-service recovery paths, the stuck-pending troubleshooting guide and the custody-and-failure guide cover where funds sit and what you can actually do, and if the cost math is your question rather than the mechanism, the Binance-withdrawal vs cross-chain-swap break-even matrix lays out the trade-off. For reference, UpSwap's coverage spans 24+ chains, 111+ tokens, and 166 chain-token combinations across the intent and relayer rails it aggregates.