Different DEX designs: 0x, AMMs and intents

DEX is not a single product shape. Signed orders, AMM pools, RFQ and intent networks assign discovery, quoting and execution to different participants. Comparing those choices is more useful than asking whether a market resembles Uniswap.

0x: orders can begin as messages

A maker signs structured terms. Those terms can move through a relay, a private channel or an application. A taker submits the required material to a settlement contract, which checks authorization and availability before transferring assets. The signature lets the agreement travel without handing the relay custody. 0x order introduction

This is not a new invention of the personal-agent architecture proposed in this series. Off-chain order distribution with on-chain enforcement is an established design pattern. Different 0x order types have different fields and constraints; an RFQ order should not be treated as interchangeable with every limit order. 0x order specification

A contract can accept valid orders without the user relying on one public website. A popular API can still dominate how users discover liquidity, obtain quotes and construct transactions.

These facts can coexist. Calling the whole system centralized erases permissionless contract access. Calling every layer decentralized erases the operational role of hosted services. The practical test is what survives replacement: can another relay distribute the order, can another interface construct it, and can the user still settle it?

An RFQ network can offer useful liquidity from professional market makers. Its membership, access policies and incentives should be evaluated independently of the settlement contract. A professional quote is often valuable precisely because someone has committed capital and operational capacity to honoring it.

AMMs: inventory pools replace finding a counterparty

An automated market maker changes the counterparty problem. Instead of finding someone who wants the opposite trade at the same moment, a user trades against inventory already committed to a pool.

That is more than decentralizing custody. The protocol also defines a pricing and liquidity mechanism. Liquidity organization and pricing are part of what the protocol decentralizes.

Uniswap v2 describes a constant-product market maker. Reserves and the invariant constrain execution, with fees and price movement determined by the mechanism. The pool supplies an immediate trading path while liquidity providers supply the assets and bear economic risk. Uniswap v2 whitepaper

This avoids a particular form of simultaneous matching. It does not make liquidity infinite. Larger trades move the price, and thin pools can be expensive. Arbitrage connects pool prices to other markets but also transfers value between participants.

Uniswap v3 introduced concentrated liquidity, allowing providers to choose price ranges. Capital can be more effective within a range, but a position can go out of range and require management. Liquidity provision becomes a strategy rather than a passive promise of universal depth. Uniswap v3 whitepaper

The v4 architecture adds a different extensibility model through hooks. That flexibility means the behavior and risks of a particular pool must be understood; the word Uniswap alone cannot describe every custom pool's logic. v4 overview

These are meaningful advances. A personal-agent market should be able to buy liquidity from an AMM, not pretend it can replace committed inventory with conversation.

Intents, RFQ and solvers: who organizes execution?

An intent specifies an acceptable outcome rather than every execution step. A user might authorize receiving at least a certain amount before a deadline, leaving the route to another participant. A solver or filler tries to satisfy that request profitably.

This can make a complicated market easier to use. It also makes the terms of delegation especially important.

An aggregator compares paths across liquidity sources. An RFQ system requests terms from counterparties. An intent system can invite participants to compete over completing a signed outcome. These categories overlap; they are not successive versions of the same product.

The UniswapX whitepaper describes signed orders and competitive execution. Its current filling documentation makes a distinction that slogans often miss: quoting can involve vetted participants while filling is permissionless, subject to the applicable auction and exclusivity rules. Permissionless filling does not imply that every upstream opportunity is distributed identically. UniswapX whitepaper, filling documentation

We should acknowledge the real competition these designs enable while inspecting where access, timing and information remain selective.

The highest displayed output is not necessarily the best result for a particular user. Fees, expiry, failure probability, speed, privacy and counterparty requirements matter. A quote that disappears before authorization is not equivalent to a firm offer with a clear settlement path.

A personal agent could compare direct P2P, an OTC desk, a market maker, an AMM and a solver. It might split an order or wait. But it should use the user's stated constraints and explain meaningful trade-offs, rather than silently optimizing for a venue's revenue.

This is also a legal boundary. Negotiation and recommendations can be different activities from merely displaying user-selected objective information. The legal chapter examines why self-custody alone does not resolve that distinction.

How a personal agent chooses among them

A pool can enforce a trade while a frontend, router or aggregator decides which pools the user sees. RPC access, token discovery, route construction and transaction submission can remain concentrated in practice.

The user may prefer a slightly worse nominal price for lower failure risk, less information exposure or a different waiting time. Comparing those choices belongs outside any one pool's pricing formula.

The point is not to move every decision out of protocols. It is to recognize which decisions are already well expressed by them, and which require a representative that works for the individual trader. AMMs solve a hard liquidity coordination problem. They do not exhaust the possible architecture of a decentralized market.

A small group of highly capable solvers can offer excellent execution. Concentration is not itself proof of misconduct. It does create questions about entry costs, exclusive information, conflicts of interest and fallback paths.

Can a new participant receive the intent? Can the user change the relay? Is payment from liquidity providers disclosed? What happens when the favored solver fails? These questions make decentralization observable instead of decorative.

The proposed architecture adds a representative owned by the user before this execution competition. That representative can use existing solvers. It should not become another unaccountable broker simply because it speaks in a friendly voice.