Trading and routing

Quote flow

The Abyss API currently supports exact-input quote requests. It discovers connected simple routes from one to four hops, obtains output from the deployed AbyssQuoter at a pinned quotedBlock, and simulates the exact router request from the supplied sender.

The response is unsigned. The API never holds keys, signs, or broadcasts transactions.

Route identity

Each hop includes a complete PoolKey, input token, and square-root price limit. Routes must be connected, cannot repeat a pool, and cannot exceed four hops. Intermediate output is held by the router and paid into the next pool. The final output goes to the selected recipient.

Single-pool operations

The router exposes:

• exactInputSingle, which spends an exact input and enforces minimum output;
• exactOutputSingle, which requests an exact output and enforces maximum input; and
• exactInput, which executes a route of one to four pools and enforces final minimum output.

The public API quote endpoint supports exact input only, even though the router has a single-pool exact-output function.

Slippage and deadlines

Slippage tolerance is converted into amountOutMinimum for exact-input execution. If final output is lower, the transaction reverts. A deadline is a Unix timestamp after which the router rejects execution.

Slippage protection limits execution away from a quote. It does not prevent sandwiching, adverse selection, failed execution, or loss from token behavior.

Callback authentication

During each swap, the router resolves the complete pool key through the factory. Callback data binds that key, the exact resolved pool, and the payer. On callback, the router resolves the key again and requires both msg.sender and the bound address to match. Being some factory-recognized pool is insufficient.

The pool verifies actual balance increase after callback rather than trusting a reported payment amount.

Common failure states

Transaction submission is not success. A confirmed successful receipt is the state-change boundary.