JW3
رجوع
Execution8 دقيقة قراءة

Your trade took a route you never read

A route is the record of how your order actually executed: which venues filled it, in what proportions, through how many hops, and against which gas estimate. Three aggregators return it in three different shapes. Almost nobody opens it.

الترجمة غير متاحة بعد — يتم عرض الإنجليزية.

Your order left your wallet and reached a pool, or several, and something in between decided how. That decision was written down before you signed. It was called a route, it was probably rendered as a small row of text or a percentage breakdown, and it is the only complete description of the trade you will ever get.

Most people see the number, sign, and close the tab.

The route matters because it answers questions the quote cannot. Which venue took the trade. What share each venue took. How many contract calls stand between your token and yours. Whether the price came from a curve that moved or from a market maker who named it. Those facts determine what your slippage tolerance is actually covering, and they are sitting in the response you already received.

Three aggregators, three field names

The route is not one standard. It is a convention each aggregator invented, and the differences are informative.

0x returns it as route, a list of fills, and each fill carries a from token, a to token, a source name, and a proportionBps. The field name is the important one: basis points implies the share of your order assigned to that venue. The documented response example on the quote reference page shows the field, though it carries no description of its own, so treat the semantics as implied by the name rather than documented. The source string is fully documented, and that is where the venue identification is unambiguous.

1inch returns the same idea as nested protocols and hops, where each hop declares a part. Their API reference describes one as the distribution percentage from the source token coming to the destination token on that hop, and a second, at the venue level, as the distribution percentage from the total amount coming to a specified destination token. The response also returns dstAmount, labelled expected amount of destination token, and a gas field labelled estimated gas.

ParaSwap, whose documentation now lives under the Velora name, returns a priceRoute object. Its own description of that object is the most useful sentence anyone in this business has written about it:

The priceRoute is stateless and unsigned: it's just a routing plan. It expires quickly (prices move) but holds no commitment.

Hold that sentence. It is the answer to the question everyone asks and nobody asks out loud.

What a split route does to your price

When a router splits your order, it is doing arithmetic on price impact. A constant-product pool moves against you in proportion to how much you push through it. Take the same size order through one pool and it eats the depth of that pool. Take it through three pools in thirds and each pool absorbs a third of the push. The marginal price is worse in every individual pool, and the aggregate is usually better.

1inch describes this as the core of its approach:

Superior liquidity efficiency: by splitting volumes into finer chunks and blending paths, Pathfinder taps into pools more effectively, skimming the cream from concentrated liquidity for optimal exchanges.

That is their wording, and it is accurate about the mechanism. It is also worth noticing that the "cream" is the thin, most price-sensitive layer of a concentrated liquidity range. Splitting moves your order into the layer that is most sensitive to being touched, so the split percentages are your price impact budget, allocated venue by venue.

The cost side is gas. Every additional hop is another contract call. 1inch's own documentation lists gas efficiency as a design goal of the current Pathfinder version, achieved "by merging paths to achieve better gas cost efficiency". Merging two paths that both end in the same intermediate token removes a redundant swap and reuses the same market for both. The routing decision is therefore a net calculation: extra token out, minus extra gas in, minus pool fees, minus whatever the integrator charges.

Why a single-pool route is not automatically worse

This is where most execution-quality advice misleads people. Splits are treated as a quality signal. They are an output of a cost comparison, not a certificate.

1inch states plainly which pools are even candidates:

When comparing available liquidity sources, Pathfinder considers factors such as the expected swap rate, available liquidity, price impact, and gas costs. As a result, a supported pool may still not appear in the final route if another pool or combination of liquidity sources offers better execution.

There is a second filter before that one. Their help centre puts it directly: 1inch can only route swaps through liquidity sources that Pathfinder supports, and a pool can hold substantial liquidity and still be unavailable if its pool type, execution logic, or associated hook is not supported. A large pool that the router cannot model is not a route. So a single-fill route can mean the router found nothing better that it could actually price and execute.

There is a third case, and it is the one that inverts the usual intuition. A single fill from a named market maker carries no AMM curve at all. There is no marginal price that moves as you push, no price impact to split away, and fewer conditions that can revert. 0x describes its RFQ system as "exclusive to 0x, has 0 slippage, and better trade execution", and notes that part or all of a standard quote may be sourced that way.

Read that as 0x's claim, not as a measurement. The part worth keeping is structural: a maker fill is priced, an AMM fill is computed. The route tells you which one you got.

0x's getSources endpoint returns the array of liquidity sources aggregated for a chain. The documented example response for Ethereum lists 21, beginning with 0x_RFQ and including Ambient, BalancerV1, BalancerV2, BancorV3, Curve, DodoV1, DodoV2, FraxswapV2, Integral, Lido, MakerPsm, Maverick, Origin, PancakeSwapV3, RocketPool, SolidlyV3, SushiSwap, Synapse, UniswapV2 and UniswapV3. 0x_RFQ sits in the same list as the pools. The route does not tell you which kind you got by the fact that a fill exists. It tells you by the source string.

What the aggregator does not guarantee

Three separate limits, worth keeping distinct.

First, the route is a plan, not a commitment. Velora's wording again: it expires quickly and holds no commitment. You are not signing the route. You are signing a transaction built from it.

Second, what is enforced is your bound, not their price. CoW Protocol is explicit about which side carries the constraint. The settlement contract "verifies the signature of the user's intent and ensures that execution happens according to the limit price and quantity specified by the user", and on their MEV protection page: "The winning solver must provide at least the price accepted by the user's signed intent, and bears the risk of sourcing a valid settlement under those constraints." The floor is yours. The price is theirs to find.

Third, and most practically, your tolerance is the only automated defence, and it defaults open. On 0x's getQuote and getPrice, slippageBps is documented as the maximum acceptable slippage of the buy token in basis points, where setting it to 0 means no slippage will be tolerated, and: if not provided, the default slippage tolerance is 100Bps. One percent, pre-authorised by whoever built the interface you are using. If the interface never set it, you signed a one percent gap between quote and fill without seeing the number.

Read also what else is inside the quote and therefore inside your signature. 0x exposes excludedSources, so venues can be removed from consideration, and tradeSurplusMaxBps, documented as the maximum trade surplus (positive slippage) that can be collected in basis points of the buy amount, defaulting to 10000, which is 100 percent. Positive slippage is money you received above the price you asked for, and something in the stack is configured to keep it unless the integrator has a recipient for it.

How to read the route before you sign

Six checks. All of them are free, and all of them are answerable from the response you already have.

  1. Count the fills. One venue is a statement about what the router could price, not a verdict on quality.
  2. Read each source or protocol name. Is it a pool you can name, a market maker, or something you cannot identify?
  3. Read the split. If one venue takes 5 percent of your order and four others take 23 or 24, the tail is where the marginal price is.
  4. Count the tokens. More tokens means more hops means more gas and more conditions that can revert.
  5. Find the gas figure and compare it to the size of the trade. On a small order the gas can dominate the routing gain entirely.
  6. Find the slippage number and ask whether anyone chose it. The default matters more than the field name.

Then, after settlement, reconcile. 0x points integrators at its 0x-parser library for the purpose of displaying the final amount swapped after a transaction has settled, which is a plain statement that the settled amount is a separate fact from the quoted one. Keep a log of quoted versus received, per route shape, until you have your own baseline.

Sources

Risk note: cryptocurrency trading, leveraged perpetual futures, and automated algorithmic strategies carry significant risk of rapid and total financial loss. Never risk funds you cannot afford to lose completely. Routing through third-party liquidity carries its own execution risk, including fills materially different from the quoted price, and slippage tolerances set loosely enough to permit them. Nothing in this article is investment advice, a recommendation, or an offer to sell any product.