About zkDatabase
What Is zkDatabase? A Guide to the Verifiable Database
October 23, 2026
12 mins read
zkDatabase keeps sensitive data off-chain and generates a Zero-Knowledge Proof for every update and query, so others verify it without seeing it.
zkDatabase is a verifiable database powered by Zero-Knowledge Proofs, built by Orochi Network to ensure both data integrity and privacy. A Zero-Knowledge Proof is a small piece of math that shows a statement is true without revealing the data behind it. zkDatabase keeps data off-chain and generates a proof for every write and every query. Smart contracts, auditors and counterparties check that proof against a small commitment on-chain, so they confirm the data was stored and processed as claimed without ever seeing the data itself.
That matters because the data institutions care about most, such as stablecoin reserves, a fund's net asset value (NAV), loan collateral and identity checks, is too sensitive to publish on a public chain. Today it is checked through reports and audits at fixed points in time. zkDatabase adds cryptographic evidence between those reports, for every change.
This guide explains what zkDatabase is, how it works step by step, how it differs from a traditional database, and where it is used.
Key Takeaways
- zkDatabase is a verifiable database. Data stays off-chain; a Zero-Knowledge Proof for each operation goes on-chain.
- A proof shows the data was stored and processed as claimed. It does not reveal the raw data, and it does not claim that a real-world input is true: if a wrong reserve figure is entered, the proof shows it was handled correctly, not that it is right. Source checks such as bank statements and audits still matter.
- It adds evidence next to audits and reports. Counterparties and regulators check each update without waiting for the next report.
What Is zkDatabase and Why Does Web3 Need It?
zkDatabase combines a NoSQL database with a Zero-Knowledge prover. The prover uses Groth16, a widely used type of ZK proof (a zk-SNARK) that produces very small proofs which are cheap to check on-chain. The architecture is modular, so other proof systems can be added later.
Web3 needs this layer because smart contracts now act on data that lives off-chain. A tokenized fund settles against a NAV, a stablecoin mints against reserves, a lending pool accepts collateral. A smart contract cannot read a bank statement or a custody report, and publishing those files on-chain would expose data no institution is allowed to share. zkDatabase gives the contract something it can check: a proof that the off-chain data was recorded and processed under the stated rules.
How zkDatabase Works
zkDatabase sits at the core of a verifiable data pipeline, where every step from storage to on-chain verification is provable. Raw data stays off-chain. Proofs move on-chain.
How is data stored off-chain in zkDatabase?
Data is stored off-chain in collections and documents, in a NoSQL style that supports flexible data models and large datasets. The state of each collection is committed to a Merkle tree, a structure that hashes data in pairs, level by level, down to one value at the top called the Merkle root. The root acts as a fingerprint of the whole dataset. Any change to the data changes the root, so the history of changes stays checkable.
Large or sensitive datasets never need to be published on-chain to be checked.
How does zkDatabase generate proofs for data integrity?
For each operation, zkDatabase generates a Zero-Knowledge Proof and submits only that proof and the new Merkle root on-chain. A smart contract verifies the proof without access to the underlying data. Because a Groth16 proof is small, this keeps the on-chain footprint and gas cost low, and the same proof can be verified on other Ethereum Virtual Machine (EVM)-compatible chains.
How zkDatabase Proves Off-Chain Data On-Chain (Step by Step)
zkDatabase makes off-chain data checkable by generating a proof for every database operation and anchoring the database state on-chain. There are two flows:
- Data write verification (insert, update, delete)
- Query result verification
Flow 1: Data write verification
Step 1: A data provider submits an operation. An application sends an
INSERT, UPDATE or DELETE to zkDatabase. The operation runs off-chain.Step 2: zkDatabase executes it and updates the state. The database applies the operation to its storage, updates the Merkle tree and produces a new Merkle root.
Step 3: zkDatabase generates a proof. The proof shows that the operation was valid, that the Merkle tree was updated correctly, and that the new root was derived from the previous one. It reveals no raw data.
Step 4: The proof and roots go on-chain. zkDatabase submits the proof, the old Merkle root and the new Merkle root to a smart contract.
Step 5: The smart contract verifies the proof.
Verify(ZKP, oldRoot, newRoot)
If the proof is valid, the contract stores the new root. If it is invalid, the contract rejects the update and keeps the previous state. Only the Merkle root is stored on-chain: no data and no execution logic are published.
Flow 2: Query result verification
Step 1: A user submits a query. A user, an application or a smart contract sends a query to zkDatabase.
Step 2: zkDatabase runs the query and generates a proof. The query runs off-chain. The proof shows that the result was computed correctly and comes from the latest committed state of the dataset. For a simple lookup this is a proof of membership in the Merkle tree.
Step 3: zkDatabase returns the result and the proof.
Step 4: Someone verifies the proof. A user or application fetches the latest Merkle root from the smart contract and runs:
Verify(ZKP, MerkleRoot)
A smart contract verifies the proof directly when its own logic depends on the result. In both cases the check depends on the proof and the on-chain root, not on the word of whoever runs the database.
How Is zkDatabase Different From Traditional Databases?
Traditional databases are built for speed, scale and access control. They do those jobs well. What they were not built to do is give an outside party a cryptographic proof of what happened inside them.
What does a traditional database leave unproven?
In a traditional database, the operator stores, updates and reports the data, and outside parties rely on that operator plus periodic audits. Logs exist, but they sit inside the same system and cannot be checked independently by a counterparty. Reporting is usually periodic and based on snapshots. That works for internal use. It leaves a gap when a smart contract, a lender or a regulator needs to check the data between reports.
How does zkDatabase prove what happens inside the database?
zkDatabase attaches a Zero-Knowledge Proof to every insert, update and query. Any party checks the proof against the on-chain commitment, at any time, without asking the operator for access. Privacy comes from the proof itself rather than from access control alone: the verifier learns that the rule held, not the data behind it.
That is why zkDatabase is called a provable database: integrity and state changes are proven, not reported.
Core Features of zkDatabase: Privacy, Integrity and Scale
zkDatabase is built as general Verifiable Data Infrastructure for systems where data must be provable, private and scalable at the same time.
How does zkDatabase preserve data privacy?
zkDatabase proves statements about data without revealing the data. Financial data, identity attributes and compliance files are checked without being disclosed. Privacy is part of how the system works, not an extra layer on top.
How does zkDatabase support audit-grade data integrity?
Every state change carries a proof, from the first insert to every update and query. Auditors, regulators and applications confirm correctness at any point in time, not only at the next scheduled review. The audit still happens; it now has a continuous, checkable trail to work from.
How does zkDatabase scale?
zkDatabase separates execution from verification. Storage and computation happen off-chain, and only small proofs and roots go on-chain. This keeps throughput high and gas costs low, which suits large datasets and frequent updates.
What Are the Most Important Use Cases of zkDatabase?
zkDatabase is built for financial systems that depend on off-chain data but settle on-chain. The main use cases are Real-World Assets (RWA), stablecoins, custody and collateral, and on-chain credit.
Real-World Assets (RWA)
RWA tokenization depends on off-chain data: ownership documents, valuation reports, custody statements and compliance files. These usually sit in PDFs and private databases and are referenced on-chain without a way to check them.
zkDatabase lets RWA platforms prove, without sharing the documents:
- That the recorded document data has not changed since it was committed
- That eligibility and compliance rules were applied as stated to that data
- That asset data stays consistent across every update
Platforms keep their files confidential and still give investors and venues something they can check.
Stablecoins
Stablecoin holders and regulators want to know that reserve data matches circulating supply at any time, not only on the day of a report. In the US, the GENIUS Act final rule from the Office of the Comptroller of the Currency (OCC) (21 October 2026, effective 18 January 2027) turns reserves, redemption, reports and audits into federal rules for the issuers it supervises.
For Proof of Reserves (PoR), zkDatabase gives issuers:
- A proof that the reserve-to-supply check ran correctly on the recorded reserve data
- Proofs that reserve policy rules, such as asset type and maturity limits, were applied as stated
- A proof check that mint and burn logic can require before it runs
Bank balances and account-level data stay private. The proofs add evidence between the required reports and audits; they do not replace them.
Custody and Collateral
Tokenized securities and collateral depend on custody data, collateral status, valuation methods and settlement conditions, which are usually reconciled by hand on a schedule.
zkDatabase gives these systems:
- Custody proofs that custody data was recorded and updated as claimed
- Valuation proofs that pricing and margin rules were applied as stated
- A time-stamped trail of every change, checkable by each counterparty
This lowers reconciliation work and dispute risk without disclosing positions.
On-Chain Credit
On-chain credit still relies on sensitive off-chain signals: income data, credit history, repayment behavior and underwriting decisions.
zkDatabase supports verifiable on-chain credit by:
- Proving that know-your-customer and know-your-business (KYC/KYB), sanctions and eligibility checks ran as stated on the recorded data
- Turning off-chain data that borrowers agree to share into credit signals lenders check without seeing the raw data
- Proving that underwriting and monitoring followed the agreed policy
Lenders check the process without turning borrower data into a public dataset. The same approach supports decentralized identity and private KYC.
How Does zkDatabase Power RWA Infrastructure?
Ownership, valuation, custody and compliance all start off-chain, while the token and its rules live on-chain. zkDatabase acts as the verification layer between the two.
RWA platforms generate shareable proofs about:
- The integrity of recorded legal and custody data
- Eligibility rules such as jurisdiction, issuer limits and approved custodians
- Coverage and continuity, so asset data stays consistent across updates
Because these proofs are anchored on-chain, they form one audit trail that venues, chains and counterparties reuse without re-sharing sensitive files.
How Does zkDatabase Work With Oracle Infrastructure?
Oracle networks bring external data to smart contracts and are the established way to deliver prices and other feeds on-chain. For sensitive or regulated data, a contract often also needs to know how that data was stored and processed before it reached the chain.
zkDatabase covers that layer. It works as a backend verification layer behind the data an oracle delivers: the message arrives with a proof that the underlying data was recorded and processed as claimed. For a longer comparison, see Zero-Knowledge Proofs for off-chain data vs oracles.
Where Verifiable Data Infrastructure Is Heading
Rules now ask institutions to show more evidence about their data. The OCC's GENIUS Act final rule sets federal reserve, redemption, report and audit requirements for supervised US stablecoin issuers from 18 January 2027. In the EU, the European Digital Identity Framework (eIDAS 2, Regulation (EU) 2024/1183, in force since May 2024) names Zero-Knowledge Proofs in Recital 14 as a privacy-preserving technology that Member States should build into the EU Digital Identity Wallet.
Both point the same way: institutions must show more about their data, more often, while sharing less of it. A verifiable database gives them a way to do both.
FAQs
What makes zkDatabase different from a traditional database or an oracle?
zkDatabase is a provable database: every insert, update and query comes with a Zero-Knowledge Proof. A traditional database relies on its operator and periodic audits, and an oracle delivers data on-chain. zkDatabase adds a proof that the data was stored and processed as claimed, with data kept off-chain and only proofs and Merkle roots checked on-chain.
Does zkDatabase store data on-chain or off-chain?
Off-chain. zkDatabase stores data in a NoSQL-style database and submits only small proofs and Merkle roots on-chain. This keeps raw data private and gas costs low.
What proof system does zkDatabase use?
Groth16, a zk-SNARK picked for compact proofs and cheap on-chain checks. Support for further proof systems is planned through the modular design.
What use cases is zkDatabase built for?
Use cases where data must be private, verifiable and audit-ready:
- Real-World Assets (RWA): ownership, valuation and compliance proofs
- Stablecoins: private Proof of Reserves with a proof for every update
- Custody, collateral and on-chain credit: checkable data without disclosure
See how the verifiable database works and which use cases it supports.
Related toAbout zkDatabase
