Perp DEX Aggregators: Routing, Builder Fees and Execution

Start with the action you need. A funding comparison page helps you discover a market but may never submit an order. A trading terminal lets you select several exchanges from one screen. A router chooses an execution destination. A split router can allocate parts of a requested position to different sources. None of these labels tells you, by itself, which service a particular product currently provides.

Tangerine’s Hyperliquid documentation describes an agent signing orders for the user’s underlying account. Multi’s API describes automatic venue selection, while its batch endpoint submits orders sequentially and says that one failure does not abort the others. MUX’s own site explicitly describes routing a trade whole or split between liquidity sources. These are documented capabilities, not results from our own executed comparison.

There is another category that is easy to misclassify. Contango builds leveraged positions using spot and money markets. Its documentation describes spot aggregation for the swap involved in opening, changing or closing the position. That does not make its position equivalent to an order split between two conventional perpetual order books. The borrowing market remains part of the economic result.

Ask the product to make its decision visible. If a screen only presents an exchange selector, you are choosing the venue. If it suggests one destination, inspect why that destination won for your quantity. If it divides the order, the expected allocation and separate resulting exposures matter. A badge saying “smart” answers none of those questions.

Suppose two terminals both send your BTC perpetual orders to the same underlying book and account. They may offer different charts, shortcuts, mobile controls and service charges. They do not create two independent sets of bids simply because their colors and domain names differ. Summing the depth displayed by both would count the same liquidity twice.

This is why a long list of connected applications is less useful than a list of actual execution venues. The question is not how many logos the interface can display. It is whether your intended size can access independent executable interest, with margin already available where the order will arrive. A venue integration without access to that market or account is not usable capacity for this order.

Tangerine leaves assets and positions on the underlying platform. For a Hyperliquid account, query the actual trading account rather than its signing-agent address; the latter can return an empty view. That distinction gives you a direct way to find the position if the aggregator display fails.

Before relying on an alternative frontend, identify the main account or subaccount and exact market shown in the native venue. This is especially useful when an interface creates a subaccount or a product uses a contract-owned account. Do not assume that connecting the same wallet to another website will expose every position created by an unrelated protocol.

A useful quote comparison starts with the same economic request. “Buy $50,000 of BTC exposure” is not the same instruction as “use $5,000 margin,” unless the leverage and recognized collateral make those requests equivalent. One router may ask for coin quantity, another for dollar notional, and another for collateral. Normalize the intended exposure before comparing any prices.

Match the direction as well. A lower execution price benefits a buyer; a higher one benefits a seller. A prominent mid-price is neither a firm ask for a long nor a firm bid for a short. For a large order, compare the expected average execution of the whole quantity rather than the first visible price level. Our order-book depth guide covers that calculation separately.

Contracts with the same ticker can still use different collateral and settlement rules. A USDC-margined linear perpetual and a coin-settled inverse future are not interchangeable just because both track Bitcoin. An apparent entry-price advantage may come with a currency conversion, additional price exposure or a different position-size unit. Routing should preserve the exposure you actually requested.

The holding period can reverse the entry decision. Imagine route A saves $15 on opening, but its estimated carrying cost is $4 more per day than route B. If that difference remained unchanged, the entry advantage would be exhausted after 3.75 days. This is a sensitivity calculation, not a funding forecast. It explains why a router optimized for immediate execution need not minimize the cost of a week-long position.

Collateral already available at a venue can also change the result. If the alternative requires a bridge or swap, compare the final margin credited after those costs. A quoted saving on the futures order may be smaller than the cost of funding the destination. Conversely, do not add a transfer cost when your funds are already there: only incremental costs belong in the decision.

Here is an intentionally constructed comparison for the same $50,000 opening exposure. Route A has $15 of estimated adverse execution relative to the common reference price; route B has $35. Looking only at execution, A appears $20 better. Both charge $20 of venue trading fees, but A adds a $30 interface charge and a $10 funding-route cost. B adds neither.

The completed cost model is $75 for A and $55 for B. Route A loses its price advantage because its extra $40 exceeds the $20 execution improvement. This conclusion follows from the stated numbers; it does not depend on describing an attractive quote as misleading. If A charged only $5 extra instead, it would be the cheaper route. The calculation, rather than the aggregator label, decides.

A service charge of 0.06% on $50,000 is $30. Applying that rate to the $5,000 margin would produce $3 and understate this example by $27. The relevant base must come from the route’s actual terms. Deposits, swaps and position changes can use different bases even within one protocol.

Do not count the same execution shortfall twice by adding a displayed price-impact estimate to an already adjusted execution price. Nor is the slippage-tolerance setting itself an expected fee: it is a constraint on acceptable execution. Use the expected fill and explicit charges for an estimate, then replace those estimates with actual fill records when reviewing the result.

Obtain a closing quote as well. Entry rebates and sponsored transactions can expire or apply only once, while a per-fill charge may apply to both legs of the round trip.

The fee cap and the fee charged are different numbers

Hyperliquid documents builder fees as per-order charges subject to a maximum approved by the user. The published perpetual cap is 0.1%, and the main wallet must authorize the builder; an agent wallet cannot grant that approval. The ceiling is not the fee every order necessarily pays. A frontend can ask for permission up to a limit while using a lower charge on an individual order.

For scale, a hypothetical 0.03% builder charge on a $20,000 fill is $6. If both entry and exit execute at that same notional and rate, the builder subtotal is $12, before venue commission or funding. A maximum permission of 0.1% would allow up to $20 for a $20,000 fill, subject to the protocol’s rules. Compare the actual order charge, not just the approved maximum.

GMX keeps the request’s recorded UI fee

GMX UI fees are added to protocol fees and use the size change for increases and decreases. Their factor is recorded when the request is created, so an already pending request retains that factor even if the frontend later advertises a lower rate.

An agent’s trading authority can still affect your capital

Permission to trade is another decision. An agent that cannot withdraw funds can still open losing positions or change exposure. “No withdrawal permission” does not mean “no financial influence.” Tangerine documents revocation through the underlying Hyperliquid account. Treat revoking the trading agent and changing a builder-fee approval as separate controls with separate purposes.

Consider a planned $100,000 long divided into $60,000 on venue A and $40,000 on venue B. A fills completely while B fills only $10,000. Your actual exposure is now $70,000, with $30,000 still unfilled. An interface reporting a problem with the second route does not cancel the successful first route.

The next action depends on your objective. If the intended size is still $100,000, the unresolved amount is $30,000, not a fresh $100,000. If the first fills are no longer wanted, closing the actual $70,000 is another trade with its own price and fees. Neither action should be inferred merely from an ambiguous “failed” message.

Multi provides a concrete reason to distinguish these states: its documented batch order endpoint is sequential, and a failed order does not stop the remaining orders. Its safety page also describes request deduplication to prevent a repeated request from becoming an unintended second submission. Those features concern different problems. A deduplicated retry does not make a multi-order route all-or-nothing.

A single transaction on one chain can have stronger execution guarantees when its contract explicitly enforces them. That guarantee should not be borrowed by a route involving independently submitted orders or different chains. “One click” describes the interface gesture, not necessarily the settlement relationship among all the resulting actions.

Protective orders require the same attention. A stop attached to venue A is not automatically a stop for venue B. If the screen offers a combined close or combined stop, inspect whether it created the expected instructions for every live position. After a partial close, the remaining quantities—not the original requested allocation—are what need protection.

If the interface fails, locate the actual position on the underlying venue. For the Tangerine example, the position belongs to the Hyperliquid account, not to a separate copy of the trade held by the frontend.

Revoking a trading agent stops that permission from being used again; it does not close existing positions or cancel every resting order. Account access, trading permission and open exposure need separate handover steps.

An aggregator can be worthwhile even when its explicit fee is not the lowest. A workflow that exposes independent venues, keeps quantities understandable and reliably reports partial fills may solve a real operating problem. For someone already using one venue with straightforward orders, a second interface may offer little beyond layout and convenience. The useful comparison is against your actual workflow, not an imaginary trader who uses every integration.

A practical evaluation uses the same intended quantity and common price reference for the direct venue and the proposed route. Record the expected allocation, the extra fee and any transfer required. Then, if you later trade, judge the service by the completed fills and the effort needed to manage the resulting positions. A quote-ranking screen is a starting point, not a completed execution benchmark.