July 2nd Post-Mortem: 82.3 BTC Secured, Attack Failed

TL;DR

On July 2nd, an attacker exploited a consensus-level bug in the Alkanes indexer to fabricate ~1.47M phantom DIESEL, drained the DIESEL/frBTC pool, and attempted to unwrap 82.3 frBTC into BTC.

SUBFROST's automated signer-layer halted the unwrap. Zero BTC left the protocol. Zero funds were lost. The DIESEL contract itself was never compromised, and its real supply never changed.

The underlying bugs were identified and patched, and the protocol was fully operational roughly 10 hours after detection.

What happened, step by step

On July 2nd, Alkanes and SUBFROST survived a serious exploit attempt, and not by luck. The system was designed with layered defenses for exactly this scenario. Here is the complete account of what happened.

At block 956,326, an attacker deployed a custom contract on Alkanes and executed a single transaction that exploited a state-consistency bug in the deployed indexer (v2.2.0-rc.8). The bug, which is described below, allowed them to duplicate token balances. By cascading roughly 24 doublings inside one transaction, they inflated their DIESEL balance to approximately 1.47 million DIESEL, more than twice the entire legitimate supply of ~663K.

Two critical points before we go further.

First: this was balance-sheet duplication, not a mint. The DIESEL contract itself was never touched. Its total supply endpoint stayed correct throughout, holding steady at 3.125 DIESEL per block. What the attacker created were phantom entries in the indexer's accounting, not real tokens issued by the DIESEL contract. This distinction matters enormously for what recovery looks like, as explained below.

Second: the fabricated balance was only useful if it could be converted to real BTC. And that is where the attack died.

The attacker sold the phantom DIESEL into the DIESEL/frBTC liquidity pool, “walking away” with 82.3 frBTC. They then attempted to unwrap that frBTC into native BTC through SUBFROST, twice.

Both unwraps were blocked. The SUBFROST framework does not blindly honor unwrap requests. Automated security mechanics flagged the activity and refused to sign. The 82.3 BTC never moved. This was fully-automated, in fact, our core team was asleep during the entire incident.

The response & recovery

At approximately 7:30am EST, our team took the following steps.

1. Disabled frBTC→BTC unwraps as a precaution. This meant no BTC could leave the system regardless of any on-chain state. The attacker's unwraps had already been halted previously.
2. Performed root cause analysis and identified the exercised inflation bug consensus-level vulnerability.
3. Reproduced the bug deterministically against the deployed version using self-contained proofs of concept.
4. Wrote and verified the fix, then converted the exploit PoCs into permanent regression tests.
5. Roughly 10 hours after the incident began, the protocol was operational again.

Recovery works like this. The fixed indexer (v2.2.1) replays the Alkanes index from block 956,325, the last clean block before the attacker's contract existed.

Under the corrected execution rules, the attacker's transactions simply no longer duplicate anything. The phantom DIESEL never materializes in the replayed history.

We then validate that the attacker's contract holds zero and that total DIESEL held is consistent with real supply. We then deploy via the existing upgrade mechanism so every operator converges on the same interpretation of the index.

No indexer reorg. No rollback of anyone's legitimate activity. Just a corrected reading of the same chain.

The technical details

We believe in full transparency, so here is exactly how the bug used to work.

During message processing, the protorune indexer tracks balances in two places.

1. An atomic key-value store, which is transactional, with checkpoint/rollback semantics. If a message fails, its writes are undone.
2. An in-memory balance map, which is not transactional. Rollback does not touch it.

When a message settles, the indexer credits outgoing tokens into that in-memory map one token at a time, in ascending token-ID order, mutating state as it goes. If any single credit overflows, the loop bails with an error mid-way, leaving every credit applied before the failure sitting in the in-memory map.

The attacker's transaction produced an outgoing sheet with two tokens: a low-ID token V (DIESEL) worth x, and one unit of the attacker's own high-ID token C, whose balance at the destination had been pre-loaded to the maximum possible value (u128::MAX). Walking the sheet in ID order:

1. V:x is credited first and written to the in-memory map.
2. C:1 overflows the pre-loaded maximum, so the operation errors out.
3. The error path rolls back the atomic KV store, restoring the contract's original V balance, but the in-memory credit of V survives, because that map is outside the rollback's reach.
4. The block finishes, and the in-memory map, phantom credit included, is committed to canonical state.

Net result: V now exists twice. The contract has its x back, and the destination output holds a duplicated x. Repeat the primitive and the balance doubles each round. The attacker chained ~24 doublings in a single transaction.

The fix makes the credit operation all-or-nothing. A first pass validates every addition with checked arithmetic before any mutation, and only then does a second pass apply them. An overflow is now caught before any partial credit exists, so the rollback leaves both stores consistent.

What this means for DIESEL holders

We know many of our users hold DIESEL, and we know an exploit "targeting DIESEL" sounds alarming. So let us be precise.

• The DIESEL contract was never compromised. Its emission schedule (3.125/block) and total supply were correct the entire time.
• The phantom DIESEL does not exist after recovery. Because this was indexer accounting corruption and not real tokens, the fix is an index replay, not a token intervention.
• Nothing about DIESEL's rules, supply, or your holdings has changed.

Why the system held

It's worth reiterating why this post-mortem describes a failed attack rather than a loss.

The SUBFROST signer ring independently refused to convert fraudulently-acquired frBTC into real BTC. Even with the index compromised, real funds had their own gate, and that gate held.

We started building this architecture as early as 2019 and have adopted the strongest security mechanics from some of the most elite teams that came before us.

This architecture worked exactly like it was supposed to, and on July 2nd it worked under live fire, on mainnet, with 82.3 BTC ($5M+) on the line.

Closing

Protocols don't get to choose whether they're attacked. They only get to choose how prepared they are.

On July 2nd, Alkanes and SUBFROST were tested by a real adversary, with real BTC at stake, and the answer came back: not one satoshi lost, root cause fixed in hours, and a stronger protocol on the other side.

Bitcoin DeFi has to be held to a higher standard than what came before it. This is what that standard looks like in practice: transparent, fast, and verifiable. You can check the fixes and run the regression tests yourself.

We aren’t going anywhere.

Gabe

CEO, SUBFROST