• Pricings

  • Stablecoin

    Stablecoin Depeg: What Causes It and How Reserves Are Verified

    July 28, 2026

    9 mins read

    A stablecoin depeg happens when a token drifts from its target price. The causes fall into a few repeatable patterns, and each one maps to a different gap in how reserves are verified.

    TL;DR: A stablecoin depeg occurs when a stablecoin trades meaningfully away from its target value, usually one dollar. The causes fall into repeatable patterns: insufficient or low-quality collateral, reserve concentration and banking access, algorithmic reflexivity, liquidity panic, and verification opacity. Reserve verification reduces some of these risks but not all; zkDatabase adds a re-runnable reserve proof as a supplementary layer.
    When one token slips off its target, the damage rarely stops there, because stablecoins are the settlement asset underneath most of on-chain finance. That is what makes a stablecoin depeg a systemic event rather than a local one, and the causes are not random; they cluster into a few structural patterns. zkDatabase's role is limited but specific: it makes reserve data continuously checkable by any party, so one class of depeg, the kind driven by opaque or unverifiable backing, is harder to hide. The rest still require honest assets and sound design.
    Key Takeaways:
    • A stablecoin depeg is a token trading away from its target price, and its causes cluster into five repeatable patterns rather than one.
    • The patterns are insufficient collateral, reserve concentration and banking access, algorithmic reflexivity, liquidity panic, and verification opacity.
    • The 2023 USDC event was an access failure with sound assets; the 2022 algorithmic collapse was a design failure; the 2026 msUSD depeg was a verification failure.
    • Reserve verification catches some patterns and not others: it exposes missing backing but cannot fix a broken peg mechanism.
    • zkDatabase makes reserve data re-runnable by any party as a supplementary layer, and does not guarantee a peg or replace an auditor.

    What is a stablecoin depeg and what causes it?

    A stablecoin depeg is a sustained or sharp deviation of a stablecoin from its target price, and its causes fall into five patterns: insufficient collateral, reserve concentration, algorithmic reflexivity, liquidity panic, and verification opacity. Most real depegs are a combination, but one pattern usually leads.
    A brief drift of a fraction of a cent is normal market noise. A depeg is when the deviation is large enough or long enough that holders stop treating the token as worth its target, which can become self-reinforcing as redemptions accelerate. The reason it is worth naming the cause is that each pattern maps to a different defense, and reserve verification only addresses some of them.
    Cause patternWhat goes wrongIllustrative caseDoes reserve verification help
    Insufficient or low-quality collateralBacking is short or held in risky assetsUnder-collateralized designsYes, it exposes the shortfall
    Reserve concentration / accessAssets are sound but trapped or illiquidUSDC at SVB, 2023Partly, it shows where reserves sit
    Algorithmic reflexivityPeg depends on a token that can collapseAlgorithmic dollar, 2022No, the mechanism is the flaw
    Liquidity panicThin pools amplify a sell-offMultiple minor depegsNo, this is market depth
    Verification opacityNo one can independently check backingmsUSD, 2026Yes, this is the direct fix
    The table is also a diagnostic: read the failure, name the pattern, and you know whether better verification was ever going to be the answer.
    2026-07-10-stablecoin-depeg-causes-reserve-verification-body.png
    The five depeg patterns and which ones reserve verification actually catches.

    The major depegs each failed on a different axis

    The three most instructive depegs each failed on a different axis, which is why treating them as one story leads to the wrong defense. One had good assets it could not reach, one had a mechanism that could not hold, and one had backing no outsider could verify. Naming the axis is the lesson.
    USDC in March 2023 is the access case. Around $3.3 billion of otherwise-sound reserves were briefly trapped at a failed bank, the token fell to roughly $0.87, and it recovered above $0.99 within about two days once a backstop restored access, per S&P Global. The assets were real; the problem was where they sat. The 2022 algorithmic collapse is the design case: the peg relied on a paired token, confidence broke, and a reflexive redemption loop erased more than $40 billion in days. Verification could not have saved a mechanism that was structurally fragile. The 2026 msUSD depeg is the verification case, where the token dropped from about one dollar to roughly $0.29 after its reserve-verification provider exited and holders were left with no independent way to check backing, detailed in the msUSD depeg and re-runnable proof of reserves.

    How does reserve verification reduce depeg risk, and where does it stop?

    Reserve verification reduces the depeg patterns rooted in the asset ledger (insufficient backing and verification opacity) by making reserves visible and checkable. It does nothing for the patterns rooted in mechanism design or market liquidity. Verification is a strong defense against the right failure and irrelevant to the wrong one.
    There is a ladder of verification strength. A self-reported dashboard is the weakest rung. A periodic attestation by an accounting firm is stronger, confirming reserves at a point in time. Continuous cryptographic proof is stronger again, because it lets any party re-check backing between attestations rather than waiting for the next report. Issuers also reduce concentration risk operationally by diversifying custody, as Circle did after 2023 by moving reserves toward a major custodian, a regulated money-market fund, and short-dated Treasuries. What none of these rungs can do is repair a peg that depends on a collapsing token, or manufacture liquidity in a thin market during a panic. For the mechanics of what these proofs actually establish, see what proof of reserves is.
    Verification is the answer to "is the backing real and checkable," not to "is the peg mechanism sound."

    The assets-versus-liabilities distinction decides what a depeg check catches

    A reserve check that only reads the asset side can miss the failure that matters most, over-issuance, because solvency depends on assets covering the full set of claims, not just assets existing. A large reserve wallet is not the same as enough reserves.
    This is why proving backing and proving solvency are different tasks. An issuer can show a reserve balance and still be short if it has issued more claims than that balance covers, which an asset-only proof will not reveal. The stronger form commits both sides of the ledger and proves assets are greater than or equal to liabilities, a construction covered in proof of reserves solvency: why assets alone do not prove it. Oracle-reported reserve figures compound the gap, because a pushed value is only as good as the off-chain calculation behind it, a limit examined in proof of reserves for stablecoins: oracle feeds versus cryptographic proof.

    Where zkDatabase fits in reducing depeg risk

    zkDatabase generates a reserve proof over committed data that any party can re-run, so the backing behind a stablecoin stays continuously checkable rather than dependent on a single vendor or a quarterly report. It is a supplementary layer, not a peg guarantee. It targets exactly one depeg pattern: verification opacity.
    The database commits to reserve data and produces a Zero-Knowledge Proof that a stated condition holds, publishing the proof so a holder, protocol, or regulator can verify it independently without seeing individual balances. Because the artifacts are public, the check survives even if the issuer's own dashboard goes offline, the failure at the center of the msUSD case. What zkDatabase does not do is confirm the assets are genuine, guarantee liquidity, or fix a fragile peg mechanism. Its contribution is to remove the excuse that no one could tell, so a market is never one vendor's exit away from flying blind. For yield-bearing designs where obligations shift, the same principle applies to the harder liability side, discussed in the yield-bearing stablecoin dual-mandate trap.
    Explore zkDatabase See how zkDatabase keeps a stablecoin's reserve proof re-runnable by any party, without exposing the balances behind it.

    FAQ

    What is a stablecoin depeg?

    A stablecoin depeg is when a stablecoin trades meaningfully away from its target price, usually one dollar, for long enough that holders stop treating it as worth the target. Small deviations of a fraction of a cent are normal market noise. A true depeg is larger or more sustained, and it can become self-reinforcing as holders redeem or sell, deepening the gap.

    What are the main causes of a stablecoin depeg?

    Stablecoin depegs cluster into five patterns: insufficient or low-quality collateral, reserve concentration and banking-access problems, algorithmic reflexivity where the peg depends on a collapsible token, liquidity panic in thin markets, and verification opacity where no one can independently check the backing. Most real events combine several, but one pattern usually leads and determines the right defense.

    Can reserve verification prevent a stablecoin depeg?

    Reserve verification reduces some depeg risks but cannot prevent all of them. It exposes missing or misplaced backing and removes verification opacity, so a market can keep checking reserves continuously. It does nothing for a broken peg mechanism, such as an algorithmic design that unwinds, or for a liquidity panic in shallow markets. Verification answers whether backing is real and checkable, not whether the peg design is sound.

    Does zkDatabase guarantee a stablecoin will hold its peg?

    No. zkDatabase makes reserve data re-runnable by any party, targeting the depeg pattern caused by opaque or unverifiable backing. It generates a Zero-Knowledge Proof over committed reserve data that a holder or protocol can verify independently. It does not confirm the assets are genuine, guarantee liquidity, or repair a fragile peg mechanism, and it does not replace an issuer's auditor.