What is the worst scenario imaginable when creating a new currency?

One answer stands out: the ability to mint unlimited supply without authorization. That single flaw would destroy any currency overnight.

Bitcoin had two separate inflation bugs that let anyone create BTC far beyond the 21 million cap. In June 2026, Zcash disclosed the Orchard bug, an inflation-risk vulnerability in its zero-knowledge proof layer. ZEC dropped roughly 50% on the news, even though no exploitation was confirmed.

These bugs are not ancient history. They are an active, evolving threat.

What is an Inflation Bug?

An inflation bug is a code vulnerability that allows the unintended generation of currency, typically only on platforms that use smart contracts (autonomous programs).

In blockchain computer science, it refers to any means of manipulating the token supply. Inflation bugs can still occur with secure, flawless code.

Whenever you hear that a platform got hacked but no one lost tokens, it’s likely an inflation bug.

That’s because the “loss” comes from creating tokens against the rules or out of thin air, then selling them, and leaving holders with a worthless project.

Depending on the project size, the token price could lose 90% overnight.

If unsolved, the inflation bug can drain all the funds ever deposited into the protocol.

That’s why it’s also called the infinite-minting bug. Both terms are essentially the same, although inflation bugs are broader and not limited to token generation.

Developers frequently request audits from agencies like Certik to look for inflation bugs and others. Here are a few common mistakes:

Inflation Bug Types: Three Distinct Attack Classes

Not every inflation bug works the same way. Security researchers now group them into three classes, each with a different attack surface and mitigation path.

Infinite Mint. The attacker calls a minting function directly or through an unguarded pathway, producing tokens without any corresponding collateral or burn event. The MonoX hack in 2021 and the BNB Bridge exploit in 2022 both fall here.
Invalid Coinbase or UTXO Manipulation. The bug lives in transaction validation logic. Bitcoin's 2010 integer overflow bug created 184 billion BTC because the code checking transaction values broke above a certain threshold. The 2018 Bitcoin Core bug allowed miners to call already-spent outputs as valid.
False-State Acceptance in Zero-Knowledge Proofs. This is the newest and fastest-growing class. In zk-SNARK and zk-STARK systems, a prover submits a cryptographic proof that a transaction is valid without revealing the underlying data. If the verifier circuit has a flaw, it may accept an invalid proof, effectively treating counterfeit coins as legitimate. The June 2026 Zcash Orchard bug belonged to this class.

Why does the taxonomy matter? Each class requires a different audit approach. Infinite-mint bugs are caught by access-control review. UTXO bugs require arithmetic boundary testing. ZK false-state bugs require formal verification of the proof circuit itself, a significantly harder and more expensive process.

Blockchain Protocol-Level Attack Classes: How They Work and How to Mitigate Them

👉 Quick takeaway: Infinite mint attacks are the most documented and costly class, with the BNB Bridge losing $570M in 2022. Arithmetic bugs can affect even battle-tested chains — Bitcoin itself had a 184 billion BTC overflow in 2010. ZK false-state acceptance is the hardest to detect and requires formal circuit verification, not just a standard code audit.

Attack Class	How It Works	Detection Difficulty	Real Example	Primary Mitigation
Infinite Mint	Minting function called without authorization or collateral	⚠️ Medium Visible in on-chain supply data	BNB Bridge 2022 🔴 ~$570M lost	Access control, multi-sig on mint functions
UTXO / Arithmetic Bug	Transaction validation breaks at extreme numeric values	⚠️ Medium Requires boundary-case testing	Bitcoin integer overflow 2010 🔴 184 billion BTC created	Arithmetic boundary testing, formal code review
ZK False-State Acceptance	Verifier circuit accepts invalid cryptographic proof	🔴 High Transaction data is hidden by design 🔴 Hardest to detect of the three classes	Zcash Orchard bug 2026 ⚠️ No confirmed exploit	Formal verification of ZK circuit ⚠️ Standard code audit is not sufficient

How Does An Inflation Bug Happen

There are many variables that, when changed to unintended values, can cause inflation bugs.

It’s not as simple as a Generate token button. It has more to do with unintended functionality than actual coding errors.

If you manipulate the token price, you could indirectly manipulate the supply (especially on bridges, liquidity pools, and algorithmic stablecoins).
If there’s a bug in the burning mechanism (not enough supply reduction), the gradual inflation will eventually push down the price.
If the project has pre-minted all tokens but locked them away from circulation, an exploit that unlocks those coins would also cause inflation.
If a project or its bridge is very centralized, a cyber-attacker could potentially force fraudulent transactions into the blockchain to unbalance the price or supply.
If there’s no maximum supply, whatever inflation bug appears might potentially send the project to $0.
If developers don’t test all functions, including impractical ones, users can loop them to inflate prices and drain the platform’s funds.

In the (MonoX Protocol) example, an “attacker” deposited the same token for both pairs of the liquidity pool, causing the second token to update to a higher price.

The attacker then kept adding 55 times to further inflate his token quantity and the end sell for other platform assets and leave.

All because developers assumed there was no reason for anyone to swap equal tokens.

Implications of Inflation Bugs

What’s the worst that can happen? If it’s stopped on time, developers can always burn the equivalent amount to mitigate the losses. The problems get worse when the token has no deposit limits or maximum supply.

From most to least obvious, the bug can:

Devalue the cryptocurrency too quickly for investors to react to the losses. Even lose 99% of the price.
Drain the liquidity of the platform. If you locked this token for liquidity pools, staking, or others, these can no longer guarantee the return of your initial amount. Or at least not fast enough to avoid further price drops.
Overwhelm the network. Depending on the total-value-locked (TVL), the bug can increase transaction costs, not only from panic-sellers but possibly urge investors to sell other coins. Maybe you have to hold to the bottom because the fees are too high.
De-peg stablecoins. Unless it’s an algorithmic stablecoin, the bug would allow printing money without backing. If it doesn’t lose the dollar peg first, it will drain whatever collateral is backing it and prevent holders from redeeming.
Lose investor confidence. Confidence is critical for stablecoins and blue-chip cryptocurrencies because so many altcoins depend on them. But inflation bugs leave projects a slim chance of recovering prices, TVL, or active users— even if the new version is secure.

The Terra/LUNA collapse in May 2022 is covered in detail in the Examples section below.

Inflation Bug Examples

Inflation bugs are about as old as Bitcoin, but not because of that they’re less common today. Here are some infamous examples, some of which caused projects to shut down:

Bitcoin (BTC)

While at times Bitcoin may seem like the unbreakable cryptocurrency, it was at risk of vanishing twice: in 2010 and 2018. And who knows, maybe still to this day.

It’s not unexpected to hear of vulnerabilities in the 2010s. Neither Bitcoin or Ethereum started perfectly and had to upgrade continuously.

The case of August 2010 was a short-lived bug based on a numeric error called “integer overflow,” and it created 184 Billion Bitcoins.

Basically the code for checking transactions didn’t work if the values were too high.

It was so bad that Satoshi Nakamoto himself had to create a patched new version, also removing the 184B block and all that followed.

If that sounds outrageous, the second inflation bug enabled unlimited Bitcoins!

It was discovered by Bitcoin Core developer Matt Corallo on a crash report shared by Greg Maxwell on September 17th, 2018.

The cause of the inflation is called: multiple unspent transaction outputs (UTXOs), allowing miners to theoretically bypass the 21M limit by calling already-spent Bitcoins.

By then, the Bitcoin price was around $6,000. Given the gravity, developers kept it a secret for two years until they were certain that it was no longer a risk.

In the meantime, they corrected the bug on the next Bitcoin Core version and urged as many miners as possible to update.

Terra USD (UST) and Luna (now LUNC)

Terra UST was an algorithmic stablecoin (no backing) programmed to balance the supply and dollar peg based on a second token: Luna.

For example, if there’s a lot of demand for UST, the protocol mints more tokens by first locking Luna. It creates arbitrage opportunities on both sides (above and below $1 UST) to keep balance.

In May 2022, however, this was no longer maintained because the market cap of Luna had flipped UST’s.

Essentially, people panic-sold UST and didn’t want Luna despite the discount (for many reasons like insolvency risk, reduced rewards on Ankr, or the 85M UST sell order).

The UST mass sale unlocked more Luna, which within a few days increased its supply from 300M to 7 TRILLION. From $90 to <$0.01.

BnB Chain (BNB)

In October of 2022, cyber-attackers managed to generate two million BNB tokens on the Binance Bridge (~$570M).

Binance Bridge is a mint-burn bridge, meaning that before generating the token you want, you need proof that the first token was destroyed or sent to a burn address.

But attackers found a way to forge messages and generate tokens without burning any.

It would have been way worse if the BnB validators didn’t halt the blockchain— which isn’t precisely a good thing.

If you hold BNB you likely didn’t notice much price action because the circulating supply is 155M, but there’s no maximum token limit.

Validators recently deflated BNB by regularly burning tokens.

Zcash Orchard Bug (June 2026)

In June 2026, the Zcash development team disclosed a vulnerability in the Orchard shielded protocol, the privacy layer that uses zk-SNARK proofs to validate transactions without revealing sender, receiver, or amount.

The bug created a theoretical inflation surface. A sufficiently sophisticated attacker could have submitted a crafted proof that the verifier circuit accepted as valid, effectively minting shielded ZEC outside the protocol's supply rules. Because Zcash's privacy layer hides transaction details, detecting unauthorized minting would have been exceptionally difficult.

No confirmed exploitation occurred. The team issued a patch and disclosed the vulnerability after the fix was distributed widely enough to reduce risk.

Markets did not wait for confirmation. ZEC fell roughly 50% in the days following disclosure. Trading volume spiked sharply as holders exited positions before any clarity on whether the bug had been used.

The Orchard case illustrates a specific risk in privacy-coin design: the same cryptographic opacity that protects legitimate users also makes unauthorized inflation harder to detect. That is a structural tradeoff, not a fixable coding error.

Other Examples

👉 Quick takeaway: All three exploits were patched after discovery, but the damage was done before intervention in each case. Stellar's flaw briefly created 25% of its entire supply. MonoX lost $31M through a price manipulation loop enabled by a single-token pool design. Raven Coin's vulnerability came from a community code submission rather than a core team error.

Project	Date	Amount Created / Lost	Root Cause	Resolved?
Raven Coin (RVN)	July 2020	🔴 315M RVN minted	Community code submission introduced minting flaw	🟢 Yes, patched
Stellar (XLM)	April 2017	🔴 2.2B XLM created 25% of total supply	`MergeOPFrame::doApply` function flaw	🟢 Yes, patched
MonoX (MONO)	November 2021	🔴 $31M drained 🔴 Largest dollar loss in table	Same token used for both pool pairs inflated price artificially	⚠️ Yes, post-exploit Resolved after funds were drained

Are Zero-Knowledge Systems More Vulnerable?

The short answer: yes, in specific ways that older smart-contract platforms are not.

Traditional smart contracts on Ethereum or BNB Chain execute visible logic. Auditors can read the code, trace every function call, and test boundary conditions directly. That is not easy, but the attack surface is legible.

Zero-knowledge proof systems work differently. The prover generates a mathematical proof that a computation was done correctly. The verifier checks the proof, not the computation itself. If the verifier circuit has a flaw, it may accept a false proof as valid. The underlying transaction data remains hidden, which means the inflation may not appear in any public ledger until significant damage is done.

Several crypto security reviews from 2025 and 2026 label this class of vulnerability among the most severe in current inventories. The difficulty is not just finding the bug. It is detecting whether the bug was used before a patch is deployed.

Bridges that connect zk-proof chains to other networks add a second layer of exposure. A false-state acceptance on one side of a bridge can mint tokens on the other side with no corresponding burn event, combining the ZK vulnerability class with the infinite-mint class simultaneously.

How To Avoid Inflation Bugs: A 7-Point Audit Checklist

No mitigation eliminates all risk. But security firms consistently check the same seven surfaces when auditing for inflation bugs.

Access control on minting functions. Every function that creates tokens should require multi-signature authorization. Removing admin keys entirely is the strongest option where governance allows.
Arithmetic boundary testing. Integer overflow was the cause of Bitcoin's 2010 bug. Test all numeric operations at maximum and minimum values, not just typical ones.
Strong typing and naming conventions. Ambiguous variable names cause functions to be called in unintended sequences. Explicit, literal naming reduces that risk.
Oracle sourcing. Price data pulled directly from an exchange can be manipulated within a single block. Use decentralized oracles like Chainlink for any price-dependent minting or burning logic.
Burn verification on bridges. Every mint event on a bridge should require verified proof that the source token was destroyed. The 2022 BNB Bridge exploit succeeded because attackers forged those proofs.
Immutable core logic. Community code submissions should not be able to overwrite core minting or burning functions. Separate upgradeable modules from immutable base logic.
Formal verification for zk-SNARK circuits. Standard code audits do not catch false-state acceptance bugs in zero-knowledge verifier circuits. Formal mathematical verification of the circuit is required. This is significantly more expensive than a standard audit and is often skipped on smaller projects.

For token holders evaluating a project: look for published audit reports from firms like Certik, Trail of Bits, or Consensys Diligence. Check whether the audit covered the bridge layer and, for privacy coins, whether the ZK verifier circuit was formally verified.

Inflation Bug Risk: How to Evaluate Any Project You Hold

You do not need to read smart contract code to assess inflation-bug risk. These five signals are visible in public information.

Is there a published, recent audit? Audits older than 12 months may not cover new code deployed since. Check the audit date and whether it covers bridge logic.
Does the project use a bridge? Cross-chain bridges are the highest-frequency inflation-bug surface. If a project bridges to multiple chains, look for bridge-specific audit coverage.
Is the token supply verifiable on-chain? For transparent chains like Ethereum and BNB Chain, tools like Etherscan let you verify circulating supply against the contract's minting history. An unexplained supply spike is an early signal.
Does the project use zero-knowledge proofs? If yes, ask whether the ZK verifier circuit has been formally verified, not just audited. Most teams will disclose this in technical documentation or blog posts. If they haven't done it, that is a gap worth noting.
How did the team respond to past bugs? Teams that disclose vulnerabilities promptly, patch quietly before going public, and provide post-mortems are demonstrating responsible security culture. The Zcash team's handling of the Orchard bug in June 2026 is one example of this pattern, even though ZEC's price still fell sharply on disclosure.

None of these signals guarantees safety. They reduce uncertainty.

Frequently Asked Questions

What is the difference between an inflation bug and regular crypto inflation?

Regular crypto inflation is a scheduled, intentional increase in token supply built into a protocol's rules, such as Bitcoin block rewards. An inflation bug is an unintended supply increase caused by a code vulnerability or design flaw. One is planned. The other is an attack.

Can a zero-knowledge proof system have an inflation bug even if no coins appear on a public ledger?

Yes. That is the core danger of ZK inflation bugs. Because the transaction data is hidden inside the proof, unauthorized minting may not appear in any publicly readable form until the supply discrepancy becomes large enough to detect through other signals.

Why did ZEC drop 50% after the Orchard bug if no exploit occurred?

Markets priced in the possibility that exploitation had already happened but was undetectable due to Zcash's privacy layer. Uncertainty about whether unauthorized ZEC existed in circulation was enough to drive significant selling pressure. The disclosure itself, not confirmed theft, was the catalyst.

How long does it typically take to patch an inflation bug after discovery?

Timelines vary. The 2018 Bitcoin Core bug was kept secret for roughly two years while developers quietly deployed a fix and urged miners to update. The Zcash Orchard bug was patched and disclosed in June 2026 after the fix reached sufficient network adoption. Responsible disclosure prioritizes deploying the fix before public announcement.

Are smart contract audits enough to catch inflation bugs?

For traditional smart contracts, a thorough audit covers most inflation-bug surfaces. For zero-knowledge proof systems, a standard audit is not sufficient. The ZK verifier circuit requires formal mathematical verification, which is a separate and more expensive process.

Infinite Mint Attacks Explained: How Unauthorized Token Creation Works