How Do Intents Work in Crypto?

Intents replace step-by-step transaction instructions with a signed statement of the outcome you want. Here is the short version before we go deeper. 

• Intent: A signed message that declares a result ("give me at least 1,000 USDC on Base before 3pm") instead of an execution path. It is usually an EIP-712 signature, not a transaction, so it costs no gas to create.

• Solver: An off-chain actor that reads your intent, finds a route through DEXs, private inventory or its own balance sheet, and competes for the right to fulfill it. In cross-chain systems the same role is often called a filler or relayer.

• Settlement contract: The on-chain referee. It holds your input funds in escrow, checks that the delivered output matches every constraint you signed, and only then pays the solver.

• Competition is the pricing engine: Solvers bid against each other through batch auctions, Dutch auctions, RFQ quotes or a race to fill. The winner is the one who gives you the best result, not the one who is fastest to the mempool.

• MEV protection comes for free: Your order never sits in a public mempool as an executable transaction, so sandwich bots have nothing to front-run. Any execution risk becomes the solver's problem.

• ERC-7683 is the common language: A shared order struct and settlement interface so one signed order can be understood by many solver networks instead of one proprietary API per bridge.

• The main risk is centralization: Order flow concentrating in a few permissioned solvers can recreate the intermediaries that DeFi was built to remove.

An intent is a signed message in which a user declares a desired outcome and the constraints around it, while leaving the execution path open. Compare the two styles: 

• Transaction (imperative): "Call the router at address 0x… , swap exactly 1 ETH through the ETH/USDC 0.05% pool, accept up to 0.5% slippage, deadline in 20 blocks."

• Intent (declarative): "I will give up to 1 ETH. I want at least 3,200 USDC on Arbitrum. Anyone can fill it before 14:00 UTC." 

The second message does not name a pool, a bridge, or a chain hop. It names a result. That single change is what makes everything else in this article possible. 

In practice an intent encodes a small, fixed set of fields: the input asset and chain, the output asset and chain, the recipient, a minimum output or maximum fee, an expiry, and any extra conditions such as allowed solvers or a callback to run after delivery. The user signs it off-chain, so producing an intent is free and instant. Nothing hits a block until someone commits to fulfilling it.

This is closely related to cross-chain intents and to the broader push toward chain abstraction, where the user stops thinking in terms of individual networks at all.

The multichain world broke the old model. A user holding assets on one chain and wanting exposure on another had to choose a bridge, trust it, wait for finality, then swap on arrival, then acquire the destination gas token to do anything at all. Each step was a separate decision, a separate fee, and a separate failure mode. 

Intents matter because they move all of that complexity to actors who are good at it. A solver already holds inventory on twelve chains, already pays gas everywhere, and already runs the routing math thousands of times per minute. Letting it absorb the work is simply a better division of labor. 

The timing is also technical. Signature standards such as EIP-712 made structured off-chain messages safe to display in wallets, account abstraction normalized the idea of a third party paying gas on your behalf, and cheap L2 blockspace made it economical for solvers to fill small orders. The pieces arrived at roughly the same time.

The last reason is MEV. On a traditional DEX your swap is a public, executable transaction sitting in the mempool where searchers can sandwich it. An intent is not executable by itself, so there is nothing to front-run. That matters because sandwich attacks have quietly transferred a large amount of value from ordinary traders to extractors over DeFi's short history.

Four roles appear in almost every intent system, whatever the marketing names. 

The user:

Signs the intent and approves the input token to a settlement contract. That is the entire job. The user takes no gas cost, no routing decision, and no bridge selection risk. 

The solver:

An off-chain agent, usually a professional market maker, MEV searcher or DEX aggregator, that reads incoming intents and calculates whether it can fulfill one profitably. It sources liquidity from AMMs, private inventory, centralized venues or its own treasury. In cross-chain systems the solver often fronts its own capital on the destination chain and gets reimbursed later, which means it is lending you liquidity for a few minutes. Rango's solver networks article goes deeper on how these networks are structured and funded. 

The filler:

In practice, "filler" and "relayer" are the terms used when the actor's job is narrower: take a specific order and deliver the output on the destination chain, without running a full optimization search. ERC-7683 uses "filler" for this reason. When you see "solver" and "filler" used interchangeably, the difference is usually how much routing intelligence the actor applies, not a different position in the pipeline. 

The settlement layer:

One or more smart contracts that escrow the user's input, verify the fill against the signed constraints, and release payment. This is the only trustless component in the whole design, and it is what keeps the solver honest. If the solver disappears, the escrow simply refunds the user after expiry. 

A fifth role appears in some designs: an auctioneer or orderflow coordinator that collects intents, runs the competition, and broadcasts the winner. CoW Protocol's batch auction driver and RFQ hubs are examples.

Here is the full lifecycle of a cross-chain intent, from signature to final reimbursement. 

1. Sign. The user signs a structured off-chain message describing inputs, outputs, recipient, minimum acceptable amount and deadline. No gas, no on-chain footprint.

2. Broadcast. The intent is posted to an intent pool, sent to a permissioned solver set, or routed to specific market makers as an RFQ.

3. Compete. Solvers evaluate it. Depending on the design they submit sealed bids, wait for a Dutch auction price to fall to their reservation level, or simply race to be first on-chain.

4. Fill. The winning solver submits the fill transaction on the destination chain, pays that chain's gas from its own pocket, and delivers the output asset to the recipient. From the user's point of view, the asset just appears.

5. Verify. The settlement contract compares the fill against the signed constraints. Did the recipient receive at least the minimum output? Was it the right token? Was it before the deadline? A fill that misses any constraint is not a valid fill.

6. Settle. The escrowed input on the source chain is released to the solver. In cross-chain designs this step often waits for a message to arrive across a bridge, or for an optimistic challenge window to pass without a dispute.

The user experiences steps 1 through 6 as a single action: sign once, then see the asset arrive. Everything else is infrastructure.

Intent-based systems can structure solver competition in different ways depending on how orders are matched, priced, and executed. The main designs differ in speed, price discovery, solver incentives, and the degree of market-maker participation. 

  The batch auction has one extra property worth calling out: coincidence of wants. When two users in the same batch want opposite sides of the same pair, the solver can match them directly against each other. No pool, no LP fee, no price impact. Whatever cannot be matched peer to peer falls back to on-chain liquidity.

An example makes it concrete. Alice wants to sell 10 ETH for USDC. Bob, in the same 30-second batch, wants to buy 8 ETH with USDC. The solver matches 8 ETH directly between them at a uniform clearing price and routes only the remaining 2 ETH through an AMM. Both get a better price than either would alone. 

The settlement layer is where the trust question is actually answered, and it is worth understanding before you use any intent protocol.

The core guarantee is escrow plus conditional release. Your input tokens are locked by a contract the moment your order is opened. They are released only against proof that the output was delivered exactly as specified. If nothing valid arrives before the deadline, the escrow refunds you. The solver can be slow, unlucky or incompetent, but it cannot take your funds and walk away. 

The harder question is how the source chain learns that the destination fill happened. Three approaches are in use: 

• Optimistic verification:

The solver asserts it filled the order, posts a bond, and is paid after a challenge window during which anyone can dispute the claim with evidence. Cheap, but adds a delay before the solver recovers capital. 

• Message-passing verification:

A canonical bridge or messaging layer relays a proof of the destination fill back to the origin settler. Security inherits from whatever that messaging layer assumes. 

• Native or shared verification:

Rollups sharing a settlement layer, or a dedicated intent chain, can verify the fill without an external bridge at all. 

This distinction matters more than most marketing pages admit. Intents do not remove bridge risk from the system, they move it away from the user and onto the solver, who now carries it in exchange for a fee. A protocol is only as safe as the weakest verification path it settles through.

ERC-7683 exists to make this landscape legible. It defines shared order structs and origin and destination settler interfaces so that any solver can parse an order from any protocol implementing the standard. Notably, it deliberately does not specify how solvers compete or how they get paid. Those are left to the market, which is why competing designs can all be ERC-7683 compatible. The Open Intents Framework builds an open-source reference implementation and solver on top of it. 

Intents are not a free win, and the honest version of this article says so.

Centralization of order flow:

If most intents route through a small permissioned solver set, those solvers become the new intermediaries. They can extract rent, deprioritize certain users, or refuse to adopt competing intent formats that threaten their business. Research from Paradigm flagged this early: moving activity out of the public mempool concentrates power unless the solver set stays genuinely open. 

Opacity:

You see the result, not the path. Without good tooling it is hard to check whether the price you received was actually the best available or merely acceptable within your signed minimum. Your minimum output is your real protection, so set it thoughtfully. 

Solver failure and expiry:

In a race-to-fill design, a period of low liquidity or high volatility can leave your intent unfilled until expiry. You get your funds back, but you also lost the time and the price. 

Inherited bridge assumptions:

As above, cross-chain settlement rides on a messaging layer or an optimistic dispute process. Both have failure modes, and neither is removed by the intent abstraction. 

The mitigations are known: open and permissionless solver registration, standardized formats such as ERC-7683 that lower the barrier to entering the solver market, published surplus data, and conservative user-set constraints.

The category is now broad enough that most people have used an intent system without noticing. 

• CoW Protocol: Same-chain batch auctions with coincidence-of-wants matching and uniform clearing prices, the original MEV-protection-first design.

• UniswapX: Dutch auction orders filled by a competing filler network, with Uniswap pools available as a fallback route.

• 1inch Fusion: The resolver model, extended cross-chain through Fusion+.

• Across: A relayer network that fronts destination liquidity immediately and reconciles back to the source chain through optimistic verification.

• Eco, Aori, Relay, Symbiosis: Various settlement and orchestration layers, mostly converging on ERC-7683 compatibility.

• NEAR Intents and Anoma: Designs that treat intents as a first-class chain-level primitive rather than an application on top of an existing chain.

For Rango, the headline is simple: intents turn cross-chain execution into a single outcome the user asks for, and everything underneath becomes a routing problem. That is the problem we have been solving for years across 70+ chains. Our intents engine auctions each request to a solver network and coordinates the whole outcome end to end, including gasless execution, so a user does not need to hold the destination chain's native token to receive assets there.

Intents are a change in what the user is responsible for. Instead of specifying a path through a fragmented multichain system, you specify a result and let a competitive market of solvers find the path, pay the gas and carry the risk. The settlement contract is what keeps that market honest.

The architecture works because competition prices execution better than any single route ever could, and because escrow makes the solver's failure the solver's problem. The open question is whether the solver market stays open enough to keep delivering on that promise.

• Paradigm: Intent-Based Architectures and Their Risks

• Ethereum ERCs: ERC-7683 Cross Chain Intents Standard

• Open Intents Framework: ERC-7683 reference implementation

• CoW Protocol Documentation: Coincidence of Wants

• CoW DAO: How CoW Protocol Actually Works