Procuring a Blockchain Pilot: A UK Public Sector Checklist Built Around Aergo

Public sector blockchain pilots rarely fail on technology. They fail in a procurement questionnaire, at the point where a supplier is asked to name the hosting region, describe the change-control process for a smart contract, and explain what happens to the data if the contract is terminated early. Builders who have only rehearsed the throughput figures tend to go quiet around question nine.

This piece is a mapping exercise rather than a sales pitch. It sets out what UK buyers typically ask, and where Aergo's design gives a straight answer, where it needs a caveat, and where the honest answer is that you must configure something deliberately. Documentation and release details change, so verify anything material against the current Aergo repositories and your own legal advice before it goes into a bid.

Why the public sector asks different questions

A private company buying a pilot can accept a degree of novelty. A local authority or an NHS trust cannot. It is spending public money, it is subject to the Freedom of Information Act, it must complete a Data Protection Impact Assessment where personal data is involved, and it will be asked by an internal audit function to demonstrate that the arrangement can be ended cleanly. Add the Technology Code of Practice, the Open Standards principles, Cyber Essentials for baseline assurance, the Data Security and Protection Toolkit for health bodies, and social value commitments under the Procurement Act 2023 framework now in force, and the paperwork becomes the project.

None of that is hostile to distributed ledger technology. It simply means the answers must be specific.

Architectural fit: permissioned today, public later

Aergo's relevant characteristic is that the same node software can run as a public network or as a closed deployment with a named validator set. That matters commercially, because it allows a pilot to start inside a controlled environment and, if the business case survives, connect to a wider network without a rewrite.

Two consensus configurations are typically discussed: delegated proof of stake, as used on the public mainnet with its limited block producer set, and a RAFT-based arrangement for consortium or private deployments where deterministic, fast finality inside a known group of organisations is the priority. For a procurement answer, the useful line is not the consensus name but the governance statement that follows it: who the validators are, how they are appointed, how they are removed, and what happens if one becomes unavailable or uncooperative.

Buyers will also want to know the block time and finality assumption in plain English, because their service-level expectations are written in seconds and hours, not in rounds.

Data residency: the question that ends most conversations

Aergo is software, not a hosted service. That is an advantage for public sector work, because it means the deployment can sit in a UK region of a hyperscaler, in a Crown-hosted environment, or on trust-owned infrastructure. The answer to 'where does the data live' is therefore a design decision you control, and it should be documented as such.

The trap is the public mainnet. Writing personal data to a globally replicated public chain is generally incompatible with UK GDPR obligations around erasure and storage limitation. The defensible pattern is to keep records off-chain, in an environment the buyer controls, and anchor only cryptographic hashes or minimal references on-chain. If IPFS is used for larger payloads, describe who pins the content, where, and for how long, because content addressing does not by itself satisfy a retention schedule.

Auditability and smart-contract governance

Aergo supports smart contracts written in Lua and in a SQL-based dialect, with event logs available for downstream reconciliation. For an audit committee, the questions are less about the language and more about control: who can deploy, who can upgrade, and how a change is approved before it reaches a production network.

Deployed contract code is immutable in the ordinary sense, so teams usually introduce upgradeability through proxy patterns. That is a governance decision disguised as a technical one, and it should be written down. Practical controls include hardware security modules or equivalent key custody, separation of duties between the team that writes a contract and the team that signs a deployment, a change log aligned to existing ITIL practice, and a record in the Algorithmic Transparency Recording Standard where the system makes or supports decisions affecting the public.

Independent smart-contract audit is now an expectation rather than a nicety. Budget for it early; a review from a recognised firm with UK presence will typically take several weeks and should be completed before any pilot touches live data.

Lock-in, exit and the procurement question nobody enjoys

Open-source licensing helps, but it is not an exit plan. A credible answer to the exit question covers four things: the licence under which the node software and SDKs are published, the contractual right to receive a full state snapshot and event history in a portable format, the handover of operational documentation and key material under escrow, and a dated transition schedule with defined acceptance criteria.

Aergo's SQL-style contracts make state comparatively readable, which is a genuine advantage when a buyer's data team needs to extract records into a warehouse. Event logs can be streamed and archived. What you must avoid is a bespoke pilot contract with no documentation, because that converts an open-source foundation into a proprietary liability.

Cost, tokens and the commercial model

Procurement teams will ask whether participation requires holding a volatile token. For a closed deployment, the fee model can be configured so that gas is effectively neutral, removing the question entirely. For public network use, the AERGO token is used to pay for computation, and the budget should be expressed in sterling with a buffer and a stated assumption about price movement. Finance colleagues will want to know how the holding is treated and who controls it; treasury policy, not blockchain design, usually decides that.

A twelve-week pilot shape that survives scrutiny

Weeks one to three: discovery, DPIA, data-flow mapping, and the governance statement. Weeks four to seven: build the off-chain store and the anchoring contract, in a permissioned environment, with audit booked. Weeks eight to ten: integrate with one legacy system; this is where most schedules slip. Weeks eleven and twelve: independent review, extract-and-exit rehearsal, and a written recommendation on whether to scale.

The checklist, condensed

• Named hosting location, with a UK region or on-premises confirmed in writing.
• Consensus configuration and validator membership documented.
• Governance statement covering validator appointment and removal.
• DPIA completed; no personal data on a public chain.
• Off-chain storage owner, retention period and deletion process specified.
• Smart-contract deployment and upgrade authority defined, with key custody described.
• Independent audit completed and report shared.
• Cyber Essentials Plus or ISO 27001 evidence, plus a recent penetration test.
• Open-source licence and version pinning confirmed.
• Data export format, frequency and acceptance test agreed.
• Key escrow and transition schedule in the contract.
• Token exposure quantified, or eliminated by design.

The technology is rarely the obstacle. The obstacle is a supplier who cannot answer question nine with a sentence that a lawyer and an auditor both accept.