The Liquid Mercury Algo Suite: Seven Execution Strategies

The seven algos at a glance

Sweep

Sweep is a strategy designed to execute orders efficiently while minimizing market impact. It sweeps multiple exchanges and liquidity providers, including OTC venues, to secure the best available prices. It supports spot, perpetuals, futures and options, and its logic is the foundation for many of the other algos in the suite.

How it works.

1. Aggregate market data. Sweep aggregates order book data from multiple exchanges and liquidity providers and monitors liquidity, spread and price movement across the books.
2. Route. It identifies the best available prices in real time, routes orders to multiple venues simultaneously, and prioritizes execution on liquidity depth, fee structure and latency. This is smart order routing. See smart order routing.
3. Select the order type. It chooses dynamically between market orders, for speed when liquidity is high; limit orders, to capture better prices with minimal impact; and iceberg orders, to hide large trades from the public book.

Use it when the aim is a good all-in price across fragmented liquidity, including large orders that would move a single book.

TWAP

The time-weighted average price (TWAP) algorithm executes an order over a predefined period by breaking it into smaller, evenly distributed trades. The goal is an average execution price close to the market's time-weighted price, reducing market impact and slippage.

How it works.

1. Set the parameters. The trader sets the order size, the execution window (for example, 30 minutes) and the interval between orders (for example, every 30 seconds).
2. Slice. The total is divided into child orders placed at fixed intervals. Order size per interval equals total order size divided by the number of intervals.
3. Execute. The algo places market or limit orders at each interval and avoids aggressively taking liquidity, reducing market disruption.
4. Adjust. It can increase order sizes if execution lags the schedule, reduce them if volatility rises, and use price triggers to avoid trading in unfavorable conditions.

Use it when the priority is to spread an order over time without leaning on the market. See TWAP and, for the volume-based alternative, VWAP.

Chase

The Chase algorithm keeps a trader's limit order competitive in the order book by adjusting its price as the best bid or offer moves, within user-defined aggression and price boundaries. It is built for traders who want to maximize fill probability without crossing the spread unnecessarily or taking excessive adverse selection risk.

How it works.

1. Set the parameters. Side, size and an initial limit price, plus chase aggression (how closely to follow the best bid or offer), a maximum chase distance in ticks or price units, and optional minimum and maximum price limits.
2. Track the best price. For buy orders it tracks the best bid; for sell orders, the best offer, subject to the aggression profile.
3. Adjust. When the best price moves away beyond the configured threshold, it cancels the working order and re-posts closer to the market, within the maximum chase distance and any price caps. If the market moves toward the order and it becomes marketable beyond the trader's tolerance, the algo can execute, pause chasing or stop, depending on configuration.
4. Complete. As partial or full fills occur, it updates the remaining quantity and keeps chasing until the target is filled or the algo is cancelled. If the market drifts past the allowed range, it can stop or leave the remainder resting at the last acceptable price.

Use it when the trader wants to rest passively but stay near the front of the queue.

Spreader

The Spreader algorithm legs into multi-leg orders while maintaining a target net price. The trader can set venues, maximum leg exposure and slippage in real time. It supports spot, perpetuals, futures and options.

How it works.

1. Define the structure. The trader defines a multi-leg order. Each leg has a target price ratio or a net price constraint.
2. Prioritize legs by liquidity. The algo watches real-time depth on all legs and decides which to execute first based on liquidity availability, price movement and slippage control.
3. Execute and adjust. It places orders for individual legs so that the first leg sets up favorable conditions for the rest, and later legs adjust to maintain the net price. If conditions shift, it re-evaluates the sequence.
4. Monitor the spread. After one or more legs fill, it tracks the remaining legs, adjusts orders as prices in the executed legs shift, and can use hedging techniques if the spread deviates beyond acceptable risk.

Use it when the trade only makes sense as a package, such as a calendar spread or a basis trade.

Market Making

The Market Making algorithm provides two-sided markets on one exchange while leaning on liquidity from another. The trader chooses a source exchange and a destination exchange, and sets price and risk parameters. When an order fills on the destination exchange, the algo hedges on the source exchange, which limits the trader's risk and position size.

How it works.

1. Configure. Set the source exchange whose prices are consumed, the destination exchange where markets are made, the price mark-up and the risk parameters. The algo maps like contracts and allows manual adjustment.
2. Make markets. Using source prices, it places one- or two-sided orders on the destination market within the risk parameters. As the source price changes, it cancels and resubmits orders in real time.
3. Hedge. On a destination fill, it cancels resting orders on that contract and hedges the execution on the source exchange. When and how to hedge are configurable.
4. Monitor. A dedicated dashboard in the Mercury Pro interface shows the algo's operations and gives the trader full control over executions.

Use it when the desk wants to quote a thinner venue against a deeper one. For the wider topic, see automated market making in crypto.

Volatility

The Volatility algorithm quotes and executes options based on a trader-defined implied volatility, and can hedge the resulting delta in the corresponding futures market. Option orders trigger only when both volatility and underlying price conditions are met.

How it works.

1. Define the strategy. Set side, size, target option contract and limit implied volatility. Define the underlying futures contract, the minimum and maximum underlying price and allowed underlying slippage in basis points. Optionally enable auto-hedging and set the wave quantity and wave period for staged execution.
2. Watch the underlying. If the underlying futures price, including the slippage band, is outside the range, the algo waits.
3. Compare implied volatility. For buy orders it compares the contract's market implied volatility (for example, the ask) to the trader's limit, adjusted by an internal slippage parameter. For sell orders it compares in the opposite direction.
4. Price and send waves. When both conditions hold, it computes the option price with the Black model from the trader's implied volatility and market inputs (futures price, strike, time to expiry and rate), then submits a child order in the configured wave quantity. It repeats after each wave period until the parent order is filled or cancelled.
5. Hedge delta (optional). After each fill it calculates the delta for the filled quantity and, if auto-hedging is on, sends a hedge order in the underlying futures using the chosen aggressiveness profile (mid-and-adjust for normal, market order for aggressive). See delta.
6. Re-price. It monitors implied volatility, cancels and re-prices resting option orders when needed, and throttles recalculation so that it only acts on meaningful, directional changes, which respects venue rate limits.

Use it when the desk thinks in volatility, not price, and wants the hedge handled automatically.

OTC Posting

OTC Posting is used primarily by OTC brokers that have white-labeled Liquid Mercury's OTC platform, but Pro customers can use it as well. Many liquidity providers accept only marketable orders. The OTC Posting algo lets a trader post a synthetic resting order against a pool of liquidity providers, so the trade executes at a predefined price at some point in the future. An example of a broker running on Mercury OTC is documented in the live K33 case study.

How it works.

1. Define the order. Set the price and size, and choose which liquidity providers to include.
2. Aggregate and monitor. Provider prices are aggregated into a single order book and monitored.
3. Execute. When the order becomes marketable, orders go to the chosen providers. A single order may be split into smaller orders depending on market conditions, and execution can use streaming or RFQ workflows.

Use it when the desk wants a resting, limit-style order but its liquidity providers only deal on marketable orders.

Basis trading and spread legging in plain language

A basis trade takes two positions in the same underlying asset at different prices. A common form buys the asset in the spot market and sells a future or perpetual against it, so the desk earns the gap between the two prices instead of betting on direction. A spread works the same way with other pairs, such as two contract months of one future, or the two sides of an options structure. In each case the trade only makes sense if both legs are done at a combined price the trader accepted.

Legging is the way a desk gets there. Legging into a spread means trading the legs one after another instead of as a single package. The risk is that the first leg fills and the market moves before the second one does, and the net price is worse than the one the trader wanted. Doing this by hand across several venues is slow, and a desk that wants to make its basis trading more efficient is usually trying to remove that gap.

The Spreader algo is built for this job. The trader defines the legs and a target price ratio or net price, and the algo watches depth on every leg, decides which to execute first and adjusts the later legs to hold the net price. The trader sets the venues, the maximum exposure on any one leg and the slippage allowed. If one leg fills and the spread moves outside acceptable risk, the algo can apply hedging techniques. See the Spreader section for the steps.

Two points apply to any spread tool. First, ask what happens to the filled leg if the rest of the package cannot be completed, because that is where the loss sits. Second, ask whether the net price is a limit the algo will not cross or a target it aims for. Both answers should be written down.

Order and execution management (OEMS) language

Buyers often ask for an OEMS, an order and execution management system. The term joins two jobs. The order management side records orders, positions and the state of each trade. The execution management side works the order in the market, through routing, algos and connections to venues. A desk that wants both in one place avoids copying orders between two screens. For the order side alone, see order management system.

Mercury Pro is described in its materials as an EMS and OMS in one platform, with the algos on this page, smart order routing and a centralized order book and aggregated positions across connected venues. Liquidity aggregation, the ability to see books from several venues in one place and route to them, is what Sweep builds on. How the platform reaches each venue is covered in crypto venue connectivity.

Choosing an algo

Algos are not exclusive. Sweep underlies several of the others, and Auto-Liquidation in Liquid Mercury's position management offers a TWAP-style passive mode for unwinding positions over time. For the controls that sit around any algo, see kill switch, and for how the platform reaches each venue, see crypto venue connectivity.