An intent is an order that says what you want to end up with, not which transactions to send. You sign it, a competitive set of solvers bids to deliver the outcome, and a settlement layer pays whoever did. That shifts routing, gas and cross-chain waiting off the user and onto a professional counterparty, and it introduces a different set of questions: who is allowed to bid, what they are measured against, what backs their promise, and what happens to your money when nobody bids at all.
Declarative orders: what an intent actually is
A normal transaction is imperative. It names the contract, the function, the arguments and the gas, and signing it authorises exactly one computational path against a given state. Everything is decided before you sign, and everything that was not anticipated is your problem.
An intent is declarative. It is a signed set of constraints describing the outcome you will accept, and it permits any execution path that satisfies them. A transaction says "do A then B, pay exactly C to get X"; an intent says "I want X and I am willing to pay up to C". Read that way, a transaction is the special case of an intent that allows exactly one state transition.
The practical consequence is that by signing and sharing an intent, you grant a third party permission to choose the computational path on your behalf. That is where the convenience comes from, and it is also where every risk in this article comes from.
None of this is new in kind. Limit orders, paying fees in a token you already hold, and aggregators that promise the best route across several venues are all intent-shaped: the user states a condition and someone else picks the execution. What is new is that this is being built as general infrastructure, and that one order can span several chains.
The four roles in an intent system
Written out as a lifecycle, the pattern has four parts. A user expresses an intent to an application; the application turns it into an order for a specific protocol; the order goes to an order feed where solvers can see it; a solver evaluates it, executes the required steps, and a settlement process pays the solver.
The vocabulary is worth learning, because it is now written into a standard. An order is an offer of payment in exchange for the fulfilment of a set of requirements. A solver, also called a filler, is the actor that fulfils those requirements. Payment closes the loop: the solver does the work first and is paid at settlement.
The standard in question is ERC-7683, Cross Chain Intents. It is a Standards Track ERC, created in April 2024, and at the time of writing it is still at Draft status. It has also been reworked substantially: an earlier draft standardised order encoding, an on-chain order feed, escrow and the fill function, while the current text standardises only the interface through which a solver reads an order, leaving each protocol free on order creation, authorisation, pricing and settlement. It builds on ERC-7930, the interoperable address format, which sits at Review.
Draft status matters more here than it does elsewhere, because this is not the only proposal in the area: ERC-7521 covers general intents for smart contract wallets and is also a draft. Treat none of it as settled. Each ERC carries a status field at the top of its page in the Ethereum ERCs repository, and the live discussion sits in the Ethereum Magicians thread it points to, so check the current stage yourself.
Why the solver fronts the money
Underneath cross-chain intents sits an awkward fact: two chains do not settle atomically, so somebody has to move first. In the common design the user's funds are locked in a contract on the origin chain when the order is created, so that the solver has assurance the money exists before committing its own capital on the far side.
The solver then delivers the outcome out of its own inventory: it holds the destination asset, sends it to you, and is only reimbursed later out of the locked funds through the settlement process. In one production design fills are aggregated into batches and repaid on a cycle measured in hours rather than seconds, which is why a solver needs working capital and not just a fast bot.
The solver also sends the transactions, which means it pays the gas. That is the mechanism behind intent flows advertised as gasless: the cost has not disappeared, it has moved into the price the solver quotes you.
The gap between spending and being paid is exactly where solver risk lives. The standard's own security section puts it plainly: a solver is exposed from the moment it commits capital, approvals or transactions until its expected payment is final and spendable. Everything that can go wrong in that window, from chain reorganisations to message delivery to a protocol changing state, is already priced into the quote you see.
How competition decides the price you get
Because the user has stopped specifying the route, the price has to be produced by competition instead. Designs differ in how: some run Dutch auctions where the level a solver must beat moves over time, some take the price from an oracle, some fix the fee and let solvers compete on speed alone.
Batch auctions are the most explicit version. Orders are collected over a short window, solvers submit complete solutions, each solution is scored roughly by how much surplus it produces for the users in the batch, and the highest-scoring solution wins. Winners are paid under a second-price rule, so the reward is tied to the margin over the next-best bid rather than to whatever the winner claimed.
Competition only helps if there is a benchmark. One published rule set requires that a solver's prices be no worse than what the user would have got from a defined list of baseline liquidity sources, and requires uniform clearing prices: two orders on the same pair in the same direction must receive the same price. Without something like that, best execution means whatever the winning solver says it means.
This is also the honest answer to why intents can beat manual routing. A solver can net your order against another user's opposite order, pack several fills into one transaction, and pick the repayment chain that costs it least. Those savings are real, but they reach you only to the extent that the competition and the scoring rule force them out.
What actually backs the solver's promise
Signing an intent hands someone latitude. What stops abuse is not the signature, it is the accountability layer built around the solver set, and that layer differs in every system, which is the part most explanations skip.
The first control is usually entry. In one published rule set a solver has to be on a whitelist before it can submit a settlement at all; the operators run monitoring that inspects every on-chain settlement and flags suspicious ones; systematic rule-breaking can be penalised, up to slashing.
The second control is verification with a challenge window. Rather than proving every fill on-chain, one settlement design lets an actor propose a batch of results together with a bond, and the batch is accepted if nobody disputes it within a fixed period. The user gets speed first; the proof comes afterwards.
The third control is the trust boundary itself, and the standard is unusually blunt about where it stops. ERC-7683 standardises how an order is described to solvers; it does not standardise or guarantee the security of the protocol that ultimately settles it. Solvers are expected to vet the contract that translates orders for them and to validate the assumptions that contract cannot check itself. To the user, the standard promises nothing about the settlement system underneath.
Concentration, censorship and the path back to your funds
The structural risk of the intent model is that the set of parties able to see and fill your order gets small. If access to intent flow is permissioned and the list is chosen carelessly, order flow concentrates, and a party controlling a large share of it is in a position to extract rents and, at the extreme, to censor.
Open propagation does not fix this on its own. A node that can profitably execute an intent has no incentive to forward it to competitors, and a fully public intent pool exposes orders to the same extraction that a public mempool does. That is why so many systems land on permissioned or hybrid designs, and why the practical question is not whether it is decentralised but who is on the list and who decides.
The related cost is opacity. In the worst version you sign something, it disappears, and it reappears as a transaction with no visible account of who built it or which alternatives were rejected. Execution quality you cannot audit is execution quality you are taking on trust.
Then there is the plain failure case, which is more common than the exotic ones: nobody bids. Orders carry a fill deadline. If it passes with no fill and no partial fill, the order expires and the locked funds go back, usually to the address named on the order and, by default, on the origin chain. The causes are mundane: an unusually large size, an odd token pair, or solvers briefly offline.
What that refund is not is instant. Because the money comes back through the same batched settlement process that pays solvers, a normal fill takes seconds while an expiry can take hours to unwind. When you are sizing an order or building a product on top of one, the fill deadline and the refund path are the two parameters worth reading before the fee.
The bottom line
Intents move the work of execution from the user to a bidder: you sign the outcome you want, solvers compete to deliver it, they front the capital and the gas, and a settlement layer pays whoever performed. The efficiency is real and so is the trade, because you are handing a third party discretion over how your order is executed, and what protects you is not the signature but the auction rules, the benchmark those bids are scored against, the entry rules and monitoring around the solver set, and the deadline that returns your funds when nobody bids. The cross-chain order standard, ERC-7683, is still a draft and has already been redesigned once, so treat any description of it, including this one, as a snapshot and check its status field before you build on it.
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of August 2026; refer to the latest official information.
References
[1] ERC-7683: Cross Chain Intents eips.ethereum.org
[2] ERC-7930: Interoperable Addresses eips.ethereum.org
[3] ERC-7521: General Intents for Smart Contract Wallets eips.ethereum.org
[4] Intent-Based Architecture and Their Risks paradigm.xyz
[5] What are Crosschain Intents? docs.across.to
[6] Intent Lifecycle in Across docs.across.to
[7] Refunds docs.across.to
[8] Solver competition rules docs.cow.fi
