Read docs

ar.io — verifiable indexes

Query Arweave's base layer. Verify every byte.

Every transaction on Arweave, searchable with SQL right here. No account, no install, and your queries never leave the browser.

—
Transactions
—
Blocks
—
Covering
Checking the publisher's signature… How it's verified
  1. The publisher's signing key, read from the ar.io registry through a different gateway
  2. The publication's signature, checked against that key
  3. The query engine, matched against a hash pinned in this page, and its Parquet reader, which the engine accepts only with DuckDB's signature — checked when you first load data
  4. Every piece of data a question reads, checked as it arrives against the file's BitTorrent v2 hash tree, whose root the signed publication pins — checked when you first ask

A question fetches only the parts of each file it needs, and nothing it reads is used until it matches the hash tree. Where a browser cannot do that, files are downloaded whole and hashed against the digest the signature covers instead. A failure at any step stops the question, and a check that cannot run counts as a failure. This page's own scripts, the range reader included, come in the same Arweave manifest as the page, so they are not hashed separately.

Ask the chain

Search, pick a question, or write SQL. Answers are computed in this tab.

 

Checking the publication first…

Pick a question, or search for anything on Arweave

Show the SQLHide the SQL edit it, or write your own

Start from an example:

Over the period chosen at the top

Columns and SQL tips

The txs table

tx_idTransaction ID, base64url, as you would paste into a gateway URL
heightBlock height it was mined in
mined_atWhen that block was mined, a real timestamp you can date_trunc
ownerWallet address that signed it, base64url
targetRecipient address for a transfer, empty otherwise
data_sizeBytes of data, as an integer
content_typeIts Content-Type tag, often NULL
quantityAR transferred, in winston
rewardMining fee paid, in winston
format1 or 2, the transaction format
data_rootMerkle root of the data, base64url

The blocks table

heightBlock height, joins to txs.height
mined_atTimestamp the block was mined
tx_countTransactions in the block
block_sizeBytes the block added to the weave
block_idIts independent hash, base64url

Writing a query

  • It is ordinary SQL. SELECT, WHERE, GROUP BY, ORDER BY, JOIN and window functions all work.
  • IDs and addresses are plain text here, so WHERE owner = 'FPjb…' is all a wallet lookup needs. Matching the stored bytes is quicker, since nothing is decoded first: FROM rawtx WHERE owner_address = unb64u('FPjb…'). Either way a wallet over all history reads every band's wallet column, a few hundred MB; a transaction ID found with the search bar reads a few dozen.
  • Three shortcuts work over any period: SELECT * FROM find_tx('…'), wallet_totals('…') and tag_counts('App-Name'). Where the bands carry lookup files they read those, about a megabyte a band, instead of a whole column.
  • Sizes are bytes. Divide to taste: round(data_size / power(2,20), 2) AS mib.
  • AR amounts are winston, so divide by 1e12 for AR.
  • Questions cover the period chosen at the top, next to the search bar. Pick a wider one to reach further back.
  • Everything runs locally, so a mistake costs nothing. Try things.
Datathe newest blocks

Nothing loads until this publication passes the checks under How it's verified, at the top of the page.

Questions open the period themselves. Load it ahead of time here, or after switching gateway.

Reading the publication…