Indexed SonicBlockchain Data

Sonic is an EVM Layer 1 whose mainnet opened on 18 December 2024, and it is the successor to Fantom Opera rather than a layer on top of anything. Blocks are produced under a proof-of-stake, DAG-based asynchronous BFT protocol, with inclusion in a second or two and finality that is not revisited afterwards. The native asset is S, which pays gas, secures the network through staking and votes in governance, and the chain answers to chain ID 146. Execution is account-based over twenty-byte addresses, so Solidity contracts and their artifacts move across unchanged. Fee monetization is written into the protocol: a share of the network fees an application generates is paid back to whoever deployed it, so a fee record here can have a recipient that is not a validator. FTM holders upgrade to S at one to one through a portal, but the ledger did not come with them: this chain began empty.

SonarX indexes Sonic blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, and token transfers and balances, in the normalized model used on every chain SonarX covers.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. The real-time balances API and the batch wallets, tokens and balances API are available for Sonic, and the rest can be enabled on request. Kafka streaming carries the same records as a live topic today.

The interesting problem here is the boundary, not the chain. Sonic’s own records start at a December 2024 genesis and are self-contained, but the ecosystem on it is inherited: the same teams, the same contract source and often the same deployer addresses, with new addresses and no shared block numbering. So a question about a protocol’s life, or a holder’s position, is a join between this chain and an older one whose finality and fee model differ. Inside the chain, sub-second block production means the row count per hour runs ahead of the value moved, which is a streaming and partitioning decision rather than a storage one.

Migration analysis is the workload unique to this chain: which contracts and which holders actually came across from Opera, how quickly, and what stayed behind. Nothing about that is answerable from one side alone. Position-level DeFi analytics is the second job, since the applications that redeployed here brought their lending and liquidity mechanics with them, and reconstructing a position needs decoded events with internal transfers attached. Fee and cost research is the third, helped by a dense block series. Teams benchmarking execution designs usually put Monad beside it.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. This chain’s full history is available now, and Fantom can be scoped beside it for the years before the upgrade. 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.