Indexed TempoBlockchain Data

Tempo is a Layer 1 built for payments and very little else. Stripe announced it in September 2025, a public testnet opened that December, and mainnet went live the following March. Blocks are produced roughly every half second by a permissioned validator set under Simplex BFT consensus, which gives deterministic finality: a block is settled when it is agreed, with no reorg window to sit through. Execution is EVM, so contracts are ordinary bytecode, addresses are the familiar twenty bytes, and token transfers emit event logs an existing pipeline already decodes. The fee model is the real departure. There is no native gas asset at all: fees are denominated in dollars and paid in a stablecoin the transaction itself names, under the chain’s own token standard for payment assets. Because no native asset exists, the balance opcodes report zero and value never moves as a native transfer, only as a token transfer. Creating new state is priced far above Ethereum’s schedule, deliberately, to keep state growth in check on a chain built to carry payment volume.

SonarX indexes Tempo in the shapes an EVM team expects: blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces down to internal calls, and token transfers and balances, with the fee denomination carried alongside each charge. The normalized model is shared with every network SonarX covers, so a Tempo query and a Polygon query take the same shape and a payment estate spanning both can be reported on once.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Balance tables and the balance APIs can be enabled for Tempo on request. Kafka streaming can be enabled for Tempo on request.

Two protocol choices change the job here. There is no native asset, so nothing behaves the way ETH behaves on an EVM chain: every payment is a token transfer, the balance opcodes report zero, and a pipeline that reconstructs value from native transfers and traces would find an empty chain. Fees are the second. A transaction names the stablecoin it pays in and the charge is denominated in dollars, so a cost record carries an asset as well as an amount and totals summed without it mix units. Finality works in the indexer’s favor for once: consensus is deterministic, so there is no reorg depth to allow for and a block, once indexed, stays as written.

The work here is payments work rather than research. Settlement reconciliation is the first: matching onchain transfers against internal ledgers so that what a business believes it moved and what the chain recorded agree, down to the fee. Float and treasury reporting is the second, since a stablecoin balance held for operational reasons still has to be stated as at a date and explained. Transaction monitoring is the third, following counterparties and flows across a payment estate rather than sampling them. A payments ledger is judged on completeness rather than on coverage of interesting contracts: a missing transfer is a broken reconciliation, not a gap in a research dataset, which is why these engagements start with the whole history rather than a sample of it. Teams running rails on several networks usually pull Stellar alongside for comparison, and token analytics covers the asset-level view across all of them.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Tempo history is available now, so a first delivery is provisioning rather than engineering. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.