Indexed InkBlockchain Data

Ink is an Ethereum Layer 2 built by Kraken on the OP Stack, and it has been producing blocks since December 2024. It is an optimistic rollup with permissionless fault proofs: a sequencer orders transactions, batches are posted to Ethereum, and anyone may challenge a proposed state. Two choices set it apart from its Superchain siblings. Blocks arrive every second rather than every two, which was a deliberate decision for trading and DeFi applications, and the chain has posted its batch data to Ethereum as blobs since its first block, so it has no earlier calldata era. Execution is the EVM, unchanged: twenty-byte addresses, Solidity contracts, the same opcodes as the L1, and gas paid in ETH rather than in a token of its own. Because Kraken operates the network, assets can also move on and off it through the exchange rather than only through the canonical bridge.

SonarX indexes blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces including internal value transfers, and token transfers and balances. The same normalized model is used on every chain SonarX covers, so Ink joins to the other rollups and to Ethereum without a translation step.

Full historical coverage is provisioned for Ink on request. Balance tables and the balance APIs can be enabled for Ink on request. Kafka streaming carries the same records as a live topic today.

One-second blocks change the arithmetic before they change anything else: at the same transaction volume, a day here produces twice the block rows of a two-second chain, so partitioning and any metric keyed on blocks rather than transactions has to be sized for that. Uniform data availability helps in the other direction. Because batches have been blobs since the first block, reconstructing the chain from L1 follows one rule across the whole history, where older OP Stack chains switched formats partway through. The exchange path is the third consideration: assets moving through Kraken rather than the canonical bridge leave no matching L1 bridge record, so inflow analysis has to treat both routes.

Requests here come from trading and treasury desks more than from researchers. Flow analysis is the first: following value between the exchange, the canonical bridge and the applications on the chain, which only reconciles when both routes are in the same dataset. Position-level DeFi analytics is the second, since lending and perpetuals venues are what the one-second block time was built for and their state is a sequence of decoded events. Latency research is the third, comparing time-to-inclusion here against Unichain and the two-second Superchain chains, which needs full block history rather than samples. Compliance and monitoring teams use the same records to follow addresses that appear on several rollups at once.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Ink coverage is provisioned on request, so tell us the history depth and the delivery target and we will scope it. 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.