The 07/02 Incident: What an Attack on Alkanes Can and Cannot Do to frBTC

I want to put down a less formal account of what happened on 07/02, because the attempted drain of the frBTC reserve — carried out as an attack on the metaprotocol layer that SUBFROST receives its unwrap signal from — surfaced a set of questions that are genuinely worth answering in the open. The discussion around the incident touched a few points that warrant clarification, and some of them are things I have wanted to write about for a while anyway.

The first is centralization, and specifically how the word applies, and does not apply, to the two systems that were in the room on 07/02: the Alkanes metaprotocol, and the SUBFROST federated custodian. These are not the same kind of object, and they do not share a trust model. The easy way to conflate them is to assume that because one feeds the other, an attack on one is an attack on the other. That assumption is where the whole thing falls apart.

In the ideal state, the metaprotocol statutes are fixed. They are an irrefutable source of truth, and it is from that source of truth that a FROST multisignature system of custody can opt to honor outgoing transfers of BTC. When I say "the metaprotocol" here I mean it strictly: the operations expressed in alkanes.wasm, the consensus program we supplement on top of the primary Bitcoin Core consensus. In steady state this is a fixed object. The rules do not change.

SUBFROST — subzero-rs, as the code project is called — is a different animal entirely. It is genuinely a p2p system, and the closest familiar analogue is a proof-of-stake network, but it is a realtime system that receives signals from arbitrary endpoints, and, most importantly, its consensus program is mutable. What matters is only that a supermajority of connected signers proliferate a wasip2 executable to update its logic. That mutability is not a defect to be apologized for; it is the defining feature of an L0, which is the layer SUBFROST exists to operate — the layer that actually custodies the BTC backing frBTC.

On a closed system, that wasip2 program can be reactive. It can, for example, receive information from an AI agent so that signers can actively maintain consensus in real time. The set of behaviors and rules SUBFROST will honor when it computes a queue of signatures to broadcast is not strictly a public-facing object, and it is not even required to be perfectly consistent at all times. That is by design, and it is the point.

It is worth noting that this has a much broader scope of applications than what SUBFROST offers BRC20 or Alkanes today. It is, for instance, a genuinely interesting framework for prediction markets, because it gives you a truly decentralized resolution mechanism. Any framework for an oracle can become decentralized once you include these primitives — and that is close to what SUBFROST already does, across the places where it is replicated.

But that is not exactly what happened on 07/02, and I want to be precise here. Nothing mutated within the signing logic across replicas to render the attack on Alkanes insufficient to drain BTC. The ruleset already protects BTC custody in a number of ways, before any reaction is required at all.

The framework is designed so that the underlying BTC it governs can be timelocked, or otherwise deployed in systems that are market-neutral relative to Bitcoin. What this buys us is the ability to ascertain — "pin" is the word I like — capital that, for one reason or another, could not honestly be queued for disbursement. You can arrive at this by heuristics alone. In this case there are certain truths we know should hold regarding frBTC and its current distribution, and those truths effectively give us a pinning magnitude we can expect: an amount that should either be protected outright or treated as "cold." This is much closer to the security protocols that signers already honor, and it is a large part of the reason an attack on Alkanes does not necessarily translate into an attack on frBTC.

Concretely: a great majority of frBTC represents timelocked positions on the DIESEL/BTC LP. Those funds are protected by an evolving consensus program inside SUBFROST, in exactly the sense I described above.

Now, the part that is actually true, and that I do not want to wave away. There is a centralization question here worth answering head-on. Alkanes as a metaprotocol can be updated, and those changes are authored by a small set of contributors. That is a real centralization vector. It is somewhat true, with some important caveats, and it is worth holding up against the nature of Bitcoin Core itself, and how it is maintained and evolves.

Alkanes is a notably immersive framework in terms of complexity, and the group actively working on the indexer logic is small today. But a small contributor base does not mean the work happens in the dark: Alkanes is an open-source project, and there is an audit log of every update made to the consensus logic. The framework it runs on, METASHREW, is open-source as well — the general-purpose indexer stack that makes it possible for Alkanes to be deterministic in the first place. The funds the system custodies are not ours, and we are public-facing, both as individuals and as a group. The update we shipped in reaction to the attack resolves an unintended vector that existed in the framework. Judging by the shape of what landed on-chain, reaching even a working proof of concept against the protocol would plausibly have taken a significant, sustained development effort — the kind of thing that is only within reach today with the best agentic tooling available, and even then not quickly. The other thing that surfaced in the process was a single DoS vector that could be orchestrated. We have had significant security review from independent analysts, and this incident represents a very long expenditure of compute and effort to find and solve for this one flaw.

Think about what that actually hands us. We get a payload, on-chain, that expresses the path toward an existential problem. We can walk that payload backwards and use it to triage a much larger spectrum of conceptual alignment across the routines in the codebase that share the same pattern. The result is that we get, effectively for free, probably the most important security improvement money can buy.

This is the kind of modification we can realistically make to Alkanes as maintainers, and it is the kind we should make, given the fiduciary responsibility that comes with putting this technology into the world in the first place. The distinction I care about is intent. If Alkanes were modified specifically for personal profit, against the interests of the collective who use it today, that would certainly result in a fork of the index, and it would compromise years of collective effort building what is, in my view, the greatest expression of chaindata on proof-of-work available today. That is not a trade anyone rational makes. What we did instead was the consensus change we needed to make as maintainers: we aligned Alkanes to what SUBFROST expects, rather than the other way around.

The steady state I described at the top — the one where the statutes are fixed and irrefutable — is a world where we no longer have to update Alkanes at all. We are not there yet. Until we are, we will keep shipping security improvements, and we will keep inviting the world to join us in contributing to Alkanes and making it better.