DEX essentials

What an intent means in decentralized trading

Understand signed outcome constraints, solver-selected routes and the difference between an intent and an executable transaction.

An intent states an authorized outcome while leaving part of the execution method to someone else. In token trading, it can specify the assets, amounts, recipient and validity conditions without choosing every pool operation in advance.

Outcome first, route later

A hypothetical user signs “sell up to this quantity of A and receive at least this quantity of B under these conditions.” A solver then searches for a compliant fulfillment. The user does not need to know whether the final route uses Pool One, Pool Two or compatible orders from other traders.

CoW's intent documentation explicitly separates a signed expression of trading constraints from an executable user transaction. UniswapX provides another example in which signed orders invite competing fillers.

A signature is not a settlement receipt

The signature authorizes specified behavior. An executor still needs to construct and submit a valid settlement. Until that succeeds, the desired token balance has not arrived merely because the order was signed.

This differs from signing a complete transaction that already contains a chosen execution path. In either model, authorization must remain bounded; the difference is how much execution choice the user delegates and which contracts enforce that delegation.

What a useful intent must make clear

  • The asset identities and network.
  • The quantities and acceptable exchange relationship.
  • The recipient and validity window.
  • Whether partial fulfillment is permitted.
  • Any additional constraints the settlement design supports.

Some products call a broad range of delegated operations intents. The label alone does not establish custody, order visibility, cancellation behavior, MEV treatment or guaranteed execution. Those are properties of the implementation.

Intent-based systems can combine routing with competition among executors. They can also match compatible order flow. These are opportunities created by delegated execution, not automatic benefits of every signed message. The practical question is what the signed terms allow and what the settlement mechanism actually checks.

Sources & verification (3)

Source-check date is recorded in the article details. URLs are provided for manual verification. Use Copy to keep this page open.

  1. Intents | CoW Protocol Documentation

    Signed constraints differ from executable transactions; solvers choose settlement.

    https://docs.cow.fi/cow-protocol/concepts/introduction/intents
  2. UniswapX Overview

    Signed-output orders and competing fillers; Dutch auction as one supported mechanism.

    https://developers.uniswap.org/docs/liquidity/uniswapx/overview
  3. GPv2Settlement

    Settlement checks, partial order constraints and clearing-price mechanics.

    https://docs.cow.fi/cow-protocol/reference/contracts/core/settlement

Continue reading

What a solver does for a swap order Batch auctions vs Dutch auctions for token swaps Coincidence of wants: matching opposite trading needs