Skip to Content
Symmio Trading-SDK — the SDK surface for builders on Arbitrum
CorePoolsDetail tables

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.

TableReadBackend
PositionsgetListingMarketDetail + toPoolPositionsListing backend
Open quotesgetPoolQuotesAnalytics subgraph
Limit orderssearchTpSlOrdersTP/SL handler
Trade historygetPoolTradeHistoryAnalytics subgraph
Deposits and withdrawalsgetPoolTransactionsListing 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 / walletAddress differs row to row, so showing it is not decoration — without it the rows are ambiguous.
  • They are not the account-scoped reads. getQuoteHistory and getSubAccountQuotes answer “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

Helpers

Last updated on