Stablecoin
Re-Runnable Proof of Reserves: The Lesson From the msUSD Depeg
July 15, 2026
8 mins read
The msUSD depeg showed what happens when a reserve proof can only be re-run by one vendor. Re-runnable proof of reserves is the property that removes that single point of failure.
TL;DR: Re-runnable proof of reserves means a token's backing proof can be independently re-verified by any party, not only the vendor that generated it. In June 2026 msUSD lost its peg after its reserve-verification provider ended the relationship, leaving holders unable to check the backing themselves. Public proof bytes, verification key, and verifier remove that single point of failure.
Reserve verification sounds like an implementation detail until the only party able to re-run it walks away, which is exactly the gap re-runnable proof of reserves closes. This article explains what the msUSD episode exposed and where zkDatabase fits as a supplementary layer that keeps the check open.
Key Takeaways:
- Re-runnable proof of reserves is a reserve proof any counterparty can independently verify, using published proof data and an open verifier, without trusting the party that generated it.
- The June 2026 msUSD depeg followed the exit of the token's reserve-verification provider; with the check tied to one vendor, holders had no independent way to confirm backing.
- A proof is only independently verifiable if the proof bytes, verification key, public inputs, and a matching verifier are all public, otherwise "verified" collapses back to trusting a dashboard.
- zkDatabase generates a reserve proof over committed data that anyone can re-run, as a supplementary layer alongside attestation, not a guarantee that the underlying assets are real.
What is re-runnable proof of reserves?
Re-runnable proof of reserves is a reserve proof designed so any party, a holder, a lending protocol, an auditor, can re-verify it themselves from published data, instead of relying on the vendor that produced it to confirm it is valid. The word doing the work is independent. A reserve dashboard showing a green "verified" mark is only as trustworthy as the server drawing it; a proof you can re-run is trustworthy because you checked it.
That difference is invisible when everything is working and decisive when it is not. A holder glancing at a passing reserve check cannot tell, from the badge alone, whether the proof behind it is something an outside party could reconstruct, or something only the vendor's own infrastructure can validate. The two look identical right up until the vendor stops publishing.
Terms that recur across this topic: Merkle root, verification key, public inputs, open-source verifier, attestation, and solvency proof. Each maps to whether a given reserve proof can actually be re-run by someone other than its author, which is the only test that matters here.
What did the msUSD depeg reveal about reserve verification?
In June 2026 the msUSD stablecoin lost its dollar peg after the third-party provider running its reserve verification ended the relationship; the token fell from around $1 to about $0.29, and the two sides publicly disagreed over whether the backing was ever the problem. As reported by crypto.news and The Block, the issuer maintained the reserves were intact and blamed the verification feed, while the provider said the protocol had failed its verification standards. From the outside, that dispute is exactly the point: no one holding the token could settle it independently.
The damage did not stop at one token. Reporting noted extreme illiquidity on a connected lending market, and a separate vault of roughly $39 million that relied on the same verification provider wound down even though it had no msUSD exposure. When verification is concentrated in one vendor, that vendor becomes a shared dependency across everything it touches, so its exit propagates outward.
Strip away the specifics and the structural lesson is plain. The reserve check was not re-runnable by holders. It lived with a single provider, and when that provider went dark, the market had nothing left to verify against and priced in the uncertainty within a day. Whether the assets existed became almost secondary, because no independent party could check either way.
Why isn't a "verified" badge the same as a verifiable proof?
A "verified" badge asserts that some proof validated against some key on some server; a verifiable proof lets you supply the inputs and confirm the result yourself, and the gap between those two is where the msUSD-style risk lives. A cryptographic proof is only meaningful if an independent party can re-run the check, and re-running requires specific artifacts to be public.
To re-verify a Groth16-style reserve proof at the pass or fail level, a checker needs the proof bytes, the verification key, the public inputs with a clear schema, a verifier that matches the exact proof system, and the statement being proven, so "verified" means "reserves satisfy the stated condition" rather than "a proof validated against a key." When any of those is missing, the badge is a claim, not a check.
| Property | Vendor-validated proof | Re-runnable proof |
|---|---|---|
| Who can verify | The vendor's own server | Any party with the published artifacts |
| Proof bytes | May be shown | Published |
| Verification key + public inputs | Often withheld | Published with a clear schema |
| Verifier | Hosted, closed | Open, matches the proof system |
| Failure mode | Vendor exits, check goes dark | Check survives the vendor |
| Trust basis | Trust the dashboard | Re-run the math |
The msUSD case sat on the left column. A reserve proof on the right column does not depend on any one provider staying online, because the artifacts needed to check it are already in the open.
How does re-runnable verification change the failure mode?
Making a reserve proof independently re-runnable does not make a token safe on its own, but it removes one specific and avoidable failure: the market going blind the moment a single verification vendor stops publishing. That is a narrower claim than "cryptography prevents depegs," and it is the honest one.
Independent re-verification changes who holds the off switch. When the proof bytes, verification key, and an open verifier are public, a holder or a lending protocol can regenerate the check against committed reserve data at will, so no single provider's withdrawal can leave them unable to look. The vendor can still exit; the verification does not exit with it.
What re-runnable verification does not do is vouch that the underlying assets are real. If reserve data is misreported at the source, a proof will faithfully verify a computation over bad inputs. This is why the durable posture is layered: attestation and audit remain the baseline for asset existence, and independent re-verification sits on top to keep the backing claim continuously checkable by parties who are not the issuer.
Bottom line: re-runnable verification is not a solvency guarantee. It is the difference between a market that can keep checking and a market that is one vendor's decision away from the dark.
Where does zkDatabase fit?
zkDatabase generates a reserve proof over committed data using a Merkle tree combined with Zero-Knowledge Proofs, published so any counterparty can re-run the verification independently, as a supplementary on-chain layer alongside an issuer's existing attestation rather than a replacement for it. It is the same construction that exchange proof-of-reserves systems already run in production, generalized into a continuous database layer instead of a one-off snapshot circuit.
The role is deliberately narrow. zkDatabase does not certify a company's books or confirm that the assets behind a token exist; that remains the work of the auditor and the custodian. What it provides is independent re-verification (Merkle trees plus Zero-Knowledge Proofs): a proof of the reserve computation whose artifacts are public, so a holder, a protocol, or a regulator can check it without waiting on, or trusting, a single vendor's live dashboard. For how that compares to oracle-fed reporting, see our piece on proof of reserves for stablecoins, and for the accounting side, how cryptographic proof supports attestation.
Explore zkDatabase
See how zkDatabase produces a reserve proof any counterparty can re-run, without exposing the balances behind it.
FAQ
What is re-runnable proof of reserves?
Re-runnable proof of reserves is a reserve proof any party can independently re-verify from published data, rather than one only its issuer or vendor can validate. It requires the proof bytes, verification key, public inputs, and a matching open verifier to be public. That openness is what lets a holder or protocol re-check backing without trusting a single provider's dashboard.
What happened with the msUSD depeg in 2026?
In June 2026 the msUSD stablecoin lost its dollar peg after the third-party provider handling its reserve verification ended the relationship, with the token falling from about $1 to roughly $0.29. The issuer and the provider disagreed publicly over the cause. Because the reserve check was tied to that one vendor, holders had no independent way to confirm the backing.
Does independent re-verification prevent stablecoin depegs?
No. Independent re-verification removes one specific failure, the market losing visibility when a single verification vendor stops publishing, but it does not guarantee solvency. A proof verifies a computation over reported data; if the underlying reserve data is wrong, the proof still validates. Attestation and audit remain the baseline, with re-runnable verification layered on top.
Does zkDatabase guarantee a token's reserves are real?
No. zkDatabase makes a reserve computation independently re-verifiable by generating a proof over committed data that anyone can re-run. It does not confirm the underlying assets exist or replace an issuer's auditor. Its role is supplementary: keep the backing claim checkable by parties other than the issuer, so verification does not depend on one vendor staying online.
Related toStablecoin
