A testnet key template in the public source repository contained private keys. The same keys were in use on mainnet for two roles: the five maintainer keys, which sign releases and govern the maintainer set (3 of 5 signatures required), and the keys of the 12 block producers that the project operates.

1. With 3 of the 5 maintainer keys: sign a release and change the maintainer set. To reach auto-updating nodes, an attacker also needed publish rights on the project's GitHub releases, the only source the updater accepts.
2. With the producer keys: produce blocks and attest as those producers, which held most of the selection weight, and withdraw their bonds.
3. Not possible: spend other users' coins. In the UTXO model, a key signs only for its own outputs.

1. 2026-08-11 — GitHub accounts hardened: two-factor authentication, token cleanup, fewer collaborators, protected main branch and release tags.
2. 2026-08-19 to 2026-08-28 — each exposed producer withdrew its bonds in full and registered again under new keys generated offline. No bond was lost and the chain did not fork.
3. v6.25.0 and v6.26.0 — code that made a safe rotation possible: an on-chain trust root, governance transactions that can be mined, authorizations bound to a block height, and maintainer state that is undone on a reorg.
4. 2026-08-30 — maintainer rotation: 10 transactions, one Remove then one Add, five times, one at a time. The signature threshold is recomputed at each change, so removing keys in a batch would have lowered it from 3 to 2.
5. v6.26.1 and v6.26.2 — the key lists compiled into the binaries now hold only the new keys. A build test fails if any network ships a retired key.

No unauthorized maintainer change was seen: the maintainer set was still the original five just before the rotation. Every release was published by a project account or the CI bot. All producer bonds were recovered in full.

The old private keys remain public in the repository history, and this cannot be undone. On mainnet they no longer have any authority. Binaries v6.26.0 and older still trust the old keys and cannot verify new releases — upgrade them manually.

Signing-only keys. They are not producers and hold no bonds.

• d07ec4ec146245e0ce31800ba2cf98b9fc649aa7a4021a09e8534a7764033f8d
• 25c24110d98f2a34c37bab8fede0791d3de1281ca499a30fb7ff5223cdb0e23c
• 2559a47ee898f8bb9a38d90573dcca2195a97a7c787b5712ba62102e225b9e0d
• e477c1f245612f7351f66ce7936e4ffa1e0afef26a12f90f3a86ed3544ca5b8c
• 3fd5be3de8285140a461b12dbd7d14ce0d026b5e369e38daebf89f6f7cbc0245

During an operational recovery from a rolling deploy incident (INC-I-062), 456 reward pool UTXOs that had already been consumed by prior epoch distributions were re-introduced into the UTXO set. At the next epoch boundary (epoch 362, height 130,320), the EpochReward transaction consumed all 816 pool UTXOs — 360 legitimate and 456 duplicates. A silent error handling defect (let _ = on spend errors) allowed the outputs to be created without valid inputs, producing 457 DOLI from nothing.

Three defensive checks failed simultaneously:

1. Spend errors were silently discarded (Result not checked)
2. Pool input verification was skipped during sync/reorg validation
3. No post-block conservation invariant existed

The 457 DOLI stayed on that chain until it was retired. They were consensus-agreed across all 15 nodes and mixed into normal producer reward UTXOs. A retroactive correction would have required a chain reset or a punitive burn mechanism, and neither was justified for a 0.31% anomaly with no victim. The code defects were fixed to prevent any future occurrence. That chain was later replaced for unrelated reasons (see Chain history), so the excess does not exist on the current chain.