How to Read a Solidus Block

Open /blocks on the Solidus explorer and look at the top row, whatever block sits there when you load it. One honesty note before anything else: at the time of writing, the explorer UI's block list renders seeded demo data whose heights disagree with the live chain's RPC (a known product gap, flagged for engineering), so treat the specific numbers below as an illustrative worked example from that UI, while the field anatomy they demonstrate is exactly what every real block carries. State that first, because everything else on this page is a claim you can check, and a claim you can check is worth more coming from a project that concedes its own stage plainly.

The example block carries twelve transactions, was proposed by validator 0x0000...8924, and used 23.8M gas, 79% of the block's gas limit. Those four facts, height, proposer, transaction count, gas, are what this page walks through.

Height

Height is a count, not a coordinate: a block at height N exists because block N−1 was finalized first, and block N+1 will exist because block N was. It only ever goes up, and it can't be reordered after the fact: that's what "append-only" means in practice, not in the abstract. A chain's entire claim to being a ledger rather than a database rests on this one property: you can't quietly go back and change row 4,827,200 without every height after it noticing.

Proposer

Every block has exactly one proposer, on the example block, 0x0000...8924, the validator that assembled this specific block and got the rest of the committee to agree to it. Which validator gets that turn, and how the rest of the committee confirms the result, is a consensus mechanism, not an explorer topic: Solidus runs HotStuff BFT, and how finality actually works is page 9's job, not this one's. What matters here is narrower: the proposer field is a receipt. It names, specifically, which of the network's validators is accountable for this block's contents.

Transaction count

The example block held twelve transactions. Three of them are visible in the block's own transaction table, and they show what actually gets written to this chain today: a value transfer, a DID creation, and a DID update. What's worth noting instead is the range of what counts as a transaction here at all, it isn't only transfers. Registering an identity anchor or updating one is a transaction with the same footing as moving a balance, which is a large part of what an identity-native chain is for.

Gas used / limit

Gas is the unit the chain uses to price and cap the work a block can do, every operation inside a block, from a transfer to a DID update, costs some amount of gas, and a block has a ceiling on how much it can spend in total. The example block used 23.8M gas, 79% of that ceiling. The ceiling exists for the same reason any resource limit exists in a distributed system: without one, a single block could demand unbounded computation from every node that has to process and verify it. 79% is neither empty nor full, it's a block doing a normal amount of work, comfortably inside its limit.

What this page skips

A Solidus block carries more than these four fields, and this page is not the place to cover the rest. The block's state root, a single hash that commits to the entire chain's state as of this block, gets its own page, because it deserves a proper explanation of Merkle trees rather than a paragraph: see Merkle trees and state roots, shown not defined. The block's finality status, what "Finalized" actually certifies, and how a three-chain HotStuff commit gets there, is page 9's subject, not this one's. The block detail view also carries a per-block reward figure; this page leaves it alone. These are the four fields that teach you the shape of a block. The rest have their own pages, and they're linked above rather than compressed into a footnote here.

Where to go next

Everything above came from a block that existed at the moment this page was written and will be superseded by the time it's read, that's not a caveat, it's the whole mechanism working as intended. Open /blocks directly, pick whichever block sits at the top when you look, and read its own height, proposer, transaction count, and gas figures against what's written here. Watch the height change on a second load. If a transaction in your block is a DID operation rather than a transfer, that's resolving a DID yourself: the next page in this series, and the one that turns a proposer address or a DID string on this page into something you query directly rather than just read.