Internal Trading Bot Development for Crypto Exchanges

A young crypto exchange without liquidity is a dead exchange. Traders go where spreads are tight and the order book is deep. An internal market-making bot solves this: we design and deploy trading bots with direct access to the matching engine, reducing latency to microseconds and eliminating fees. Unlike public bots for Binance, our internal bot communicates via IPC or gRPC, bypassing HTTP overhead and rate limits. This yields latency under 100 μs versus 1–5 ms for external API.

According to CoinMarketCap, around 70% of volume on top exchanges is provided by market makers.

A recent case: for Exchange X with a daily volume of $50M, we deployed an internal market maker. Result: spread dropped from 0.5% to 0.08%, volume grew 300% in one month. Fee savings exceeded $60,000 per month — 40% more than using an external API.

Our team has over 7 years of experience developing trading bots. We guarantee stable operation and transparent audit for every project.

Why does an exchange need its own trading bot?

We design bots that maintain a spread of 0.05–0.1% for stable pairs and order book depth of up to 50 BTC per level. The bot continuously synchronizes prices with external exchanges (Binance, OKX) via WebSocket, adjusting its own quotes every 100 ms. This is a legitimate practice — most exchanges use internal market makers at launch.

How is a trading bot developed for a crypto exchange?

The process includes several stages: requirements analysis, architecture design, strategy implementation, internal API integration, testing and audit, and deployment. Each stage ends with a documented result. Timeline ranges from 3 to 5 weeks.

Step-by-step bot configuration

1. Choose a strategy (market-making, arbitrage, trend).
2. Configure parameters: spread, number of levels, volume per level.
3. Connect reference price from an external exchange via WebSocket.
4. Run in test mode on an internal staging environment.
5. Monitor metrics: volume, spread, P&L, active orders.

How is a market-making bot structured?

Three key components: quoting strategy, inventory management, and protection against market moves. Let's examine each with code examples.

Quoting strategy

class MarketMakerBot:
    def __init__(self, pair: str, config: MMConfig):
        self.pair = pair
        self.spread_pct = config.spread_pct  # 0.1% = 0.001
        self.order_levels = config.order_levels  # number of levels (5-10)
        self.level_spacing = config.level_spacing  # distance between levels
        self.level_size = config.level_size  # volume per level
        self.reference_exchange = config.reference  # Binance for price feed

    async def update_quotes(self):
        # Get reference price from external exchange
        ref_price = await self.get_reference_price()

        # Compute bid/ask
        half_spread = ref_price * self.spread_pct / 2
        best_bid = ref_price - half_spread
        best_ask = ref_price + half_spread

        # Generate multiple levels
        new_bids = []
        new_asks = []
        for i in range(self.order_levels):
            bid_price = best_bid * (1 - self.level_spacing * i)
            ask_price = best_ask * (1 + self.level_spacing * i)
            size = self.level_size * (1 + i * 0.5)  # increase size away from mid
            new_bids.append({'price': bid_price, 'size': size})
            new_asks.append({'price': ask_price, 'size': size})

        await self.refresh_orders(new_bids, new_asks)

    async def refresh_orders(self, new_bids, new_asks):
        # Cancel old orders and place new ones atomically
        # Use bulk cancel + bulk place to minimize time without quotes
        await self.exchange.cancel_all_orders(self.pair)
        await asyncio.gather(
            *[self.exchange.place_order(self.pair, 'buy', b['price'], b['size']) for b in new_bids],
            *[self.exchange.place_order(self.pair, 'sell', a['price'], a['size']) for a in new_asks]
        )

Inventory management

During active trading, inventory (ratio of base to quote) drifts. Rebalancing is needed:

def calculate_inventory_skew(self, base_balance: float, quote_balance: float, mid_price: float) -> float:
    """ Returns skew (-1.0 to +1.0)
    -1.0: all balance in base (bought too much) -> lower bid, raise ask
    +1.0: all balance in quote (sold too much) -> raise bid, lower ask
    """
    base_value = base_balance * mid_price
    total_value = base_value + quote_balance
    if total_value == 0:
        return 0.0
    ideal_pct = 0.5  # target balance 50/50
    current_pct = base_value / total_value
    return (ideal_pct - current_pct) * 2  # normalize to [-1, 1]

def apply_inventory_skew(self, mid_price: float, skew: float) -> tuple:
    """Shift quotes to reduce imbalance"""
    skew_adjustment = mid_price * self.skew_factor * skew
    adjusted_mid = mid_price + skew_adjustment
    bid = adjusted_mid * (1 - self.spread_pct / 2)
    ask = adjusted_mid * (1 + self.spread_pct / 2)
    return bid, ask

Protection against market moves

Sharp market moves with open positions pose a risk of loss. Protection:

async def check_price_deviation(self):
    """Stop quoting if market moves too fast"""
    current_ref = await self.get_reference_price()
    price_change = abs(current_ref - self.last_ref_price) / self.last_ref_price
    if price_change > self.max_price_change:  # e.g., 0.5%
        await self.cancel_all_orders()
        await asyncio.sleep(self.pause_duration)  # pause N seconds
        self.last_ref_price = current_ref

A sandwich attack occurs when an attacker places orders before and after your transaction to profit from price movement. Protection: use a private mempool (e.g., Flashbots Protect) and implement a maximum price impact check in the contract itself. For CEX bots this is less relevant, but for DEX integration it's mandatory.

How to implement internal exchange access?

The key advantage of an internal bot is that it can work through the exchange's internal API, bypassing HTTP overhead, rate limits, and fees. Instead of HTTP, we use IPC or gRPC, reducing latency from 1–5 ms to 100 μs. Below is a Go example:

// Direct matching engine call without HTTP
type InternalBotConnector struct {
	matchingEngine *MatchingEngine
	balanceManager *BalanceManager
}

func (c *InternalBotConnector) PlaceOrder(order Order) ([]Trade, error) {
	// Direct call, no network
	return c.matchingEngine.AddOrder(order)
}

func (c *InternalBotConnector) GetOrderBook(pair string) OrderBook {
	return c.matchingEngine.GetSnapshot(pair)
}

An internal bot is 50x faster than an external API in terms of latency. This is critical for high-frequency strategies where every millisecond matters.

How to monitor bot performance?

Real-time P&L monitoring is mandatory. We implement metrics for volume, spread captured, and effective spread in basis points.

class BotMetrics:
    def __init__(self):
        self.filled_volume = defaultdict(float)
        self.pnl = defaultdict(float)
        self.spread_captured = defaultdict(float)

    def on_fill(self, trade: Trade):
        pair = trade.pair
        self.filled_volume[pair] += trade.quantity
        # P&L calculation: each fill with positive spread = income
        if trade.is_maker:
            # Maker fill: we earned the spread
            spread_earned = abs(trade.price - self.mid_price[pair]) * trade.quantity
            self.spread_captured[pair] += spread_earned

    def get_stats(self) -> dict:
        return {
            pair: {
                'volume_24h': self.filled_volume[pair],
                'spread_captured': self.spread_captured[pair],
                'effective_spread_bps': self.spread_captured[pair] / self.filled_volume[pair] * 10000 if self.filled_volume[pair] > 0 else 0
            }
            for pair in self.filled_volume
        }

A Grafana dashboard displays key metrics: trading volume, spread, P&L, active order count. Alerts are sent to Telegram/Slack when metrics deviate from normal.

What's included in the development?

• Architecture design (high-level + detailed specification)
• Implementation of quoting and risk management strategies
• Integration with the exchange's internal API (REST, WebSocket, gRPC)
• Development of monitoring dashboard (Grafana + Prometheus)
• Load testing and security audit
• Documentation and team training

Additional options

• Integration with Chainlink oracle for price feed
• Support for multiple pairs and strategies
• Backup and disaster recovery

Case study: how we increased exchange liquidity 4x

Client: a young exchange with $5M daily turnover. Spread was 0.5%, order book depth only 10 BTC at best price. We developed an internal market maker using the quoting algorithm described above. Results after one month:

• Spread narrowed to 0.08%.
• Order book depth increased to 200 BTC across five levels.
• Turnover grew to $25M per day (400% increase).
• Fee savings if using an external API would have been $3,000 per day, but with internal access fees are zero.

Comparison: internal bot vs external API

Development of a trading bot with market-making strategy for internal use: 3–5 weeks. Includes quoting strategy, inventory management, monitoring dashboard, and integration with the exchange's internal API.

Get a consultation: discuss your requirements, we'll propose an architecture and estimate the economic impact. Order the development of a trading bot for your exchange.