Researchers affiliated with the Bank for International Settlements tested the XRP Ledger as a verification layer for official statistics, according to a working paper published on Sept. 2.
Summary
- BIS researchers tested XRP Ledger Devnet for verifying integrity and origin of official statistical datasets.
- Prototype recorded cryptographic dataset fingerprints rather than publishing the underlying statistics onchain for public verification.
- Controlled tests produced median publication latency of three to five seconds in researchers’ measurements conducted.
- Verification took one to two seconds by comparing files against XRP Ledger records during testing.
- Authors said the experimental system was not intended for production and remains unmaintained prototype software.
The prototype connected the XRP Ledger with Statistical Data and Metadata eXchange, or SDMX, an international standard used by organizations including the BIS to exchange statistical information.
Instead of placing complete statistical datasets onchain, the system calculated cryptographic fingerprints representing the data. It then recorded those fingerprints on the XRP Ledger’s Devnet, allowing a recipient to check whether a downloaded file matched the version originally published.
The experiment does not represent a production deployment, partnership with Ripple or endorsement of XRP as an investment. The paper also states that its conclusions belong to the authors and may not reflect the institutional position of the BIS.
XRP Ledger prototype verifies whether data changed
Official statistics are commonly distributed through websites, databases and automated data feeds. A recipient must trust that the downloaded file is authentic and that its contents have not changed since the publisher released it.
The researchers designed their prototype to provide an independent verification record. Before publication, the software converted an SDMX file into a standardized format and calculated a SHA3-512 cryptographic hash.
A hash functions like a unique digital fingerprint. Changing even a small part of the source file produces a different result. A recipient can therefore repeat the calculation and compare the result with the fingerprint recorded onchain.
The prototype supported checking an entire file or selected statistical series within it. When multiple series were included, the system combined their hashes into a Merkle root. This allowed several data components to share one onchain record while remaining independently verifiable.
The root was anchored through an XRP Ledger transaction. A reference to that transaction was then embedded in the SDMX file, giving recipients the information required to locate the onchain record and complete the comparison.
The design means the XRP Ledger did not establish whether the statistics themselves were accurate. It only provided evidence that the verified data matched the version connected to the original record.
BIS researchers reported verification within seconds
The paper reported median publication latency of approximately three to five seconds under controlled testing conditions. Verification took approximately one to two seconds.
Publication latency covered the process of creating and confirming the blockchain record. Verification involved recalculating the fingerprint and checking it against information stored in the relevant XRP Ledger transaction.
Those results should not be treated as guaranteed performance under production conditions. The researchers conducted the measurements through an experimental system operating on XRPL Devnet rather than the public main network used for real transactions.
Devnet supplies test XRP through a faucet and allows developers to experiment without using assets carrying market value. Its activity, reliability requirements and operating environment differ from those of the XRP Ledger mainnet.
The researchers selected XRPL partly because of its relatively fast transaction confirmation and low transaction costs. However, the experiment did not compare XRPL performance directly against Ethereum, Solana, permissioned databases or conventional digital timestamping services.
The code was released in a public BIS repository. Its documentation describes the software as an experimental proof of concept that is neither intended for production nor actively maintained.
Identity checks strengthen the statistical record
Confirming that data has not changed solves only part of the verification problem. A malicious actor could create a valid hash for a fraudulent file and publish it from an unrelated blockchain address.
The prototype addressed that risk with a publisher identity system. It used a W3C Verifiable Credential signed by an identity key associated with the publisher’s XRP Ledger address.
A recipient could use that credential to check that the party publishing the file controlled the recognized address. The verification process therefore assessed both data integrity and publisher identity.
The SDMX message carried the transaction reference, ordered Merkle leaves and credential required for the check. A verifier could reproduce the root from the received file and compare it through one ledger lookup.
The researchers said the architecture could eventually support zero-knowledge proofs. Such technology could let an organization prove selected facts about restricted data without disclosing the full dataset.
They also identified potential use by artificial intelligence agents. Automated systems increasingly retrieve statistics without a person manually confirming each source. A machine-readable verification record could allow software to reject altered or incorrectly attributed files.
These remain proposed extensions. The published repository provides experimental code rather than a production service for central banks, national statistics agencies or AI companies.
XRP Ledger use case does not require XRP adoption
The prototype used XRP Ledger infrastructure because every onchain record requires a transaction. However, it did not use XRP for payments, liquidity, settlement or cross-border transfers.
Only a small transaction fee would be required to anchor each record on mainnet. The amount would depend on network conditions and the publication method selected by an institution.
That distinction matters because use of the XRP Ledger does not necessarily create material demand for its native asset. A data publisher could anchor many statistical series through a single Merkle root, reducing the number of transactions required.
The experiment nevertheless extends the types of applications tested on XRPL beyond payments and tokenized financial assets. The network is also developing institutional features covering permissioned trading, lending and asset issuance.
In related coverage, XRP Ledger’s institutional infrastructure has expanded through permissioned markets and native lending proposals. Those financial applications are separate from the BIS researchers’ statistical verification system.
The network’s activity has also become more concentrated. XRP Ledger order-book volume rose 79% while daily traders declined during the second quarter, according to research published by Evernorth.
Neither development establishes that the statistical prototype will enter production. They provide broader context for the different financial and nonfinancial applications being tested across the XRP Ledger ecosystem.
Production adoption would require further testing
The prototype would need additional security, governance and operational work before an official statistics provider could rely on it. Institutions would need policies governing publisher keys, compromised credentials, transaction failures and corrections to previously issued datasets.
The permanence of blockchain records creates another challenge. Official statistics are frequently revised after agencies receive new information or correct errors. A production system must distinguish legitimate revisions from unauthorized alterations without suggesting that the earliest version remains current.
Publishers would also need to decide whether to depend on a public blockchain, run additional infrastructure or combine blockchain records with existing digital signature systems. Privacy rules may restrict which metadata can appear in public transactions.
The authors said their approach is not limited to SDMX. It could be adapted for other structured formats, including XBRL, which companies and regulators use for financial reporting.
No implementation deadline was provided. The repository states that the software is unmaintained, and the BIS has not announced plans to deploy it across its official statistical publications.
The verified result is therefore narrower than claims that the BIS adopted the XRP Ledger. BIS-affiliated researchers demonstrated that an experimental system could use XRPL Devnet to authenticate statistical files within seconds under controlled conditions.
