Tables & naming

For a program with a bundled IDL, OnchainQueries generates several aliases for the same physical table. A Pump Fun event table can be addressed as any of these:

pump_fun_trade_eventprod_solana_eventstream.pump_fun_trade_eventpump_fun.trade_eventpump_fun_solana.pump_fun_evt_trade_event

Instruction tables use qualified names built from the instruction rather than the event:

pump_fun_solana.pump_fun_call_buy

Names are derived from the program’s own IDL, so tradeEvent becomes trade_event. OnchainQueries also exposes verified account_<name> aliases for instruction account columns when the bundled IDL and live schema agree. Unknown tables and aliases fail before a source query is issued.

The physical catalog is fixed to prod_solana_eventstream. OnchainQueries records the source catalog hash and high-watermark slot used to plan a query, and fingerprints source partitions before and after execution — if the catalog or relevant partitions change mid-flight, it retries the affected work rather than publishing a mixed result.

dex_solana.trades and dex.swaps are available when the required Pump Fun columns exist.

If you need market-wide numbers, query the individual protocol tables and union them yourself — that way the coverage is something you decided, not something you inherited.

Sixteen of the 37 bundled programs declare no events in their IDL, so they have no evt_ tables at all. Their activity is read from call_ tables instead — the instruction and the accounts it touched. Every dataset page states which tables a program actually has.