How Market-Making Bots Work: Spreads, Inventory and Skew

Market-making bots earn money by sitting on both sides of an order book simultaneously — posting a bid slightly below the fair price and an ask slightly above it. The difference, the spread, is the gross profit on every round-trip fill. But capturing that spread reliably is much harder than it sounds, because the bot is constantly accumulating directional risk it never asked for.

Understanding how a market-maker actually manages that risk is what separates theoretical edge from a live system that keeps running after a volatile session. Our trading-bot services are built around exactly this loop.

The Spread-Capture Loop

Every market-making bot operates a tight cycle:

1. Quote — place a bid and an ask around a reference price (mid-market, oracle, or VWAP).
2. Wait for fills — one side of the quote gets lifted by an incoming taker.
3. Rebalance — cancel the remaining resting order, reprice around a fresh mid, and repost.

The raw economics look attractive: if the bot quotes a 10 bp spread on a perpetual futures CLOB like Hyperliquid, every completed round-trip (bid filled, then ask filled, or vice-versa) nets 10 bp minus fees. At meaningful notional size, this compounds quickly. The problem is that fills rarely arrive symmetrically.

When only one side is hit repeatedly — say, all bids fill while asks go untouched — the bot accumulates a long inventory position it did not want. If price continues falling, inventory losses eat into every spread gain. This is adverse selection: the takers who fill the bot's quotes often know something the bot doesn't, at least in that instant.

Inventory Risk and Quote Skew

The core defense against inventory blow-up is quote skew. The bot tracks its net position in the base asset — in real time, updated on every fill event — and tilts its quotes to encourage the market to rebalance it.

If the bot is long 5 SOL more than its target, it shifts both bid and ask slightly down: the ask becomes cheaper, attracting more sell-side takers, while the bid moves away from where buying pressure is concentrated. The skew magnitude is typically a linear or sigmoid function of inventory deviation normalized to a maximum position limit.

On a venue like Hyperliquid, which uses a CLOB with on-chain settlement and funding rates on perpetuals, the bot must also factor the current funding rate into its fair-value calculation. A strongly positive funding rate — longs paying shorts — makes a long position bleed cash every hour, so the target position might shift net-short during those periods.

On Solana, the data-feed problem is more acute. Useful implementations subscribe to an account-change Geyser stream to get sub-slot latency on order book updates, rather than polling RPC. Order placement uses Jito bundles with competitive priority fees to land transactions before the book moves — particularly important when trading on AMMs or hybrid CLOBs where backrunning is common. For a deeper look at how these components wire together, see our Hyperliquid market-maker case study.

Kill-Switches, Simulation and Latency Budget

No spread-capture model survives without hard guardrails:

• Position limits and kill-switches — if net exposure breaches a threshold (e.g., ±$10 k notional), the bot cancels all open orders and halts until manually re-enabled. This prevents a runaway skew loop during an illiquid gap.
• Spread floors — the minimum quote width is widened automatically during high-volatility regimes (measured by realized vol over a rolling window), so the bot doesn't post a 5 bp spread into a news event.
• Simulation and anti-rug checks — before sending any transaction on Solana, a preflight simulation call validates that the instruction will land as intended. This catches cases where a pool was drained or a program was upgraded mid-session.
• Latency budget — the entire loop (feed event → reprice decision → order cancel/place) must complete within the target slot time (~400 ms on Solana). Anything slower and the stale quote becomes a gift to arbitrageurs. Geyser websocket feeds, local order-book mirroring, and pre-signed cancel transactions queued in memory are standard techniques to stay within budget.

On prediction markets like Polymarket, the mechanics differ at the edges but the core loop is the same: quote around an implied probability, skew when your YES inventory gets heavy, and widen the spread when the market approaches resolution time because tail risk spikes.

Putting It Together

The loop is simple to describe and genuinely difficult to get right. Quote → fill → reprice is three steps, but each step touches real-time data latency, on-chain execution costs, inventory accounting, and risk limits that all have to function coherently under market stress.

If you are building or evaluating a market-making system, the questions worth asking are: what is the skew function's response curve, what is the kill-switch threshold and who can override it, and what does the P&L attribution look like separated into spread capture versus inventory carry? A system that can answer those questions cleanly is one that is actually under control.

Start a project with our team to discuss how these mechanics apply to your specific venue and token pair.

---

Ready to run a market-making strategy on Solana, Hyperliquid, or Polymarket? Tell us about your project and we will scope a system built around your target spread, position limits, and latency requirements.