Intent Architecture

What Is Intent Architecture?

Intent architecture is a protocol design pattern in which users express desired outcomes rather than specifying the exact sequence of on-chain operations needed to achieve them. In a traditional blockchain interaction, a user constructs a transaction that explicitly calls a specific contract function with specific parameters on a specific chain: "swap 1 ETH for USDC on Uniswap v3's ETH/USDC 0.3% pool." In an intent-based system, the user instead signs a declarative message: "I want at least 2,500 USDC for my 1 ETH, by this deadline."

This shift from imperative to declarative protocol design mirrors a well-established pattern in computer science. SQL lets users declare what data they want without specifying how the database retrieves it. HTML declares what a page should contain without specifying how the browser renders it. Intent architecture applies the same principle to blockchain transactions: users declare constraints, and a competitive market of specialized agents called solvers determines the optimal execution strategy.

The architectural pattern was first formalized in the Ethereum ecosystem around 2022 and 2023, with protocols like CoW Protocol, UniswapX, and Across Protocol building production systems around it. By 2025, intent-based systems had expanded from DEX trading into cross-chain bridging, chain abstraction, and generalized protocol interactions. The Ethereum Foundation launched the Open Intents Framework in early 2025, signaling that intent architecture had moved from experimental concept to core infrastructure.

How It Works

Intent architecture organizes protocol interactions into three distinct layers, each with clearly separated responsibilities:

The Intent Layer

The intent layer is where users define what they want. An intent is a signed, off-chain message that specifies constraints rather than instructions. It describes the desired outcome (tokens received, destination chain, minimum amounts) and the boundaries within which a solver must operate (deadlines, slippage limits, permitted settlement contracts).

Intents are typically signed using EIP-712 typed data, which produces a cryptographic commitment without submitting an on-chain transaction. This means users never pay gas at the intent creation step. The signed intent is broadcast to a solver network: a private order book, a batch auction queue, or a public relay.

// Simplified intent structure
{
  "action": "swap",
  "inputToken": "0xC02...WETH",
  "outputToken": "0xA0b...USDC",
  "inputAmount": "1000000000000000000",
  "minOutputAmount": "2500000000",
  "deadline": 1730000000,
  "sourceChain": 1,
  "destinationChain": 42161,
  "signature": "0x..."
}

The Solver Layer

The solver layer is where execution optimization happens. Solvers (also called fillers, resolvers, or relayers depending on the protocol) are off-chain agents that monitor incoming intents and compete to fulfill them. Each solver evaluates an intent, determines the most efficient execution path, and submits a solution to the auction mechanism.

Solvers can source liquidity from any combination of on-chain AMM pools, centralized exchange inventories, private market-maker networks, their own balance sheet, or other pending intents. This flexibility is the key architectural advantage: by abstracting execution behind a competitive market, the system can access liquidity sources that no single on-chain protocol could reach.

Different protocols use different auction mechanisms to select the winning solver. Batch auctions (CoW Protocol) optimize across multiple intents simultaneously. Dutch auctions (UniswapX, 1inch Fusion) use time-decaying prices to discover market-clearing rates. Request-for-quote systems (Across Protocol) have solvers bid directly on individual intents.

The Settlement Layer

The settlement layer is where on-chain verification occurs. After a solver executes an intent, a settlement contract validates that all user-specified constraints were met. If the fill satisfies the intent (correct tokens, sufficient amounts, within deadline), the contract finalizes the transfer. If not, the transaction reverts.

This layer enforces trustlessness: users do not need to trust solvers to behave honestly because the settlement contract programmatically verifies every fill. Solver bonds and slashing mechanisms provide additional accountability. If a solver fails to complete a fill they committed to, their staked collateral can be forfeited.

Imperative vs. Declarative Transactions

The core innovation of intent architecture is the shift from imperative to declarative transaction models. Understanding this distinction clarifies why the architectural pattern exists.

In imperative systems, the user bears the full complexity of route selection, gas estimation, and MEV avoidance. In declarative systems, that complexity shifts to professional solvers who can amortize infrastructure costs across thousands of intents.

Use Cases

Token Trading

Intent-based trading is the most mature application of intent architecture. Protocols like CoW Protocol, UniswapX, and 1inch Fusion use the pattern to deliver better execution prices, gasless swaps, and MEV protection. Solver competition consistently produces price improvement over direct AMM routing because solvers aggregate liquidity across on-chain pools, centralized exchanges, and private market makers.

Cross-Chain Bridging

Intent architecture simplifies cross-chain asset transfers by eliminating the need for users to interact with bridge contracts directly. Across Protocol uses an intent-based model where users express a desire to move assets between chains, and relayers front capital on the destination chain for near-instant delivery. The relayer is reimbursed after settlement verification through an optimistic oracle system.

This approach avoids the lock-and-mint security model that has been the source of billions of dollars in bridge exploits. Since solvers use their own capital on the destination chain, there is no shared liquidity pool for attackers to drain.

Chain Abstraction

Chain abstraction is an emerging application where intent architecture hides multi-chain complexity entirely. A user interacts with an application without knowing which chain their assets are on or which chain the transaction will settle on. The intent system routes the operation to whichever chain offers the best combination of cost, speed, and liquidity.

This approach is particularly relevant for stablecoin payments. A user holding USDC on one chain can pay a merchant who accepts USDC on a different chain, with the intent system handling the cross-chain routing invisibly. Protocols building in this direction aim to make the underlying blockchain infrastructure as invisible to end users as TCP/IP is to web users.

Generalized Protocol Interactions

While trading and bridging dominate current implementations, intent architecture is extensible to any protocol interaction. Lending intents could express "deposit my idle USDC into the highest-yielding lending protocol across all chains." Yield farming intents could express "allocate my capital across strategies to maximize risk-adjusted return." The Anoma protocol has pursued this direction with a design for generalized intents that can encode arbitrary state transitions, not just token transfers.

Cross-Chain Intent Standards

As intent-based protocols proliferated, the lack of a common standard created fragmentation. Each protocol defined its own intent format, solver interface, and settlement mechanism. Solvers had to build separate integrations for each protocol, and users were locked into whichever solver network their chosen protocol supported.

ERC-7683, co-authored by Uniswap Labs and Across Protocol, addresses this by defining a standard interface for cross-chain intents. The standard specifies:

• A common order structure (CrossChainOrder) that any intent protocol can use
• A resolved representation (ResolvedCrossChainOrder) that solvers use to evaluate and fill orders regardless of the originating protocol
• Two settlement interfaces: IOriginSettler for order initiation and IDestinationSettler for fill verification

The Ethereum Foundation's Open Intents Framework, launched in early 2025 with support from over 30 teams including Arbitrum, Optimism, Polygon, and zkSync, builds on ERC-7683 to create a shared solver network that can serve multiple rollups and chains simultaneously. This standardization is conceptually similar to how ISO 20022 standardizes messaging across traditional payment rails: a shared format that enables interoperability without requiring every participant to use the same platform.

Architectural Tradeoffs

Solver Centralization

The most significant tradeoff in intent architecture is the concentration risk at the solver layer. Running a competitive solver requires substantial capital, sophisticated execution algorithms, low-latency infrastructure, and integrations across multiple liquidity sources. These barriers to entry naturally favor well-capitalized firms. Research on TradFi-DeFi convergence highlights that on UniswapX, two fillers handle over 90% of volume, while on CoW Protocol, the top three solvers handle over 50% of batches.

If solver competition weakens, the architecture loses its core value proposition. Users receive worse prices, and the system effectively recreates the centralized intermediary model it was designed to replace. Bonding requirements and open participation help, but the economic moats around successful solver operations remain substantial.

Censorship at the Solver Layer

In a permissionless AMM, anyone can submit a swap transaction. In an intent-based system, solvers must actively choose to fill an order. If all solvers refuse to fill a particular intent (due to regulatory compliance, sanctions screening, or economic unprofitability), the user's intent expires without execution. This introduces a censorship vector that does not exist in direct on-chain interactions.

Small orders, illiquid token pairs, and chains with high gas costs are particularly vulnerable to this form of exclusion. Solvers prioritize profitable orders, which means some users may consistently receive worse service or no service at all.

Trust Assumptions

While the settlement layer provides on-chain verification, the off-chain auction process introduces trust assumptions. Users trust that the auction mechanism is fair, that solvers are not colluding on prices, and that the solver network has sufficient competition to deliver genuine price improvement. These assumptions are difficult to verify from outside the system, and concerns parallel the Payment For Order Flow (PFOF) debates in traditional equity markets.

Execution Latency

Intent-based systems trade immediacy for optimization. Batch auctions on CoW Protocol collect orders for roughly 30 seconds. Dutch auctions on UniswapX run for 30 to 60 seconds. This latency is acceptable for most trading scenarios but makes intent architecture unsuitable for time-critical operations like liquidations or high-frequency trading.

Complexity Shift

Intent architecture does not eliminate complexity: it moves it from users to solvers. The total system complexity may actually increase because solvers must maintain infrastructure across multiple chains, liquidity sources, and settlement systems. If the solver ecosystem fails (network outages, mass solver exits, liquidity crises), users lose access to the simplified experience the architecture provides and must fall back to imperative transactions.

Risks and Considerations

Intent Specification Risk

Users must correctly specify their intent constraints. An overly generous slippage tolerance or a distant deadline can result in a fill that technically satisfies the intent but extracts value from the user. Unlike imperative transactions where users see the exact execution path before signing, intent-based systems require trust in the auction mechanism to produce fair prices within the user's stated bounds.

Settlement Failures

Cross-chain intent settlement involves multiple chains and asynchronous verification. If a solver fills an intent on the destination chain but the settlement verification on the origin chain fails (due to reorgs, oracle delays, or network congestion), recovery depends on the protocol's dispute resolution mechanism. These edge cases are inherently more complex than single-chain imperative transactions.

Ecosystem Lock-In

Despite standardization efforts like ERC-7683, each intent protocol maintains its own solver set, auction mechanism, and settlement contracts. Users and applications that build deep integrations with a specific intent protocol may face switching costs if a better alternative emerges. Shared solver networks mitigate this, but full portability across intent protocols remains an unsolved problem.

Intent Architecture and Bitcoin

While intent architecture originated in the Ethereum ecosystem, analogous patterns exist in Bitcoin infrastructure. Lightning Network pathfinding separates the user's intent ("pay this invoice") from the routing logic that selects a path through the channel graph. Submarine swaps and atomic swaps use hash-locked contracts to enable trustless cross-layer transfers with intent-like semantics. As Bitcoin Layer 2 networks like Spark expand programmability, intent-based patterns may emerge for optimizing cross-layer routing and stablecoin transfers across the Bitcoin ecosystem.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.