Cross-Chain Intent Swaps: How ERC-7683 Changed Execution
ERC-7683 standardized cross-chain intent orders so solvers compete to fill them. Here's how it differs from bridges and what to check before signing.
ERC-7683 — the cross-chain intents standard co-authored by Uniswap Labs and Across Protocol — went from a draft specification to carrying 88% of Across's production volume within nine months of its final release. The shift matters for any user who swaps assets across chains. Traditional bridge flows require a user to interact with one protocol to move funds, then a second to swap them on the destination chain. Intent-based protocols collapse that into a single signed order, with competing solvers handling the execution mechanics. The result is fewer steps, harder-to-exploit execution, and in many cases, lower total cost.
What Traditional Bridge Swaps Actually Do
When you want to move ETH from Arbitrum to Base through a conventional bridge, the execution chain has several mandatory steps. You deposit ETH into the bridge contract on the source chain. A relayer or validator network detects that deposit and issues a corresponding token on the destination chain — either a wrapped version or a burn-and-mint equivalent. If you need a different token on the destination, you swap on arrival, paying a second set of fees at the destination.
Each step adds cost, latency, and risk. Bridge contracts hold one of the largest concentrations of locked value in DeFi, and message verification logic has historically been where critical vulnerabilities emerge. In 2026, three of the four largest DeFi hacks targeted cross-chain bridge infrastructure — the mechanics behind those failures are covered in DeFi Bridge Exploits.
Wrapped tokens introduce a second layer of exposure. A user holding WBTC or cirBTC on Ethereum holds a claim backed by the issuer's custody and smart contracts, not native Bitcoin. The underlying asset is controlled by a separate entity, and the wrapped token may not be redeemable on every chain where it circulates.
The conventional model works at scale — over $10 billion in wrapped BTC currently circulates across Ethereum. But it requires trusting the bridge and the wrapper issuer separately, and the execution flow spans multiple protocol interactions rather than one.
How Cross-Chain Intent Protocols Work
Intent-based execution replaces sequential protocol interactions with a single signed order. The user signs a message stating the desired outcome: "I have 1 ETH on Arbitrum and want at least 150 USDC on Base, settled within 30 minutes." This order goes to a solver network, not a bridge contract.
A solver is a competitive market participant who evaluates whether they can fill that outcome profitably. If a solver already holds USDC inventory on Base, they can pay out to the user immediately and settle the incoming ETH on Arbitrum separately — often using their own capital or a fast liquidity facility. The user receives funds on the destination chain in seconds, without waiting for a cross-chain message to be relayed and verified.
Three mechanics define how intent protocols execute:
- Solver competition: multiple solvers bid to fill the same order. The protocol selects the solver offering the best execution output, which drives settlement closer to fair value than a single-path bridge route can.
- Optimistic settlement: the solver pays the user first and handles cross-chain accounting in the background. This inverts the bridge model, which requires the source-side lock to confirm before the destination pays out.
- Fill-or-fail guarantee: if no solver fills the order before the deadline, the user's funds return without loss. An unfilled intent does not leave assets stranded in a bridge contract waiting on a stalled relayer.
The key difference from a bridge is who bears the settlement complexity. A bridge puts the user in the critical path — they wait for message verification. An intent protocol puts the solver in that path. The user's experience ends at destination receipt.
What ERC-7683 Standardized
Before ERC-7683, every intent protocol defined its own order format. An Across solver could not fill a UniswapX order. A CoW Protocol solver had no way to handle Across-formatted intents. Each system required separate solver infrastructure, which fragmented liquidity across protocol boundaries and limited competition on any given order.
ERC-7683 defines a shared CrossChainOrder struct: a standardized encoding for origin chain, destination chain, input token, output token, and settlement deadline. Protocols that conform to the specification can interoperate at the order level. A solver built to fill ERC-7683 orders can participate in any compliant network without building protocol-specific routing logic from scratch.
As of early 2026, the major protocols have all shipped production-compliant endpoints:
| Protocol | Role | ERC-7683 Status |
|---|---|---|
| Across | Settlement and bridging layer | 88% of total volume on ERC-7683 orders |
| UniswapX | DEX swap execution | Cross-chain orders use CrossChainOrder struct |
| CoW Protocol | Batch auction settlement | Production endpoint live |
| Eco | Cross-chain wallet routing | Native ERC-7683 from initial release |
Wallets including MetaMask, Rabby, Safe, and Argent have added signing support. On the L2 side, Arbitrum, Optimism, Polygon, zkSync, Linea, and Base committed to the Open Intents Framework, which uses ERC-7683 as its order format.
The standard shifts solver economics toward the user. When solvers can fill orders across networks without rebuilding per-protocol routing logic, more solvers participate in any given auction. More competition on an individual order typically produces better output than a fragmented system where each protocol gates its own solver pool.
One friction remains at the solver level: a solver capable of filling Across orders is not automatically capable of filling UniswapX orders, even with a shared format. Solvers still maintain separate inventory positions, gas models, and chain-specific liquidity. The standard solves order portability; it has not yet fully eliminated solver fragmentation.
What to Check Before Signing a Cross-Chain Swap
The user-facing experience on intent protocols resembles a standard swap interface: input token, output token, destination chain, and a confirm button. The mechanics underneath differ substantially, and a few fields are worth checking before signing.
Minimum output on the destination chain. This is the floor below which the order will not fill. It should be prominently displayed before signing — not hidden in an advanced panel. If you cannot find it, do not sign. The gap between quoted output and minimum received tells you what the solver network reserves as tolerance. On well-trafficked routes, that gap should be under 0.3%.
Settlement deadline. How long the signed order remains valid. Shorter deadlines reduce the window where a stale order sits against a moved market. Standard defaults run 10 to 30 minutes for most L2 routes. For routes involving Bitcoin, deadlines run longer because on-chain confirmation requires multiple BTC blocks.
Protocol model. Check whether the interface routes through a bridge contract or a solver network. Intent-based fills on ERC-7683-compliant protocols typically settle in 10–60 seconds on L2-to-L2 routes. Native cross-chain swaps through THORChain settle in 3–5 minutes on average for BTC routes, because they await confirmation on both the source and destination L1. Optimistic rollup bridge withdrawals take 7 days without a third-party fast-liquidity service.
Solver execution vs. AMM fallback. Some interfaces show whether a fill came from a solver or routed through an on-chain AMM as a fallback. Solver execution usually produces better output on larger orders because solvers can source liquidity across venues simultaneously, as covered in DEX Limit Orders. A fallback AMM route adds pool-level price impact that the solver path avoids.
Cross-chain intents have reached production scale. ERC-7683 now underpins the majority of non-bridge cross-chain volume across the major settlement protocols, and standard wallet signing support means most users interact with it without knowing it. For anyone swapping between chains, the practical check remains the same regardless of which protocol executes the fill: confirm the minimum output figure on the destination chain before signing. On competitive routes with active solvers, that number should be close to the quoted output. A wide gap is worth investigating before the order goes in. You can swap ETH to BTC natively on Zest, with the minimum received shown before confirmation.