Indexed NEARBlockchain Data

NEAR’s mainnet has produced blocks since 2020, under Nightshade, a proof-of-stake protocol that splits the chain’s state across shards. A block here is a container: it holds one chunk per shard, and a transaction sits in the chunk of the shard that owns its account. Contracts compile to WebAssembly rather than to EVM bytecode, and NEAR is the native token, divisible into a septillion yoctoNEAR. Two design choices shape everything about the data. Accounts are readable names with subaccounts beneath them, and each account can hold several access keys, including keys restricted to calling one method on one contract, so identity is a hierarchy and a permission set rather than a single hash. And execution is asynchronous: a signed transaction is converted into a receipt, and a receipt that calls another contract produces further receipts that run in later blocks, sometimes on another shard. Accounts also pay for the state they occupy by locking NEAR against the bytes they store, so part of a balance is never spendable.

SonarX indexes NEAR through the structures the protocol actually uses: blocks and the chunks inside them, transactions and the receipts they generate, execution outcomes with their gas, contract calls with their arguments and logs, access-key changes, staking records, and derived balances. Everything is normalized into the model SonarX uses across every network it covers, so a receipt chain here becomes comparable with a transaction on a chain that executes in one step.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Point-in-time balance tables can be enabled for NEAR on request.

Following an action to its conclusion is the work here. Because receipts spawn receipts, the effects of one call can land several blocks later on a different shard, so SonarX resolves the whole tree rather than stopping at the transaction that started it. Shards are the second consideration: a block carries one chunk per shard, a shard can miss its chunk, and the layout has changed over the chain’s life, so continuity is tracked per shard rather than assumed from block height. Identity is the third, since named accounts with subaccounts and multiple access keys make one owner a tree, and storage staking means a reported balance is not all spendable.

Fund accounting is the first workload and the one the receipt model reshapes, because a movement of value is the outcome of a receipt chain rather than a line in a transaction, and a ledger built from transactions alone will not balance. Identity mapping is the second: custody teams need the subaccounts and access keys under one owner grouped together, which is what wallet analytics does across chains. Reward accounting for delegation is the third, derived from staking state per epoch. Token flow analysis is a fourth, and it depends on reading contract logs, since fungible tokens here report transfers as structured log entries rather than as indexed event topics. Teams comparing throughput designs pull Solana into the same warehouse, sometimes with Aptos 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. NEAR history is available now as a share or a file delivery, and streaming is provisioned on request. Say whether you need receipt-level detail or account-level positions, because the first is a much wider 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.