🆕 Liquidity scaling for operators

‍Summary: In this crypto exchange operator playbook we learn how to use a mix of market‑maker automation, external liquidity routing, and strong flagship pairs to scale liquidity. We also cover how to measure spread and depth targets per market. Monitor and adjust daily, and you should aim to shift liquidity responsibilities toward your user base over time.

‍

Objective

In plain terms: Make every market feel liquid. This means tight prices, quick fills, steady books. Ensure each tradable market has professional‑grade liquidity: tight spreads, sufficient depth at the top of book, reliable execution during volatility, and a plan to scale without central risk.

‍

Who this covers

Centralized trading platforms, crypto order‑book spot exchanges; adapt thresholds for derivatives.

• Centralized, order‑book exchanges running on HollaEx® white-label or similar exchange architectures.
  
  
• Applies to spot pairs; adapt thresholds for derivatives.
  
  

‍

What liquidity actually means

When traders say a market “feels good,” they usually mean the following are true:

• Depth: volume available near the top of the book (e.g., within 1% from global market prices).
  
  
• Spread: a reasonable distance (spread) between best bid and best ask.
  
  
• Execution quality: price impact and fill consistency at common order sizes.
  
  
• Reliability: ability to keep books stable during fee spikes and news events.
  
  

High liquidity produces tighter spreads and faster fills. Poor liquidity increases slippage and pushes users to competitors.

‍

‍

KPIs to track (set per market)

Numbers that prove liquidity is real, not just window dressing.

• Target spread band: e.g., flagship pairs ≤ 10 bps (0.10%), long‑tail ≤ 30–50 bps.
  
  
• Visible depth: inventory within ±0.5% of mid. Start with: flagship ≥ $50k, long‑tail ≥ $10k.
  
  
• Quote presence: ≥ 99% of the trading day both sides are quoted.
  
  
• Fill ratio: market orders ≤ $X filled within target impact (say ≤ 5 bps).
  
  
• Order freshness: average quote lifetime and cancel‑replace rates within healthy bounds.
  
  
• Inventory bounds: max inventory per market‑maker to avoid runaway exposure.
  
  

Use tighter bands for BTC‑USDT/ETH‑USDT; allow wider bands for small caps.

‍

Decision rules

Quick rules you can apply without a meeting.

• Start with automation. If a pair is new or thin, run a bot before marketing the market.
  
  
• Anchor around flagship pairs. Keep BTC‑USDT and ETH‑USDT pristine; other pairs benefit indirectly.
  
  
• Prefer APIs over manual intervention. Liquidity must be programmable and observable.
  
  
• External routing is a lever, not a crutch. Use it to hit bands, then taper as user flow grows.
  
  
• Fail safe. If a provider or bot degrades, widen spreads gracefully and fall back rather than halting the market.
  
  

Procedures

Use these in this order for new pairs. Steps (1) and (2) can run in parallel.

‍

1) Stand up automated market making

Start here when launching or reviving a pair.
 

What: Run a bot that maintains quotes around mid, with target spread and inventory rules.
 

Why: Keeps the book active 24/7, reduces empty books at off‑hours.
 

How: Connect a Market Maker bot:
https://docs.hollaex.com/advanced/market-making-bot/

‍

Example Market Making Bot config:

‍

Initial parameters (example for BTC‑USDT):

• target_spread: 8–12 bps
  
  
• depth_ladder: quotes every 5–10 bps out to 50 bps
  
  
• order_size_top: $2k, ladder grows further out
  
  
• inventory_cap: $100k notional
  
  
• refresh_interval_ms: 150–500
  
  
• quote_presence_target: ≥ 99%
  
  

Verification:

• Spread band meets ≤ 10 bps during normal hours.
  
  
• Top‑of‑book depth ≥ $50k within ±0.5%.
  
  
• Quotes not flapping (reasonable lifetime; healthy cancel/replace).
  
  

Exceptions:

• Fee spikes or node lag: reduce frequency and widen target spread temporarily.
  
  

Rollback:

• Disable new quotes, cancel outstanding, set market to “maker‑only” for 5 minutes while restarting bot.
  
  

Monitoring:

• Alerts on spread > target, quote presence < 98%, inventory > cap.
  
  

‍

‍

2) Connect external liquidity providers

Use when you need depth urgently. At launch, during promos, or for thin books.

 What: Mirror or route to external venues or market makers to deepen the book.
 

Why: Immediate depth and narrower spreads, especially at launch.
 

How (HollaEx®): Many market making services such as Wintermute and others can provide a service for filling your orderbooks.

Routing rules (examples):

• Use external quotes to backstop the top 50 bps of book.
  
  
• Cap routed order size per venue to control exposure.
  
  
• Circuit breaker: if slippage > threshold or venue health fails, route locally.
  
  

Verification:

• Post‑integration spread tightens to target.
  
  
• Depth within ±0.5% meets the dollar goal.
  
  
• No unexpected balance drift with venues.
  
  

Exceptions:

• Venue outage or abnormal latency: pause routing and rely on internal bot until health recovers.
  
  

Rollback:

• Flip to internal‑only quoting; clear stale links; re‑enable after checks.
  
  

Monitoring:

• Venue heartbeat, fill rejection rate, average routing latency, discrepancy vs reference price.

‍

Alternative to orderbooks:

If your team or resources are small consider operating simple broker style markets, not an orderbook, and setup an OTC price. The HollaEx® system allows the market maker or operator to define what account to source the funds (inventory) for both buy and sell side. This is a drastically simpler way to provide liquidity as there isn't complex orderbook price levels to manage.

‍

‍

3) Strengthen flagship pairs

These are your storefront windows; keep them immaculate.

 What: Keep BTC‑USDT and ETH‑USDT as your highest‑quality books.
 

Why: They set user trust for the whole exchange.

How:

• Double the top‑of‑book depth vs smaller pairs.
  
  
• Maintain the tightest spread band (≤ 10 bps).
  
  
• Monitor continuously during peak and news hours.
  
  
• Example live market: https://hollaex.com/trade/btc-usdt
  
  

Verification:

• Tighter spreads than other pairs.
  
  
• High fill ratio for common order sizes.
  
  

Exceptions:

• News shocks: temporarily widen bands and increase inventory caps within risk policy.
  
  

Rollback:

• If depth collapses, freeze listings dependent on the pair until quality returns.
  
  

Monitoring:

• Top‑of‑book depth, spread, rejects, queue length.
  
  

‍

4) Improve routing with enterprise features

Turn this on when growth outpaces today’s routing and throughput.

 What: Use multi‑venue aggregation, smarter routing, and higher‑throughput engines.
 

Why: Handle growth without liquidity bottlenecks.
 

How (HollaEx®): Explore Enterprise options:
https://hollaex.com/exchange/enterprise

‍

Verification:

• Lower average spread and better fill quality at larger sizes.
  
  
• Reduced incidents from venue issues due to failover.
  
  

Exceptions:

• Unexpected costs: tune routing weights or cut low‑value venues.
  
  

Rollback:

• Revert to a simpler routing profile; keep flagship pairs fully covered.
  
  

Monitoring:

• Venue cost per filled notional, failover events, per‑venue SLA compliance.
  
  

‍

5) Grow user‑generated liquidity

The endgame: most quotes come from your own users.
What: Over time, shift reliance from automation/routing to your user base.
Why: Healthier books and lower long‑run costs.
How:

• Lower maker fees on targeted pairs.
  
  
• Loyalty tiers and rewards.
  
  
• Referral incentives.
  
  
• List assets with active communities and credible teams.
  
  

Verification:

• Rising share of volume from natural takers/makers.
  
  
• Decreasing reliance on external routing for top‑of‑book.
  
  

Exceptions:

• If natural flow weakens, temporarily increase automation or routing until it rebounds.
  
  

Rollback:

• Re‑enable tighter bot parameters or expand venue coverage.
  
  

Monitoring:

• Maker vs taker share, incentives cost vs spread improvement, community‑driven volume.
  
  

‍

6) Hedge all trades

Ensure you have a clear hedging strategy and a well-defined rebalancing process. Allocate a portion of your liquidity budget to hedge exposure on external platforms.

For example, if your market-making bot accumulates too much BTC or too much USDT due to users trading with your bot, that imbalance can be offset on another exchange. A separate hedging bot can be configured to mirror the opposite side of trades executed by the market-making bot when its orders are filled.

So, if the market-making bot sells BTC, the hedging bot can simultaneously (or shortly after) buy back BTC at a better price on Binance or another exchange. This simple mirrored flow effectively hedges your trades so the market-making bot is not left with a large unbalanced position when users aggressively buy or sell against it.

‍

How is this done?

Like with the market making bot, an operator must make an account on an outside exchange, preferably with low trading fees and business account. This account should generate API key with trading allowed. The bot should watch for all the trades of the market making bot it wants to hedge against and do the opposite trade on the same market pair on the outside exchange. The API secret key should only be kept secret and only used by the hedging bot. The HollaEx® OTC broker has a built in hedging mechenism.

‍

‍

Coding your own bot yourself for hedging an MM bot on an orderbook market

‍

Example code:

‍

1. Install dependency:

pip install ccxt

‍

2. Simple hedging bot example (Python)

import ccxt

import time

# =========================

# CONFIG

# =========================

HEDGE_EXCHANGE_ID = "binance"  # e.g. "binance", "kucoin", etc.

API_KEY = "YOUR_BINANCE_API_KEY"

API_SECRET = "YOUR_BINANCE_API_SECRET"

# Safety settings

MAX_NOTIONAL_PER_TRADE = 10_000    # in quote currency (e.g. USDT)

SLIPPAGE_BPS = 20                  # 20 bps (0.20%) allowed slippage

# =========================

# EXCHANGE SETUP

# =========================

def init_hedge_exchange():

   exchange_class = getattr(ccxt, HEDGE_EXCHANGE_ID)

   exchange = exchange_class({

       "apiKey": API_KEY,

       "secret": API_SECRET,

       "enableRateLimit": True,

   })

   exchange.load_markets()

   return exchange

hedge_exchange = init_hedge_exchange()

# =========================

# CORE HEDGING LOGIC

# =========================

def hedge_trade(trade):

   """

   Mirror a trade from your market-making bot on an external exchange.

   Expected trade dict structure:

   {

       "symbol": "BTC/USDT",

       "side": "buy" or "sell",    # what YOUR MM bot did

       "amount": 0.01,             # base amount (e.g. BTC)

       "price": 65000.0,           # fill price on your MM venue

       "id": "optional-mm-trade-id"

   }

   """

   symbol = trade["symbol"]

   mm_side = trade["side"]

   amount = float(trade["amount"])

   mm_price = float(trade.get("price", 0))  # optional

   # Opposite side for hedging

   hedge_side = "sell" if mm_side == "buy" else "buy"

   # Basic notional check

   if mm_price > 0:

       notional = amount * mm_price

       if notional > MAX_NOTIONAL_PER_TRADE:

           print(f"[SKIP] Notional {notional} exceeds limit {MAX_NOTIONAL_PER_TRADE}")

           return

   # Make sure the symbol exists on hedge exchange

   if symbol not in hedge_exchange.markets:

       print(f"[WARN] Symbol {symbol} not found on hedge exchange. Skipping.")

       return

   # Get current orderbook to have an idea of fair price & slippage

   orderbook = hedge_exchange.fetch_order_book(symbol)

   best_bid = orderbook["bids"][0][0] if orderbook["bids"] else None

   best_ask = orderbook["asks"][0][0] if orderbook["asks"] else None

   if best_bid is None or best_ask is None:

       print("[WARN] Empty orderbook, skipping hedge.")

       return

   mid_price = (best_bid + best_ask) / 2

   # Simple slippage check against MM fill price, if available

   if mm_price > 0:

       diff = abs(mid_price - mm_price) / mm_price * 10_000  # in bps

       if diff > SLIPPAGE_BPS:

           print(f"[WARN] Slippage {diff:.1f} bps > {SLIPPAGE_BPS} bps, skipping hedge.")

           return

   print(f"[HEDGE] MM {mm_side} {amount} {symbol} @ {mm_price}, "

         f"placing {hedge_side} hedge on {HEDGE_EXCHANGE_ID} at market.")

   try:

       # Use market order for simplicity; in production you'd likely want limit orders.

       order = hedge_exchange.create_order(

           symbol=symbol,

           type="market",

           side=hedge_side,

           amount=amount,

       )

       print(f"[OK] Hedge order placed: {order['id']}")

   except Exception as e:

       print(f"[ERROR] Failed to place hedge order: {e}")

# =========================

# INTEGRATION EXAMPLE

# =========================

def on_mm_trade_filled(trade):

   """

   This function should be called by your MM bot whenever an order is filled

   on your own exchange.

   """

   # Here you could add filters (symbols, min size, etc.)

   hedge_trade(trade)

# =========================

# DEMO / TEST

# =========================

if __name__ == "__main__":

   # Simulated trade coming from your market making bot

   simulated_trade = {

       "symbol": "BTC/USDT",

       "side": "sell",        # your MM bot sold BTC to a user

       "amount": 0.01,

       "price": 65000.0,

       "id": "mm-trade-12345",

   }

   on_mm_trade_filled(simulated_trade)

‍

‍

How you’d plug this into your setup

• On your HollaEx® / MM bot side, whenever an order is filled and you log it, call something like:

on_mm_trade_filled({
   "symbol": symbol,
   "side": side,           # "buy" or "sell" from MM bot perspective
   "amount": filled_amount,
   "price": fill_price,
   "id": trade_id,
})

‍

That function just forwards the trade to the hedging logic, which places the opposite order on the hedge venue.

‍

‍

Verification runbook (daily)

A five‑minute morning checklist for on‑call or ops.

• Review spread and depth KPIs against targets and hedge & rebalance when needed (read above).
  
  
• Check quote presence and inventory bounds for each bot.
  
  
• Confirm routed fills by venue and compare execution quality.
  
  
• Recalculate spread bands weekly; adjust per market if demand shifts.
  
  

‍

Exceptions

What to do when reality misbehaves.

• Chain congestion: raise fee caps and lower bot frequency; keep books online.
  
  
• Venue outage: fail closed on routing; internal bot only.
  
  
• Price shocks: widen bands temporarily and increase inventory cap within risk policy.
  
  

‍

Rollback

Safe retreat plan if a change backfires.

• Disable external routing, cancel resting quotes, restart with conservative parameters.
  
  
• Communicate status to support and update status page if user impact is visible.
  
  

‍

Monitoring & alerts

The small set of alerts that matter—each tied to an action.

• Spread > target for more than T minutes.
  
  
• Top‑of‑book depth < threshold.
  
  
• Quote presence < 98%.
  
  
• Inventory > cap.
  
  
• Venue health failing or high reject rate.
  
  
• Execution slippage > X bps vs reference.
  
  

‍

Checklist

Before you call a market “ready,” confirm these are ticked.

• Market Maker Bot connected via API and meeting spread/depth targets.
  
  
• External routing configured and healthy.
  
  
• BTC‑USDT and ETH‑USDT set as anchor pairs with stricter bands.
  
  
• Enterprise routing profile evaluated for growth.
  
  
• Incentives live for makers; tracked for ROI.
  
  
• Alerts wired for spread, depth, presence, inventory, venue health.
  
  
• Weekly review of spread bands and thresholds.
  

• Hedging strategy is in place and that clear rebalancing process is worked out.

‍

Closing

Bottom line: good markets are built, not found. Liquidity is not one switch. It is a system: automated quotes, external depth, strong anchors, and incentives that attract natural flow. Start with automation, add routing to hit targets, and let user demand take over as markets mature.

‍

HollaEx® links from this playbook:

• Market Maker bot: https://docs.hollaex.com/advanced/market-making-bot/
  
  
• BTC‑USDT live market: https://hollaex.com/trade/btc-usdt
  
  
  

Related playbooks:

• Hot, Cold, and Wallet Sweeps: Setting Treasury Thresholds
  
  

Modular Crypto Exchanges: The New Blueprint for Building Customizable Trading Platforms

‍

‍