Maker prioritization

Why Maker Prioritization Matters

Market makers provide liquidity by continuously quoting prices at which they are willing to buy and sell. In doing so, they take on a fundamental risk: adverse selection. When a market maker's quote is filled, it is disproportionately likely to be filled by someone with better information, an arbitrageur who knows the price is about to move, or a sandwich attacker who can guarantee it will. These fills are called toxic flow because they systematically leave the maker on the wrong side of the trade.

In traditional exchange microstructure, makers respond to this risk by competing on latency. The fastest maker to cancel or update a stale quote avoids being adversely selected. This creates an arms race where infrastructure investment matters more than liquidity quality. Only a few well-capitalized firms can compete effectively, reducing the diversity and depth of liquidity available to takers. And even then, latency competition doesn't eliminate adverse selection, it just redistributes it to the slower makers.

On Solana, this problem is amplified by atomic composability. A transaction can bundle a swap through a maker's quote with arbitrage instructions in the same block, guaranteeing the maker gets picked off before they can react. This makes the adverse selection problem not just probabilistic but deterministic for makers serving atomic flow.

Maker prioritization on Archer

Archer takes a fundamentally different approach on two fronts

• The matching engine uses price-priority pro-rata execution: at any given price level, all makers providing liquidity are filled proportionally to their size. A maker quoting 40 units at a price level receives twice the fill of a maker quoting 20 units at the same price. This shifts the competitive axis from speed to depth, makers are incentivized to provide more liquidity rather than faster updates.

• Archer provides market modes that let makers control their exposure to toxic flow. Asynchronous and hybrid markets break the atomicity that makes adverse selection deterministic, giving makers time to update quotes before execution. Combined with per-maker spread controls, makers can fine-tune exactly how much toxic flow they are willing to serve and at what price.

The result is a market structure where makers compete on the quality and size of their liquidity, not on who has the fastest connection.

How Matching Works on Archer

During a swap, the matching engine aggregates liquidity across all active maker books (up to 64 per market) and any resting limit orders into a unified order book. The engine then fills the taker order by walking through price levels in order of best price first.

At each price level, resting limit orders fill first in FIFO (first-in-first-out) order. After all limit orders at that price are exhausted, the remaining demand is distributed pro-rata across all makers quoting at that price level. Each maker receives a share of the fill proportional to their quoted size relative to the total maker liquidity at that level.

For example, if three makers are quoting on the ask side:

Price 100: Maker A — 10 units Price 101: Maker A — 20 units, Maker B — 20 units, Maker C — 40 units

A taker buy order of 30 units would first fill 10 units from Maker A at price 100. The remaining 20 units move to price 101, where they are distributed pro-rata: Maker A receives 5 units, Maker B receives 5 units, and Maker C receives 10 units, reflecting Maker C's 2x share of liquidity at that level.

Market Modes

Archer supports three market modes, each offering different trade-offs between composability and maker protection.

Synchronous (Continuous) Markets

Synchronous markets execute swaps atomically within a single transaction. The taker sends a swap instruction and receives their output tokens in the same transaction. This makes sync swaps fully composable with other Solana programs, aggregators like Jupiter can route through Archer markets seamlessly.

The trade-off is that atomic execution exposes makers to toxic flow. Arbitrageurs and sandwich attackers can compose their swap with other instructions in the same transaction, exploiting stale maker quotes before they can be updated.

Asynchronous Markets

Asynchronous markets break the atomicity of execution by introducing a time delay. When a taker initiates an async swap, their input tokens are escrowed into the market vault and a pending order is created on-chain. This order can only be executed after a minimum number of slots have passed (the minimum delay) and before a maximum number of slots (the expiry).

A permission-less cranker executes the order during this window. Anyone can crank, it is not permissioned. The cranker calls the execute instruction, which runs the matching engine against the current maker book state and settles the fill. If the order expires without being executed, the taker can cancel and reclaim their escrowed tokens.

This delay window is the key protection mechanism. Because the swap is not atomic, it cannot be composed with other instructions in a single transaction. Sandwich attacks require atomicity to be profitable, so breaking it eliminates the vector entirely. Makers can update their quotes between the taker's order placement and execution, removing the stale-quote problem.

The market admin configures the delay window by setting min_async_delay_slots and max_async_delay_slots. The minimum delay determines how long makers have to adjust their quotes. The maximum delay determines when unexecuted orders expire, preventing takers from holding free options against maker liquidity indefinitely.

Hybrid Markets

Hybrid markets combine both sync and async execution on a single market. This avoids fragmenting liquidity across separate markets while giving makers fine-grained control over their exposure to each flow type.

The core mechanism is economic discrimination: sync swaps (toxic flow) are made more expensive than async swaps (non-toxic flow) through two independent layers of protection.

Fee Multiplier (Market-Level)

The market admin sets a sync_fee_multiplier (1-7x) that is applied to the base taker_fee_ppm for sync swaps only. If the base taker fee is 100 PPM and the multiplier is 3x, sync swaps pay 300 PPM while async swaps continue paying 100 PPM. This compensates makers for the toxic flow risk of serving atomic swaps.

Sync Spread Ticks (Per-Maker)

Each maker independently sets a sync_spread_ticks value on their book. During sync swaps, the matching engine widens the maker's quoted prices by this amount, ask prices are raised and bid prices are lowered by the specified number of ticks. This makes the maker's sync liquidity less price-competitive without affecting their async pricing at all.

These two layers, the market-wide fee multiplier and the per-maker spread widening, work together to create a pricing gradient that steers toxic flow toward the async path where makers are protected by the delay window.

The hybrid mode can only be reached by upgrading from an asynchronous market. The market must be paused during the upgrade, the base taker fee must be non-negative, and async delays must already be configured.

Cranking and Taker Priority Fees

Async swap execution is permission-less, any third party can act as a cranker and execute pending orders. The cranker is incentivized through a fee paid by the taker.

When initializing an async swap, the taker specifies a cranker_fee_ppm - a fee in parts-per-million deducted from the taker's output tokens and paid to whichever cranker executes the order. This defaults to 100 PPM (0.01%) if the taker doesn't specify one, and can be set up to a maximum of 50,000 PPM (5%).

This fee functions as a priority mechanism. A higher cranker fee makes an order more attractive to execute, incentivizing crankers to prioritize it, especially during periods of network congestion where compute and block space are scarce. A taker who needs fast execution can set a higher fee; a taker who is price-sensitive can set a lower fee or even zero and accept that their order may be executed later in the window, or not at all.

On successful execution, the cranker receives the token fee plus the rent from closing the async swap account. If the order expires without execution, the taker cancels and reclaims their escrowed tokens in full, the cranker receives nothing.