Pool detail tables
A pool’s detail view is five tables, and they do not come from one place. Three different backends fill them, and knowing which is which is what keeps a discrepancy between two tables from reading as a bug.
| Table | Read | Backend |
|---|---|---|
| Positions | getListingMarketDetail + toPoolPositions | Listing backend |
| Open quotes | getPoolQuotes | Analytics subgraph |
| Limit orders | searchTpSlOrders | TP/SL handler |
| Trade history | getPoolTradeHistory | Analytics subgraph |
| Deposits and withdrawals | getPoolTransactions | Listing backend |
These reads are pool-wide, not account-scoped
This is the single most important thing about them. getPoolQuotes, getPoolTradeHistory, getPoolTransactions and the limit-order search all return every trader’s rows on the market — there is no partyA filter anywhere in them.
That is deliberate: a pool page shows the pool’s book, not the visitor’s. It has three consequences worth designing around.
- No wallet is required. None of these reads needs a connected account, so the tables render for an anonymous visitor.
- The account column matters.
partyA/walletAddressdiffers row to row, so showing it is not decoration — without it the rows are ambiguous. - They are not the account-scoped reads.
getQuoteHistoryandgetSubAccountQuotesanswer “what does this account hold”; these answer “what is on this market”. Reaching for the wrong one gives an empty table or someone else’s data.
The subgraph reads scope by the pool’s symbolId and by source — the SYMMIO diamond the quotes were opened
against, which is simply the chain’s symmioAddress. There is no separate address to configure.
An unlisted pool has no book
A pool that has not reached LISTED has no symbolId, and without one there is no solver market to query. getPoolQuotes and getPoolTradeHistory short-circuit to an empty result rather than issuing a request, and their query factories stay enabled: false.
getPoolTransactions is the exception: deposits and withdrawals exist from the moment a listing is applied for, so that table has rows well before the pool is tradable.
Limit orders are not protocol LIMIT orders
The limit-orders table is filled by searchTpSlOrders with conditionalOrderType: TpSlSearchOrderType.SEND_QUOTE. A send_quote conditional order opens a quote when a trigger price is hit — a different mechanism from a protocol LIMIT order.
The distinction is load-bearing: the lowcap solver declares limitOrder: false, yet this table can still have rows. Do not gate it on the limitOrder capability.
Reads
One pool’s aggregate stats and inventory — the read a whole pool page is built on.
getPoolQuotesThe pool’s quote book from the analytics subgraph, filtered by quote status.
getPoolTradeHistoryThe pool’s realized closes and liquidations, one row per event.
getPoolTransactionsThe pool’s deposits and withdrawals, refunds included.
Helpers
Related
- Pools overview — the catalog these tables hang off.
searchTpSlOrders— the limit-orders read.- React: Pools hooks — the hook for each of these.