Finality Here Is Deterministic, and the Wait Is Not Two Rounds. It Is Two Rounds Whenever They Happen

Two kinds of finality, and only one of them is a rule

On a chain that mines, finality is a judgement. Nothing declares a block final; you wait for enough blocks on top that reversing it becomes implausible, and "enough" is your risk appetite rather than the protocol's promise.

On a chain that votes, finality is a rule that fires. A condition becomes true and the block is final, with no confirmations to count and no threshold to choose.

This chain votes.

The rule, exactly

A block is finalized once a certificate exists two rounds beyond it.

Until then it sits in memory, keyed by its round. When the rule fires, it is removed from that holding area, written to the store, and the committed height moves.

Which gives a reader something better than a finality flag

A block response carries no "finalized" field, and it does not need one.

Blocks reach the store only on commit, and the interface's own documentation describes the tip calls as returning the latest committed block.

So anything the endpoint returns to you is already final by the protocol's own rule. There is no provisional block to mistake for a settled one, because provisional blocks are not in the place the endpoint reads from.

That is a genuinely good property and it is easy to miss, because it shows up as an absence.

And here is the cost, which is not in the protocol

Two follow-up rounds sounds like a short wait. It is a short wait when rounds are happening.

This chain is event-driven. With no work to do, it proposes one empty block every ten minutes, from a named constant whose comment says exactly why: each heartbeat finalizes the previous burst's leftover blocks, bounds how far participants can drift, and keeps the head advancing.

Measured by canonical sequence: eight consecutive intervals of six hundred seconds, each within a couple of seconds of it.

So a block produced at the end of a burst waits for two more heartbeats. On an idle chain that is twenty minutes, not two rounds' worth of seconds.

Finality here is deterministic in its rule and elastic in its wall-clock, and those are different statements that the word "final" invites you to merge.

Why the heartbeat exists at all, in its own words

Disk. The comment records that the free-running proposer wrote on the order of a gigabyte a day, and that the heartbeat brings it to a few megabytes, at roughly a hundred and forty blocks a day.

That is a considered trade, and the cost of it is the paragraph above. A reader who only sees the quiet would call it a fault, and this estate did, twice, before reading the constant.

One thing we have not tested, named rather than assumed

The client library waits about ten seconds for a receipt and then gives up, with a comment saying the chain finalizes well inside that budget.

On a busy chain that is clearly true: in the burst this estate measured, rounds were about a second apart, so two follow-up rounds cost about two seconds.

On an idle chain it depends on whether an arriving transaction wakes the proposer for enough rounds to finalize its own block. UPDATED 2026-08-02: half of that is now settled from source. Submitting a transaction explicitly wakes the consensus loop, so the block carrying it is proposed at once rather than at the next heartbeat. Whether one wake also produces the two further rounds finality needs is still untested, because testing it means writing to the chain rather than reading it.

So this page does not claim the budget is wrong, and does not claim it is right. It names the question, and somebody should answer it before anybody relies on that timeout.

And none of the machinery is checkable from outside

No certificate is published, so a reader cannot watch the rule fire.

What a reader can check is the consequence rather than the mechanism: that the endpoint's answers are committed answers, and that the head advances on a ten-minute cadence when nothing is happening.

What you can check yourself

solidus_canonHead, then solidus_getBlockBySeq downward, comparing timestamp_ms

Use the sequence, not the height, or the intervals come out three times too long. Then look at the gaps: a run of six-hundred-second intervals is the heartbeat, and a run of one-second intervals is the chain doing work.