Intent-Based Trading Protocol Development

Intent-Based Trading Protocol Development

We specialize in designing and deploying intent-based protocols — an architecture where a user signs an intention ("I want to sell 1 ETH for the best USDC price before 15:00 UTC"), and execution is delegated to specialized solvers. Unlike the classic DEX model where a transaction exactly describes details, the intent-based approach adapts to market conditions and protects against slippage. This architecture can reduce slippage by up to 50% compared to AMM on volatile pairs, as well as cut gas costs through batch order processing. Developing a DeFi protocol in this paradigm requires deep understanding of both on-chain and off-chain components.

This approach is implemented in CoW Protocol, UniswapX, and 1inch Fusion, each with its own trade-offs. We help you choose the optimal model for your tasks: batch auction for high volumes or first-solver for low liquidity. In practice, a fill transaction on mainnet costs $5-15, which at high volumes can mean $10-20k in monthly fees. Using batch fill can reduce gas costs by up to 40%, saving $20k on a monthly spend of $50k. For a protocol processing $10M monthly volume, batch fills could save $40k in gas alone.

How does an intent-based trading protocol work?

The user signs a structured message via EIP-712 (typed data visible in MetaMask). The EIP-712 specification ensures secure off-chain signing of structured data. Minimal order structure:

struct Order { address maker; address inputToken; address outputToken; uint256 inputAmount; uint256 minOutputAmount; uint256 deadline; uint256 nonce; bytes32 partialFillable; } 

Key point: nonce management follows a word + bit scheme (as in UniswapX), allowing up to 256 active orders simultaneously. Cancelling an order — invalidation of a bit in an on-chain mapping without a separate transaction.

Why choose an intent-based model?

Key system components

Settlement contract

The central contract verifies the signature (EIP-712 recovery), checks nonce and deadline, atomically transfers tokens via safeTransferFrom. EVM atomicity guarantees: if the solver doesn't approve outputToken — the entire transaction reverts.

function fill(Order calldata order, bytes calldata signature, uint256 fillAmount) external { address signer = ECDSA.recover(_hashTypedData(order), signature); require(signer == order.maker, "Invalid signature"); require(!_usedNonces[order.maker][order.nonce], "Nonce used"); require(block.timestamp <= order.deadline, "Expired"); 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); } 

Solver network and competition

A solver is an off-chain agent monitoring the orderbook and selecting the optimal execution route. A solver's profit is the difference between the real price and minOutputAmount (surplus). Two models are possible:

• On-chain auction (CoW Protocol): all orders for a period are batched together, one winning solver executes everything at a single price. Eliminates front-running within the batch. This model is 3x more gas efficient than a sequence of individual fills.
• Off-chain first solver (UniswapX): the first to execute the order on-chain before the deadline receives the reward. Simpler, but may lead to an MEV race.

We evaluate your specifics and propose the optimal model.

Permit2 integration

Instead of the classic approve (a separate transaction), we use Permit2 — the approval is signed off-chain along with the order. Batch permit allows one-time approval of Permit2 for each token, after which all dApps use it. This is a significant UX improvement.

Solver implementation: search and protection

The solver fetches quotes from AMMs (Uniswap, Curve, Balancer), CEX (Binance API), on-chain orderbooks, and its own inventory. It selects the best price considering gas and fees. If profit < gas * gasPrice * safetyMultiplier — the order is rejected. A common mistake of novice solvers: taking unprofitable orders hoping for MEV — this is not sustainable.

Gas optimization

On mainnet, one fill costs $5-15 at gas $50. For small orders, this is unacceptable. Solutions:

• Deploy on L2 (Arbitrum, Optimism) reduces gas by 10-50x.
• Batch fill — multiple orders in one transaction amortize base gas cost.
• Compact calldata: zero bytes are cheaper, saving 20-40% of calldata gas.

Stack and component table

Smart contract development uses Solidity 0.8.x with Foundry and OpenZeppelin 5. Smart contract audit is performed by external teams.

Process

1. Analytics (3-5 days): select model (batch or first-solver), target tokens and chains, solver network requirements.
2. Design (5-7 days): EIP-712 schema, nonce mechanism, settlement architecture.
3. Development (6-10 weeks): settlement contract, Permit2 integration, orderbook, solver, frontend.
4. Audit: mandatory external audit focusing on signature malleability, reentrancy, nonce.
5. Deployment and support: deploy to target networks, monitoring, documentation.

What's included

• Smart contract development (Settlement, Permit2 wrapper)
• Off-chain solver with liquidity integration
• Orderbook (REST API + WebSocket)
• Frontend with order signing (wagmi + viem)
• API and contract documentation
• Deployment and monitoring setup
• Team training for operations
• 3-month warranty support

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 defining the model and scope. Typical MVP costs range from $25k to $50k, while a full production system may cost $60k to $120k. We offer turnkey development from design to audit. Contact us for a free project evaluation — we'll analyze your requirements and propose an architecture tailored to your volume and goals.

Order protocol development — describe your task, and we'll select an architecture matching your volume and requirements. Get a consultation to discuss your project details.