ERC-7521 is a proposed Ethereum standard that defines a general-purpose intent framework for smart contract wallets built on ERC-4337. Rather than requiring users to construct exact transaction calldata, ERC-7521 lets a wallet express a desired outcome, such as "receive at least 100 USDC for this ETH," and delegates the mechanics of execution to a network of competing solvers. The specification was authored by the Account Abstraction Working Group and lives on the Ethereum Improvement Proposals repository.
​

ERC-7521 is a general-purpose intent framework for ERC-4337 smart accounts. It standardizes how wallets express desired outcomes onchain by defining an intent object with four components: segments (sub-intents), a signature, a deadline, and a reference to an intent standard module. Solvers read the intent object and compete to find the best execution path that satisfies the user's conditions.
​

The standard's core insight is a clean separation between intent expression (the wallet's side) and intent fulfillment (the solver's side). Before ERC-7521, wallets building intent-like behavior needed custom, non-composable formats. Each protocol invented its own signed-order schema, which meant solvers had to maintain separate integrations for every wallet type. ERC-7521 provides a shared envelope that any ERC-4337 account can populate and any solver can read, similar to how ERC-20 standardized token interfaces so any exchange could list any token without a bespoke integration.
​

The specification is authored by members of the Account Abstraction Working Group and is currently in draft stage on the Ethereum Improvement Proposals repository. It complements rather than replaces ERC-4337's UserOperation flow: ERC-4337 handles account validation and bundling; ERC-7521 handles how wallets express preferences before that pipeline runs.
​

An intent is a signed statement of a desired outcome rather than a specific sequence of transaction steps. The user specifies what they want, such as receiving at least 100 USDC for a given amount of ETH, and a solver finds and executes the best path to achieve that result. The user never writes calldata or selects a router; the solver handles execution and takes on the ordering risk.
​

The contrast with a standard transaction is concrete. A traditional swap transaction calls a router function directly: router.exactInputSingle({ tokenIn: WETH, tokenOut: USDC, amountIn: 1e18, amountOutMinimum: 1950e6, ... }). Every parameter is fixed at signing time. If the market moves or a better route becomes available between signing and execution, the user gets the original parameters, no more. An intent-based swap instead encodes a constraint: "give me at least 1,950 USDC for 1 WETH, settled before block N." The solver picks the router, selects the pool, and can aggregate across multiple venues. Any surplus above 1,950 USDC may go to the solver as profit, aligning the solver's incentive with finding the best price.
​

This model is not new to DeFi. CoW Protocol has used a similar signed-order approach since 2021, and 1inch Fusion introduced solver-based fills in 2022. ERC-7521 generalizes this pattern at the protocol level so any smart contract wallet can participate without custom integration work. The innovation is not the concept of intents but the standardized envelope that makes intents composable across wallets and solvers.
​

Understanding the trust assumptions matters here. When a user signs an ERC-7521 intent, they are trusting the intent standard module that validates fulfillment and the deadline field that bounds execution time. The solver cannot steal funds; the smart account's validation logic enforces the stated constraints. This is a trustless design in the sense that correct execution is enforced by code, not by trusting the solver's honesty.
​

ERC-7521 works by defining a structured intent object that smart accounts sign. The object contains four fields: segments (an array of sub-intents, each specifying a constraint), a signature, a deadline (block number or timestamp after which the intent expires), and an intent standard identifier pointing to the pluggable module that knows how to validate and execute that segment type. Solvers fetch unexecuted intents, compute a profitable fill, and submit execution transactions against the smart account's ERC-7521 handler.
​

The execution lifecycle has two phases. In the validation phase, the smart account's ERC-7521 handler checks the signature, confirms the deadline has not passed, and calls the referenced intent standard module to verify that the proposed execution satisfies the stated constraints. In the execution phase, the solver's transaction calls the relevant protocols (DEXs, lending pools, bridges) and then proves fulfillment back to the intent standard module. If the fulfillment check fails, the transaction reverts.
​

The EIP-7521 specification defines the intent object schema at the ABI level. The segments field is an array of IntentSegment structs, each containing a reference to an IIntentStandard address and standard-specific data. This means a single intent can combine heterogeneous constraints: one segment expressing a swap requirement and another expressing a conditional transfer, validated sequentially by their respective modules. The modular design keeps the core envelope lightweight while allowing arbitrarily complex intent logic in the plugged-in standards.
​

Deadline enforcement is straightforward. A block-number deadline means the solver must include the fulfillment transaction in a block at or before the specified height. Timestamp-based deadlines work similarly. Expired intents are permanently invalid; no cancellation transaction is required because the smart account rejects any fulfillment attempt after the deadline. This approach borrows the pattern established by Uniswap v3's deadline parameter but enforces it at the wallet level rather than the router level.
​

ERC-7521, ERC-4337 UserOperations, and ERC-7683 address related but distinct problems. ERC-4337 UserOperations define how smart account transactions are bundled and validated. ERC-7521 sits on top of ERC-4337 and defines how preferences and constraints are expressed before bundling. ERC-7683 extends the intent model to cross-chain fills. The table below summarizes the key differences across five dimensions.
​

ERC-7521 and ERC-7683 are complementary rather than competing. A wallet could sign an ERC-7521 intent for a single-chain conditional swap and a separate ERC-7715-scoped permission for a cross-chain transfer settled via ERC-7683. All three operate within the ERC-4337 smart account ecosystem. The key architectural distinction is that ERC-7521 governs preference expression while ERC-7683 governs cross-chain settlement; neither duplicates the other's function. See the EIP-7683 specification for the cross-chain fulfillment model.
​

Intent standards are smart contracts that implement the IIntentStandard interface defined in ERC-7521. Each standard encodes the validation and fulfillment logic for a specific intent type. A swap intent standard checks that the output token balance increased by the required amount. A transfer intent standard checks that a target address received a specified value. A conditional intent standard evaluates an onchain oracle condition before allowing fulfillment. Any address implementing the interface can register as an intent standard.
​

This plug-in architecture follows the same logic that made ERC-4337 itself composable. Just as ERC-4337 defines a validateUserOp interface that any account can implement, ERC-7521 defines a validateIntent and executeIntent interface that any module can implement. Wallets reference the module address in the intent's intentStandard field. Solvers inspect that address to understand what fulfillment looks like, compute a profitable fill, and submit accordingly.
​

Several intent types are feasible under the current specification:

The modular design means the community can develop and audit intent standard modules independently from the core ERC-7521 envelope. A module handling real-world asset settlement, for example, could enforce compliance constraints without modifying the base standard. This extensibility is one of the reasons the Ethereum Magicians discussion drew significant interest from account abstraction teams building products across DeFi verticals. DeFi protocols building limit order systems, automated yield strategies, and conditional execution flows are the natural adopters of this standard.
​

ERC-7521 shifts MEV exposure from users to solvers by turning execution into a competition rather than a direct transaction. When a user submits a standard swap, their transaction is publicly visible in the mempool. MEV bots can sandwich it, inserting buys before and sells after the user's trade to extract value. With ERC-7521, the user never broadcasts a concrete swap transaction; they broadcast a signed intent with constraints. Solvers compete privately or via protected channels to produce the best fulfillment, reducing the surface for sandwich attacks.
​

The mechanism is not MEV elimination but MEV redirection. Solvers bear the ordering risk; their profit comes from finding better execution than the minimum stated in the intent, not from attacking users. A solver who captures a favorable fill earns the spread between the user's minimum and the market price. This competition among solvers is structurally similar to how Flashbots MEV-Share routes MEV back to users: competitive solvers have incentive to find better prices, and users set a floor below which they will not settle.
​

In practice, the MEV protection quality depends on solver competition. A thin solver market means fewer competing bids and potentially poorer fills. A deep solver market, as seen with CoW Protocol's network of professional market makers, produces fills that frequently beat onchain AMM prices for large orders. The ERC-7521 framework creates the conditions for this competition by standardizing how wallets express constraints, making it feasible for solvers to support many wallets from a single integration rather than building bespoke support for each wallet's custom order format.
​

Gas costs are also affected. Because the solver bundles fulfillment logic and can batch multiple intents into a single transaction, the per-intent gas overhead is lower than submitting individual transactions. Flashbots research on bundle efficiency shows batching can reduce effective gas costs by 20-40% for concurrent fills, though exact figures depend on the specific intent types and network conditions at execution time.
​

ERC-7521 is in draft stage as of April 2026, with active discussion on Ethereum Magicians and in the Account Abstraction Working Group. No major wallet has shipped a production implementation, but several teams building account abstraction infrastructure have cited the standard in their public roadmaps. The EIP was authored by developers affiliated with account abstraction projects and builds directly on ERC-4337's infrastructure, meaning wallets already running ERC-4337 have the foundational plumbing to add ERC-7521 support without a full rewrite.
​

The broader intent-based execution market gives context for why this standard matters. CoW Protocol processed over 1 million intent-based orders in 2023 using its own signed-order format. 1inch Fusion, which uses a resolver-competition model, launched in late 2022 and handles a significant share of 1inch's volume. Both demonstrate that solver markets for intent-based execution are real and competitive. ERC-7521's contribution would be lifting this capability from protocol-specific implementations to a shared standard that any ERC-4337 wallet can plug into.
​

Eco's intent-based architecture aligns closely with this direction. Eco Routes expresses user payment preferences as outcomes rather than calldata, with solvers on Ethereum, Optimism, Base, Arbitrum, and 11 other chains competing to fulfill transfers. As ERC-7521 matures toward finalization, wallets built on Eco's infrastructure would be natural candidates for early adoption, given that the solver-competition model is already operational across Eco's supported networks. The full EIP-7521 specification is public and open for implementation feedback.
​

Yes. ERC-7521 is built on top of ERC-4337 smart accounts. The intent object is validated and executed through the smart account's handler, which requires the account to implement the ERC-4337 interface. Externally owned accounts (EOAs) cannot use ERC-7521 directly without first being wrapped in a smart account.
​

An intent standard module is a smart contract that implements the IIntentStandard interface from ERC-7521. It encodes validation and fulfillment logic for a specific intent type, such as a swap or conditional transfer. Any developer can deploy a module and register it; wallets reference the module address inside the intent object's intentStandard field.
​

ERC-7521 handles single-chain intent expression for smart accounts. ERC-7683 handles cross-chain intent settlement, where a filler advances funds on the destination chain before being reimbursed on the origin chain. Both use intent-based design, but ERC-7521 is a generalized framework for any intent type while ERC-7683 is specifically scoped to cross-chain token fills.
​

Yes. The segments field in the ERC-7521 intent object is an array of sub-intents, each referencing its own intent standard module. A wallet can encode a swap constraint in one segment and a transfer requirement in another. The smart account validates all segments before accepting a fulfillment, making the full set of conditions atomic.
​

The intent expires and becomes permanently invalid. No cancellation transaction is required; the smart account's handler rejects any fulfillment attempt referencing an expired intent. The user's funds remain in their account untouched, and they can sign a new intent with updated parameters if market conditions have changed.
​

Sources and methodology. EIP details sourced from eips.ethereum.org and the Ethereum Magicians ERC-7521 thread. CoW Protocol order volume figures sourced from publicly available protocol data. Flashbots bundle efficiency data sourced from Flashbots documentation. Figures verified April 2026.
​