# What agents can do with AsyncSwap

Updated 2026-10-30. **Status: Test deployments are live on Unichain Sepolia (chain id 1301), chain 6343 (chain id 6343), Robinhood Chain testnet (chain id 46630), Arc testnet (chain id 5042002), Ethereum Sepolia (chain id 11155111). There is no mainnet deployment: the earlier Unichain and Arc mainnet deployments had bugs and are retired, so do not send orders to them. The indexer stores testnet PoolPriceObserved events for price and tick analysis in PostgreSQL. REST and MCP order endpoints do not expose testnet order data; read testnet order activity from the hook's events. The contracts are not yet audited; the official launch will be announced here.**

Two lists: what works now, and what is planned. Anything in the second list has no endpoint, contract or card yet; do not look for one.

AsyncSwap is an asynchronous limit-order book on Uniswap v4 for large, institutional-size swaps. A maker posts an order on-chain with an exact input and the minimum output they accept; the order is matched against resting orders by coincidence of wants, filled from pool liquidity when that satisfies the limit, or settled by a filler who pays the maker's price and keeps the spread. How the book, the matching and the sequencing work is in https://app.asyncswap.org/llms-full.txt.

## Today

### Read the market, no credentials

- Order book, one order, its lifecycle events, pools, book statistics, recent Uniswap swaps on the same pairs, candles, reference routing of past output legs: REST at https://api.asyncswap.org (spec https://api.asyncswap.org/openapi.json).
- Live order updates: WebSocket at wss://api.asyncswap.org/v1/filler/stream.
- The same reads as MCP tools at https://app.asyncswap.org/mcp (card: https://app.asyncswap.org/.well-known/mcp/server-card.json) and as WebMCP tools on any page of this app.
- Chains: Test deployments are live on Unichain Sepolia (chain id 1301), chain 6343 (chain id 6343), Robinhood Chain testnet (chain id 46630), Arc testnet (chain id 5042002), Ethereum Sepolia (chain id 11155111). There is no mainnet deployment: the earlier Unichain and Arc mainnet deployments had bugs and are retired, so do not send orders to them. The indexer stores testnet PoolPriceObserved events for price and tick analysis in PostgreSQL. REST and MCP order endpoints do not expose testnet order data; read testnet order activity from the hook's events. Ethereum mainnet is Uniswap-only in the app; the hook is not deployed there.

### Act as a maker, with your own wallet

- Place an order: exact input, minimum output, pool, and an optional USDC priority bid. The input is escrowed in the Uniswap v4 PoolManager. On arrival the order is matched against up to eight resting orders, then tried against pool liquidity; the remainder rests on the book and can be partially filled by later orders.
- Reprice an open order (change the minimum output) and cancel it (remaining input is returned; any chosen priority bid is non-refundable).
- Authorize executors: the maker signs a grant that lets the Router (or another address) create, fill and cancel on their behalf. Grants can be revoked.
- Everything is an EIP-712 message plus a transaction you send and pay gas for. There is no relayer, no server key and no custody: the agent must hold the maker's key. Skill: https://app.asyncswap.org/.well-known/agent-skills/place-asyncswap-order/SKILL.md.
- Pools use optional priority bids: zero is valid and is the interface default. At the same price, higher bids rank first, then earlier submissions. Nonzero bids are escrowed at creation and settle to FeeVault as orders fill or close.

### Act as a filler, with your own wallet

- Current testnet filler fills pay the live `amountOutMin` through the Router. The maker receives that output less 0.02%, and the filler receives the escrowed input less 0.02%. Book matches charge the same trade fee on each side’s proceeds. Optional priority bids are separate.
- Fillers can also advance a crossed book with `Router.matchBook` without funding anything, or retry a resting order against pool liquidity with `Router.fillFromPoolLiquidity`.
- A filler fill takes the whole remainder; partial fills happen through book matching, not through fillers.
- Same chain only. The filler sources the output token however it likes (its inventory, a Uniswap route, another venue); the protocol does not route for it.
- Verify on-chain before spending gas: the API is an indexer view and can lag. Skill: https://app.asyncswap.org/.well-known/agent-skills/fill-asyncswap-orders/SKILL.md.

### Guarantees agents can rely on

- Escrow always equals the open orders' remaining inputs plus escrowed bids; no match or fill creates or destroys tokens; claim balances never go negative; at one price, bids rank first and then FIFO. These are machine-checked in Lean 4 (asyncswap/v2-proofs) and re-proved on every protocol commit.
- A revert leaves the order open and rolls back all accounting. Two fillers racing: the first succeeds, the second reverts.
- Order ids bind chain, pool, owner, direction and salt. Never recompute a legacy nonce-based id with the salt formula.

### Not available today

- No agent accounts, API keys, spend limits, key custody or revocation on the AsyncSwap side. Those controls are the agent operator's job. See https://app.asyncswap.org/auth.md.
- No private or hidden orders: every order is public on-chain and in the API.
- No peer-to-peer transfer between agents outside the order book.
- No cross-chain orders, no multi-hop inside the protocol, no pairs without USDC. (Partial fills exist through book matching.)
- No agent-to-agent endpoint: there is no A2A card because there is no agent to talk to yet.

## Planned

Roadmap, in the order we expect. None of it exists yet. When an item ships it moves to "Today" with its endpoint or contract linked, this file's date changes, and https://app.asyncswap.org/llms.txt points at it.

1. **Agent accounts and safety rails.** Explicit wallet authorization for agents, bounded spend, key isolation, revocation and audit logs, then agent registration and health. The prerequisite for everything below.
2. **Agent-to-agent fills.** Agents filling each other's orders directly, including negotiated fills, through an A2A endpoint. An A2A agent card will be published when the endpoint is live.
3. **Private orders and peer-to-peer settlement.** Orders visible only to chosen counterparties, and direct agent-to-agent transfers of tokens and orders settled through the protocol. USDC-paired first.
4. **Multi-hop with USDC accounting.** Orders that route through several pools, with each hop valued in USDC up to the final token, so an agent can ask for "X of token Z" and have the protocol account the path.
5. **Any-token pairs.** Lifting the USDC-on-one-side requirement.
6. **Paid data and priority services for fillers**, probably over x402, which is when authenticated endpoints and OAuth metadata appear.

## Where to look next

- https://app.asyncswap.org/llms.txt (entry point), https://app.asyncswap.org/llms-full.txt (full reference)
- https://app.asyncswap.org/.well-known/agent-skills/index.json (skills), https://app.asyncswap.org/.well-known/mcp/server-card.json (MCP)
- https://github.com/asyncswap/contracts (contracts; docs served at https://app.asyncswap.org/protocol.md), https://github.com/asyncswap/v2-proofs (proofs)