Indexed NibiruBlockchain Data

Nibiru has produced blocks since its genesis on 8 November 2023. Validators run CometBFT under proof of stake, NIBI is the native token in unibi units, and accounts are bech32 strings with a nibi prefix. The chain launched with CosmWasm as its execution environment and added an EVM at its v2 upgrade, so Solidity and Rust contracts now run against one state machine and one block, a pairing Sei arrived at from the other direction. Two protocol modules shape the record more than the contracts do. An oracle has validators vote on prices each period, aggregates those votes into the value applications read, and counts misses against whoever failed to submit. A token factory lets any account mint denominations namespaced by their creator, so a token identifier here is a string rather than a contract address. Modules have been removed as well as added: the v1 release dropped the chain’s inflation module.

SonarX indexes both surfaces: blocks and transactions with their typed messages, CosmWasm contract calls, EVM transactions with receipts and logs decoded against contract ABIs, oracle votes and the aggregated prices they produced, token-factory denominations, staking and reward records, IBC transfers, and derived balances. Those records land in the normalized model SonarX uses on every network it covers.

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 Nibiru on request.

The history has a seam in it. Wasm contracts came first and the EVM arrived later, so EVM blocks, receipts and decoded logs begin partway through the chain instead of at genesis, and a series spanning both sides has to acknowledge that boundary. Identity crosses the same line, because one key reaches the Wasm side as a nibi address and the EVM side as twenty bytes, and treating them as two holders splits an account. Oracle prices are the third consideration: the value applications consumed is derived from individual validator votes, so the input and the output are separate records.

Protocol analytics across both surfaces is the first workload: contract activity read through decoded logs on the EVM side and through typed messages on the Wasm side, counted once rather than twice. Oracle research is the second and is specific to this chain, since validator vote participation and deviation are recorded and can be measured against the aggregate that applications actually used. Token supply work is the third, because factory denominations are created by accounts rather than deployed as contracts. Reward accounting is a fourth. DeFi analytics covers contract-level work across chains, and teams comparing designs often pull Injective alongside 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. Nibiru coverage is provisioned on request, so tell us the history depth and the delivery target and we will scope it. Say whether the EVM side, the Wasm side or both are in scope, because that changes the backfill. 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.