Skip to main content
These chains work differently enough inside that they match none of the other families, and what they have in common with each other is that and little else. Each one keeps its own set of tables. The Tables section below says where each chain’s tables are documented and names the two conventions that hold across all of them.

​
Chains

Chainchain_id
Algorandalgorand
Cardanocardano
Flowflow
Hederahedera
NEARnear
Rippleripple
Starknetstarknet
Stellarstellar
TONton
Trontron

​
Tables

Each chain’s tables are listed on its own page above, with every column and the month its history starts. Two habits hold across every chain here, whatever its tables are called. A table with one row per transaction or per event is split by day on block_timestamp, and a table of blocks on timestamp. Filter on that column in every query: without a filter the query reads the whole table. Identifiers reuse the familiar names wherever the chain has a matching idea: block_number, transaction_hash, and *_index for a position within something.

​
Exceptions

  • Ripple and Stellar call their blocks ledgers; on both chains the ledgers land in blocks.
  • Stellar splits a transaction into a list of operations, so operations holds what a transaction did and effects holds what each operation changed.
  • TON’s block_headers and shards are unpartitioned, so a query against either reads the whole table. Its transactions and messages split by day on block_timestamp, and blocks on timestamp, as usual.
  • Tron writes each address in two forms and both are here: the *_hex columns hold the form that looks like an Ethereum address, and the plain address-style columns hold the base58 form that starts with a T. Pick whichever matches the addresses you are joining against.