TABLES of one per-chain transfer database (list the tables of eth, bsc, polygon, tron, solana,
bitcoin …) — the SHOW TABLES equivalent for eth_api, bsc_api,
matic_api (Polygon), arbitrum_api, base_api, optimism_api, robinhood_api, arc_api, tron_api, solana,
bitcoin, bitcoin_flow, ripple / ripple_flow (XRP Ledger), cardano / cardano_flow,
altcoin / altcoin_flow (Litecoin, Dogecoin and Dash in one database), bitcash / bitcash_flow
(Bitcoin Cash) and stellar — with each table's engine, sort key, partition key and approximate
row count (Total_Rows; empty for most solana, bitcoin, ripple, cardano, altcoin and stellar
tables, where no quick count exists). Only the tables you should query are listed, under the name to use in SQL.
The sort key is what makes raw SQL fast: filter on its LEADING columns first (e.g. the
address of transfers_sender / transfers_receiver, the transaction hash of the *_tx tables);
a query that skips them scans far more data and may time out.
Next steps: chain_describe_table for one table's columns, chain_search_columns to find which
table has a column, then that chain's <chain>_transfers_raw_sql to run the SQL (bitcoin and
bitcoin_flow → btc_transfers_raw_sql, matic_api → matic_transfers_raw_sql, ripple* →
xrp_transfers_raw_sql, cardano* → ada_transfers_raw_sql, altcoin* → ltc_ / doge_ /
dash_transfers_raw_sql with the chain's blockchain_id filter, bitcash* → bch_transfers_raw_sql,
stellar → xlm_transfers_raw_sql). Prefer a
specialized per-chain tool whenever one answers the question — chain_capabilities lists them.
For trading_rt (DEX trades, prices, OHLC bars) use list_tables; list_databases describes
every database.