You want to swap your ETH on Arbitrum for USDC on Base. With a traditional DeFi workflow, that means: bridge ETH to Base, pay gas twice, approve a router contract, swap, and hope nothing fails mid-route. Then a protocol asks you to sign a single message and promises to handle the rest. You do not approve any contracts. You pay no gas upfront. Two minutes later, 1,024 USDC lands in your Base wallet.
What you just used was an intent. And understanding why that works — and why it is safer than it sounds — is the conceptual foundation for everything this series covers.
What Makes a Transaction Different From an Intent
A traditional blockchain transaction is imperative. When you execute a swap on Uniswap v2 directly, you are specifying the exact execution path: approve this ERC-20, call this specific router contract address, swap on this specific liquidity pool. The chain executes those instructions verbatim, or the whole thing reverts. You chose the route, the pool, and the gas price. The outcome depends entirely on your choices being correct at the moment of execution.
An intent is declarative. It specifies a desired outcome and leaves the execution path completely open. In our example: "I want to receive at least 1,000 USDC on Base, paying with my ETH on Arbitrum, before this deadline." Nothing about which DEX, which bridge, which intermediate token, or which route. The intent says what you want, not how to get it.
The user never crafts a blockchain transaction when using an intent-based system. Instead, they sign an off-chain typed message — structured data that encodes order parameters: input asset, output asset, minimum acceptable output, expiry deadline. Because this signed message is never broadcast to the chain's public mempool, the user pays no gas at submission time.
A useful analogy: a stock limit order says "sell 10 shares at no less than $50" without specifying which buyer. An intent says "give me at least 1,000 USDC" without specifying which DEX, bridge, or route.
One important distinction worth making early: this is not the same as ERC-4337 UserOperation architecture. A UserOperation (the core primitive in ERC-4337) is an account-abstraction mechanism that lets a smart account vs an EOA pay gas in different ways and batch operations — but it still specifies the execution path. An intent abstracts the path entirely, delegating route selection to a competitive third party called a solver.
The Intent Lifecycle: Sign, Compete, Fill, Settle
Understanding how an intent travels from your wallet to on-chain settlement clarifies both why the model works and where it can fail.
-
User signs. You sign a structured off-chain order specifying input token and chain, output token and chain, minimum output amount, and an expiry deadline. This signature is your only required action.
-
Order dissemination. The signed order is broadcast to an off-chain order book or intent mempool where solvers — also called "fillers" in UniswapX, "resolvers" in 1inch Fusion, "solvers" in CoW Protocol — are listening.
-
Solver competition. Solvers analyse the order, calculate optimal execution paths across DEXs, liquidity pools, and bridges, and compete to fill it. Two common auction mechanisms shape this competition. In a Dutch auction (used by UniswapX), the offered price decays from an expensive ceiling to a floor until the first solver accepts it. In a batch auction (used by CoW Protocol, which exploits coincidence of wants — matching offsetting orders directly before routing the remainder), orders are collected for roughly 30 seconds and auctioned to the best solver as a bundle.
-
On-chain settlement. The winning solver executes all required on-chain steps — swapping, bridging, routing across multiple protocols — entirely at their own cost and risk.
-
Verification and payout. The settlement contract on the destination chain verifies that you received no less than the promised minimum output. Only upon that verification does the contract release payment to the solver. If you did not receive the promised output, the solver is not paid.
If no solver fills the order before the intent expiry, the intent simply expires. Nothing happens on-chain. Your funds were never locked, so they are never at risk.
The Key Actors and Their Incentives
You, the user, want the best available rate with minimal friction — no gas token management on every chain you touch, no multi-step approve-bridge-swap sequences, no manual routing decisions.
The solver (or filler, or resolver) is a professional market participant — in practice often a well-capitalised market maker or trading firm — that maintains liquidity inventory across chains, monitors intent order books, and competes to fill orders profitably. Their margin is the spread between what they pay to source your output and what they receive from the settlement contract.
Critically, solvers absorb three categories of risk that previously fell on you: execution risk (the on-chain transaction could revert), inventory risk (they must pre-position liquidity on destination chains before any order arrives), and MEV exposure (they manage their own execution against front-running bots rather than exposing your transaction to the public mempool).
This matters because the historic alternative — bridging manually and swapping on an AMM — meant you bore all of these risks yourself. If you understand wallets, gas, and token approvals, you already know how much friction this involves: you need gas tokens on every chain, and a failed mid-route transaction can leave assets stranded.
The settlement contract is the trust anchor. It custodies user deposits, enforces the payment condition, and releases solver compensation only upon verified delivery. Your security model reduces to trusting this contract's code — not any individual solver.
A concentration reality worth noting: as of early 2025, UniswapX's top two fillers accounted for over 90% of volume. Solver centralisation is an active concern. ERC-7683, co-authored by Uniswap Labs and Across and introduced in 2024, addresses this by defining a shared cross-chain order interface so solvers can operate across multiple intent protocols without fragmented, protocol-specific integrations — widening the competitive field over time.
Why Intents Emerged: The UX Hostility of Manual DeFi
Moving assets across chains today without intents requires: holding the native gas token on every chain you touch, executing a multi-step approval → swap → bridge → swap sequence, tolerating slippage at each hop, and risking a failed transaction at any step that leaves funds stranded mid-route. MEV bots surveilling the public mempool routinely sandwich user transactions — front-running buys and back-running sells to extract value directly from the user's execution.
Intents compress all of that to a single signature. The solver, not the user, worries about gas on the destination chain, optimal routing, slippage at each intermediate step, and MEV exposure. This design builds on the logic of off-chain RFQ (request-for-quote) systems long used by professional market makers, but extends the model to arbitrary user-specified outcomes rather than just price quotes.
CoW Protocol passed $10 billion in monthly volume in 2025, and the broader intent-based category — UniswapX, CoW Swap, 1inch Fusion, Across — collectively processes tens of billions of dollars monthly. The model is well past proof-of-concept. Part 2 of this series covers how UniswapX and CoW Swap pioneered the intent model in detail.
The Trust-Model Shift: From Execution Path to Settlement Contract
In traditional DeFi, trust is distributed across many contracts. When you execute a multi-hop swap, you are implicitly trusting the router contract, the specific AMM pool, the bridge contract, and the oracle feeding prices to each. Auditing every step in your transaction's execution path is impractical for most users, as covered in what DeFi actually is.
With intents, trust collapses to a single point: the settlement contract that enforces "the solver only gets paid if you received what you asked for." Which DEXs, which bridges, which routes the solver used — these become irrelevant to your security model.
This is a meaningful improvement for most users, but it introduces a new concentrated risk: if the settlement contract has a vulnerability, the entire system's security breaks. The contract's code quality and audit history matter more than any individual solver's behaviour.
Solvers absorb MEV exposure during their own execution, but they can also extract value indirectly — by bidding slightly less competitively than possible, pocketing a larger spread. Robust solver competition is the market mechanism that limits this. When solver concentration is high, this check weakens.
One final risk worth understanding now: signing an intent is signing a financial order with real economic authority. If a user is tricked into signing a malicious intent via a phishing site that mimics a legitimate protocol, an attacker acting as a "solver" can fill it in a way that extracts the user's funds within the parameters of the signed message.
Risks to Understand Before You Use an Intent-Based Protocol
Solver centralisation. Barriers to entry — large inventory capital, low-latency infrastructure, technical complexity — favour a small number of professional solvers. In a concentrated market, solvers could collude on pricing, selectively censor intents, or extract hidden fees through spread manipulation. ERC-7683 is designed to reduce this risk over time, but it has not yet been eliminated.
Settlement contract risk. Your entire security model rests on the settlement contract's correctness. A bug could allow a solver to claim payment without delivering the promised output, or allow funds to be drained entirely. Always verify that a settlement contract has been audited before using a protocol.
Signature and approval risk. Signing an intent is signing a financial order. Phishing sites that mimic intent-based protocols can present forged order parameters. Always verify the exact input token, output token, minimum amount, and expiry before signing — and never sign an intent on an unverified website.
Liquidity exhaustion attacks. Researchers have identified attack vectors specific to intent-based cross-chain bridges where adversaries deliberately drain solver liquidity to prevent legitimate orders from being filled.
Non-fulfilment and censorship. If no solver deems an order profitable — because the asset is illiquid, the order size is too small, or the deadline too tight — the intent expires unfilled. Unlike an on-chain AMM swap, which executes deterministically if submitted with sufficient gas, there is no guarantee of execution.
Off-chain opacity. The matching and routing process happens off-chain. Unlike a transparent AMM where every execution step is publicly auditable on-chain, intent execution paths are only visible after settlement.
Key Takeaways
- An intent is a signed declaration of a desired outcome, not a step-by-step execution instruction. The user signs once; a competitive solver handles all on-chain plumbing.
- The settlement contract is the only trust anchor. It enforces payment to the solver only if the user received the promised output. Audit its code before you use the protocol.
- Solvers absorb execution risk, inventory risk, and MEV exposure — but they are not altruists. Robust solver competition, not individual goodwill, keeps pricing honest.
- Intent expiry protects you: if no solver fills before the deadline, nothing happens on-chain and your funds remain untouched.
- The main risks are solver centralisation, settlement contract bugs, and phishing attacks that trick you into signing a malicious order. Verify every parameter before signing.
Part 2 of this series examines how UniswapX and CoW Swap pioneered the intent model and how the mechanics described here play out across the two most influential intent protocols today.
