The exchange is informal
An officer emails a counterpart in another organisation. The request, the reason, and the outcome live in a mailbox — and leave with whoever owns that mailbox.
Blockchain consent · Public sector first · Paper-free
Consent is enforced, not promised.
zapXD is a complete ecosystem for governed data exchange: the consent layer, the exchange that carries the data, and the evidence trail behind it. Every exchange between two organisations is authorised by consent held in a smart contract, and written permanently to a blockchain neither party can alter — so the permission and the proof are the same record.
Built for
- Government & public sector
- Health & social care
- Banking & financial services
- Telecoms & utilities
- Regulators & auditors
No citizen ID on the blockchain
Identifiers are converted to a one-way code before they reach the ledger, so the ledger never holds anything that names a person.
Nothing moves without consent
No consent on record means no access. Silence is never treated as permission.
Every exchange is written to the blockchain
Permanently, and in a form neither side can alter. Both sides hold the same record, so neither can rewrite the past.
Encrypted between the two organisations
Exchanges travel straight between the two organisations over an encrypted link. Nothing is pooled, and nothing travels unprotected.
The problem
Data sharing runs on trust and phone calls.
Organisations genuinely need each other's data — to treat a patient, to verify an identity, to assess a claim, to open an account. The exchange is real and it happens every day. What's missing is any enforceable record that it was allowed to happen. So it stays paper — and paper can't be searched, can't be trusted to survive, and can't prove anything years later.
The person it's about is never in the room
Data moves about them, for purposes they cannot see, with no record they can inspect and no way to withdraw a permission they never knowingly gave.
Nothing survives an audit
When a regulator asks who accessed what, and on whose authority, the answer is reconstructed from memory, spreadsheets and filing cabinets — after the fact.
The harder problem was never moving the data. It's proving, years later, that you were allowed to move it.
The mechanism
Approving one exchange, end to end.
A private hospital needs a patient's record for emergency care. Below is the real sequence: a signed request, a registry lookup, a consent check, a citizen decision, field-level minimisation, and a ledger entry that neither party can later edit.
Exchange request
requestId
—
consumerId
MU.PRV.FLACQ
providerId
MU.GOV.MOH
serviceCode
eHR.PatientRecord.v1
purposeCode
TREATMENT
subjectNIDHash
—
signature
verified · key service
Fields requested → resolved
- full_name
- date_of_birth
- blood_type
- allergies
- active_diagnoses
- hiv_status
Governed lifecycle
- 1 Request signed and dispatched Envelope signed by the consumer's key service
- 2 Registry resolves the provider Control plane only — no data involved
- 3 Consent checked before routing Ledger lookup on subject hash + service
- 4 Citizen notified Request surfaced with purpose and requesting organisation
- 5 Citizen decides Awaiting decision
- 6 Response returned directly to the consumer Not yet reached
You are the citizen.
A request for your health record is waiting. Nothing has moved yet.
Immutable ledger
0 blocks
No entries yet. Run the exchange to append a block.
This is a live simulation, not a live network. It runs entirely in
your browser — no request leaves this page, and no real record exists. The sequence,
the field-level filtering, the default-deny behaviour and the hash chain are the
real ones: the ledger hash is computed from the block's own contents, and each
block carries the previous block's hash, so editing an earlier entry breaks the
chain visibly. Notice that hiv_status is requested but never released —
consent covers the fields it covers, and the rest are dropped at the provider.
The network
Everyone joins once. The record goes direct.
An organisation reaches every other member through a single connection — no link per partner, no bilateral integration. What travels along that connection is the question. Six of the seven steps below settle permission in the middle and carry no personal data at all. Only the last two leave the middle behind, and only the final one carries the record.
Providers
Ministry of Health
Civil Status Division
Revenue Authority
Transport Authority
The platform
Exchange registry
Citizen portal
Consumers
Banks
Insurers
Flacq Hospital
Licensed institutions
Data lane
Everything that passes between the two organisations travels here — the signed request on the way out, the approved record on the way back. The platform above is not on this path and sees none of it.
Ministry of Health
provider
Flacq Hospital
consumer
Ready. Trace the exchange to walk one request from Flacq Hospital to the Ministry of Health, and see which of the seven steps carry the record.
This is a diagram, not a deployment. The organisations shown stand for the sectors the platform connects, and the two-route split is the real architecture: a request resolves and is authorised in the middle, then the record travels directly between the two parties with the platform unable to read it.
Architecture
Three planes, deliberately separated.
Most data-sharing platforms collapse these into one system, and the platform operator ends up able to read everything. Splitting them is what makes the sovereignty claim structural rather than contractual.
Control plane
Registry & Consent Manager
Knows which organisation offers which service, at which address, and whether consent exists. The consent itself is held in a smart contract on the blockchain, not in a database somebody can edit. This plane resolves and it authorises — and it never carries the data itself, so it never has any to leak.
Data plane
Direct, organisation to organisation
The data travels straight from provider to consumer over an encrypted connection — each side proves to the other who it is. One direct call, not a nightly file transfer. It is never pooled, never brokered, and never routed through the platform. Data residency stops being a promise and becomes a topology.
The post office never reads the letter.
Evidence plane
Dual-write audit
Every exchange is written twice: to an ordinary database, where it can be searched and reported on, and to the blockchain, where it becomes permanent evidence. If the two ever disagree, that disagreement is treated as a security incident.
PostgreSQL to operate on. Hyperledger Fabric to prove on.
Why this wins
A broker you have to trust, versus a protocol you can check.
The obvious way to build this is a central platform that pools everyone's data and mediates every request. It's faster to build and it concentrates all the risk in one place — the operator holds the data, and everyone's assurance depends on trusting that operator. This architecture refuses that trade.
That difference is the whole product. A centralised broker has to be trusted by every participant, and giving up that control is exactly the concession organisations are unwilling to make. A protocol that never holds the data can be adopted without it — which is what makes it deployable across ministries, and then across borders.
Who it's for
Public sector first. Every sector that moves personal data.
The consent problem is not a government problem. It is the problem of anyone who has to prove, long after the fact, that they were allowed to move someone's data. The same mechanism answers all four.
Government & public sector
Cross-ministry exchange, benefits assessment, identity verification. The person sees every access made against their record, and can withdraw at any time.
Health & social care
A clinician treating a patient needs records held by someone else. Consent covers the named fields, for that purpose, and nothing beyond it.
Banking & financial services
Account opening, identity checks, credit assessment. Consent a regulator can verify for itself, instead of a filing cabinet of signed forms.
Telecoms & utilities
Data sharing with partners and regulators, where the permission and the proof of the permission have to be the same artifact.
Capabilities
What it guarantees, and how each is enforced.
Six commitments, stated plainly. Each one is built into the platform and checked automatically on every build, so it cannot quietly stop being true. The monospace line under each is the technical detail, for the engineers in the room.
A citizen's ID never travels
The national ID is the most sensitive number a government holds, so it is not passed around. It is converted into a code at the edge, and only that code moves from there — never the number itself.
subjectNIDHash = SHA-256(NID) · hex · lowercaseThe app never holds a signing key
Signatures are made inside a dedicated key service. The application asks for a signature; it never holds the key that produces one. If the application were breached, there would be no key sitting there to take.
sign via key service · never load a key into a processConsent is checked before anything else happens
The consent check runs ahead of the code that would fetch or forward anything, so a request without consent never reaches the point where it could do harm. That ordering is enforced by tests and cannot be silently changed.
consent middleware → router · order asserted in testsOnly the fields that were agreed to
Consent covers named fields, not an entire file. Anything outside that list is stripped out by the organisation holding the data, before the response goes anywhere.
unconsented fields removed at the providerOne purpose per consent
Agreeing to treatment is not agreeing to an audit, or to a research study. Every consent names the purpose it was given for and is valid only for that one.
TREATMENT · ADMINISTRATIVE · RESEARCHThe public website has no route to the blockchain
Citizen-facing pages talk to the consent gateway, never to the ledger itself. With no path from a browser to the ledger, there is no path to attack from one.
portal → gateway API → ledger SDKHow it's delivered
The whole ecosystem, or just the layer you're missing.
Most organisations take all of it — consent, exchange and evidence, running as one platform with one integration and one place to operate. Some already run an exchange they are happy with and take only the consent layer. It is the same product either way: how consent is enforced does not change.
- The complete ecosystem Consent, service discovery, message exchange and the audit trail, delivered together and operated as one platform. One integration to build, one system to run, one record to audit.
- Or the consent layer on its own If you already run an exchange, the consent engine reaches it through a single adapter interface. Point it at what you have, and nothing downstream has to change.
- One question, one answer Is this exchange authorised, for this subject, for this purpose? The answer comes from the blockchain — before the request is routed anywhere.
The consent layer answers one question
GRANTED
Exchange proceeds, and is recorded
REVOKED
Refused, and the refusal is recorded
EXPIRED
Refused, and the refusal is recorded
NO RECORD
Refused, and the refusal is recorded
Three of those four outcomes are a refusal. No record is not permission — the only state that lets data move is an explicit, current grant.
Deployment
Sovereignty isn't a tier you upgrade to.
zapXD is designed so that it never holds the data it authorises. There is no edition in which your data lives with us. The only question is where the infrastructure runs.
National cloud
Operated inside your own government cloud account, on infrastructure you already control and audit.
- Your own account, your own keys
- Standard hardening baseline
- Fastest path to a pilot
Private VPC
An isolated deployment with its own database, its own key material and its own network boundary. Nothing is shared with any other nation.
- Isolated database & key material
- Customer-managed encryption keys
- Data residency your choice
On-premise
Runs completely disconnected from any outside network, for classified environments or where residency rules leave no alternative.
- No external dependency
- Hardware key service on-site
- Full source access
Questions
The ones that get asked first.
It can replace it, or it can sit in front of it. zapXD is a complete ecosystem — consent, exchange and evidence — and most organisations take all of it. If you already run an exchange you are happy with, you can take the consent layer on its own instead: it reaches your exchange through a single adapter interface. Consent is enforced the same way either way.
On a private blockchain — Hyperledger Fabric — run by the organisations involved, typically the platform authority and the organisations themselves. It records consent and the fact that an exchange happened. Never the data itself, and never a raw identifier. Members join by certificate, so who may read the ledger is a governance decision your institutions make, not a vendor's.
The blast radius is one organisation. There is no central pool to steal, because the data never leaves its owner and is never brokered. An attacker who takes over one organisation still has to satisfy the consent check for every single record, and every attempt — successful or refused — is already on a ledger the attacker cannot rewrite.
Yes, and that is a primary feature rather than a report. The citizen portal shows every request made against their record — the requesting organisation, the declared purpose, the outcome, and the timestamp — and lets them grant or revoke. Revocation takes effect immediately and is itself written to the ledger, so the withdrawal is as provable as the access was.
That is treated as a security incident, not a sync error. Every exchange is written to both at the same time, and a background job checks that the two still match. The blockchain is the authoritative record of what was authorised; the database is a working copy for searching and reporting. Treating a mismatch as routine is exactly how audit trails quietly become fiction.
Through a digital onboarding flow, not a paper form. The organisation applies, receives an identity, sets up its signing key, and registers the services it offers along with the consent each one requires. The platform authority approves the member; after that the organisation manages its own services.
Next step
See it running on your own data model.
Thirty minutes, architecture-level, with the engineers who built it. Bring a real exchange you'd like to govern — a treatment record, a KYC check, a benefits assessment — and we'll walk it through the lifecycle end to end.
Architecture documentation, threat model and the test suite are available under review on request.