Intent-Based Trading

Users specify a desired outcome (declarative intent) rather than the exact sequence of transactions (imperative execution). For example, a user declares "Swap ETH for USDC at the best rate" instead of manually finding liquidity pools, calculating slippage, and signing multiple transactions. This abstracts away complexity, allowing intent solvers to compete to find the optimal path.

Specialized actors called solvers or fillers compete in a permissionless market to fulfill user intents. They propose optimized transaction bundles that achieve the user's goal, often by leveraging cross-protocol liquidity and complex MEV (Maximal Extractable Value) strategies. The user receives the best-found solution, turning potentially harmful MEV into a source of execution quality and cost savings.

Intent architectures often allow gas sponsorship, where the solver pays the transaction gas fees. The cost is bundled into the overall execution quote. This enables gasless transactions for the end-user, removing a major UX hurdle. Payment can be in the transaction's input/output assets (e.g., paying fees in the USDC you receive), simplifying the user experience significantly.

Complex, multi-step DeFi operations are executed as a single atomic transaction. An intent like "Deposit ETH as collateral, borrow DAI, and swap 50% for USDC" is resolved into a bundle that either completes entirely or fails without leaving partial state changes. This eliminates liquidation risk between steps and guarantees the user only receives their desired, complete outcome.

Instead of signing a specific transaction, users sign a message representing their intent, often using EIP-712 structured signatures. This signed intent is broadcast to a network of solvers. Critical innovations like ERC-4337 account abstraction and intent-specific signature schemes enhance security by limiting the solver's authority to only actions that fulfill the precise, signed objective.

A typical intent-based system involves several key components:

• User: Signs and submits an intent.
• Intent Pool / Mempool: A shared space where intents are published.
• Solver Network: Entities that compute and bid on execution solutions.
• Aggregator / Auction Mechanism: Selects the winning solver based on price and quality (e.g., Dutch auction).
• Settlement Layer: Ensures atomic execution of the winning bundle on-chain.

The computational backbone of intent-based systems. Solvers (or fillers) are specialized actors who:

• Compete in off-chain auctions to fulfill user intents.
• Source liquidity across DEXs, private pools, and their own inventory.
• Propose optimal settlement paths, bundling multiple intents for efficiency.
• Submit the final transaction to the blockchain, paying gas fees and earning a fee or spread.

Intent-based trading fundamentally changes the user's interaction model:

• From Transaction Specification to Outcome Declaration: Users state what they want (e.g., "swap X for at least Y of Z"), not how to do it.
• Gas Abstraction: Users often don't pay gas directly; solvers bundle and pay fees, potentially offering gasless or sponsored transactions.
• Asynchronous Execution: The user signs an intent and can go offline; fulfillment happens later by the solver network.

Solvers are specialized agents that compete to fulfill user intents in a permissionless market. They are responsible for:

• Finding optimal execution paths across DEXs, bridges, and other protocols.
• Submitting the winning transaction bundle to the blockchain.
• Earning rewards (often via MEV) for providing the best-priced fulfillment.

Examples include professional market makers, arbitrage bots, and specialized intent-solving DAOs.

Domain-Specific Languages (DSLs) and standards provide the grammar for expressing intents. They define the rules and constraints a solver must satisfy.

• EIP-712 Signed Typed Data: Often used for signing intent messages off-chain.
• Project-Specific DSLs: Frameworks like Anoma's Taiga or CowSwap's CoW AMM intent system.
• Composability: A standard DSL allows intents to be aggregated, nested, and fulfilled across different applications.

These are the user-facing applications that collect and broadcast intents to the solver network. They act as the interface layer.

• Primary Role: Translate user goals into a structured intent, manage signatures, and broadcast to solvers.
• Examples: 1inch Fusion, CowSwap, and UniswapX are prominent intent-based aggregators.
• Fee Model: Often take a small percentage of the solver's reward or charge a flat protocol fee.

The User is the entity declaring a desired end state (e.g., "Swap X token for at least Y amount of Z token"). Key concepts:

• Off-Chain Signing: Users sign an intent message (a commitment) with their private key, which does not require gas.
• No Transaction Construction: The user delegates the "how" to solvers.
• Enhanced UX: Enables gasless interactions, batched operations, and complex conditional logic.

Specialized infrastructure for intents that span multiple blockchains. These protocols coordinate solvers across domains.

• Core Function: Manage the atomicity and security of cross-chain state changes specified in an intent.
• Components: Include verification layers (like light clients) and messaging systems to connect solvers on different chains.
• Example: A user intent to "Provide liquidity on Chain A if the APR is >X%, sourced from assets on Chain B."

The on-chain infrastructure that finalizes intent execution. This ensures solvers acted correctly according to the signed intent.

• Settlement Contract: A smart contract that receives the solver's transaction bundle, verifies it matches the intent constraints, and executes it atomically.
• Dispute Resolution: Some systems include a challenge period or fraud-proof mechanism to penalize malicious solvers.
• Finality: This layer provides the guaranteed on-chain outcome for the user.

Users must trust the solver network to execute their intents optimally and honestly. Key risks include:

• Solver Collusion: A dominant solver or cartel can extract maximal value (MEV) from user intents.
• Centralized Infrastructure: Reliance on a few major solver APIs or block builders reintroduces single points of failure.
• Liveness Failures: If no solver fulfills an intent, the user's desired outcome is not achieved, a unique denial-of-service risk.

The security of the declarative intent itself is paramount. Risks include:

• Ambiguous Specifications: Poorly defined constraints or preferences can lead to solvers fulfilling the letter, but not the spirit, of the intent (e.g., excessive fees).
• Signature Replay: An intent signature, if not properly constrained with nonces or specific solver addresses, could be maliciously reused.
• Frontrunning the Intent: The public broadcast of an intent can be frontrun by adversarial solvers or searchers before a legitimate solver acts.

Intents often span multiple blockchains, introducing interoperability risks:

• Bridge Exploits: Fulfillment may require asset transfers via bridges, which are frequent attack targets.
• Partial Execution: A solver may fulfill part of an intent on one chain but fail on another, leaving users with stranded assets.
• Oracle Manipulation: Intents conditional on external data (e.g., "swap when price is X") depend on the security of price oracles.

Broadcasting intents to a solver network leaks sensitive trading information:

• Strategy Exposure: Complex intents reveal a user's trading strategy, allowing solvers to anticipate and profit from future moves.
• Wallet Linkability: Intent patterns can link disparate addresses to a single entity, compromising pseudonymity.
• Mempool Sniping: Unlike a private transaction, a public intent is a visible target for exploitation until fulfillment.

Verifying that a solver's proposed solution is optimal is computationally difficult, creating a verification gap:

• Prover-Verifier Model: Users must trust the solver's proof of optimal execution or pay high gas fees to verify complex fulfillment paths on-chain.
• Opaque Fee Structures: Solver fees and extracted MEV may be hidden within complex transaction routing, reducing transparency.
• Post-hoc Audits: Tools like MEV-Explore and EigenPhi are needed to audit whether execution matched the best possible outcome.

Emerging designs aim to reduce these risks:

• Solver Bonding & Slashing: Solvers post collateral (bonds) that can be slashed for malicious behavior.
• Decentralized Solver Networks: Permissionless networks with competitive solving (e.g., CowSwap's solver competition).
• Intent Standardization: Well-defined standards (like ERC-7521 for intents) reduce ambiguity and enable safer client-side simulation.
• Encrypted Mempools: Using threshold decryption to hide intent details until they are ready for execution.

This is the core paradigm shift. Imperative transactions (standard today) are step-by-step instructions: "call function X on contract Y with parameters Z." Declarative transactions (intents) state a desired end state: "I want my wallet to hold at least 1000 USDC." The burden of figuring out the 'how' shifts from the user/wallet to the solver network, dramatically simplifying the user experience.

A cryptographic primitive where a user signs a message granting permission for a future transaction only if specific conditions are met. This is how intents are secured. The user signs their intent (the condition), not a specific transaction. A solver can then submit a transaction that fulfills the condition, and the signature validates it. This enables MEV protection and atomicity—the trade either executes exactly as intended or fails entirely.