Intent-Based Trading Protocol Development

Intent-Based Trading Protocol Development

The classical DEX model: a user signs a transaction that precisely describes what to do (swap 1 ETH for a minimum of 3450 USDC via Uniswap V3 pool X). If market conditions change — the transaction either reverts or executes at an unfavorable price. The intent-based model inverts this: a user signs an intent ("I want to sell 1 ETH for the best possible USDC price before 15:00 UTC"), and execution is delegated to specialized solvers who compete for the right to fulfill it.

This is an architectural shift comparable to the transition from limit order books to AMMs. CoW Protocol, UniswapX, and 1inch Fusion are implementations of this idea with different trade-offs.

Key System Components

Order Structure and Signing

An intent is a structured message that a user signs via EIP-712. Minimal structure:

struct Order {
    address maker;          // who creates the order
    address inputToken;
    address outputToken;
    uint256 inputAmount;
    uint256 minOutputAmount; // minimum acceptable
    uint256 deadline;        // valid until
    uint256 nonce;           // replay protection
    bytes32 partialFillable; // whether partial fill is allowed
}

EIP-712 typed signature: the user sees human-readable data in MetaMask, not raw hex. This is critical for UX and phishing protection (the user understands what they're signing).

An important nuance with nonce: classical incrementing nonce doesn't allow multiple active orders simultaneously. UniswapX uses a word + bit scheme: 256 orders can be active in parallel, each bit in a uint256 word is one nonce. Canceling an order = invalidating a bit in an on-chain mapping without a separate transaction for each order.

Solver Network and Competition

A solver is an off-chain agent that monitors an orderbook (typically off-chain orderbook with on-chain settlement), finds optimal execution, and executes it on-chain. A solver's profit is the difference between the actual execution price and the order's minOutputAmount (so-called surplus).

Architecturally, two models are possible:

On-chain auction (CoW Protocol): batch auction, all orders over a period are collected together, one winning solver executes the entire batch. Uniform clearing price — all orders in the batch execute at one price. This eliminates front-running within the batch.

Off-chain first solver wins (UniswapX simplified): the first solver who executed the order on-chain before the deadline gets the reward. Simpler, but possible MEV race between solvers.

For a custom protocol: the choice of model depends on volume. With low volume, the batch auction doesn't fill — no point in waiting. With high volume, batch saves users gas and provides better prices.

Settlement Contract

The central contract that:

1. Verifies order signature (EIP-712 recovery)
2. Checks nonce (whether order was already executed)
3. Checks deadline
4. Verifies that solver transfers no less than minOutputAmount
5. Atomically transfers inputToken from maker to solver and outputToken from solver to maker

function fill(Order calldata order, bytes calldata signature, uint256 fillAmount) external {
    // 1. Recover signer
    address signer = ECDSA.recover(_hashTypedData(order), signature);
    require(signer == order.maker, "Invalid signature");
    
    // 2. Check nonce
    require(!_usedNonces[order.maker][order.nonce], "Nonce used");
    _usedNonces[order.maker][order.nonce] = true;
    
    // 3. Check deadline
    require(block.timestamp <= order.deadline, "Expired");
    
    // 4. Transfer tokens atomically
    IERC20(order.inputToken).safeTransferFrom(order.maker, msg.sender, fillAmount);
    IERC20(order.outputToken).safeTransferFrom(msg.sender, order.maker, outputAmount);
    
    emit OrderFilled(orderHash, msg.sender, fillAmount, outputAmount);
}

Atomicity is achieved through safeTransferFrom in both directions in a single transaction. If the solver didn't approve the outputToken — the second transferFrom reverts, the first one too (EVM atomicity).

Permit2 Integration

A user must approve the settlement contract for the inputToken. Classical approve — a separate transaction before the first order. With Permit2 (Uniswap) — permission is signed off-chain along with the order, without a prior on-chain transaction. This is a significant UX improvement.

Permit2 supports batch permit — allow multiple tokens with one signature. For a protocol with multiple pairs — the user approves Permit2 once per token (once per token, not per protocol), then all dApps use Permit2.

Solver Implementation

Finding Optimal Execution

A solver must find the best execution route for an order: through AMM pools (Uniswap, Curve, Balancer), through CEX (Binance via API, if arbitrage exists), through on-chain orderbooks (Seaport for NFTs, clob-based DEX), or through solver inventory (if they have the outputToken).

Algorithm: request quotes from all sources → choose best price → calculate profitability (outputAmount - minOutputAmount - gas cost - any protocol fees → profit).

If profit < gas * gasPrice * safetyMultiplier — don't take the order. A common beginner solver mistake: taking loss-making orders hoping for MEV — this doesn't work sustainably.

Protecting Solver from Rogue Orders

An attacker can create an order with inputToken that triggers reentrancy in the settlement contract during transferFrom. Or inputToken might be deflationary (transfer fee) — the solver receives less than expected.

Settlement contract protection: nonReentrant on fill. Solver defense: check inputToken against a whitelist of known tokens or conduct simulated fill via eth_call before actual execution.

Gas Optimization

Each fill is a minimum of 2 transfers + signature recovery + nonce check. On mainnet at $50 gas — this is $5-15 per transaction. With small orders (100 USDC) — unacceptable.

Solutions:

• L2 deployment: Arbitrum One reduces gas 10-50x, Optimism similarly
• Batch fill: solver executes multiple orders in one batchFill call, amortizing base gas cost
• Calldata optimization: order abi-encoding is optimized for zero bytes (zero bytes are cheaper, 4 gas vs 16 gas). Compact encoding reduces calldata gas by 20-40%

Development Stack

Solidity 0.8.x + Foundry + OpenZeppelin 5.x. EIP-712 through OpenZeppelin EIP712 abstract contract. Permit2 integration through Uniswap/permit2 repository. Off-chain solver: Node.js + TypeScript + ethers.js v6 + viem. Orderbook: own server or integration with existing (CoW Orderbook API).

Work Process

Analysis (3-5 days). Choose model (batch auction vs first-solver), target tokens and chains, solver network requirements (open or permissioned), integration with existing liquidity sources.

Design (5-7 days). EIP-712 order schema, nonce mechanism, settlement contract architecture, solver reward mechanism.

Development (6-10 weeks). Settlement contract → Permit2 integration → off-chain orderbook → basic solver → frontend. Each component is tested independently.

Audit. Settlement contract manages user funds directly. External audit is mandatory. Special attention: EIP-712 signature malleability, reentrancy in fill, nonce invalidation correctness.

Timeline Estimates

MVP with basic settlement and one solver — 4-6 weeks. Production-ready protocol with batch auction, open solver network, and gas optimization — 2-3 months.

Cost is calculated after model and scope determination.