Orderbook

The orderbook is the core matching engine for limit and market orders on Intotes. Every market maintains its own orderbook, which pairs buyers and sellers at agreed-upon prices using standard price-time priority.

Bids and Asks

An orderbook consists of two sides:

• Bids (buy orders) -- traders willing to buy shares at a given price or lower.
• Asks (sell orders) -- traders willing to sell shares at a given price or higher.

Bids are sorted from highest to lowest price, because the most aggressive buyer (highest price) should be matched first. Asks are sorted from lowest to highest price, because the most aggressive seller (lowest price) should be matched first.

Price-Time Priority

When multiple orders exist at the same price level, the order that was placed first gets filled first. This is the standard price-time priority model used by most exchanges:

1. Orders are first ranked by price (best price wins).
2. Among orders at the same price, the earliest order wins.

OrderbookEntry Structure

Each price level in the orderbook is represented by an entry containing two fields:

{
  "price": 6500,
  "amount": 25000
}

Field	Type	Description
price	int64	Price in cents (6500 = $0.65)
amount	int64	Total volume available at this price, in cents

All monetary values are integers representing cents. See the Money Format page for details on how Intotes represents currency.

Orderbook Response

When you fetch orderbook data for a market, the response contains the full depth on both sides:

{
  "market_id": 101,
  "bids": [
    { "price": 6500, "amount": 25000 },
    { "price": 6400, "amount": 18000 },
    { "price": 6300, "amount": 12000 }
  ],
  "asks": [
    { "price": 6700, "amount": 20000 },
    { "price": 6800, "amount": 15000 },
    { "price": 6900, "amount": 10000 }
  ]
}

• bids are sorted high to low (best bid first).
• asks are sorted low to high (best ask first).

Spread

The spread is the gap between the best ask and the best bid:

spread = best_ask - best_bid

In the example above, the spread is 6700 - 6500 = 200 cents ($0.02). A tighter spread means better liquidity and lower trading costs for participants.

In-Memory Orderbook

The orderbook is maintained entirely in memory for maximum performance. Best bid and best ask lookups are O(1) operations, meaning order matching and price discovery happen with minimal latency regardless of orderbook depth.

When the server starts, orderbooks are reconstructed from persisted open orders in the database.

Automatic Liquidity

To ensure markets always have sufficient depth, Intotes automatically manages liquidity on the orderbook:

• Spread target: The system keeps the spread at or below 2 cents ($0.02). If the spread widens beyond this threshold, the system places orders to tighten it.
• Volume floor: If either side of the book drops below $200 in total volume, the system adds orders to restore depth.
• Trigger conditions: Liquidity is refreshed after every trade and also on a periodic schedule of every 5 minutes, whichever comes first.

This automatic liquidity mechanism ensures that traders can always execute at reasonable prices, even in less actively traded markets. The system-placed orders behave identically to user-placed orders and follow the same matching rules.

How Matching Works

When a new order arrives:

1. If it is a buy order, it is compared against existing asks starting from the lowest ask price.
2. If it is a sell order, it is compared against existing bids starting from the highest bid price.
3. If the incoming order's price crosses the opposing side (e.g., a buy at $0.68 when the best ask is $0.67), the order is filled immediately at the resting order's price.
4. If the incoming order is only partially filled, the remaining amount is placed on the book at the original limit price.
5. If no match is possible, the entire order rests on the book until it is filled or cancelled.

Intotes uses a hybrid model: limit orders are first matched against the orderbook, and any residual quantity that cannot be filled by resting orders is routed to the LMSR AMM for execution against the liquidity pool.