Skip to content

GCRI · Digital Public Infrastructure

Distributed ledgers for public use

Distributed ledger technology records transactions across multiple parties without a single central database. In this field it is assessed critically for public uses such as registries, credentials and payments, where its benefits must be weighed against cost, governance and privacy.

Make an enquiry Back to STEM foundation of Digital Public Infrastructure
01Contents

Distributed ledgers for public use in five parts.

Protocol5 steps
  1. 01ApplicationWhat distributed ledgers and digital assets does here
  2. 02DataWhat the method consumes
  3. 03ValidationHow results are checked
  4. 04ConnectionsTopics that rely on this method
  5. 05StewardshipWho maintains the method
02Application

What distributed ledgers and digital assets does here.

Distributed ledgers and digital assets use shared, replicated records maintained by consensus among participants. They support new forms of payment, asset registration and contracting, with distinct operational and financial risks. In digital public infrastructure and cyber and digital resilience, ledger analysis informs how digital asset failures could spill into payments and markets. It supports evaluation of ledgers for transparent registries and aid distribution. The canonical description is on the STEM Commons.

Fit-for-purpose assessment

Proposed ledger uses are assessed against simpler alternatives, asking whether multiple parties truly need a shared record without a trusted operator.

Privacy and erasure constraints

Ledger designs are reviewed for compatibility with data protection, including the right to erasure, which immutable records complicate.

Governance of permissioned ledgers

Who may join, validate and change rules on permissioned ledgers is documented, since governance determines trust.

03Monitor

Settlement ledger.

The screen a team would use to follow this method: its measures, states and decisions. Names are examples and values are illustrative.

Settlement ledger

Digital public infrastructure · Distributed ledgers for public use · Run R-5205

ReconciledGCRI · Digital Public Infrastructure

Settlement batches

B-12731088263PendingQueued
B-06512372247FinalQueued
B-0750241820FinalSettled
B-2401784871PendingRejected

Method card

Method
Distributed ledgers and digital assets
Model
deferred net, hourly
Fallback
manual procedure
Label
MODELLED

Intraday liquidity

Settlement ledger: the screen's structure, terms and states for Digital public infrastructure.Example names and illustrative values; a design, not a record or a live system.
04Data

What the method consumes.

Datasets and records used by distributed ledgers and digital assets on this platform, with the role each plays and the label its values carry. Sources are listed in the source register.

DataRoleLabel
Pilot evaluationsOutcomesREPORTED
Technical specificationsDesignDECLARED
Cost dataComparison with alternativesESTIMATED
05Methods and evidence

How distributed ledgers for public use is modelled, measured and tested.

The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.

Datasets and provenance

The data classes behind distributed ledgers for public use and what is recorded about each before it is used.

Data classProvenance recordedResolution statedLicence checked
Satellite imagery, optical and radarsensor, processing level, acquisition datepixel size and revisitper scene
Reanalysis and climate model outputmodel, experiment, member, versiongrid and time stepper release
In-situ sensors and gaugesstation, instrument, calibration recordpoint and sampling rateper network
Population and asset exposuremethod, vintage, input sourcescell size and unitper release
Boundaries and reference geographyproducer, edition, datescaleper edition
Lineage
W3C PROV record from source to figure
Principles
FAIR: findable, accessible, interoperable, reusable
Gaps
shown as missing, never filled silently
Data classes and the provenance fields recorded for each; a dataset is listed by name only once its licence admits the use.
FAIR guiding principles · GO FAIR and FORCE11W3C PROV · World Wide Web ConsortiumGuidance on consistent treatment of uncertainties · IPCCCEOS Analysis Ready Data · Committee on Earth Observation Satellites
06Validation

How results are checked.

Protocols and contracts are checked through formal verification, audits and adversarial testing. On-chain data allow independent reconciliation of balances and flows.

CheckHow it is done
Alternative comparisonLedger designs are compared with conventional databases
Data protection reviewDesigns are reviewed by data protection experts
Governance documentationValidator and change rules are published

Code defects and governance disputes can cause irreversible losses. Links to the traditional financial system are often opaque.

07Process

How the process runs.

Process explorer · Process

Distributed ledgers for public use: Payment from instruction to finality

8 steps4 stages

Process

Distributed ledgers for public use: Payment from instruction to finality

An RTGS system checks a payment, queues it if funds are short, settles it gross in real time and gives final settlement.

  1. 01 Intake

    1. 01Payment instructionSource · ParticipantThe system should use, or at least accommodate, relevant internationally accepted communication procedures and standards.
    2. 04Validity and conditionality checksStep · System operatorA payment is accepted once it passes validity and conditionality checks, such as funds or credit. An invalid payment is generally rejected.

  2. 02 Settlement

    1. 02LiquidityDataset · ParticipantParticipants need liquidity for outgoing payments: central or commercial bank balances, incoming payments and intraday credit.
    2. 05QueueModel · System operatorA valid payment that fails conditionality checks is queued or rejected. Queuing and other liquidity-saving tools can cut liquidity needs.
    3. 06Settle in real time, grossStep · System operatorRTGS settles payments continuously, without deferral, usually one by one. Money settlements should use central bank money where practical.

  3. 03 Finality

    1. 07Final settlementRecord · System operatorThe system gives clear, certain final settlement by the end of the value date at least, intraday or real time where needed.
    2. 08ReconciliationStep · System operatorReconciliation checks that records issued by two different entities match. The pages read state no timing for payment systems.

  4. 04 Resilience

    1. 03Business continuity and secondary siteExercise · System operatorThe plan uses a secondary site and aims to resume critical IT within two hours and settle by end of day. Arrangements are regularly tested.

Outline of an external standard or method, from its public sources. It describes what the framework says, not a record of any run. It does not show that Nexus or any partner performs, certifies or approves a step. A gate is a step of the method, never a Nexus approval. The source is the CPMI-IOSCO Principles for financial market infrastructures. A business continuity plan covers disruption.

08Connections

Topics that rely on this method.

09Stewardship

Who maintains the method.

Fintech Nexus stewards distributed ledgers and digital assets for the Consortium and reviews how it is applied across platforms.

Canonical page: Distributed ledgers and digital assets

10Connected

Where this page leads across the Consortium.

11Questions

Questions and answers.

What are the limits of distributed ledgers and digital assets in this field?
Code defects and governance disputes can cause irreversible losses. Links to the traditional financial system are often opaque.
How are results checked?
Protocols and contracts are checked through formal verification, audits and adversarial testing. On-chain data allow independent reconciliation of balances and flows.
Are the values on this page real?
The data names, roles and checks are real descriptions of practice. The canvas shows a design of the method's use, not a run; no result is reported here.
Where else is this method applied?
The canonical method page lists every platform that applies it.
ReportsContribute

Contribute evidence from this page.

Reports is the Consortium's quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.

GCRIDigital Public InfrastructureStrategic SystemsExponential Technology

Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.

Digital Public Infrastructure

Bring a method, a dataset or a question.

Information and enquiries are open today. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.

Propose a method See all contact routes
Legal

Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.