polymarket clob book: orderbook table shows worst prices first (best bid/ask buried at bottom) #75

Activity

1. aion-blue-labs commented on Jun 20, 2026

   

   aion-blue-labs

   on Jun 20, 2026 – with ChatGPT Codex Connector

   More actions

   This is worth treating as more than display polish. The same ordering pitfall can leak into bot/risk code if a caller accidentally treats the first array element as best price.

   A useful invariant for the CLI/tests would be:

   • best bid = max bid price, never bids[0] unless the API contract changes;
   • best ask = min ask price, never asks[0] unless the API contract changes;
   • human table should make those best levels visually adjacent or explicitly labelled;
   • JSON output should preserve raw API order for compatibility, as you noted.

   We hit the same class of bug in a pre-action risk gateway: the book looked like top_bid=0.001 / top_ask=0.999, which made otherwise liquid markets appear degenerate. A small regression fixture with intentionally reversed raw order would prevent this from reappearing in both display and downstream metrics.
2. osr21 commented on Jul 23, 2026

   

   osr21

   on Jul 23, 2026

   More actions

   Confirming the display order issue. The CLOB REST API returns:
   - bids sorted ascending by price (lowest bid first, best bid last)
   - asks sorted descending by price (highest ask first, best ask last)

   So the raw API order puts the least competitive prices at the top of both tables — the opposite of every standard orderbook UI convention.
   
   The correct display for a typical L2 orderbook is:
   
   ```
   Asks (descending — worst ask at top, best ask at bottom, closest to mid):
   ┌────────┬──────────┐
   │ 0.72   │ 3 200    │   ← worst ask
   │ 0.71   │ 1 800    │
   │ 0.70   │  900     │   ← best ask  ← spread here
   └────────┴──────────┘
   Bids (descending — best bid at top, worst bid at bottom):
   ┌────────┬──────────┐
   │ 0.69   │ 1 100    │   ← best bid  ← spread here
   │ 0.68   │ 2 400    │
   │ 0.67   │  600     │   ← worst bid
   └────────┴──────────┘
   ```
   
   Fix in Rust: reverse the iterators before building the `tabled::Table`:
   
   ```rust
   // bids: API returns ascending → display descending (best at top)
   result.bids.iter().rev()
   
   // asks: API returns descending → display descending (worst at top, best just above spread)
   // already in correct display order — no reversal needed
   result.asks.iter()
   ```
   
   Note: PR #81 already addresses this. This comment adds the rationale for why asks don't need reversal (they're already in the right display order from the API).