Intent-Based Transaction

Unlike traditional imperative transactions that specify every step (e.g., 'swap X for Y on DEX A, then bridge to chain B'), declarative intents state only the desired outcome (e.g., 'get the best price for 1 ETH in USDC on Arbitrum'). This abstraction shifts complexity from the user to specialized solver networks that compete to fulfill the intent optimally.

A network of specialized actors called solvers or fillers competes to discover and propose the most efficient execution path for a user's intent. This competition:

• Optimizes outcomes for users (best price, lowest cost).
• Transforms MEV (Maximal Extractable Value) from a user loss into a solver's reward for efficient execution.
• Creates a market for execution quality, where solvers profit by finding better routes than their competitors.

Intent architectures often abstract away transactional complexities:

• User signs an intent message, not a transaction. This signature can authorize a solver to execute a complex, multi-step bundle on their behalf.
• Gas fees can be sponsored by the solver and deducted from the output, allowing users to pay in the output token (e.g., pay for an ETH swap with the resulting USDC).
• Enables batch execution, where one solver's transaction fulfills intents for many users simultaneously, amortizing costs.

Intents natively enable complex, cross-protocol operations within a single declaration. A single intent can seamlessly orchestrate actions across:

• Multiple DEXs and AMMs for optimal price routing.
• Bridges for cross-chain asset transfers.
• Lending protocols for leveraged positions.
• NFT marketplaces for purchases with swapped funds. This creates a unified interface for DeFi lego without requiring users to manually chain transactions.

Delegating execution introduces new considerations:

• Solver trust: Users must trust the solver network's honesty or rely on cryptoeconomic security (slashing, bonds).
• Intent fulfillment guarantees: Systems require mechanisms to ensure a signed intent is fulfilled fairly and promptly, often using time limits or commit-reveal schemes.
• Privacy: Broadcasting an intent can reveal trading strategy; some systems use private mempools or encrypted order flows to mitigate.

A complete intent-based system typically involves:

• User Interface (UI): Where intents are composed and signed.
• Intent Standard: A common schema (e.g., EIP-4337 UserOperations for account abstraction, or Cross-Chain Intent Standard) for expressing desires.
• Solver Network: The competitive layer that finds execution paths.
• Aggregation Engine/Protocol: The core system that matches intents with solver solutions, verifies fulfillment, and settles.
• Execution Layer: The actual blockchain transactions submitted by solvers.

An intent is a declarative statement of a user's desired end state, signed and submitted to the network, without specifying the precise sequence of low-level operations required to achieve it. It outsources the responsibility of finding an optimal execution path to specialized network actors.

• Declarative vs. Imperative: Contrasts with traditional transactions that imperatively command the blockchain (e.g., 'swap 1 ETH for at least 3000 USDC on Uniswap V3').
• Flexibility: Allows solvers to leverage private order flow, MEV opportunities, and complex cross-domain routes to fulfill the user's goal efficiently.

The fulfillment of intents relies on a competitive ecosystem of solvers and aggregators.

• Solvers: Network participants (often sophisticated bots or professional market makers) that compete to discover and propose the most efficient fulfillment path for an intent, submitting a proof of fulfillment to claim a reward.
• Intent Aggregators: Applications or protocols (like CowSwap, UniswapX, or Flashbots SUAVE) that act as a user-facing interface. They collect user intents, manage the solver competition, and ensure the final settlement is valid and trust-minimized.

Intent-centric design fundamentally improves the blockchain user experience by abstracting away complexity.

• Gas Abstraction: Users often do not need to hold the native gas token for the chain they are interacting with; solvers can pay fees.
• Optimal Execution: Solvers are incentivized to find the best price across all liquidity sources, including off-chain venues, often resulting in better rates than a user could find manually.
• Simplified Interactions: Complex multi-step DeFi operations (e.g., cross-chain swaps with bridging) can be expressed as a single, simple intent.

Several cryptographic and economic mechanisms underpin secure intent-based systems.

• Signature Schemes: Intents are signed messages, often using EIP-712 for structured data, committing the user to their desired outcome and conditions.
• Fulfillment Proofs: Solvers must provide cryptographic proof that their proposed transaction bundle correctly satisfies the signed intent's constraints.
• Commit-Reveal Schemes: Used in auction mechanisms to prevent frontrunning and ensure solver competition is fair.
• Partial Fill Support: Intents can often be partially filled by multiple solvers over time until the total desired amount is acquired.

Intent-based transactions are closely related to, but distinct from, Account Abstraction (AA) as defined by ERC-4337. Both aim to improve UX, but through different means.

• ERC-4337 (UserOperations): Focuses on abstracting wallet logic, enabling gas sponsorship, batched transactions, and custom authentication—still largely imperative.
• Synergy: Intents can be signed by AA wallets, combining the UX benefits of smart accounts with the execution efficiency of a declarative network. Projects like Candide and ZeroDev are exploring this integration.

While promising, the intent-centric model introduces new design challenges and potential risks.

• Solver Centralization & Trust: The system's efficiency depends on a competitive solver market. Collusion or dominance by a few solvers could reduce benefits.
• Complexity in Verification: Ensuring a solver's fulfillment path is valid and optimal is computationally intensive and requires robust fraud-proof or cryptographic verification systems.
• MEV Implications: Intents can create new forms of MEV (e.g., solver extractable value) and require careful mechanism design to protect users.
• Standardization: Lack of universal standards for intent expression and fulfillment can lead to fragmented liquidity and user experience.

Users must trust the solver network to execute their intent optimally and honestly. Risks include:

• Solver Collusion: Solvers could form cartels to extract maximum value (MEV) from transactions.
• Centralization Pressure: The most efficient solvers may dominate, creating systemic risk if compromised.
• Malicious Solvers: A solver could front-run, censor, or fail to execute an intent, resulting in financial loss.

The security of an intent depends on its precise, unambiguous definition.

• Overly Broad Intents: A poorly defined intent (e.g., "get the best price") gives solvers excessive discretion, potentially leading to unfavorable outcomes.
• Oracle Dependency: Intents relying on external data (e.g., "swap when price hits $X") inherit the security risks of the oracles providing that data.
• Interpretation Attacks: Adversaries may exploit ambiguities in the intent's natural language or parameters.

Submitting an intent to a public mempool or solver network can reveal user strategy.

• Information Asymmetry: Solvers see the intent first, creating opportunities for front-running and sandwich attacks.
• Pattern Analysis: Repeated intents from a wallet can reveal trading strategies or asset holdings.
• Cross-Intent MEV: Solvers can bundle multiple user intents to extract value across transactions, potentially harming some users.

The new software stack for intents introduces novel attack surfaces.

• Intent Standard Vulnerabilities: Bugs in the EIP-4337 account abstraction standard or specific intent DSLs could be exploited.
• Solver Client Bugs: Faulty solver software could cause failed executions or financial loss.
• Network Censorship: Relayers or the solver network itself could censor certain intents or users.

While intents abstract transaction construction, users retain ultimate custody and signing authority.

• Signing Blindly: Users must still verify the final transaction bundle before signing, a complex task the intent paradigm aims to simplify.
• Social Engineering: Phishing attacks may trick users into signing malicious intent declarations.
• Smart Account Risk: Many intent systems use smart contract wallets (ERC-4337), which themselves can have vulnerabilities.

The legal status of delegating transaction construction is untested.

• Solver Liability: Who is liable for a failed or malicious execution—the user, the solver, or the protocol?
• OFAC Compliance: Solvers acting as intermediaries may become subject to sanctions screening requirements, leading to censorship.
• Consumer Protection: The "set it and forget it" nature of some intents may conflict with financial regulations requiring explicit user consent for each transaction.

This is the core paradigm shift. Imperative transactions (standard on-chain txs) specify the exact step-by-step commands (e.g., swap 1 ETH for USDC on Uniswap V3). Declarative transactions (intents) specify only the desired end state (e.g., I want at least 1800 USDC for my 1 ETH). The former gives control but requires expertise; the latter abstracts complexity, delegating pathfinding to the network.

A market mechanism where the right to execute a user's transaction (or intent) is auctioned to competing searchers or solvers. The goal is to ensure users receive the best execution by forcing solvers to compete on price, while also allowing them to monetize any MEV they uncover. This turns potentially extractive MEV into a rebate or better price for the user.

Protocols and specifications designed to express and fulfill intents across multiple blockchains. These standards tackle the challenge of atomic composability in a multi-chain environment. Examples include the Chainlink CCIP for cross-chain messaging, which can be a component in an intent-fulfillment path, and emerging frameworks from projects like Across and Socket that abstract bridging and swapping into a single declarative request.