Skip to content
← All writing
Web3 Research note

On-chain balances need a confirmation state

Most reconciliation pain in Web3 products comes from treating a chain read as a settled fact.

4 min GalvoLab

A balance read from a chain is a claim about a probabilistic state. Treating it as settled is the root of a surprising share of Web3 accounting incidents.

The failure

A deposit is observed, credited immediately, and spent. A reorg removes the deposit. The books now disagree with the chain, and the difference is discovered during a manual reconciliation weeks later.

The fix is boring

Give every balance an explicit confirmation state, and make spendability a function of depth policy per chain. A deposit is observed, then confirming, then settled. Only settled funds move.

This makes reorg handling a configuration decision made once, rather than an incident handled under pressure. It also means the ledger and the chain can be reconciled continuously. Any drift is a bug that surfaces in minutes rather than a quarterly surprise.

Double entry, still

The other half is refusing to invent a new accounting model. Double-entry bookkeeping is six hundred years old and balances by construction. Every on-chain event maps to a journal entry; if the books do not balance, the mapping is wrong and you find out immediately.

Working on something like this?

We take on a small number of engagements at a time. Bring the problem.

Free consultation