Stellar

Twelve Parquet tables with 326 documented columns in total: blocks, transactions, operations_tx, payments_tx, transfers_tx, effects_tx, effect_arguments_tx, balance_effects_tx, trade_effects_tx, claimable_balance_effects, liquidity_pool_effects and liquidity_pool_trade_effects. Covering the most recent month to yesterday, refreshed daily.

Most amount columns are exact rational strings: numerator, slash, denominator. Stellar uses 7 decimal places, so the denominator is normally 10000000 and the value above is 2.9377351 XLM. Parse and divide rather than casting the string to a float. Keeping the fraction means no precision is lost at export.

No, and this is the trap worth knowing before you aggregate. Three representations appear: rational strings in payments_tx, trade_effects_tx, claimable_balance_effects, the liquidity pool tables, and the fee and reserve columns of blocks and transactions; plain floats in transfers_tx (amount_from, amount_to); and raw stroops as an integer string in balance_effects_tx (amount), where 7481895 means 0.7481895. Check the table before summing, and never add columns across tables without converting first.

Yes. transactions carries success, and payments_tx carries its own success flag at operation level — a transaction can succeed while an individual path payment fails. Filter success = 1 on whichever table you are aggregating.

A transaction holds one or more operations, and each operation emits zero or more effects. Join transactions to operations_tx on tx_hash, and operations to the effect tables on tx_hash plus operation_index. effect_index orders effects within an operation, and order gives their sequence within the ledger.

details and liquidity_pool_details are JSON-encoded strings you can parse directly. The path column in payments_tx is NOT JSON: it is Ruby hash-inspect format using => instead of a colon, for example [{"asset_code"=>"YBX"}]. A standard JSON parser will reject it — convert => to : first, or parse it with a permissive reader.

Bitquery address labels for the account in the adjacent column — an exchange or anchor name where we have one. They are frequently empty, so treat them as a bonus for entity resolution rather than a field you can rely on being populated.

Yes, and they are distinct tables because they are distinct mechanisms. trade_effects_tx holds order-book trades with an offer_id, while liquidity_pool_trade_effects holds AMM swaps with a liquidity_pool_id and the pool's reserves at the time. liquidity_pool_effects covers deposits and withdrawals rather than swaps.

As flat Parquet files under a stable S3 layout, one prefix per table, with a JSON manifest listing every file and its sha256. Signed HTTPS links are emailed to you once the files are prepared.

Refreshed daily with T+1 latency. A purchase made today includes everything up to yesterday.

Yes. Every table links to a public sample file with real records, and the sample bucket holds full Parquet files you can load directly. No email address required.