ERC-7683 Cross-Chain Intents: Orders, Fillers, Settlement, and Solver Risk
ERC-7683 cross-chain intents provide a common solver-facing language for intent protocols so specialized fillers can evaluate what an order requires, determine what they must execute, understand how they will be paid, and identify assumptions that must hold before committing capital. The current ERC-7683 design is broader and more resolver-centric than many early explanations of the standard. Earlier drafts standardized structures such as GaslessCrossChainOrder, IOriginSettler, IDestinationSettler, open, openFor, and fill. The current draft instead lets protocols keep their own authorization, auction, settlement, and execution models while exposing protocol-specific payloads through a resolver that converts them into common steps, variables, payments, and explicit assumptions. That change makes ERC-7683 more flexible, but it also means users, solvers, auditors, and builders must distinguish what the standard actually guarantees from what remains the responsibility of each underlying intent protocol.
TL;DR
- ERC-7683 is an Ethereum standards proposal for making intent orders understandable to programmable solvers across different protocols.
- As of September 2026, ERC-7683 remains a Draft standard. Its present design is resolver-centric and differs substantially from earlier versions widely described in older documentation and articles.
- An order is an offer of payment in exchange for satisfying a defined set of requirements. Solvers, also called fillers, execute those requirements and expect payment if they fulfill the order correctly.
- The current standard does not force protocols to share one escrow contract, one auction, one settlement mechanism, one user-authorization scheme, or one destination fill function.
- A protocol can expose its order as an opaque payload together with a resolver contract. The resolver translates that protocol-specific payload into a common representation a solver can inspect.
- The resolved representation contains steps, variables, payments, and assumptions rather than the earlier ResolvedCrossChainOrder model centered on maxSpent and minReceived arrays.
- Calls can declare token-spending requirements, gas requirements, timing bounds, dependencies, and revert policies so solvers can reason about execution before committing capital.
- Variables can describe solver payment addresses, payment chains, step callers, execution outputs, off-chain witnesses, contract queries, and event queries.
- ERC-7683 uses ERC-7930 interoperable addresses so the chain context is bound to the address representation rather than relying on a plain 20-byte EVM address alone.
- The standard is designed to help solvers support many intent protocols by reviewing trusted resolver contracts rather than implementing bespoke execution logic for every protocol.
- Gasless cross-chain orders remain possible, but the current ERC-7683 draft no longer standardizes a GaslessCrossChainOrder struct. User authorization is intentionally left to the protocol.
- IOriginSettler and IDestinationSettler were part of an earlier ERC-7683 design. They are useful historical concepts, but they are not the normative interface boundary in the current draft.
- The conceptual lifecycle can still be described as create or open, resolve, execute or fill, verify, and settle, but only the solver-facing resolution model is standardized by the current ERC.
- Resolver security is critical. A resolver is expected to validate the payload and guarantee that a correctly acting solver can satisfy the declared requirements and receive payment, except for assumptions the resolver explicitly exposes.
- Protocol safety is not guaranteed by ERC-7683 compliance. Settlement contracts, bridges, message-passing systems, tokens, oracles, resource locks, auction systems, and off-chain services retain their own risks.
- Replay protection, cancellation, nonce design, escrow behavior, refund logic, partial filling, and settlement verification remain protocol-specific unless represented through the resolved requirements or assumptions.
- Fillers face risk from the moment they commit approvals, capital, gas, or transactions until expected payment becomes final and spendable.
- Users should verify origin chain, input asset, destination chain, recipient, expected output, deadline, authorization scope, and the actual transaction or typed data they sign.
- Builders should threat-model the resolver and the underlying settlement protocol separately. A correct resolver cannot make an insecure settlement system secure.
- ERC-7683 fits naturally inside frameworks such as the Open Intents Framework, but ERC-7683 and OIF are not interchangeable. ERC-7683 is a standardization layer; OIF is a broader implementation framework for intent origination, solving, fulfillment, settlement, aggregation, and related infrastructure.
The current draft has deliberately moved away from directly standardizing GaslessCrossChainOrder, OnchainCrossChainOrder, IOriginSettler, IDestinationSettler, open, openFor, and a universal destination fill interface. Those concepts belonged to an earlier draft. Today's design standardizes the solver-facing interpretation of an order through a resolver. This article explains both models so older terminology remains understandable without presenting obsolete interfaces as the current specification.
What ERC-7683 actually standardizes
Cross-chain intent protocols have a coordination problem that exists before any user moves funds.
Every protocol can design its own order format. One protocol can use escrow before execution. Another can allow a filler to execute first against a pre-existing resource lock. A third can use an auction. A fourth can calculate payment from inclusion time. A fifth can depend on an off-chain witness. All of those systems may be economically similar from the user's perspective while being completely different from a solver's perspective.
Without a common solver-facing interface, a solver that wants to participate across ten protocols may need ten custom integrations.
Each integration has to understand how the protocol represents orders, which contracts must be called, how much capital can be spent, where payment arrives, whether the order can revert, which chain each action belongs to, how prices change, what assumptions must hold, and when settlement becomes safe.
That fragmentation makes solver competition harder.
ERC-7683 attempts to standardize the language in which protocols explain their orders to solvers.
The current design does not say every intent protocol must look the same to the user. It says protocols should be capable of exposing what a solver needs through a common resolved representation.
The standardization boundary matters
This sounds like a narrow distinction, but it changes how the entire standard should be understood.
ERC-7683 is not attempting to define one universal bridge.
It is not attempting to define one universal escrow.
It is not attempting to force every protocol to share identical settlement contracts.
It is not attempting to force all users into one authorization mechanism.
It is not attempting to force every solver to call the same fill function.
Instead, ERC-7683 creates an abstraction boundary between protocol-specific intent design and protocol-agnostic solver execution.
This allows protocols to keep different mechanisms beneath the standard while giving solvers a more consistent way to understand what an order demands.
Why cross-chain orders need a common solver language
An intent can be described as a desired outcome rather than a prescribed transaction sequence.
For example, a user may want to spend USDC on Base and receive ETH on Arbitrum. The user cares about the amount, destination, recipient, deadline, and final economic result. The user may not care whether the solver routes through a decentralized exchange, maintains pre-positioned ETH on Arbitrum, uses a particular settlement mechanism, or later rebalances through another infrastructure layer.
A solver does care.
The solver needs to know every action it must perform and every condition attached to payment.
That creates two different representations of the same economic objective.
The user-facing application can remain outcome-oriented. The solver-facing representation must be execution-oriented.
Orders are offers of payment
ERC-7683 defines an order as an offer of payment in exchange for fulfillment of a set of requirements.
This definition is useful because it does not assume the order is only a bridge transaction or swap.
An order can contain several actions and dependencies.
It can require execution on multiple chains. It can use variables whose values are selected during execution. It can include payments that occur after specific steps. It can include assumptions the solver must independently validate.
This makes the standard suitable for a broader intent design space than a fixed transfer schema.
Solvers and fillers are execution actors
ERC-7683 uses solver as the primary term for the actor fulfilling order requirements. Filler is commonly used in the wider intent ecosystem for the same general role.
A solver evaluates whether an order is safe and profitable, determines variable values, executes required steps, pays gas, potentially supplies assets or approvals, and expects payment when the protocol's settlement conditions are satisfied.
The solver therefore carries meaningful economic risk.
If one required payment can disappear after the solver has spent capital, the order can be dangerous even if every call is technically executable.
ERC-7683 cross-chain order lifecycle
The current standard leaves several lifecycle stages protocol-specific, but the full process can still be visualized from user intent to solver payment.
User intent
The application creates a protocol-specific order describing the outcome, economic constraints, authorization and settlement model.
Payload
The protocol encodes its order as an opaque payload associated with a resolver capable of interpreting it.
Resolution
The resolver converts that payload into common steps, variables, payments and assumptions the solver can evaluate.
Execution
The solver chooses required variable values, validates dependencies, commits gas or capital and executes the necessary actions.
Verification
The underlying protocol determines whether fulfillment occurred using its own contracts, proofs, locks, messages or other mechanisms.
Payment
The solver receives the payment promised by the order once the protocol's settlement conditions have been satisfied.
Current ERC-7683 vs the earlier origin-settler design
Anyone researching ERC-7683 will encounter two materially different descriptions of the standard.
The distinction is not cosmetic.
Earlier versions standardized a larger portion of the cross-chain order lifecycle. They introduced structures such as OnchainCrossChainOrder, GaslessCrossChainOrder and ResolvedCrossChainOrder, together with IOriginSettler and IDestinationSettler interfaces.
The present draft changed that architecture.
| Area | Earlier ERC-7683 draft | Current ERC-7683 draft |
|---|---|---|
| Primary standardization boundary | Broader cross-chain order lifecycle and common settlement interfaces. | Solver-facing interpretation of protocol-specific order payloads. |
| User order types | Included OnchainCrossChainOrder and GaslessCrossChainOrder structures. | User authorization and payload structure remain protocol-specific. |
| Origin interface | IOriginSettler with mechanisms such as open and openFor. | No universal origin settler interface required by the current standard. |
| Destination interface | IDestinationSettler and a standardized fill-style flow. | No universal destination settler or fill function required. |
| Resolved representation | ResolvedCrossChainOrder with fields intended to summarize inputs and outputs. | ResolvedOrder containing steps, variables, payments and assumptions. |
| Profitability description | Included concepts such as maxSpent and minReceived. | Execution and payment semantics can be expressed more generally through variables, formulas, steps and payments. |
| Escrow assumption | More closely centered on orders opened through origin-side settlement contracts. | Supports broader models, including designs where execution can occur before an origin-chain action. |
| Protocol flexibility | Protocols still required implementation-specific subtype interpretation. | Protocols preserve their own authorization, auctions, settlement and execution ordering while solvers consume a common resolved language. |
| Core trusted object for solver integration | Protocol-specific order and settlement implementation. | The resolver becomes a central object a solver must vet and trust within documented assumptions. |
Why the old model was changed
The earlier design standardized order structs while still allowing implementation-specific fields inside them.
That created an important limitation.
A solver could understand the outer shape of the order while still needing custom protocol-specific logic to interpret the meaningful inner data.
In other words, standardization existed at the surface while solver integration remained fragmented underneath.
The earlier maxSpent and minReceived model also had limits when a solver's real cost depended on execution-time variables such as inclusion timing, gas prices, auction state, or other dynamically chosen values.
The present resolver architecture addresses that problem by describing execution more directly.
Rather than telling a solver only the worst-case economic bounds, it can expose the actual sequence of calls, formulas, variables, dependencies, spending requirements, payments, and assumptions needed to evaluate the order.
What happened to GaslessCrossChainOrder?
Gasless cross-chain orders remain an important intent design pattern.
A user may sign typed structured data off-chain instead of submitting the origin-chain transaction personally. Another actor can then relay or execute the order according to the underlying protocol's authorization logic.
That can remove the requirement for the user to hold native gas on the origin chain or manually broadcast the transaction that opens the order.
However, the current ERC-7683 draft no longer standardizes a GaslessCrossChainOrder structure.
Gasless authorization is now protocol-defined
Protocols can still implement gasless flows using EIP-712 signatures, permits, resource locks, delegated authorization, relayers, or other cryptographic mechanisms.
ERC-7683 deliberately does not force those protocols into one authorization structure.
From a user-security perspective, that makes the actual signature more important, not less.
A gasless interaction can still authorize asset movement. The absence of an immediate gas payment does not mean the signature is economically harmless.
Users should verify the signed domain, chain context, verifying contract, token, amount, nonce, expiry, recipient and any permissions created by the protocol.
Gasless does not mean trustless
The transaction can be relayed by a third party while settlement still depends on contracts, solvers, cross-chain proofs, token behavior, or other assumptions.
Gas sponsorship changes who broadcasts or pays for the origin action. It does not automatically change the security of the settlement protocol underneath it.
The roles that matter in ERC-7683
The current draft has fewer standardized lifecycle actors than the earlier version, but a real deployment still contains several roles.
The user
The user expresses the desired outcome and provides whatever authorization the intent protocol requires.
The user is primarily exposed to errors in asset selection, destination chain, recipient, amount, authorization scope, deadline, settlement assumptions, and application presentation.
The application
The application turns user intent into a protocol-specific payload.
It may request quotes, select a protocol, choose an auction, prepare signatures, display expected outputs, track order status and coordinate recovery when something fails.
The application's UI is not itself the settlement guarantee.
If the interface says the user will receive 1 ETH but the signed payload guarantees something different, the underlying authorization and protocol rules determine the actual result.
The order-distribution layer
Orders may be distributed through on-chain events, APIs, private order flow, auctions, aggregators, relayers, or other mechanisms.
The current ERC does not prescribe one universal feed.
Distribution affects solver competition and censorship resistance because a solver cannot compete for an order it never receives.
The resolver
The resolver is central to the current standard.
It decodes a protocol-specific payload and produces a ResolvedOrder containing steps, variables, payments and assumptions.
The solver can call the resolver off-chain using eth_call rather than paying to execute the resolution on-chain.
This allows resolution logic to be richer without forcing the entire expanded representation into transaction calldata.
The solver or filler
The solver evaluates the resolved instructions and decides whether to execute the order.
That decision can depend on required capital, current balances, allowances, gas, market prices, timing, settlement latency, payment security and any named assumptions exposed by the resolver.
The settlement protocol
The underlying protocol determines how the solver's execution becomes a valid claim for payment.
This can involve escrow, resource locks, cross-chain messages, proofs, challenge mechanisms, auctions, destination contracts, source contracts, or combinations of those components.
ERC-7683 does not make these mechanisms interchangeable.
Origin settler and destination settler
Origin settler and destination settler remain useful conceptual terms because they describe where source-side authorization and destination-side fulfillment occur.
They should not, however, be presented as mandatory current ERC-7683 interfaces.
IOriginSettler and IDestinationSettler belonged to the previous standardization model.
A current ERC-7683-compatible protocol can have contracts serving similar economic roles while exposing completely different protocol-specific interfaces underneath the resolver abstraction.
The resolver is the center of the current standard
The resolver performs more than simple decoding.
The specification describes it as a payload decoder, order validator and guarantor.
That wording is significant.
A solver needs confidence that following the resolver's output will not silently create obligations that were omitted from the resolved representation.
What a resolver should guarantee
A well-behaved resolver should ensure the order is well formed and that the solver can satisfy all required steps and receive the declared payments if no explicitly allowed abort condition occurs.
If safety depends on something the resolver cannot establish itself, that dependency should be exposed as an assumption for the solver to validate.
This creates a security boundary.
An unsafe resolver could make a malicious or broken protocol appear executable while hiding a condition that invalidates payment after the solver has committed capital.
Why solvers may whitelist resolvers
A programmable solver can support a new protocol by evaluating and approving its resolver rather than writing bespoke code for every protocol-specific payload.
That can significantly reduce integration work.
It also means resolver review becomes part of a solver's trust policy.
A resolver can be assessed through source-code review, deployed-bytecode verification, audits, formal analysis where practical, bug bounties, production history and testing against adversarial payloads.
Builders reviewing deployed contracts can use TokenToolHub's smart contract verification guide as a framework for checking verified source, deployed bytecode, proxy structure and the difference between source publication and actual deployment integrity.
Resolver trust should not become protocol trust by accident
A resolver can accurately explain an unsafe protocol.
That sounds paradoxical, but it is fundamental to ERC-7683.
The standard can expose that execution requires trusting bridge X, token Y, oracle Z, a particular resource lock, or a settlement contract with certain conditions.
The resolver does not transform those dependencies into safe systems.
The solver must decide whether it accepts them.
Inside a current ERC-7683 ResolvedOrder
The resolved order can be understood through four categories: steps, variables, payments, and assumptions.
Required actions
Calls the solver must execute, together with dependencies, token spending, gas requirements, timing and revert behavior.
Dynamic values
Values the solver chooses, queries, observes or obtains during execution and then uses consistently throughout the order.
Expected payments
Assets the solver expects to receive, their source, amount calculation, recipient variable and expected payment timing.
Assumptions
External conditions the resolver cannot independently guarantee and that the solver must validate before proceeding.
Execution steps and dependency ordering
An ERC-7683 order can contain multiple steps.
The solver must execute those steps while respecting hard dependencies.
The dependency model is required to remain acyclic. That prevents an impossible structure where step A requires step B while step B simultaneously requires step A.
This matters for cross-chain workflows because later operations can depend on results produced by earlier execution.
Call steps
A Call step identifies a target, function selector, arguments and attributes.
The solver evaluates any variables referenced by those arguments, encodes the resulting calldata and submits a transaction that calls the specified target.
The target is represented through an interoperable address, allowing chain context to be included in the identity of the destination.
NeedsStep
NeedsStep declares that one call cannot be executed until another step has successfully executed.
This is useful when an action logically requires a prior operation.
For example, a destination swap may depend on a preceding asset transfer or approval step.
NeedsVariable
NeedsVariable declares dependency on a variable even where that dependency is not already implied by arguments or formulas.
This makes execution ordering explicit rather than forcing the solver to infer hidden sequencing rules.
SpendsERC20
SpendsERC20 tells the solver that a call may transfer ERC-20 tokens from the caller using transferFrom, up to an amount determined by the order's formula.
The resolved information includes the token, amount formula, spender and recipient.
This is security-critical because approvals are a real economic commitment.
A solver should know before execution which contract needs allowance and how much capital can be exposed.
Unexpected approvals should be treated as material order behavior, not as an incidental implementation detail.
SpendsGas
SpendsGas communicates how much gas a call may require.
Without an explicit gas requirement, the solver may estimate execution through simulation when possible.
Gas is part of solver profitability.
An order that provides a large nominal payment can still be unprofitable if the execution path consumes substantially more gas than expected.
TimingBounds
TimingBounds can constrain execution according to block number or block timestamp.
This can express lower or upper timing limits and therefore provide expiry-like behavior at the execution-step level.
Timing constraints matter because cross-chain prices, auction curves and settlement assumptions can change rapidly.
RevertPolicy
A call may have an explicitly declared policy for a specific expected revert reason.
An ignore policy can permit the solver to treat a particular expected revert as non-fatal. An abort policy can terminate the order.
Unexpected reverts should not be silently tolerated.
This creates an important safety property because the solver can reason about when failure is acceptable instead of discovering hidden failure semantics after spending capital.
Variables let orders adapt during execution
Not every economically important value is known when the user first creates the order.
A solver may choose the address that should receive payment. It may choose the chain on which payment should arrive. It may need to observe block timing, gas price, contract state, event logs or an off-chain witness.
ERC-7683 variables allow these values to be represented explicitly.
PaymentRecipient
A PaymentRecipient variable lets the solver identify the account where it wants to receive payment.
This can be useful when a solver separates execution accounts, treasury accounts and settlement accounts.
PaymentChain
PaymentChain allows a solver to choose the chain on which it prefers to receive payment where the protocol permits that flexibility.
This can have substantial liquidity implications.
A solver may prefer payment on a chain where it currently needs inventory instead of receiving more capital on a chain that is already overfunded.
StepCaller
A StepCaller variable identifies the account that will call a particular step.
This matters because token balances, approvals, nonce state and permissions are caller-specific.
ExecutionOutput
ExecutionOutput variables can capture values observed during execution, including block number, block timestamp or effective gas price.
These values can then influence later parts of the order.
This is useful for auctions or pricing systems where payment depends on when execution occurred.
Witness
A Witness variable can depend on an off-chain procedure.
The specification allows a witness kind, associated data and dependencies on other variables.
Witnesses add flexibility, but they also create an obvious trust question: what off-chain system produces the witness, and under what guarantees?
A solver must understand that procedure before relying on it.
Query
A Query variable can read a contract using eth_call.
This lets the resolved order depend on current or specified-block chain state without requiring the query itself to be submitted as an on-chain transaction.
QueryEvents
QueryEvents can retrieve event logs from a specified emitter and topic pattern.
This can be useful when execution depends on an event produced by another transaction or protocol component.
RPC integrity and block-selection assumptions matter here because the solver is using external chain-state access to determine a variable that can influence execution.
Payments tell the solver what it earns
An order is economically meaningful to a solver only if payment is understandable.
The current standard can describe ERC-20 payments together with the payment token, sender, amount formula, recipient variable, triggering step and estimated delay.
This creates a richer model than simply saying the solver will receive at least a fixed amount.
Payment can depend on execution
An amount formula can depend on constants or variables.
That means payment can reflect execution-time information.
A Dutch auction, for example, can allow the economic terms to change according to inclusion timing.
The solver can resolve the formula and decide whether the expected payment justifies the required costs.
Estimated payment delay matters
A payment that arrives in five seconds is economically different from an identical payment that is expected to remain unavailable for several hours or days.
The solver's capital remains committed until payment becomes final and usable.
Settlement latency therefore affects quote quality, required inventory and solver capacity.
Named assumptions expose what the resolver cannot guarantee
No resolver can prove every property of every external system.
A cross-chain order may depend on a bridge, protocol, oracle, token implementation, messaging system, chain, resource lock or other component whose complete security cannot be established through simple payload validation.
ERC-7683 allows additional assumptions to be identified by name and associated data.
The solver is responsible for validating those assumptions before fulfillment.
Assumptions are not boilerplate
An assumption can determine whether an order is safe.
If a protocol requires trusting a particular message bridge, the solver should decide whether that bridge is acceptable.
If a token has unusual transfer behavior, the solver should understand it.
If payment relies on an oracle, the solver should understand the oracle's failure modes.
If a resource lock can be modified by a privileged controller, that authority can affect payment safety.
Implicit assumptions still exist
The specification allows underlying-chain liveness and censorship resistance to be treated as implicit assumptions.
Resolvers may also document additional implicit protocol assumptions.
This means security analysis must consider both explicit assumptions inside resolved orders and documented assumptions attached to the resolver itself.
Why ERC-7930 interoperable addresses matter
ERC-7683 currently depends on ERC-7930 for interoperable addresses.
A normal EVM address does not identify a chain.
The same hexadecimal address can exist independently on Ethereum, Base, Arbitrum, Optimism, BNB Chain and many other EVM networks.
In cross-chain systems, that ambiguity is dangerous.
A destination must identify both an address and the chain where that address is meaningful.
ERC-7930 provides a binary representation that binds chain information with the target address.
Chain binding reduces one class of ambiguity
If a solver sees only 0x123... it cannot infer whether the order means Ethereum mainnet, Base, Arbitrum or another EVM chain.
An interoperable address provides explicit chain context.
This is useful not only for EVM chains. The format is designed to support address spaces outside the EVM ecosystem as well.
Address standardization does not replace replay protection
Chain-specific addressing reduces ambiguity about where an operation belongs.
It does not automatically guarantee that an authorization cannot be replayed.
Replay resistance still depends on the underlying protocol's signature domain, nonces, consumed-order tracking, authorization design and settlement logic.
Open, resolve, fill, verify and settle
Older ERC-7683 documentation often explains the standard through open and fill interfaces.
The current draft does not standardize that exact flow, but these verbs remain useful as a conceptual lifecycle when their protocol-specific nature is kept clear.
Open or create
The protocol needs a way for a user or another authorized actor to create an enforceable order.
That could involve depositing assets, signing gasless authorization, locking resources, publishing an order to an auction, committing a permit, or another mechanism.
The current ERC leaves this step to the protocol.
Resolve
This is the current ERC-7683 standardization boundary.
The protocol-specific payload is passed to a resolver, and the resolver returns common solver instructions.
The solver can then understand the order without knowing the protocol's original internal data format.
Fill or execute
The solver performs the required calls in dependency order and supplies whatever balances, approvals, gas or other resources the resolved steps require.
The current standard does not require a universal IDestinationSettler.fill function.
The execution can involve arbitrary targets described by the resolved steps.
Verify
The underlying protocol determines whether the solver's actions satisfy the order.
This can involve direct contract state, cross-chain messaging, proofs, event evidence, resource locks, oracle conditions, signatures, auctions or other protocol-specific mechanisms.
Settle
The solver ultimately receives payment when the underlying protocol's conditions have been met.
For security analysis, the order is not economically complete merely because the solver submitted all required transactions.
Completion from the solver's perspective occurs when expected payment is final and spendable.
Filler competition and order-flow quality
Standardizing solver-facing order interpretation can broaden the pool of solvers capable of competing across protocols.
That can improve liquidity and execution quality, but competition should be measured rather than assumed.
More compatible does not automatically mean more competitive
A protocol may expose an ERC-7683-compatible resolver while distributing nearly all orders through one private endpoint available to only one solver.
The order representation is interoperable, but practical competition remains limited.
Users and builders should distinguish technical compatibility from market structure.
Order discovery matters
Solvers can compete only when they can discover orders in time to evaluate and execute them.
Private order flow can reduce information leakage but concentrates distribution power.
Public order dissemination can improve openness but may expose order details to adversarial searchers or MEV strategies.
Different protocols can choose different tradeoffs because ERC-7683 does not dictate one universal feed.
Solver economics affects whether an order is filled
An order can remain unfilled for entirely economic reasons.
The solver may face excessive gas, insufficient destination liquidity, unreliable payment, high settlement latency, unfavorable price movement or unacceptable assumptions.
It is therefore important not to label every rejected order as censorship.
The ERC-7683 risk map
The standard can improve interoperability without removing the risks of the protocols it connects.
Resolver risk
The resolver is one of the highest-value review targets in a current ERC-7683 integration.
A solver is expected to rely on its output when deciding what capital, approvals and transactions to commit.
Incorrect decoding
If the resolver interprets protocol-specific payload fields incorrectly, the common representation can misstate what the actual protocol requires.
A one-byte encoding mistake can become an asset, amount, recipient or execution error.
Incomplete requirements
The resolver must not omit obligations that can materially affect solver safety.
If a call requires an approval but SpendsERC20 does not disclose it, the solver may expose assets without expecting that risk.
If a payment depends on an external condition but that condition is neither enforced nor surfaced as an assumption, the solver can execute an apparently valid order and still fail to receive payment.
Incorrect abort behavior
Orders may abort only according to declared behavior.
Hidden abort conditions are dangerous because a solver can incur partial costs before discovering that the order will never pay.
Replay and duplicate-execution risk
Replay protection is a good example of why ERC compliance should not be confused with end-to-end protocol security.
The current ERC-7683 does not define one universal user-signature format or one universal nonce system.
Protocols must secure their own authorization paths.
Same order, same chain
A signed order should not remain executable repeatedly when the user's intent was to authorize one economic action.
Protocols commonly use nonces, order hashes, consumed-state tracking, resource-lock state or other mechanisms to prevent duplicate claims.
Same order, different chain
Cross-chain systems also need to prevent signatures intended for one network or contract from becoming valid elsewhere.
EIP-712 domains, explicit chain context, verifying-contract binding and ERC-7930 chain-specific addresses can all contribute to safer design.
None should be assumed to replace the others automatically.
Solver-side replay concerns
A solver should verify whether the order has already been fulfilled, cancelled, invalidated or consumed before committing new execution.
Race conditions between multiple fillers can matter when several solvers attempt to execute the same order simultaneously.
Expiry and timing risk
Cross-chain orders operate in markets where token prices, gas, chain conditions and liquidity can change within seconds.
Time bounds protect both users and solvers from stale execution.
User deadlines
A user usually needs some limit after which the economic terms should no longer be executable.
The exact mechanism remains protocol-specific.
The resolved execution can also contain TimingBounds that constrain individual calls according to block number or timestamp.
Filler timing
A solver must evaluate whether all required steps can realistically be completed before timing limits expire.
This becomes more difficult when execution spans chains with different block times, sequencers, confirmation assumptions or congestion.
Settlement after execution
The destination action can occur within the user's deadline while the solver's payment is not finalized until later.
Builders should distinguish execution deadline from settlement finality.
Partial fill and multi-step completion risk
The current ERC-7683 draft does not impose one universal partial-fill model.
A protocol may support partial fills, all-or-nothing execution, several independent steps, multiple outputs or other fulfillment structures.
That flexibility creates important questions.
Can the user receive less than the intended final outcome?
If partial fills are supported, the protocol needs clear rules for minimum completion, remaining order capacity and whether another filler can complete the rest.
Can the solver be paid after only part of the order?
Payments should be tied to the correct execution conditions.
A protocol should not accidentally permit a solver to collect full payment after satisfying only one economically minor requirement.
Can another solver race the same remaining capacity?
Concurrent fillers can create state races.
Solvers should evaluate current order state immediately before execution where protocol semantics require it.
Settlement risk remains protocol-specific
ERC-7683 deliberately avoids defining one universal settlement contract.
This preserves design flexibility.
It also means settlement security cannot be inferred from the standard alone.
Escrow-based settlement
A protocol can place the user's input assets into escrow before the solver executes.
The solver's security analysis then depends on whether the escrow is properly funded, whether payment can be revoked, who can upgrade or pause the contract, and what proof releases the assets.
Resource-lock settlement
Some intent systems can let solvers execute against resources secured by a trusted lock without opening a dedicated escrow for each order before fulfillment.
This can support fill-first workflows.
The solver then needs to understand the lock's guarantees, authorization scope, claim conditions and any entity capable of modifying the lock.
Auction-based settlement
Protocols can select fillers through Dutch auctions, first-come-first-served mechanisms or other designs.
Auction rules affect price formation, race behavior, MEV exposure and which solver ultimately receives the right to execute.
Cross-chain settlement verification
If payment on one chain depends on activity on another, some cross-chain verification mechanism is required.
This is where bridge, oracle, messaging and finality assumptions enter the security model.
TokenToolHub's guide to cross-chain messaging examines validator sets, light-client-style verification, optimistic designs, proof systems, message authentication and the distinction between transporting information and deciding whether that information should be trusted.
Oracle and cross-chain verification risk
ERC-7683 orders can rely on external state and protocol-specific settlement systems.
An oracle can therefore appear in more than one form.
Market-data oracles
Pricing systems can rely on market data to determine whether execution is profitable or whether an auction price is valid.
Stale or manipulated data can distort filler behavior.
Cross-chain verification
The settlement protocol may need evidence that a destination-chain event actually occurred.
That evidence can come through message bridges, light clients, storage proofs, optimistic verification, committees or other systems.
If incorrect destination state can be accepted, the origin-side payment mechanism can settle against an event that did not validly occur.
Finality assumptions
Observed inclusion is not always equivalent to economically safe finality.
Solvers should understand how many confirmations or what settlement condition the protocol assumes before treating destination execution as durable.
This is especially important when different Layer 2 systems have different sequencer and settlement characteristics.
For a broader route-level review, TokenToolHub's bridge risks and security checklist covers validation authority, upgrade controls, liquidity dependencies, token representations, emergency powers and cross-chain failure modes.
How resolved steps can expose solver capital
ERC-7683's security considerations focus heavily on solver exposure.
This is appropriate because a solver can commit its own capital before receiving payment.
Token spending
A call may require transferFrom access to solver-held tokens.
The spender, recipient and maximum expected amount need to match the order's economic purpose.
Approvals
An order that requires an approval can create authority extending beyond the immediate call if the solver uses an overly broad allowance.
Solvers should use bounded approvals where practical and avoid leaving unnecessary authorization attached to unknown contracts.
Gas exposure
A series of technically valid calls can still be economically dangerous if gas usage is understated or if transactions must be repeatedly replaced during congestion.
Callback and external contract exposure
General-purpose call execution means solvers can interact with arbitrary contracts if their policies permit it.
That increases flexibility but requires simulation, contract vetting and careful handling of approvals and callbacks.
Why end-to-end simulation matters
One benefit of a common execution representation is that order behavior becomes easier to simulate without implementing the original protocol's complete business logic inside the solver.
Simulation can reveal obvious failures before real funds are committed.
Check all required calls
The solver should simulate calls using realistic balances, allowances, caller addresses and state whenever possible.
Check dependency ordering
A call can succeed in isolation while failing when executed before a required prerequisite.
Check final balance changes
Execution should be evaluated economically, not only according to transaction success.
A successful transaction that unexpectedly transfers more solver assets than expected is still a failed risk-control outcome.
Check payment assumptions
Simulation should include the path by which payment becomes available, not merely destination execution.
Investigating executed intent transactions
Cross-chain intent incidents can be difficult to reconstruct because the user-facing application may hide several execution steps behind one quote.
On-chain analysis should separate the user's authorization from filler execution and settlement.
Start with the origin action
Identify the transaction, signature or lock that authorized the order.
Determine which token, amount and contract were involved.
Identify the execution calls
Trace which filler account executed each step and which contracts received calls.
The TokenToolHub Transaction Decoder can help turn supported EVM transaction hashes into structured views of methods, token movements, approvals, internal calls, gas behavior and execution results.
Compare execution against the intended recipient
The destination transaction should be checked against the recipient and asset expected by the order.
Trace payment
Determine which transaction or protocol state transition paid the solver and whether that payment matched the resolved order.
Investigate filler relationships when needed
For broader multichain entity context, address labeling and token-flow research, Nansen can complement transaction-level review where its supported chains and datasets cover the addresses involved.
Address labels should remain supporting evidence rather than proof of beneficial ownership or intent.
What users should verify before accepting an ERC-7683 intent quote
Most users will never interact directly with an IResolver contract.
The practical user boundary is the wallet or application that converts the intent into an authorization.
Cross-chain quote review
- Confirm the exact origin chain.
- Confirm the exact input asset and token contract where multiple versions can exist.
- Confirm how much of the input asset can actually be spent.
- Confirm the destination chain.
- Confirm the destination asset and whether it is native, wrapped, bridged or otherwise represented.
- Confirm the destination recipient address.
- Check the minimum amount you are guaranteed to receive rather than relying only on a headline estimate.
- Check whether the quote is exact-input, exact-output or dynamically priced.
- Review the order deadline, signature expiry and any step-level timing constraints shown by the application.
- Understand whether the order can be partially filled.
- Understand what happens if no solver accepts the order.
- Understand what happens if a filler starts execution but a later step fails.
- Review whether the order requires a token approval, permit, resource lock, escrow deposit or other authorization.
- Verify the spender contract for any approval request.
- Review the actual typed data or transaction whenever the wallet exposes it.
- Do not assume that gasless signing means no asset authority is being created.
- Do not assume the best quoted amount necessarily uses the settlement route with the strongest trust assumptions.
- For significant value, evaluate the bridge, messaging or verification system supporting settlement.
Compare output, not only fees
An application can display a low fee while embedding the solver's economic margin into the output price.
The more useful comparison is usually how much value leaves the origin side and how much of the intended asset is guaranteed to arrive at the destination.
Check the recipient independently
Cross-chain execution can involve several filler and settlement addresses.
The user should still verify that the final destination recipient is the account they expect.
Check deadline and recovery behavior
An expired quote should not remain indefinitely exercisable.
If user assets have already been deposited or locked, understand how they can be recovered when the order expires unfilled.
Before selecting a cross-chain route, the TokenToolHub Bridge Helper can help organize route considerations and reduce the chance of evaluating a cross-chain move purely on interface convenience.
Builder and auditor trust-assumption checklist
For integrators, the resolver should be reviewed as one part of the system rather than the whole system.
ERC-7683 implementation review
- Confirm the exact ERC-7683 draft and resolver implementation being integrated.
- Do not assume older IOriginSettler or IDestinationSettler interfaces remain normative.
- Verify that the protocol-specific payload cannot be decoded ambiguously.
- Review the resolver contract source and deployed bytecode.
- Review proxy and upgradeability structure if the resolver is upgradeable.
- Document who can replace or upgrade the resolver.
- Confirm that every required execution action appears in the resolved steps.
- Confirm that hard dependencies correctly express execution ordering.
- Reject cyclic dependencies.
- Verify that token-spending requirements are disclosed through the resolved attributes where applicable.
- Verify spender and recipient addresses for token transfers.
- Verify gas requirements or require safe simulation where explicit bounds are absent.
- Review every allowed RevertPolicy and ensure expected revert prefixes cannot hide unrelated failures.
- Confirm that timing constraints cannot produce impossible or ambiguous execution windows.
- Review all variables and determine who controls or derives each value.
- Review every Witness procedure and its trust assumptions.
- Review Query and QueryEvents usage for block selection, stale RPC state and reorganization sensitivity.
- Verify that payments cannot be invalidated after the solver incurs irreversible costs.
- Verify that payment amount formulas cannot unexpectedly underpay the solver.
- Review estimated payment delays and capital requirements.
- List every explicit named assumption returned by the resolver.
- Document every additional implicit assumption attached to the protocol.
- Validate underlying token behavior rather than assuming every ERC-20 has conventional transfer semantics.
- Review replay protection in the protocol's actual authorization system.
- Review nonce handling and consumed-order tracking.
- Review signature-domain separation and verifying-contract binding.
- Review cancellation behavior and race conditions between cancellation and filler execution.
- Review partial-fill rules if supported.
- Review multi-filler races and duplicate settlement prevention.
- Document how destination execution is verified for payment.
- Review every cross-chain bridge, messenger, oracle or proof system on which settlement depends.
- Review finality and reorganization assumptions for every supported chain.
- Define behavior when a messaging system becomes unavailable after execution.
- Define behavior when the solver executes successfully but payment is delayed.
- Define behavior when a settlement proof becomes disputed or invalid.
- Review pausing and emergency authority.
- Review asset-recovery procedures for unfilled or expired orders.
- Simulate representative orders end to end before supporting real capital.
- Simulate malicious payloads and malformed variables.
- Simulate unexpected token behavior, gas spikes, reverts and chain congestion.
- Preserve order payloads, resolver outputs, transaction hashes and settlement evidence for incident reconstruction.
Order feeds, privacy and censorship
A common order representation can improve solver portability while order distribution remains fragmented.
This means interoperability has at least two dimensions.
One is whether a solver can understand the order.
The other is whether the solver can actually receive the order in time to compete.
Private order feeds
Private distribution can protect users from some forms of order-flow leakage and MEV.
It can also create privileged access.
If only selected fillers can receive orders, the user may have fewer competing quotes even though the resolver itself is open.
Public feeds
Public dissemination can allow broader solver participation.
The tradeoff is that market-sensitive intent information can become visible before execution.
A large order can reveal desired asset, destination, timing and acceptable economic bounds.
Censorship should be measured end to end
A permissionless settlement protocol does not guarantee that every user has permissionless access to competitive order flow.
Research should ask whether users can use another application, whether solvers can connect to another feed, whether protocols can replace aggregators, and whether settlement accepts valid execution from independent fillers.
ERC-7683 does not replace bridge security analysis
The Ethereum Foundation's interoperability work treats intents and general message passing as complementary parts of the cross-chain stack.
An intent can make the user's experience feel like one action while underlying settlement still depends on bridge or messaging infrastructure.
That infrastructure remains part of the security model.
Intent abstraction can hide several trust layers
A user may see one quote while the protocol depends on a destination filler, an escrow contract, a cross-chain message, a validator set, an origin payment contract and several RPC providers.
Abstraction is useful, but security research should be able to reconstruct those layers.
Canonical and private bridges can both appear underneath intents
One protocol may verify destination execution using a canonical settlement path. Another may use a third-party message bridge. Another may use optimistic verification.
ERC-7683 does not force those routes to have equivalent trust assumptions.
How ERC-7683 fits inside the Open Intents Framework
ERC-7683 and the Open Intents Framework are closely related but should not be treated as synonyms.
ERC-7683 is a standard defining how intent protocols can expose orders to programmable solvers through a common resolution model.
The Open Intents Framework is a broader developer framework that provides smart contracts, solver software, aggregation infrastructure and related components for deploying and operating cross-chain intent systems.
ERC-7683 is an interface layer
The goal is interoperability between intent protocols and solver infrastructure.
A solver should be able to evaluate orders from different protocols by understanding the common resolved representation instead of embedding bespoke logic for each protocol's payload.
OIF is an implementation ecosystem
OIF addresses additional operational concerns such as quote aggregation, intent discovery, solver execution, settlement components and cross-chain liquidity management.
An OIF implementation can use ERC-7683 while still containing substantial architecture not defined by the ERC.
One should not be used as a security guarantee for the other
A protocol's use of OIF does not automatically prove every ERC-7683 assumption is safe.
Likewise, ERC-7683 compatibility does not mean the protocol is using OIF.
The security review should identify the exact resolver, settlement contracts, execution software and cross-chain infrastructure actually involved.
Worked examples
Example one: protocol-specific payload, common solver
Protocol A uses a Dutch auction and resource lock.
Protocol B uses an origin escrow and fixed-price order.
The two payload formats are completely different.
Each protocol deploys a resolver that converts its own payload into the common ERC-7683 representation.
A solver integrates both protocols by vetting their resolvers and supporting the general steps, variables and payments they produce.
The protocols remain different while solver integration becomes more reusable.
Example two: gasless user order
A user signs an EIP-712 authorization allowing a protocol to settle 1,000 USDC in exchange for ETH on another chain.
The user pays no origin gas at signing time.
The current ERC-7683 standard does not require that authorization to use a GaslessCrossChainOrder struct.
The protocol chooses its own authorization representation and exposes solver requirements through its resolver.
The security review therefore focuses on the protocol signature and resolver separately.
Example three: hidden spender bug
A protocol requires the solver to approve a router before execution.
Its resolver fails to disclose the required token spending correctly.
The solver follows the resolved instructions but discovers during execution that an unexpected allowance is necessary.
A cautious solver should stop rather than improvising an approval the resolver did not disclose.
The resolver failed to provide a complete description of solver obligations.
Example four: payment depends on an insecure messenger
A resolver accurately describes every execution step and payment.
However, the underlying settlement protocol trusts a cross-chain messaging system with assumptions the solver considers unacceptable.
The resolver is technically correct.
The solver can still reject the order because protocol safety remains insufficient.
Example five: timing-dependent payment
An auction pays the solver according to the block timestamp when execution is included.
The resolved order captures that timestamp as an execution variable and uses it in the payment formula.
The solver can estimate whether the order is profitable under likely inclusion times rather than relying on one static minReceived number.
Example six: destination call reverts as expected
An order contains a call that can legitimately revert with a known reason when a condition has already been satisfied.
The resolved step includes a RevertPolicy instructing the solver to ignore that specific expected revert.
An unrelated revert should still invalidate execution.
This prevents generic failure from being silently treated as success.
Example seven: solver receives payment later than the user's output
A filler executes the destination transfer immediately.
The user sees the requested token within seconds.
The settlement protocol requires a cross-chain proof before the solver's payment becomes available.
The user's perceived execution time is therefore much shorter than the solver's capital-settlement time.
Both measurements matter for the economics of intent markets.
Example eight: replay protection is protocol-specific
A user signs a gasless order once.
ERC-7683 successfully exposes the order to solvers.
If the underlying protocol fails to mark the authorization as consumed after settlement, the same payload could create duplicate-execution risk.
The problem is not solved merely because the resolver is ERC-7683-compatible.
Example nine: wrong chain, correct hexadecimal address
The same 20-byte address exists on Base and Arbitrum.
A plain address string cannot indicate which chain is intended.
ERC-7930 interoperable addressing binds chain context to the address representation, reducing that ambiguity inside the resolved order.
Example ten: resolver upgrade changes solver assumptions
A solver has previously vetted a resolver and allowed it in production.
The resolver sits behind an upgradeable proxy.
An administrator upgrades the implementation.
The address remains the same while the logic changes.
A solver that whitelists only the proxy address without monitoring implementation changes can continue trusting code it never reviewed.
Resolver allowlisting therefore needs upgrade monitoring where proxies are involved.
Common ERC-7683 misconceptions
ERC-7683 defines one universal cross-chain bridge
It does not.
The standard defines a solver-facing way to consume orders. Underlying settlement can use different bridge, messaging, escrow or proof systems.
Every ERC-7683 order uses IOriginSettler
That describes an earlier draft.
The current standard no longer requires IOriginSettler.
Every ERC-7683 order uses IDestinationSettler.fill
That also belongs to the earlier draft.
The current standard describes solver execution through general Call steps.
GaslessCrossChainOrder is the current canonical order struct
No.
Gasless authorization remains possible, but the current ERC leaves user authorization and protocol payload design to the intent protocol.
ERC-7683 guarantees safe settlement
No.
The standard explicitly separates solver-facing order description from protocol security.
A trusted resolver means every underlying protocol is trusted
No.
A resolver can expose assumptions that the solver must separately evaluate.
An unfilled order proves solver censorship
No.
The order may be economically unattractive, impossible under current liquidity, expired, unsafe or dependent on assumptions the solver refuses to accept.
Interoperable addresses eliminate all replay risk
No.
They improve chain-specific address representation. Replay safety still depends on authorization and settlement design.
Successful destination execution means settlement is complete
Not necessarily.
The solver may still be waiting for proof, settlement or payment finality.
A practical ERC-7683 research framework
Researchers evaluating an intent protocol can work from the resolver outward.
Identify
Find the protocol payload format, resolver address, supported chains and actual settlement deployment.
Resolve
Inspect the steps, variables, payments and assumptions produced for representative orders.
Verify
Check deployed code, upgrades, spender addresses, token behavior and all underlying settlement dependencies.
Simulate
Execute realistic and adversarial order scenarios before trusting the resolver with solver capital.
Monitor
Track resolver upgrades, settlement failures, filler concentration, unexpected reverts and changed cross-chain assumptions.
Record the exact resolver
A protocol name is insufficient.
Record the deployed address, chain, implementation code, proxy relationship and relevant version.
Save representative resolver outputs
Resolver behavior should be examined across different order amounts, assets, chains, timing conditions and authorization types.
Separate observation from assumption
Observation: the resolved order requires one call that transfers USDC to a specified recipient.
Assumption: the cross-chain settlement protocol will later release payment safely.
The first can be inspected directly from the resolved instructions. The second requires protocol-level analysis.
What production solvers should monitor
A solver operator should assume conditions will change after initial integration.
Resolver code changes
Monitor proxy implementation slots, ownership changes and deployed bytecode.
Unexpected resolved instructions
A previously familiar protocol suddenly producing new spenders, targets, assumptions or payment paths should trigger review.
Payment delay
Increasing time between execution and spendable payment can indicate settlement degradation.
Failed calls
A rise in unexpected reverts can indicate contract upgrades, stale state, token changes, RPC problems or broken assumptions.
Allowance growth
Operational wallets should not accumulate unexplained allowances to arbitrary contracts merely because many orders require token spending.
Chain health
Sequencer incidents, RPC instability, reorgs, settlement delays and bridge pauses can make previously safe orders temporarily unacceptable.
Filler competition
Protocols should monitor whether compatibility actually produces multiple active fillers or whether one solver controls nearly all order flow.
Why ERC-7683 matters for Ethereum interoperability
Ethereum increasingly operates as a network of interconnected execution environments rather than one location where every user action happens.
That creates pressure for interoperability systems that do not force users to manually understand every bridge, token representation, gas requirement and settlement path.
Intents address part of that problem by allowing users to express outcomes.
ERC-7683 addresses a problem underneath the user interface: how do many intent protocols share a solver market without forcing every solver to build protocol-specific execution software?
The resolver-centric design is an attempt to create that common language.
Shared solvers can improve market depth
If solvers can support new protocols by vetting resolvers instead of rewriting their entire integration stack, more protocols can potentially access existing solver liquidity.
Protocol innovation remains possible
A standard that required every protocol to use one escrow, auction or settlement model could quickly become restrictive.
The current design intentionally standardizes less of the lifecycle so protocols can continue experimenting beneath the solver interface.
Less standardization creates more responsibility at the trust boundary
Flexibility has a cost.
Solvers and auditors must understand the resolver and its assumptions because the standard no longer provides one universal settlement behavior they can reason about for every order.
Conclusion: ERC-7683 standardizes understanding, not trust
ERC-7683 is best understood as a common language between intent protocols and programmable solvers.
That framing is more accurate than describing it as one cross-chain bridge interface.
The current draft allows a protocol to keep its own payload, user authorization, auction, settlement verification, escrow model, resource locks, execution ordering and other protocol-specific behavior. The protocol then exposes a resolver that translates its order into general-purpose steps, variables, payments and assumptions.
This architecture solves a real interoperability problem.
Without it, every solver must understand every protocol's custom execution semantics. With a trusted resolver, a solver can consume a common representation and evaluate whether the order is safe, executable and profitable.
That does not make the underlying protocol safe by definition.
The resolver still has to be correct. Every required obligation must be disclosed. Payment must remain available after the solver incurs costs. Token spending must be bounded and understandable. Timing behavior must be explicit. External witnesses and queries must be reliable. Assumptions must be surfaced. Replay protection must work. Settlement systems must be secure. Cross-chain verification must correctly represent destination execution.
The evolution from the earlier origin-settler and destination-settler design is therefore important.
IOriginSettler, IDestinationSettler, GaslessCrossChainOrder and ResolvedCrossChainOrder remain useful for understanding the history of ERC-7683, but they should not be confused with the current normative architecture.
The present standardization boundary is higher-level and more flexible.
For users, the practical lesson is to verify the outcome and the authorization rather than assuming an intent interface has removed cross-chain risk. Confirm the chain, token, output, recipient, deadline and actual signature. For higher-value transfers, examine the bridge or messaging assumptions underneath the protocol.
For solvers, the central question is whether faithfully following the resolver's instructions can still lead to lost capital or invalid payment. If the answer is unclear, the order is not sufficiently understood.
For builders, the resolver should be treated as a security-critical adapter between protocol-specific intent semantics and generalized solver execution.
For broader cross-chain research, use TokenToolHub's cross-chain messaging guide to examine verification architectures, the bridge security checklist to analyze route-level trust assumptions, the Bridge Helper when comparing practical transfer considerations, the Transaction Decoder when investigating executed EVM transactions, and the smart contract verification guide when reviewing resolver and settlement deployments.
The long-term importance of ERC-7683 is not that every cross-chain protocol becomes identical. It is that protocols can remain different while solvers gain a consistent language for understanding those differences.
Verify the order behind the cross-chain experience
Intent interfaces can hide routing complexity, but they should not hide the economic terms or settlement assumptions that determine safety. Verify the assets, recipient, authorization, deadline and underlying route before committing significant value.
FAQs
What is ERC-7683?
ERC-7683 is a draft Ethereum standard that defines a common solver-facing interface for intent protocols. Protocol-specific order payloads can be translated by resolver contracts into general-purpose steps, variables, payments and assumptions that programmable solvers can evaluate.
What are ERC-7683 cross-chain intents?
ERC-7683 cross-chain intents are protocol-defined orders that can be expressed to solvers through the ERC-7683 resolution model. The intent describes an offer of payment in exchange for satisfying defined requirements, while a solver executes those requirements.
Is ERC-7683 finalized?
As of September 2026, ERC-7683 is listed as a Draft Standards Track ERC. Builders should therefore verify the current specification rather than relying on older implementations or descriptions.
What is an ERC-7683 solver?
A solver is an actor that evaluates an order's resolved requirements, chooses necessary variable values, executes required actions and expects payment after fulfillment according to the underlying protocol.
Is solver the same as filler?
The terms are commonly used for the same broad execution role. Filler often emphasizes the actor that fulfills an order, while solver can also describe the broader off-chain service responsible for evaluating, pricing and executing intent opportunities.
What is an ERC-7683 resolver?
A resolver is a contract that translates an intent protocol's opaque payload into the common ERC-7683 solver-facing representation and validates the order according to the guarantees and assumptions required by the specification.
What does a ResolvedOrder contain?
The current ERC-7683 ResolvedOrder contains arrays of execution steps, variables, payments and assumptions. This differs from the earlier ResolvedCrossChainOrder design.
What happened to GaslessCrossChainOrder?
GaslessCrossChainOrder was part of an earlier ERC-7683 design. The current draft no longer standardizes that structure. Protocols can still implement gasless authorization, but authorization and payload formats remain protocol-specific.
Does ERC-7683 still use IOriginSettler?
IOriginSettler belongs to an earlier version of the standard. The current resolver-centric draft does not require protocols to implement one universal origin settler interface.
Does ERC-7683 still use IDestinationSettler?
IDestinationSettler was part of the previous draft. The current standard describes execution using general-purpose resolved steps rather than requiring a universal destination fill interface.
What is an origin settler?
Origin settler is a useful conceptual term for source-side order or payment logic. Earlier ERC-7683 drafts standardized IOriginSettler, but current ERC-7683 leaves origin authorization and settlement implementation to each protocol.
What is a destination settler?
A destination settler generally refers to the destination-side component where fulfillment is performed or recorded. Earlier ERC-7683 drafts standardized IDestinationSettler, but the current standard no longer requires that specific interface.
Can ERC-7683 orders still be gasless?
Yes. A protocol can use off-chain signatures, permits, relayers, resource locks or other mechanisms that let users authorize an order without broadcasting the origin transaction themselves. ERC-7683 does not prescribe one gasless design.
Does gasless mean the order cannot move my tokens?
No. A gasless signature can authorize another party or protocol to perform asset-moving actions later. Users should inspect the actual authorization even when they do not pay gas at signing time.
What are ERC-7683 steps?
Steps describe actions the solver must execute. Current ERC-7683 defines general Call steps that can include dependencies, token-spending requirements, gas requirements, timing bounds and revert policies.
What is SpendsERC20?
SpendsERC20 is a Call attribute that discloses that execution may transfer ERC-20 tokens from the caller through a spender up to an amount determined by the order's formula.
What is SpendsGas?
SpendsGas describes the gas an execution step may require. Where it is absent, a solver may estimate gas through simulation when the required prerequisites are available.
What is TimingBounds?
TimingBounds constrains when a call may be included according to block number or block timestamp. It can therefore express execution windows or deadline-like requirements for individual steps.
What is RevertPolicy?
RevertPolicy describes how a solver should handle a specific expected revert reason. Supported behavior can include ignoring the specified revert or aborting the order. Unexpected reverts should not be silently accepted.
What are ERC-7683 variables?
Variables are values decided, observed, queried or obtained during order execution. Examples include payment recipient, payment chain, step caller, execution output, witness data, contract query results and event-query results.
What are named assumptions?
Named assumptions describe external conditions the resolver cannot guarantee on its own. The solver must validate those assumptions before executing the order.
Does ERC-7683 guarantee that an intent protocol is secure?
No. ERC-7683 standardizes how an order is described to solvers. The underlying protocol's settlement contracts, tokens, bridges, oracles, cross-chain systems and off-chain infrastructure retain their own security assumptions.
Can a resolver be secure while the protocol is unsafe?
Yes. A resolver can accurately describe an order and its assumptions while the underlying settlement protocol still relies on a mechanism the solver considers unsafe.
How does ERC-7683 prevent replay attacks?
It does not define one universal replay-protection mechanism. Replay resistance remains part of the underlying protocol's authorization and settlement design, including nonces, order-state tracking, signature domains and consumed-order logic.
Does ERC-7930 help with ERC-7683 security?
ERC-7930 provides interoperable addresses that bind chain context with the target address, reducing ambiguity about which chain an address belongs to. It does not replace protocol-level replay protection or authorization controls.
Can ERC-7683 orders be partially filled?
The current standard does not require one universal partial-fill model. Intent protocols can design their own partial-fill behavior and expose the resulting execution and payment requirements through their resolvers.
How is settlement verified?
Settlement verification is protocol-specific. It can depend on escrow state, resource locks, messages, proofs, oracles, bridge infrastructure, events or other mechanisms. ERC-7683 does not prescribe one universal verification system.
Why is cross-chain messaging relevant to ERC-7683?
A solver can perform destination execution while payment exists on another chain. The underlying protocol may use cross-chain messaging or proofs to establish that fulfillment occurred before releasing payment.
Can ERC-7683 reduce solver integration work?
That is one of its main goals. A solver can vet and support resolver contracts that produce a common execution representation instead of implementing custom protocol-specific logic for every order format.
Does ERC-7683 guarantee competitive filler markets?
No. A common interface can make broader solver participation easier, but real competition still depends on order distribution, liquidity, solver availability, auction design and whether independent fillers can access the order flow.
What should users check in an intent quote?
Users should verify the origin chain, input asset, maximum amount spent, destination chain, destination asset, recipient, minimum expected output, deadline, authorization scope and any approval or signature requested by the application.
What should a solver verify before executing an order?
A solver should verify the resolver, resolved steps, dependencies, token spending, gas, timing, variables, payment path, assumptions, current order state, protocol settlement security and all relevant cross-chain dependencies.
How does ERC-7683 relate to the Open Intents Framework?
ERC-7683 provides a standardized solver-facing order representation. The Open Intents Framework is a broader infrastructure framework for deploying and operating intent systems. OIF can use ERC-7683, but the two are not interchangeable concepts.
Is ERC-7683 a replacement for bridges?
No. Intent protocols can still depend on bridges, messaging systems and cross-chain proofs for settlement. ERC-7683 standardizes solver-facing order interpretation rather than replacing underlying interoperability mechanisms.
What is the most important ERC-7683 security principle?
A solver should be able to understand every material obligation and payment condition before committing capital. Requirements that cannot be enforced by the resolver or protocol should be surfaced as assumptions rather than hidden.
References and further reading
The following primary technical sources provide the authoritative basis for the current ERC-7683 architecture and its role in Ethereum interoperability.
- ERC-7683: Cross Chain Intents
- ERC-7930: Interoperable Addresses
- Ethereum Foundation Protocol Update 003: Improve UX
- Open Intents Framework Documentation
This article is educational security research. ERC-7683 is an evolving draft standard, and intent protocols can implement materially different authorization, execution and settlement systems beneath the common solver-facing interface. Verify the current ERC specification, deployed resolver, settlement contracts, bridge or messaging assumptions, token behavior and user authorization before relying on any cross-chain implementation.
