About zkDatabase
What Is Verifiable Data Infrastructure? A Guide for RWA
October 24, 2026
6 mins read
Verifiable Data Infrastructure lets anyone check financial data was stored and processed as claimed, using proof instead of trust. What it means for RWA.
Verifiable Data Infrastructure is the layer that lets anyone check that financial data was stored and processed as claimed, using cryptographic proof instead of trust in whoever runs the system. For Real-World Assets (RWA), it has to cover three things: the current state of an asset, the history of how that state changed, and who was allowed to change it. The check works without exposing the data itself, which matters when that data is reserves, NAV, collateral or client identity.
Orochi Network describes itself as The First Verifiable Data Infrastructure for RWA. This page explains what that phrase means, why tokenized assets need it, and where it sits next to the custodians, administrators, auditors and oracles that RWA already depends on.
Verifiable Data Infrastructure proves state, history and access
Most data systems ask users to trust the operator's database. A verifiable one gives users a way to check it. For RWA, that check has three parts.
State is what the data says right now: the reserve balance behind a stablecoin, the holdings of a tokenized fund, the collateral pledged against a loan. History is the sequence of changes that produced that state, so a reader can see the balance was reached by valid updates rather than written in after the fact. Access is who was permitted to make each change, so an update by the wrong party shows up as invalid.
It helps to be exact about what a proof covers. A proof shows that data was stored and processed as claimed. It does not show that a real-world input was true. If a custodian reports a wrong balance, a proof confirms that the wrong balance was recorded and handled correctly. The value of the layer is that every step after the input becomes checkable, and the input itself has a clear, accountable source.
Why RWA tokenization needs a verifiable data layer
A token is only as good as the off-chain data behind it. The smart contract can be audited and the chain can be public, yet the asset registry, the loan tape and the reserve report usually live in private systems that investors cannot inspect.
UK bridging lender Market Financial Solutions (MFS) shows what happens when that data cannot be checked across parties. Administrators were appointed by court order on 25 February 2026, after creditors petitioned for administration alleging "fraud and potential double pledging of assets", where the same collateral is pledged to more than one lender. Each lender relied on its own record of what secured its loan, with no shared, checkable view of whether that collateral was already claimed elsewhere.
Tokenized credit, funds and treasuries run on the same model: a private register of who owns what, reported to others at intervals. Moving the token on-chain does not change that. A verifiable data layer is designed to give each party a proof about the shared data it relies on, so a second claim on the same asset would conflict with what is already proven.
Where it sits in an RWA stack
An RWA platform has several layers, and each one does a distinct job:
- Source data. Custodians, transfer agents, fund administrators and servicers hold the records of the asset itself.
- Data delivery. Oracle networks bring prices and reports on-chain. Orochi integrates with Chainlink, and this layer remains essential.
- Verifiable data. This layer keeps the sensitive data off-chain and publishes a proof on-chain that it was stored and processed as claimed.
- Token and smart contracts. The asset's on-chain form, which can read those proofs before minting, lending or settling.
- Investors, auditors and regulators. They can check the proofs between reports, without asking for the raw data.
Oracles answer "what is the value?" The verifiable data layer answers "was this data kept and changed the way the operator says?" The two work together. A report delivered by an oracle can point to data whose handling is already proven.
The verifiable data layer sits between off-chain source data and the token, adding a proof that others can check.Attestation and cryptographic proof cover different layers
Attestations, such as an accountant's reserve report, are the standard way RWA issuers show their backing today, and they bring professional judgment that a proof does not replace. Cryptographic proof adds a different kind of evidence next to them.
| Attestation | Cryptographic proof | |
|---|---|---|
| Basis | A named firm checks the data and signs a report | Math anyone can verify against published parameters |
| Frequency | Set by the reporting cycle, often monthly | A proof for every update |
| What is disclosed | Summary figures in the report | Only what the proof states; the data stays private |
| Who can check it | Readers of the report | Anyone, including a smart contract |
Our comparison of Proof of Reserves audits by cryptographic proof and attestation goes deeper on how the two fit together.
Institutional research points the same way. A 2025 report on Ethereum Layer 2 networks for institutions by Etherealize, Nethermind and L2BEAT notes that Zero-Knowledge Proofs let regulators "obtain evidence of required checks being performed while commercial data stays confidential." That is the gap a verifiable data layer is built for: evidence that can be shared without sharing the data.
How zkDatabase delivers Verifiable Data Infrastructure
zkDatabase is Orochi's verifiable database powered by Zero-Knowledge Proofs, built to ensure both data integrity and privacy. It generates a Zero-Knowledge Proof for every operation, proving each data change was done correctly. The data stays off-chain; the proof can be checked on-chain or by any party that needs it.
For RWA, zkDatabase is designed to cover the three parts above. It can prove the current state of a collection, prove that a value is part of it without revealing the rest, and keep the full sequence of updates provable. Use cases include stablecoin reserves and Proof of Reserves (PoR), tokenized funds and NAV, on-chain credit and collateral, and private KYC.
The reasoning behind that design is in why Orochi built zkDatabase, and the mechanism step by step is in how zkDatabase works. For the broader idea of data that can be checked, see our guide to what verifiable data means, and for the audit angle, why tokenized assets need a new audit model.
Sources
- CMS, MFS collapse and the double pledging risk (16 March 2026)
- Etherealize, Nethermind and L2BEAT, The Future of Financial Infrastructure: Ethereum's Layer 2 Landscape (4 December 2025)
Explore zkDatabase
See how zkDatabase is designed to give RWA platforms a verifiable data layer that investors, auditors and smart contracts can check without seeing the data.
Related toAbout zkDatabase
