Building the Network — Part 2 of 4. (Start at Part 1.)

Sub-second finality

Send value on this network and it lands in well under a second — and it's final. No "pending for three business days." No holding pattern where the money exists in two places and neither.

Under the hood it's pooled virtual accounts and double-entry journals. Every movement is two postings — a debit and a matching credit — that must balance, always. There is no way to add value in one place without removing it from another, because the ledger physically refuses to record a move that doesn't sum to zero. That's not a validation rule bolted on top; it's the shape of the data.

Why does sub-second finality matter so much here specifically? Because in a largely cash economy, "the money is really there, right now" is the entire proposition. A merchant deciding whether to hand over goods can't wait three days to find out if a transfer clears. Fast, final settlement is what lets digital value feel as trustworthy as cash in hand — which is the bar you actually have to clear.

Honest note: fast finality is a design constraint disguised as a feature. When money can't be un-sent, you cannot lean on a slow settlement window to catch fraud after the fact — there is no "after the fact." Every check that matters has to run before the postings commit, in that sub-second. It makes the happy path feel like magic and the engineering behind it deliberately paranoid.

Moving money fast is easy to brag about. Doing it while keeping the tax authority in the room — on every invoice, as it's issued — is the harder trick.

Next → Invoices That Talk to the Tax Authority (Part 3 of 4)