Receipts, and why one transaction becomes many
A NEAR transaction is a request. What actually executes is a receipt, and one transaction can generate many.
The reason is sharding. NEAR splits state across shards, and a contract on one shard calling a contract on another cannot do so synchronously. The call becomes a receipt, routed to the target shard, executed there, and its result returned as a further receipt.
So a single user action — swapping tokens, say — produces a tree: the initial transaction, a receipt for the first contract, receipts for each cross-contract call it makes, and receipts carrying results back. Each is executed separately, potentially in different blocks.
This is the same asynchronous pattern as TON, with different vocabulary. And it produces the same failure mode: a transaction can succeed while a receipt deep in the tree fails, and an explorer showing only the transaction reports success.
NearBlocks renders the tree with the status of each receipt. That is the product, and without it NEAR contract interactions are essentially unreadable.
Named accounts and access keys
NEAR accounts have human-readable names — alice.near rather than a hex string — implemented at protocol level rather than as a naming service bolted on top. Subaccounts follow the same pattern, so app.alice.near is controlled by alice.near.
The more interesting feature is access keys. A NEAR account can have multiple keys with different permissions. A full access key can do anything. A function-call key can only call specified methods on a specified contract, with a spending allowance.
This is a genuinely good security model that other chains lack. An application can hold a key that lets it call its own contract on your behalf, with a capped allowance, and nothing else. It cannot drain your account because it was never granted that power — which is structurally better than the unlimited token approval pattern that dominates EVM chains.
NearBlocks lists the access keys on an account with their permissions and allowances. Reviewing that list periodically is the NEAR equivalent of checking token approvals, and it is considerably easier to reason about.
Storage staking, which surprises everyone
NEAR charges for state storage by requiring accounts to lock NEAR proportional to the data they occupy. Store more, lock more. Delete data and the locked amount is released.
The practical consequence is that part of your balance is not spendable. Attempt to send everything and the transaction fails because it would take you below your storage requirement, which is confusing if you do not know the mechanism exists.
It also means receiving a token can cost you. Registering with a token contract allocates storage, and someone has to pay the deposit — which is why some NEAR token transfers require the recipient to be registered first, and why a transfer to an unregistered account can fail.
NearBlocks shows storage usage and the locked amount on account pages. It is the first thing to check when a transfer fails for no apparent reason.
API and open source
NearBlocks is open source with a free API tier requiring a key. Being able to read how receipt trees are assembled matters here, because that assembly involves real decisions — which receipt is the "main" one, how to attribute gas across a tree, how to present a partial failure.
NEAR's own JSON-RPC is the alternative for raw data. It gives you transactions and receipts without the tree reconstruction, which is the part that takes work.
For anything user-facing on NEAR, the reconstruction is not optional. Showing a user the initial transaction and calling it done will produce support tickets from people whose action succeeded at the top and failed three receipts down.
What our reference tests showed
Our NEAR reference set was built around the receipt problem: a plain transfer, a token transfer to a registered account, a token transfer to an unregistered account, a cross-contract swap, and an account with multiple access keys.
The plain transfer was unremarkable. The token transfer to a registered account rendered as a short receipt tree and read cleanly.
The transfer to an unregistered account was the test that mattered, and it behaved as the storage-staking model predicts: the transaction succeeded, a receipt deeper in the tree failed because the recipient had no storage deposit registered with the token contract, and the tokens did not move. A user looking only at the transaction would have concluded the transfer worked.
NearBlocks showed the failing receipt with its error, several levels down, marked clearly. That is the single most valuable thing this explorer does, and it is the reason a NEAR explorer that does not render receipt trees is not usable for anything beyond confirming a plain transfer.
The cross-contract swap produced a considerably larger tree — a dozen receipts across several contracts — and remained readable, which is a real interface achievement given the underlying complexity.
The access key test listed both a full access key and a function-call key with its allowance and permitted methods. Comparing that to the equivalent exercise on an EVM chain, where reviewing token approvals means reading a list of unlimited permissions granted to contracts you may not recognise, made the security advantage of NEAR's model concrete rather than theoretical.