Between 12:20 UTC on Sunday August 16th, 2026 and 19:44 UTC on Monday August 17th, 2026, an inflation bug was exploited on Decred mainnet that generated a total of 2,077.96933695 DCR. Upon review, it was found that the bug being exploited was the same as one submitted via the bug bounty program at 03:12 UTC on Wednesday August 12th, 2026, 4 days prior.

The inflation bug exploited consensus code that had been present in the Decred codebase since its launch in February 2016. This bug allowed double spending of inputs due to an unhandled edge case when dealing with the interaction of the regular and stake transaction trees.

At roughly 19:24 UTC on Monday August 17th, the double spends from the inflation bug were spotted. Exchanges were notified to halt deposits and withdrawals temporarily out of an abundance of caution several hours later. The chain was monitored for any further double spends until the patch release was out the next day.

The emergency patch release, version 2.1.6, was pushed at 15:25 UTC on Tuesday August 18th, 2026, which fixed the inflation bug going forward but avoided the need for a chain rollback. After roughly 24 hours most Decred ecosystem participants had updated to the new patch release.

Further Details

Decred has been running a bug bounty program for the past several years. The maximum payout for a critical bug is 30,000 USD, providing a decent incentive to disclose security vulnerabilities responsibly. A variety of serious bugs have been found and fixed via this program, and this is the only legitimate reported bug exploited before a fix was deployed to date. Had this bug been responsibly disclosed it would have received a full 30,000 USD payout.

In addition to the mainnet transactions exploiting the bug between 12:20 UTC on Sunday August 16th, 2026 and 19:44 UTC on Monday August 17th, 2026, the bug was exploited on testnet at 23:38 UTC on August 14th. The timeline of the bug bounty submission, testnet exploit, and mainnet exploit is very compressed, with just under 72 hours from bug disclosure to testnet exploit and 36 hours from testnet exploit to mainnet exploit.

The transactions where inflation occurred are:

714e71358937cd33480fd2900853d43ea3440ca67b38bacdfeaeb0c37c80ee27 baa77e2b2c1a12ef080c5ffcbd056afa0a6018475f7c670a2872c4dd84f2f3fc 17228266d9d6dd7084aa2e479319aca6d755c2a9d2dbb3cf28c8151470c7a439 20d6d3ed1b609f03969474dca1f452c25e035766457dfd58061f9b9270fc4e6d 5d2e1898fe0c631cb795b1906fb3cf8d9772f1826be8dea64dd3ab85ac0ab2d3 df166a3d9a786a27dc6b9ba805b2ba1cd6aefeccf2296969f0b4e584beec4608

A silver lining to the bug bounty that was submitted is that Dave Collins, our lead consensus daemon developer, had prepared a nearly-complete fix for the inflation bug immediately after confirming the submitted bug was legitimate. There was a rough plan for a patch release to be made last week (August 17-21) before we saw the exploit run on mainnet. Despite the severity of the bug being critical, it was sufficiently difficult to exploit that we were in the process of gauging the payout on that basis. Between the bounty submission and the exploit being run, the ease of running the exploit had increased substantially. The bounty submission required crafting a custom block and colluding with miners to get it mined, whereas the exploit had been reduced to transactions that could be created and mined without any miner collusion.

On Governance

Decred is defined by the governance of its stakeholders, but an emergency consensus change is not something that is practical to have subjected to its established governance system. Under all other scenarios, consensus changes to Decred are dictated by an established process where there is a coordinated upgrade, the stakeholders vote, and a consensus change only activates if it achieves a supermajority (75%) stakeholder approval over a period of several weeks.

A valid concern is that if Decred consensus can be changed in an “emergency”, there is a risk of it becoming a thin wedge, much as it has become in the context of nation-state governance. With this in mind, the only change made during this upgrade was a narrowing of the consensus rules to protect against the inflation bug. A consensus change that prevents critical, obviously unintentional behavior of the existing stakeholder-ratified consensus rules (e.g. an inflation bug), does not create a crisis of governance, but a broader change in policy would. Going forward, Decred stakeholders must remain vigilant and ensure any emergency consensus changes adhere to existing stakeholder-ratified policy without any questionable additions.

Conclusions

Rather than try to roll back the chain to recoup roughly 2,000 DCR, it was decided to minimize problems for users and keep moving forward.

21 million DCR is the hard cap for the issuance of Decred, and this generation of 2,000 DCR will not affect that. Over the lifespan of the project a large amount of subsidy has already been “missed” because block subsidy can be reduced when there are missed votes. As of block 1106816, the total missed subsidy from votes and reduction in miner subsidy is 215,243 DCR, so the addition of 2,000 DCR will not even come close to creating a surplus of DCR supply.

In response, a low-complexity service that watches for possible double spends has been developed. A challenge with cryptocurrency consensus daemons is that they have to maintain a large amount of state and context, whereas watching for possible double spends can be done with much less state and context, leading to simpler code. This is a simple additional layer of security with a low cost.

Decred is built to execute coordinated consensus changes over a period of several months, but it is not built to execute emergency consensus changes. The existing block and stake version fields have strong constraints regarding activation, concurrent versions, etc, so they are not suitable for signaling that miners and voters have upgraded in an emergency scenario. There is a plan to add new version fields that signal miners and voters have upgraded to the latest version, in case there are any future emergency upgrades. This will allow for a more accurate assessment of upgrade progress after an emergency fix is deployed.