Introducing DIA ZK: Verifiable Offchain Data, Proven Onchain
Yield-bearing stablecoins, tokenized treasuries, and vaults built on offchain strategies together account for tens of billions of dollars of onchain value, and the figure keeps climbing as capital chases returns that originate in CeFi and traditional markets. Every one of those tokens inherits the same structural gap: it trades onchain while the strategy that backs it sits somewhere a smart contract cannot read.
The proof an issuer can't produce
This new paradigm puts asset issuers in a difficult position as the token holders, the risk curator sizing an allocation, and the lending market deciding whether to list it, all want to know the backing is real. The reality is none of them can see the custody balance, the exchange positions, or the loan book. So they ask for proof of it, and the usual answers are increasingly insufficient.
The demand for proof contains three separate questions, and most current setups answer only the first.
- Did the number come from the source it claims?
- Was it changed on the way onchain?
- And can the issuer prove the fact that actually matters, that reserves cover supply, without publishing the positions it would rather keep private?
June this year showed what the open questions cost. A popular yield-bearing stablecoin lost its peg after the third-party service that verified its reserves ended its relationship. A lending market built around the token was left with roughly $18 million of affected collateral, and a separate vault with no direct exposure to the token was hit too, because both relied on the same verifier.
DIA ZK: proof bound to the source
Today, we are excited to launch a new product to address this.
DIA ZK is a verifiable data assurance layer for DeFi, RWAs, and cross-chain applications. It is a proof layer for offchain data that sits on top of the verifiable and trustless oracle stack DIA already runs, where feeds come directly from the original venues and every computation is published onchain, and it makes the output verifiable onchain, in two ways.
Source authenticity: Prove where the value came from
Using zkTLS, a proof is generated inside the encrypted session with the source, a custodian API or a fund administrator endpoint, binding the reported value to that session. Where a source signs its data, a signed attestation carries the same guarantee; where speed matters, a trusted execution environment assists. A consumer contract can check that the balance or the NAV came from the stated source, unaltered.
| Method | How it works | Best when |
|---|---|---|
| zkTLS | A proof is generated inside the encrypted HTTPS session with the source | The source is a standard web or API endpoint |
| TEE-assisted zkTLS | A trusted execution environment assists the proving step | Faster proving or production simplicity matters |
| Signed attestations | The source’s own cryptographic signature is verified | The source already signs its data |
Selective disclosure: Prove the fact without the figure
The number an issuer wants to keep private is usually not the number the market needs. A curator does not need the exact reserve balance; it needs to know reserves exceed supply. A lending market cares whether the collateral ratio holds, not what sits in the portfolio behind it. DIA ZK proves the statement rather than the value: it generates a zero-knowledge proof that the condition is true, verifiable onchain by anyone, while the underlying figure stays private.
Because those proofs are verified on DIA’s own onchain oracle layer, no single vendor can switch the feed off.
| Instead of revealing | Prove only that |
|---|---|
| The exact reserve balance | Reserves exceed supply or a set threshold |
| The full collateral portfolio | The collateral ratio clears its minimum |
| The treasury balance | It sits above the required covenant |
| Exact TVL or liquidity | It stays above a floor |
What a proof does not do
A proof binds a value to its source, but it does not make the source honest. If a custodian’s API reports a balance it does not hold, zkTLS will prove a wrong number faithfully. For fully offchain reserves, trust in the source remains, and DIA is explicit about where that line sits. What changes is that the report becomes cryptographically bound to its source and checkable onchain, which a dashboard and a monthly PDF are not.
From Stablecoins to Derivatives
The first fit is where backing is offchain and opaque. The same proofs extend to any offchain figure a contract has to trust, from the reserves behind a wrapped Bitcoin to the reference price a derivatives market settles on:
- Stablecoins and synthetic dollars. Prove reserves cover supply and collateral values hold, from custodian and issuer data, without publishing the exact holdings or where they sit.
- Vaults and lending. Prove the offchain collateral behind a vault token and that its risk parameters hold, so a lending market can check liquidation readiness against authenticated values instead of a self-reported number.
- Tokenized RWAs. Prove NAV inputs, asset-administrator data, and proof-of-backing for a tokenized fund, each bound to the source that produced it.
- Bitcoin DeFi. Prove that a wrapped or synthetic Bitcoin product is fully backed, with source-authenticated reserve and threshold proofs.
- Perps and derivatives. Feed authenticated price and reference-index inputs into settlement, funding, and liquidation, each bound to its source.
Why this is landing now
The rules are catching up to the risk. In the EU, MiCA has governed stablecoin reserves since mid-2024: issuers must hold matching reserves, reconcile them daily, submit to periodic auditor attestation, and report to regulators, with penalties reaching up to €5 million or 12.5% of annual turnover. In the US, the GENIUS Act will introduce federal reserve and disclosure requirements for qualifying stablecoin issuers. Both turn “prove your backing” from a market courtesy into a standing obligation, and a point-in-time attestation is not built to meet a continuous one.
The assets that earn the most are the ones whose backing is hardest to see. Proving that backing, continuously and onchain, without forcing the issuer to open its book, is the next thing the oracle layer has to do.
If your protocol holds stablecoin reserves, tokenized fund NAVs, or vault collateral offchain, it is where to start.
