Anatomy of a Transaction: One Real Failed Transfer, Read End to End

Correction, made the same day this page was written. It first said the chain was "not producing blocks", because the tip had not moved across a nineteen-minute observation. That was wrong. The observation had landed inside a quiet period.

Second correction, 2026-08-02, and it replaces the first one's numbers. This page then said the chain "produces three blocks within about a second, then falls silent for twenty or thirty minutes", and derived a per-height rate from that. Both figures were artefacts of counting the wrong index.

Three chained blocks share a single height value on this chain, so counting by height sees one block in three and collapses three intervals into one. Re-measured by canonical sequence, the quiet is a configured ten-minute heartbeat: the proposer is event-driven, and with no work it emits one empty block every ten minutes, from a named constant whose comment says so. Eight consecutive intervals came back at six hundred seconds, each within a couple of seconds of it.

So the chain was not intermittent in the sense this page meant. It was idle, and idle here has a designed cadence. The full account is on the finality page. History is readable throughout, which is what this page uses, and nothing here should be taken as evidence about the network's rate on any particular day.

Three calls, not one

A block does not contain its transactions. It carries a count and an array of hashes.

So reading one transaction takes three calls: fetch the block, take a hash from it, fetch the transaction, and fetch its receipt separately.

That matters for anyone building against this. A block read tells you how many transactions there were and what they are called. It does not tell you what any of them did.

The transaction we found

Scanning back from the tip, twenty-five heights were requested, nine were readable, and exactly one of those carried a transaction.

Its body carries three things worth naming: a counter value, a typed payload, and the sender's public key.

The payload is a tagged variant. This one is a transfer, carrying an amount and a destination. A payload is not a free-form blob: the chain knows which kind of operation it is holding, which is why the fee for it can be decided before it runs.

The destination and the public key come back as arrays of bytes, while the same chain's validator listing returns addresses as short readable strings. Two representations of the same kind of thing, across two methods, and a client has to know which it is holding.

And it failed

The receipt says so plainly, naming the reason, the height it was recorded at, the fee actually paid, and an empty event list.

The reason: the sender could not cover the transfer fee. The status names both quantities, what the account had and what the operation needed, which is the difference between a receipt you can act on and one you have to guess at.

Why the failure is the useful part

This estate read the fee rule in source: a transaction that cannot cover its fee returns a receipt with fee zero and writes no state.

The receipt confirms it from outside. The fee actually paid is zero. The rule read in the code and the artefact produced by the running chain agree, which is worth more than either alone.

And the amount required matches the flat schedule for a transfer, so the schedule is not theoretical: it is what the chain applied.

What one transaction cannot tell you

Whether events are ever populated. This receipt's event list is empty, and one empty list is not evidence that the field is unused.

Whether failures are typical. One transaction in four hundred heights is a sample of one, on a network with almost no traffic, and we are not going to build a rate out of it.

Why sixteen of twenty-five heights returned null now has an answer, found while correcting the paragraph above: every readable height is divisible by three, and the heights between them return null with no error. It was first recorded as unexplained; it is not random loss, it is exactly two in every three. Whether those heights exist and cannot be fetched, or are never produced, is still not answerable from outside.

What you can check yourself

solidus_getBlock with a height, then solidus_getTransaction with a hash from it, then solidus_getReceipt with the same hash

Expect empty blocks. Most blocks on this network carry nothing, so scan back rather than assuming the tip has something in it.