{"id":"ERC-7683","name":"Cross Chain Intents Standard","status":"Draft","chain":"both","category":{"id":"cross-chain","name":"Cross-Chain","description":"Moving assets and messages between chains"},"journeyStages":[{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"},{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"ERC-7683 defines a solver-facing resolver interface for opaque cross-chain protocol payloads. Applications can express protocol-specific intents and let resolvers evaluate them, while order shape, settlement, fills, pricing, and recovery remain properties of the selected protocol rather than guarantees of the ERC.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-7683","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-7683","specConstraints":[{"id":"ordered-fulfillment","constraint":"Fulfillment must follow acyclic hard dependencies and use decided variables consistently.","appliesTo":"infrastructure","normativity":"normative","specQuote":"To fulfill the requirements of an order, each step MUST be executed as specified, and variable values MUST be decided as specified and used consistently.\n\nA step or variable can have *hard dependencies* on other steps and variables as documented below. Not every mention of a variable is a hard dependency. Hard dependencies MUST be acyclic. Fulfillment MUST proceed in hard-dependency order, i.e., a step MUST NOT execute before its hard dependencies have successfully executed.","specSection":"Specification / Orders","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Represent prerequisite and completed steps separately. Do not mark a dependent action executable before its prerequisite succeeds or change a decided value between steps."},{"id":"solver-token-allowance","constraint":"The solver must provide sufficient caller balance and spender allowance for a SpendsERC20 step.","appliesTo":"infrastructure","normativity":"normative","specQuote":"The solver MUST ensure the caller account has balance of `token` and allowance for `spender` of at least said amount.","specSection":"Specification / Orders / Step: Call / SpendsERC20","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"In solver-facing tools show the required asset, spender, amount, and available allowance. Do not confuse the solver's capital requirement with a universal request for an end-user approval."},{"id":"solver-gas-budget","constraint":"The solver must provide at least the gas specified by a SpendsGas attribute.","appliesTo":"infrastructure","normativity":"normative","specQuote":"The solver MUST ensure the call executes with a gas limit of at least said amount of gas.","specSection":"Specification / Orders / Step: Call / SpendsGas","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Surface an insufficient solver gas budget separately from the user's quoted output; use the resolved step rather than a universal cross-chain gas estimate."},{"id":"revert-policy","constraint":"A matching revert policy can allow a step to be skipped or require the whole order to abort.","appliesTo":"application","normativity":"normative","specQuote":"If the call would revert with data that begins with `expectedReason`, the solver MUST proceed according to `policy`:\n\n- `ignore`: The step MUST be considered executed. The solver MAY safely skip this action and proceed with fulfillment. An included reverted transaction MUST NOT be required.\n- `abort`: The entire order MUST be aborted.\n\nA call MUST NOT revert without a matching `RevertPolicy` attribute.","specSection":"Specification / Orders / Step: Call / RevertPolicy","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Distinguish ignored or skipped steps from aborted orders and actual included reverts. An ignored step does not require a reverted transaction, and an abort is not a standardized refund promise."},{"id":"timing-bounds","constraint":"A call's inclusion must satisfy the order's configured execution-time bounds.","appliesTo":"application","normativity":"normative","specQuote":"The call MUST be included onchain such that the value of `field` observed when executed is at least `lowerBound` and at most `upperBound`.","specSection":"Specification / Orders / Step: Call / TimingBounds","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Show whether a bound uses block height or timestamp and whether the step is not yet eligible or too late. A local countdown is not proof of valid onchain inclusion."},{"id":"solver-payment","constraint":"Payments are tied to a specified step, asset, amount formula, recipient, and chain.","appliesTo":"infrastructure","normativity":"normative","specQuote":"When the step numbered `onStepIdx` is executed, a payment MUST be made of at least the amount given by `amountFormula` of `token` sourced from `sender`. The payment MUST be transferred to the address value of the variable numbered `recipientVarIdx`, on the chain indicated by `token`. The payment SHOULD be delayed by `estimatedDelaySeconds` with high confidence.","specSection":"Specification / Orders / Payments / ERC20","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Separate fulfillment from final spendable settlement. Show the payment asset and network and treat the stated delay as an estimate, not a universal completion deadline."},{"id":"resolver-fulfillment-obligation","constraint":"Resolvers must guarantee fulfillment and payment unless an explicitly specified abort policy is triggered.","appliesTo":"infrastructure","normativity":"normative","specQuote":"A resolver MUST guarantee that an order may only abort as explicitly specified in revert policies. If no abort policy is triggered, a solver that begins to execute the steps of an order MUST be able to fulfill all requirements and receive all payments.","specSection":"Specification / Resolvers","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Evaluate the selected resolver and its assumptions before presenting an order as fillable. This resolver obligation is not a promise that any arbitrary protocol, token, or cross-chain system is safe."},{"id":"implicit-assumptions","constraint":"Solvers must review a resolver's implicit assumptions before trusting it.","appliesTo":"infrastructure","normativity":"normative","specQuote":"Liveness and censorship resistance of the underlying chains MAY be implicitly assumed. A particular resolver MAY make and document additional implicit assumptions (e.g., the security of a particular protocol). A solver MUST review all such implicit assumptions before a trusting a resolver.","specSection":"Specification / Resolvers","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Make the chosen resolver, chain-liveness assumptions, and additional protocol trust assumptions available during integration review. Standards compliance alone does not establish those assumptions."},{"id":"named-assumptions","constraint":"Order-specific assumptions must be named and validated by the solver before fulfillment.","appliesTo":"infrastructure","normativity":"normative","specQuote":"Additional assumptions for a given order must be identified by a name and may be parameterized by data.\n\nA solver MUST validate the assumption (e.g., checking against a whitelist) before fulfilling the order.","specSection":"Specification / Resolvers / Named Assumptions","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Provide a blocked or unverified state when an assumption cannot be established; do not silently accept an unknown assumption name."},{"id":"offchain-resolution","constraint":"The resolver translates and validates protocol payloads offchain through eth_call.","appliesTo":"application","normativity":"rationale","specQuote":"A compliant intent protocol must implement and deploy a resolver, along with a payload format that encodes orders for that protocol. The resolver contract must validate and interpret order payloads, and produce instructions for solvers to follow.\n\nResolution happens offchain via `eth_call`, even though the resolver is published onchain. Because resolution is not required to be included in an onchain transaction, the payload and translation process are not constrained by onchain gas costs. Resolvers can therefore support semantically rich orders and perform complex decoding, validation, and instruction generation without forcing that complexity into calldata or emitted events.","specSection":"Rationale / Resolver-Centric Standardization","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Do not request an additional signed transaction merely to resolve the payload. Keep resolver output, user authorization, execution, and settlement as distinct parts of the selected protocol."},{"id":"execution-context","constraint":"Execution must use the intended chains, contracts, and relevant order payload data.","appliesTo":"infrastructure","normativity":"rationale","specQuote":"An important component of the standard is creating a flexible and robust mechanism for solvers to ensure their executions are valid. For execution to be valid, it typically must satisfy the following constraints:\n\n1. It must be executed on the correct chain(s)\n2. It must be executed on the correct contract\n3. It must include some (not necessarily all) information from the order payload\n4. It may require some execution information from earlier steps, e.g. auctions based on inclusion timing","specSection":"Rationale / Execution Instructions","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"In a solver or order-inspection view bind each execution step to its chain and contract, and keep context visible when a step depends on earlier execution data."},{"id":"settlement-trust-boundary","constraint":"ERC-7683 does not guarantee the security of the underlying settlement protocol.","appliesTo":"application","normativity":"security-considerations","specQuote":"This ERC standardizes how a protocol describes an order to solvers; it does not standardize or guarantee the security of the protocol that ultimately settles the order. A resolver can describe the steps, payments, and assumptions for an order, but the safety of following those instructions depends on the resolver implementation, settlement contracts, assets involved, and any offchain or cross-chain systems used by the protocol.\n\nResolver implementations should document any implicit assumptions they rely on beyond those allowed by this ERC, so solvers and auditors can evaluate them alongside the explicit assumptions included in resolved orders.\n\nSolvers are exposed to risk from the time they commit capital, approvals, or transactions to an order until their expected payment is final and spendable. Security analysis should therefore cover the full execution and settlement window, including adversarial changes to protocol state, chain state, token behavior, oracle values, permissions, or message-delivery paths that could make previously valid instructions or assumptions unsafe.\n\nAudits of resolver and protocol implementations should focus on whether a solver that correctly follows resolver instructions can be led into an insecure position. In particular, they should verify that all requirements needed for solver safety are either enforced by the resolver or protocol or surfaced as assumptions, that execution steps cannot spend solver assets, require solver permissions, or create solver obligations except as disclosed by the resolved order, and that payment paths cannot be invalidated after the solver has incurred costs.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7683","designImplication":"Disclose protocol-specific trust and recovery assumptions. Keep risk visible through final spendable payment, and do not portray a resolved order, audit label, or successful first step as proof that settlement is safe."}],"summary":"ERC-7683 defines a solver-facing resolver interface for opaque cross-chain protocol payloads. Applications can express protocol-specific intents and let resolvers evaluate them, while order shape, settlement, fills, pricing, and recovery remain properties of the selected protocol rather than guarantees of the ERC.","partialDeployment":{"body":"ERC-7683 is Draft. Treat intent and resolver flows as conditional until the selected protocol, solver or resolver, settlement, quote, and recovery implementations are verified; the ERC does not guarantee an order fill, refund, or route."},"applicability":{"whenToUse":["Your users must manually navigate cross-chain operations.","Your product addresses: finding best route across chains is complex.","The flow should deliver: express a protocol-specific intent and disclose the resolver's fill and recovery assumptions.","You are designing a intent-based cross-chain swap experience with visible states and recovery paths."],"whenToAvoid":["The product never submits a cross-chain intent to a resolver.","The selected protocol has no solver or resolver quote flow to compare.","The application cannot describe the chosen settlement and recovery policy.","The product only performs same-chain actions."]},"designerTakeaways":["Design the flow to support express intent \"get USDC on Base\".","You can compare resolver or solver offers when the selected protocol exposes them.","You can show fill, abort, and recovery states according to the selected settlement protocol; the ERC does not guarantee a refund."],"problemsSolved":[{"problem":"Users must manually navigate cross-chain operations","oldWay":"Bridge ETH to Arbitrum → wait → swap on Arbitrum → bridge to Base → wait...","newWay":"Express a protocol-specific intent; the selected resolver/provider handles its documented steps","impact":"critical"},{"problem":"Finding best route across chains is complex","oldWay":"Compare bridge fees, DEX rates, gas costs across chains manually","newWay":"A selected resolver evaluates the protocol payload; quotes and execution depend on that resolver","impact":"critical"},{"problem":"Stuck transactions on bridges","oldWay":"TX stuck mid-bridge, unclear status, manual recovery","newWay":"Display protocol-specific fill, abort, ignored-step, and recovery states instead of promising a universal refund","impact":"high"},{"problem":"Different bridges = different interfaces","oldWay":"Learn Hop, learn Across, learn Stargate... all different UX","newWay":"A resolver interface carries opaque protocol payloads without requiring one common order or settlement ABI","impact":"high"}],"uxPatterns":[{"name":"Intent-Based Cross-Chain Swap","description":"Express a desired outcome and inspect the selected resolver/provider assumptions","userFlow":["User specifies what they have and where","User specifies what they want and where","Resolver/provider offers are shown when available","User accepts an offer after reviewing its settlement and recovery assumptions","Sign intent transaction","Selected resolver/protocol executes its documented settlement path","User sees the provider-specific delivery or failure state"]},{"name":"Intent Status Tracking","description":"Track cross-chain intent fulfillment","userFlow":["Intent signed and submitted","Resolver/provider reports its protocol-specific state","Track progress only where the selected protocol exposes it","Show route and settlement assumptions when supplied","Confirm delivery or abort according to provider evidence"]},{"name":"Multi-Solver Comparison","description":"Compare offers from competing solvers when the selected protocol exposes them","userFlow":["Request quotes from multiple resolvers or solvers when the selected protocol exposes that flow","Display returned offers ranked by output amount","Show route and time when supplied by the provider","User selects a preferred offer only when the protocol supports selection","Show quote expiry when the provider supplies it"]},{"name":"Intent History","description":"View past cross-chain intents","userFlow":["View list of past intents","See completed, pending, expired","Expired intents show the protocol-specific abort or recovery status","Click to view full details"]}],"uiComponents":[{"name":"CrossChainInput","description":"Input with chain and asset selection","states":["empty","valid","insufficient","chain-mismatch"],"props":["chains[]","assets[]","balance","onChainChange","onAssetChange"]},{"name":"SolverOfferCard","description":"Display resolver/solver offers when the selected protocol supplies quotes and route details.","states":["loading","quoted","expired","accepted"],"props":["solver","outputAmount","route","estimatedTime","onAccept"]},{"name":"IntentStatusTracker","description":"Track selected protocol/provider status when available; ERC-7683 does not define filling or delivery stages.","states":["pending","claimed","filling","delivered","expired"],"props":["intentId","steps[]","currentStep"]},{"name":"ChainRouteDisplay","description":"Show selected protocol/provider route steps when supplied.","states":["preview","in-progress","completed"],"props":["sourceChain","destChain","intermediateSteps[]"]}],"antiPatterns":[{"pattern":"Showing only one solver option","why":"User can't compare, may get worse rate","instead":"Show multiple solver offers with comparison","severity":"high"},{"pattern":"Hiding the route taken","why":"Users can't understand where their funds are","instead":"Show bridge/DEX route for transparency","severity":"high"},{"pattern":"No expiration on quotes","why":"Stale quotes lead to failed fills or bad rates","instead":"Show countdown timer, refresh quotes automatically","severity":"high"},{"pattern":"Unclear refund mechanism for unfilled intents","why":"Users panic if intent expires, don't know about refund","instead":"Explain the selected protocol's expiry, abort, and recovery behavior without promising a universal refund","severity":"medium"}],"keyTakeaways":["Intents = user says WHAT they want, not HOW to get it","Show multiple resolver/solver offers with rate comparison when the protocol supports them","Display route and estimated time with the provider/source of each value","Handle expiration, abort, and recovery according to the selected settlement protocol"],"technicalNotes":"ERC-7683 currently defines a solver-facing resolver interface for opaque protocol payloads. It does not require a common CrossChainOrder struct, escrow, settlement contract, or fill function. Its RevertPolicy allows a step to be ignored or to abort, and the ERC does not standardize the selected settlement protocol's security or refund guarantees. Treat older CrossChainOrder/settler language as an earlier draft and label partial fills, auctions, quotes, and recovery as protocol-specific.","lastUpdated":"2026-09-18","sources":[{"label":"ERC-7683 official specification","url":"https://ercs.ethereum.org/ERCS/erc-7683","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7683","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-7683","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-7683","markdown":"https://www.eipsfordesigners.com/standards/ERC-7683/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-7683/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-7683","official":"https://ercs.ethereum.org/ERCS/erc-7683","discussion":"https://ethereum-magicians.org/search?q=ERC-7683"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}