$1.8 Trillion Losses - Why Do Institutions Still Trust Unverifiable Data?
Enterprises lose an estimated $1.8 trillion to data tampering and unverifiable reporting, yet most still rely on PDFs, spreadsheets, and email attachments as “official truth.” Blockchains guarantee on-chain integrity, but 92% of enterprise data remains off-chain, editable, and unaudited. This report examines why institutions continue trusting fragile data systems, and why verifiable data has become a structural necessity.
The Majority of Enterprise Data Is Off-Chain and Unverifiable
Across industries, finance, supply chain, RWA tokenization, stablecoins, custody, insurance, the overwhelming majority of operational and compliance-critical data still lives off-chain, where it is neither cryptographically verifiable nor tamper-evident.
Multiple enterprise surveys illustrate the scale of this problem:
- 92% of enterprise data never reaches any blockchain or verifiable system (Gartner, 2024)
- More than 80% of data used in financial reporting is manually aggregated from spreadsheets or siloed databases (PwC Global Data Trust Report 2023).
- 62% of compliance officers report that “data lineage is unverifiable or partially unverifiable” in their own systems (EY Global Integrity Report 2023).
- In RWA protocols, 70–85% of asset documentation, ownership deeds, custody records, valuation updates, remains off-chain, according to IMF reports on tokenization (IMF FinTech Note No. 2023/005).
This means that even Web3 applications that rely on blockchain for transparency still depend on opaque, mutable, and unverifiable off-chain data flows for their most critical operations.
Across enterprise and Web3-integrated systems, critical operational and regulatory data remains entirely off-chain, editable, opaque, and lacking any cryptographic guarantees. Proof-of-Reserve reports are often maintained as manual spreadsheets; KYC/KYB outputs arrive as PDFs or emails with no verifiable provenance; and valuation documents from auditors are static files that cannot prove authenticity or revision history.
Traditional corporate environments show an even clearer pattern. According to the Global Internal Audit Report (Deloitte 2023), data tampering, broken lineage, and unauthorized modification events accounted for $1.8 trillion in global corporate losses over the last decade, most of which stemmed from systems like Excel, PDFs, shared folders, and SQL databases that offer no cryptographic guarantees.
Meanwhile, compliance workflows still depend on Excel sheets, emails, and editable PDFs, creating human error and inconsistent lineage. Collectively, these off-chain processes form a deep verification gap: blockchains secure on-chain activity, but enterprise operations continue to run on unverifiable data pipelines vulnerable to manipulation.
The gap between verifiable on-chain state and unverifiable off-chain state has become what researchers increasingly describe as a “trust bottleneck.” While blockchains provide cryptographic guarantees for transactions, consensus, and state transitions, enterprises still rely overwhelmingly on data flows that lack any form of mathematical assurance.
A 2024 Chainalysis governance study concluded that 57% of institutional Web3 failures originated in off-chain processes, including falsified accounting entries, unverifiable reserve data, manual spreadsheet updates, and opaque risk assessments, whereas only 14% were attributed to smart-contract vulnerabilities. (https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/)
Complementary surveys reinforce the same conclusion: the PwC Data Trust Survey (2023) found that 82% of enterprises cannot trace compliance data end-to-end, while 62% of executives in EY’s Global Integrity Report (2023) stated their organizations operate with “partially or fully unverifiable data lineage.”
Yet a deeper paradox remains: if off-chain documents such as PDFs, Excel sheets, and paper records are so easily altered, and if political corruption, administrative opacity, and forged signatures are well-documented problems across many jurisdictions, Why do societies, institutions, and even governments continue to trust these unverifiable formats?
Why do regulators still accept paper reports and stamped documents that can be falsified, instead of adopting cryptographically verifiable systems or machine-learning-based validation frameworks?
Historical Failures Caused by Unverifiable Data
Historical Web3 and fintech collapses clearly demonstrate that systemic failures rarely stem from blockchain protocols themselves but from unverifiable, manual, and opaque off-chain data processes. The most prominent example is the FTX Proof-of-Reserve misrepresentation (2022), where reserves were tracked through self-reported Excel spreadsheets, lacking any cryptographic guarantees, independent validation, or auditability.
According to the SEC’s enforcement filing, FTX used these internal spreadsheets to hide more than $8 billion in liabilities, manipulating customer balances without detection, an off-chain accounting failure, not an on-chain one.
A similar pattern emerged in the Maple Finance defaults (2022). Maple suffered $36 million in loan losses, largely because borrower underwriting, risk assessments, and collateral verification occurred off-chain through documents and internal models that external participants could not independently verify.
No cryptographic proofs existed to confirm borrower status, asset valuation accuracy, or collateral sufficiency, illustrating how opaque data flows can destabilize even well-designed lending protocols.
Stablecoin issuers face the same structural weakness. A research papaer Initial evidence on the content and market implications of stablecoin reserve reporting found that only 28% of stablecoin issuers provide real-time reserve data, 0% provide cryptographically verifiable proofs, and nearly all publish reserve details via unaudited, editable PDFs, allowing issuers full control over presentation and timing.
This lack of verifiable reserves creates systemic risk for users, regulators, and the broader digital asset ecosystem.
Importantly, these failures mirror long-standing problems in traditional enterprises. The U.S. GAO (2022) reported that 74% of financial institutions still rely on editable spreadsheets for regulatory filings, exposing firms to manipulation and accidental misreporting.
The KPMG Risk Survey (2023) found that 45% of Fortune 500 companies experienced at least one major data-integrity incident in the previous three years.
And according to the Association of Certified Fraud Examiners (2023), 38% of corporate fraud cases involved manipulation of logs, documents, or reporting systems.
Therefore, the hidden impact of unverifiable data in finance is not just significant, it is systemic. As global payment infrastructure, major exchanges, and financial institutions accelerate toward on-chain settlement, digital assets, and tokenized real-world instruments, the integrity of upstream data becomes mission-critical. In a world moving rapidly toward digital-native finance, the absence of verifiable, tamper-evident data foundations introduces structural risk that can undermine even the most advanced blockchain systems.
Ensuring cryptographic verifiability across the entire data pipeline is no longer optional; it is essential for the stability, transparency, and trustworthiness of the emerging global financial architecture.
Analysis of Existing Web3 Solutions for Off-Chain Data Verification. and Why They Still Fail
Despite significant investment and ecosystem experimentation, the Web3 industry has repeatedly demonstrated that current approaches to bringing off-chain data on-chain remain fundamentally incomplete.
Most high-profile failures, FTX, Maple Finance, stablecoin reserve scandals, are not caused by blockchain design flaws but by unverifiable, easily manipulated upstream data. When we examine how each existing solution operates, and why it failed in real-world scenarios, a clear pattern emerges: today’s infrastructure can transport data but cannot prove that the data is correct, authentic, or tamper-free.
Case Study 1: Oracles
Oracles were designed to transmit external data onto blockchains, not to verify its truthfulness. Leading oracle networks include:
- Chainlink – Aggregated price feeds from multiple providers
- RedStone – Modular oracle with flexible push/pull architecture
- Pyth Network – High-frequency financial market data
Oracles collect data from external providers, sign it, and deliver it to smart contracts. Blockchains verify signatures, not data correctness, meaning the system confirms “who sent the data, not whether the data is true.”
Systemic weaknesses
- If upstream data is wrong, the oracle publishes wrong data perfectly.
- Oracles cannot verify the authenticity of documents, reports, or valuations.
- Data providers can adjust numbers before submitting them, blockchain has no way to detect it. This leads to the classic failure mode: garbage in → garbage out.
- Oracles solve the transport layer but not the integrity layer.
Case Study 2: Proof-of-Reserve (PoR)
PoR was created to prove that custodied assets match reported reserves. Custodians create a snapshot of reserves, hash it into a Merkle tree, and allow users to verify their position.
However, PoR only validates the final dataset, not the source data, authenticity, or methodology. However, some of the mistakes when using PoR (this is the common application almost the DEX used it). A hash of a manipulated spreadsheet still produces a “valid” hash.
Most PoR audits are point-in-time, allowing temporary reserve reshuffling.
Liabilities are often excluded, meaning the system proves only half the picture.
No mechanism validates the truthfulness of bank statements or financial documents.
→ The Mazars–Binance case showed PoR’s structural limits: Mazars withdrew from crypto PoR entirely after acknowledging PoR cannot validate upstream data integrity.
Rollup Infrastructure Still Assumes Trusted Off-Chain Database
Despite major advancements in scalability and modular execution, Rollup-as-a-Service (RaaS) platforms such as Conduit, Caldera, and AltLayer continue to rely fundamentally on trusted off-chain databases for critical enterprise information.
These platforms provide the technical backbone, sequencers, state transition logic, indexers, RPC layers, data availability modules, but none of these components validate or verify the integrity of upstream off-chain inputs. For example:
- Conduit → https://www.conduit.xyz
- Caldera → https://www.caldera.xyz
- AltLayer → https://altlayer.io
This is not an oversight, it reflects the design boundaries of rollups. As Conduit explicitly states in its technical documentation:
“State proofs guarantee execution, but external data must be trusted unless verified cryptographically.” Source:https://docs.conduit.xyz/rollups/architecture/
In other words, rollups guarantee that what happens on-chain is correct, but they cannot guarantee that the off-chain data feeding the rollup is truthful. Even the most secure rollup inherits the weaknesses of the off-chain data pipelines required by enterprise applications. Whether it’s a KYC vendor producing unverifiable PDFs, an auditor generating valuation spreadsheets, or a custodian providing manually assembled reserve disclosures, the rollup must trust that the input itself is valid.
This reveals a deeper structural limitation of today’s modular blockchain ecosystem: while execution is cryptographically guaranteed, truthfulness at the data-ingestion layer remains entirely dependent on human processes, legal frameworks, and centralized databases. Until off-chain data becomes verifiable at the source, through cryptographic proofs, tamper-evident commitments, and provable policy enforcement, rollups will continue to operate on foundations vulnerable to manipulation, misreporting, and systemic trust failures.
→ When these inputs can be edited, fabricated, or selectively disclosed without leaving a mathematical trace, even the most secure blockchain infrastructure becomes exposed. Ultimately, the integrity of any on-chain system is bounded by the trustworthiness of the humans and institutions responsible for producing the data that feeds it.
Cryptographic Verifiability: Research Analysis and Critical Perspective
What Counts as “Verifiable Data”?
In the context of modern enterprise systems, verifiable data is not a buzzword but a shift in the trust model: every operation on a dataset, whether an insert, update, query, or access, must be accompanied by a mathematically provable guarantee of correctness, provenance, and authorization. The core idea is that data becomes not merely stored but cryptographically accountable.
This creates a fundamental departure from traditional attestations (“trust me, this is correct”) toward a model of computational proofs (“verify me, mathematically”).
What makes this shift noteworthy is the distinction between two independent assurance layers:
- Provenance assurance, proving where the data came from.
- Correctness assurance, proving how the data was processed and whether the operation followed required rules.
Different cryptographic primitives target each layer.
Merkle commitments and basic hash-based commitments excel at proving the existence and integrity of an inserted document or dataset. ZK-SNARKs and ZK-STARKs enforce correctness of transformations and updates, effectively a compliance layer encoded in math. Verifiable query systems, such as those explored by Axiom, introduce a powerful middle ground by allowing queries to be proven correct without exposing the underlying database.
Finally, ZK-based access control adds an authorization layer, proving not only that an operation is valid but also that the actor performing it is permitted to do so, without revealing the actor’s identity or sensitive attributes.
From a systems viewpoint, this represents a paradigm shift from “trust-but-verify” to “verify-by-default.” It reframes audit, compliance, and data management as cryptographically enforceable processes rather than procedure-driven ones.
For institutions operating in fraud-prone or regulation-heavy environments, this shift has extremely practical implications: internal audits no longer rely solely on procedural controls; regulators no longer depend exclusively on attestations; and data integrity can no longer be compromised silently by human operators.
Critical Thinking: Practicality, Cost, and Real-World Constraints
When mapping each operation (insert, update, query, access) to its respective cryptographic guarantee, one must also confront the practical trade-offs.
- Proof-of-presence (i.e., Merkle commits) is cheap and easy to deploy for evidence that a document existed at a specific time.
- Proof-of-Correctness via ZK-SNARK/ZK-STARK circuits is extremely strong but often computationally heavy and requires business logic to be fully expressed as arithmetic circuits, a nontrivial engineering challenge.
Verifiable queries reduce trust assumptions but still rely on the quality and correctness of the original commitments.
Thus, a fully verifiable system demands a hybrid approach, balancing:
the cost of generating proofs,the latency acceptable in enterprise workflows,the complexity of encoding real-world business logic into provable circuits, and the operational readiness of institutions adopting these mechanisms.
Research Lineage: The Foundations Behind Verifiable Data
The modern concept of verifiable data is the result of decades of research converging from cryptography, distributed systems, and enterprise security. Merkle trees, introduced by Ralph Merkle in 1979, remain the foundation for tamper-evident commitments.
The emergence of ZK-SNARKs, initiated by the Pinocchio protocol in 2013, made practical Zero-Knowledge verification feasible for real-world systems, while ZK-STARKs (Ben-Sasson et al., 2018) introduced transparency and post-quantum considerations.
Incremental Verifiable Computation (IVC), captured in works like the 2021 recursive-proof frameworks, provided the ability to stitch multiple proofs into a single, succinct guarantee, enabling historical verification at scale.
Even earlier, authenticated data structure research (e.g., Liskov et al., MIT) laid the groundwork for verifiable databases by exploring how to ensure that queries over untrusted servers remain trustworthy. Each of these contributions pushed the boundary of what can be proven cryptographically, not only what is stored but how it is manipulated and how it evolves over time.
It is important to emphasize that none of these technologies emerged with enterprise verifiability as their initial design target. Merkle commitments were created for authenticated file systems, not compliance pipelines. SNARKs were built for succinct arguments in secure computation, not regulatory audit trails. Yet the modern enterprise landscape, dominated by unverifiable PDFs, spreadsheets, mutable SQL logs, and permissioned databases, has inadvertently created the perfect environment for these cryptographic primitives to converge into a new class of systems: verifiable data infrastructure.
The convergence is not merely technical but socio-technical. Enterprises are increasingly pressured by regulators, auditors, and even AI-driven automation systems to produce data that is not just “reported” but provably correct, tamper-evident, and policy compliant. In environments where human-driven manipulation and opaque workflows generate systemic risk, the need for verifiable computation and verifiable data ingestion becomes foundational, not optional.
Regulatory & Legal Implications of Verifiable Data
As regulators move from ex-post inspections toward continuous supervision, the legal landscape for digital assets and corporate reporting is changing from permissive attestations to requirements that increasingly imply verifiability, traceability and privacy-preserving disclosure.
The EU’s Markets in Crypto-Assets Regulation (MiCA), for example, formalizes expectations for reserve transparency and operational resilience for stablecoin issuers, creating a legal appetite for provable reserve reporting rather than ad-hoc PDF attestations.
Similarly, the FATF’s Travel Rule and subsequent guidance explicitly require verifiable provenance for virtual-asset flows and identity claims, pressuring Virtual Asset Service Providers to adopt tamper-evident evidence chains.
These regulatory shifts create a strong incentive for enterprises and their vendors to adopt cryptographic proofs as admissible evidence in regulatory workflows.
Against this regulatory backdrop, several Web3 projects and technologies have emerged that can realistically support , to varying degrees, the legal needs of auditors, supervisors and enterprise compliance teams.
The following discussion treats each project as a technical primitive in a larger Verifiable Data Infrastructure, it evaluates what the project supplies, how that capability maps to regulatory needs, and where gaps remain from both a technical and an enterprise operations perspective.
Orochi Network’s zkDatabase targets the core problem regulators are increasingly concerned with: proving the authenticity and lifecycle of off-chain records without exposing sensitive contents. zkDatabase documents its goal of combining NoSQL-style data models with ZK proofs to generate commitments at ingest and to produce proofs for updates and queries, which directly map to regulatory requirements for tamper-proof audit trails, controlled disclosure and verifiable lifecycles.
From an institutional perspective this capability is compelling: a regulator can be given a succinct proof that certain accounting entries existed, were computed under specific rules, and were not retroactively altered, while the firm retains confidentiality of underlying documents.
Technically, however, the strength of the guarantee depends on the security of the ingestion boundary (how the data is signed and who attests the original source), proof-generation cadence (real-time vs batched), and the legal acceptance of proof artifacts as audit evidence. The project’s documentation and developer guides lay out the primitives (commitments, ZK-backed operations) that make these guarantees possible.
Projects that verify computation and queries are also essential components of any regulator-friendly stack. Axiom demonstrates how query results over on-chain state can be cryptographically attested; its proving API and V2 contracts show that a verifier need not trust a node operator to accept a query result. For enterprises, Axiom’s approach addresses the regulator’s need to validate assertions about chain state and historical events without having to process raw node data, reducing audit friction.
The limitation for compliance is straightforward: Axiom proves that a query was computed correctly against a given dataset, but it does not itself prove that off-chain inputs used to construct that dataset were authentic. Therefore, in regulatory terms Axiom is a powerful read verifier but not a complete ingestion solution.
Succinct and similar prover-networks / prover marketplaces aim to make proof generation inexpensive and highly available. Succinct’s emphasis on a decentralized prover network and tooling (SP1, Prover Network) reduces one of the main enterprise barriers to ZK adoption , operational cost and developer friction. For auditors and compliance teams this matters: proofs that would once have been cost-prohibitive are now feasible to produce on a schedule that aligns with reporting windows.
Nevertheless, from a legal evidence perspective, using Succinct requires careful process integration: enterprises must demonstrate that the inputs to provers are properly authenticated and that the prover infrastructure itself maintains non-repudiable provenance of the proof generation process. In other words, Succinct addresses how to prove, but enterprises must still prove what was proven and who attested the inputs.
General-purpose zkVMs such as Risc Zero enable complex business logic, risk models, AML scoring, credit underwriting , to be executed and proven.
This is particularly relevant to regulators who need proof that internal models behaved as claimed at a given time. Risc Zero’s ongoing work on formal verification and performance improvements reduces barriers to adopting provable execution. From an enterprise architecture viewpoint, zkVMs let teams encapsulate legacy processes into provable units, which can help satisfy documentation lifecycle requirements under SOX or SEC rules.
The open question, again, is ingestion authenticity: a provable execution is only as reliable as its inputs, and enterprises must implement cryptographic anchoring or attestation flows at the edges of their systems to remove that trust assumption.
Oracles such as RedStone and Chainlink remain central because regulators and enterprises still require reliable feeds (prices, indices, attestations) to drive on-chain activity. RedStone has advanced modular delivery and low-latency feed models that reduce some operational risk for DeFi applications; Chainlink provides broad market adoption and tooling for price and PoR aggregation. Yet both types of oracle systems fundamentally provide transport and aggregation guarantees, not absolute source verification.
The FTX and subsequent PoR controversies , and Mazars’ pause on exchange PoR attestations , illustrate that hashed or signed attachments do not solve the underlying legal problem if the original documents or liability disclosures are incomplete or manipulated. For legal acceptance, oracles need to be combined with upstream ingestion proofs and custodial attestations that are cryptographically anchored.
Rollup infrastructure providers (Conduit, Caldera, AltLayer) illustrate another dimension of the legal-technical tradeoff. These RaaS platforms secure execution and can be configured for different fraud or validity models, but their documentation is explicit: state proofs guarantee execution, but they do not prove that external data inputs are truthful. Rollup security therefore answers the question “did the code run correctly?” but not “was the data fed into the code correct?”
For a regulator concerned with solvency, audited reserves, or AML compliance, that remaining gap is legally meaningful: an on-chain state root consistent with a rollup proof can still reflect incorrect accounting if upstream reserve data was manipulated before commitment. Hence rollups and RaaS accelerate adoption but concurrently increase the urgency for verifiable ingestion layers.
When we examine these projects from the institutional operational lens, a pattern emerges. Regulators require three things from evidence in practice:
(1) integrity (tamper evidence)
(2) provenance (who/when/where)
(3) a defensible chain of custody that stands up in audit and legal review.
To meet these expectations in a Web3 context, enterprises must combine: cryptographic ingestion commitments (anchored by systems like zkDatabase), provable computation (zkVMs like Risc Zero or proof services like Succinct), and verifiable query/delivery layers (Axiom, RedStone), all integrated with institutional identity and key management that satisfies KYC/FATF requirements.
Piecemeal adoption of any one technology reduces a single point of risk; only an orchestrated stack produces the holistic evidentiary trail regulators seek. Relevant research papers and rollup/zk literature underscore this integration requirement as the natural next step for modular stacks.
A legal implication to emphasize is admissibility and standardization. Today’s laws (SOX, SEC rules, MiCA, FATF recommendations) do not universally mandate cryptographic proofs as the exclusive form of evidence, but they increasingly require demonstrable, auditable trails that cryptography can produce more reliably than human processes.
That gap creates a practical path for regulators and industry bodies to define standards that accept ZK-Proofs and commitments as primary evidence for certain classes of compliance assertions (for example, reserve sufficiency, non-exposure of client funds, correct application of AML screening rules).
The EU and FATF workstreams already highlight how regulators are comfortable with machine-readable, rule-based evidence; the technical community must now translate that into legally interoperable proof formats and retention policies. Relevant regulatory sources (MiCA texts, FATF Travel Rule guidance) and supervisory good-practice documents confirm that regulators are moving in this direction, which strengthens the business case for Verifiable Data Infrastructure.
Finally, from a risk management perspective, enterprises should treat Verifiable Data Infrastructure as a form of “regulatory insurance.”
The economics are straightforward: the incremental cost of proof generation and secure ingestion is traded against reduced litigation risk, lower audit overhead, faster regulatory responses, and, to the extent the market values provable transparency, reputational gains.
Axiom and RedStone reduce verification overhead for auditors and on-chain consumers; rollup platforms provide scale. But no single project solves governance, key custody, legal chain-of-custody, or international evidence handling.
Those are organizational problems that require legal, technical, and operational co-design between vendors and regulated institutions. If a visualization is useful for regulators or board members, an architecture diagram showing how ingestion commitments (commit), ZKP generation (prove), on-chain commitments (anchor), and auditor verification (verify) map to compliance goals often clarifies the legal claim being made.
For a practical starting point, Orochi’s zkDatabase documentation offers an architectural sketch of those layers that can be adapted to a compliance flowchart used in legal reviews or regulator briefings.
FAQs
Question 1: Why do institutions still rely on unverifiable data like PDFs and spreadsheets?
Because legacy systems, reporting workflows, and regulations still accept these formats. They are easy to use but offer no data integrity or provenance, creating major risks despite their widespread adoption.
Question 2: What makes off-chain data the biggest weakness in RWA and Web3 systems?
Blockchains verify on-chain state, but most critical RWA data stays off-chain, where it can be altered or falsified. This gap leads to failures like FTX and Maple—caused not by blockchain flaws, but by unverifiable upstream data.
Question 3: How does Verifiable Data Infrastructure fix the trust gap?
It adds cryptographic guarantees to every data operation. Systems like zkDatabase generate proofs for inserts, updates, and queries, ensuring data is authentic, tamper-evident, and compliant without exposing sensitive details.
Experience verifiable data in action - Join the zkDatabase live demo!
Book a Demo
