· Protocolzone
A land title changes hands. Two years later someone asks who owned the parcel on a specific date, under which encumbrance, and why the boundary shifted. The current record answers the first question and none of the others, because the system stored the latest state and overwrote the path that produced it. That is the failure that makes people reach for a blockchain, and it is worth being precise about what a chain does and does not fix before reaching.
This is a design position, not a delivery record. We have not built a government blockchain, and this post does not describe one running anywhere. It sets out where we think a chain earns its keep in public systems, where it does not, and what it would take to ship one responsibly. We are writing it from adjacent work we have actually done, which we will mark as we go.
What we have actually done here
Two things are lived, and they bound what we are willing to claim.
We have delivered analytics work for government, through an enterprise partner: a computer-vision system for field monitoring that reached 96% identification accuracy against a set of 20,000+ labelled images and cut manual review workload by roughly 70%, and a civic sentiment classifier that reached 92% accuracy on public feedback at volume. Both shipped. Neither is a blockchain, and neither pretends to be. They tell us how public-sector delivery actually goes: the constraint is rarely the model, it is provenance, retention and who is allowed to see what.
We have also done real blockchain engineering, on our own wallet and settlement work rather than for a government client. That is where our view of the technology’s edges comes from: signing, key custody, reconciliation against an off-chain ledger, and the operational reality of a record you cannot edit after the fact.
Everything below reasons from those two. When we move past what we have shipped into what we would build, we say so plainly.
A registry’s real asset is provenance, not the chain
Ask what a public registry is actually for and the answer is not “storage”. It is a defensible history: who asserted what, when, on whose authority, and what the record looked like on any past date. A title, a licence, a permit, a company filing, a benefit entitlement. The value is the lineage, and the ability to reconstruct the state as of a date without trusting whoever holds the database today.
A chain gives you one part of that: tamper-evidence. Append-only structure with hash linkage means an altered past entry is detectable, and the detection does not depend on the good behaviour of the operator. For a registry that has been quietly edited in the past, that property alone can be the whole reason to move.
But most of the win is provenance discipline the chain does not give you for free. Effective-dating (the record carries the date a fact became true, not just the date it was entered), bitemporal history (what we knew, and when we knew it, tracked separately), lineage back to the authorising instrument, and a schema that refuses to overwrite. You can build every one of those on an ordinary relational store, and if you do not build them, a chain underneath buys you a tamper-evident log of an impoverished record. We have thought hard about effective-dated and bitemporal registry modelling; it is the part that carries the value, and it is boring, and it is where projects underinvest because the chain feels like the exciting half.
So the honest framing is order of operations. Get provenance right first. Then a chain is one credible way to make that history tamper-evident and to remove the single trusted operator. It is not the source of the discipline, and it cannot substitute for it.
Programmable settlement: compelling, and harder than the demo
The second place a chain plausibly earns its place in public systems is settlement: conditional disbursement of money against rules. A grant that releases in tranches when milestones are verified. A refund that fires when a condition clears. A subsidy that flows to eligible recipients without a manual payment run. Expressing the condition and the transfer in the same programmable rail is genuinely attractive, and it is the strongest case for a stablecoin.
We have not built a stablecoin. Treat everything in this section as a capability direction we can reason about, not a product, not a token, and not a financial promise. What our wallet and settlement engineering tells us is that the demo is the easy 20%, and the hard parts are the ones a pilot skips:
Custody. Who holds the keys that can move public money, under what authorisation, with what recovery path when a key is lost or a signer leaves? This is an operational and governance problem long before it is a cryptographic one, and it is where most of the risk actually lives.
Reversibility of mistakes on an irreversible ledger. A duplicate disbursement, a payment to the wrong recipient, a rule that fired on bad input. Ordinary payment systems have chargebacks, clawbacks and reversals because mistakes are normal. An irreversible ledger has to reintroduce reversibility at the application layer through compensating transactions, holds and escrow, which means designing the corrections engine with the same care as the settlement engine. Public money makes this non-negotiable.
Regulatory acceptance. A settlement rail for government funds has to be acceptable to a treasury, an auditor and a regulator before it is acceptable to an engineer. That is a longer road than the technology, and pretending otherwise is how these projects stall after a successful proof of concept.
None of this says do not do it. It says the interesting engineering is custody, correction and acceptance, and a proposal that leads with the token has the priorities backwards.
Where a chain does not earn its place
Plenty of public-system problems get a chain proposed at them and should not.
If there is a single legitimate authority for the record and no need to remove trust in that operator, a chain adds consensus overhead and key-management risk in exchange for a property nobody needed. An internal audit log with proper access control and append-only storage is usually the right answer.
If the data is personal and must be correctable or erasable, an immutable ledger of that data fights data-protection obligations directly. The workable pattern keeps personal data off-chain and anchors only hashes or proofs, which is more architecture, not less.
If the win being claimed is “trust” in the abstract, with no named party whose trust you are trying to remove, the chain is decoration. The question that filters most proposals is simply: whose good behaviour are you no longer forced to assume? If there is no clear answer, keep the database.
What it would take
If we were to build a government registry or settlement system on a chain, this is the shape of the work, and it is deliberately unglamorous:
- Provenance and effective-dated modelling done first, and provable on an ordinary store, so the chain is an integrity layer over a correct record rather than a substitute for one.
- Personal data off-chain, with only hashes or proofs anchored, so correction and erasure obligations stay satisfiable.
- A custody and key-recovery design signed off by the people accountable for the funds or the record, not retrofitted after the pilot.
- A corrections and reversal engine treated as a first-class part of settlement, because mistakes are ordinary and the ledger will not forgive them for you.
- Parallel running against the incumbent system of record, with the chain authoritative only after its history has been reconciled against the old one for long enough to trust.
That is a multi-year programme with a regulator in the room, not a quarter with a framework. We would rather say that up front than discover it at a go-live.
The honest summary
A public registry’s value is a defensible, tamper-evident history with lineage. A chain is one way to get the tamper-evidence, and a good one when you need to remove a single trusted operator; it is not where the lineage comes from, and it will not manufacture provenance discipline you did not build. Programmable settlement on a stablecoin rail is a real and compelling direction for conditional public disbursement, and one we have not built: the technology is ready and the custody, reversibility and regulatory-acceptance questions are the actual project.
We have delivered government analytics. We have engineered wallets and settlement. We have not shipped a government chain or a stablecoin, and this essay is where we would start if asked to.
- blockchain
- registries
- provenance
- settlement
- stablecoin
- government