Update, later the same day. The HAWK team has withdrawn HAWK from NIST's additional signature standardisation process. Leo Ducas confirmed the attack roughly halves the lattice reduction block size needed to recover an equivalent secret key, and stated that the obvious escapes, doubling parameters or moving to higher rank modules, make HAWK uncompetitive. That closes the fallback described below. We are moving off HAWK entirely, including for the infrastructure keys we had planned to keep at HAWK-1024. The replacement is being selected now and we will publish the choice separately. Everything else in this piece stands, and the case for it is stronger today than it was this morning.
On 28 July 2026 Anthropic published HAWK-n Key Recovery Reduces to SVP in Dimension n/2 + 1, a paper that cuts more than 40 bits off the claimed key-recovery cost of the signature scheme our chain runs on. The attack is the work of Zygimantas Straznickas and Stephen A. Weis, developed together with Anthropic's Claude Mythos. Here is what the paper shows, what it does and does not mean for us, and the redesign we are adopting because of it.
What the paper shows
HAWK's designers assumed that recovering a secret key meant lattice reduction on a rank-2n lattice. Straznickas and Weis give a deterministic polynomial-time reduction that collapses this to a single exact-SVP call in dimension n/2 + 1. The attack needs nothing but the public key, and it uses only two structural facts that every HAWK key shares: the secret basis has determinant one, and the public key is the Gram matrix of that basis.
For HAWK-512, the parameter set we ported, the claimed cost of key recovery drops from about 2¹⁵⁰ gates to at most 2¹⁰⁸. HAWK-256, the challenge parameter, falls outright: the authors recover those keys end to end on one server in a few hours. HAWK-1024 keeps about 2¹⁸².
Nothing in an implementation can defend against this. It attacks the mathematics, not the code. To be precise about severity: 2¹⁰⁸ is still far beyond anyone's reach, no signature is forgeable today, and HAWK-512 remains unbroken in the forgery sense. What is gone is the margin, the security category the parameter set claimed. We ship a byte-exact HAWK-512 port, so this is our problem too.
We run a testnet. There are no real funds on the chain, so nobody needs to move or sweep anything. That is lucky timing, and we intend to use it.
The lesson we refuse to relearn
The narrow response would be to move to HAWK-1024, advise against address reuse, and carry on. That was our plan this morning, and the withdrawal has since ruled it out. Even had it held, it treats the wrong layer. Two structural choices made this paper a bad day for us: our spend authorization was pinned to exactly one signature scheme, and every spend published the public key, the one input this attack feeds on, and the input any future key-recovery attack will feed on too. Fix those two and the next paper of this kind becomes a parameter update instead of an architecture question.
That is what v2 does.
Outputs that never show a key
v2 keeps the UTXO model exactly as it is. What changes is the lock on each output. Today a transparent output locks funds to the hash of a HAWK public key, and spending reveals that key next to a signature. In v2 an output locks funds to a lattice commitment to the owner's key material, and spending proves in zero knowledge that the wallet knows the opening of that commitment, with the proof bound to the transaction signing message it authorizes. Double-spending is prevented the way it always was, by consuming the output. Proving happens in the browser. The secret key, the signature, and the public key itself never leave it. Only the proof travels.
The v2 spend path. Key material never leaves the browser; transactions carry proofs; the node verifies one algebraic relation and never sees a user key.
The chain, for its part, verifies one fixed algebraic relation, natively and in batches. It never runs a signature verifier for a user transaction and never stores a user's verification key. Recall what the attack needs: the Gram matrix. In v2 no key that guards a user's funds appears on the wire or in state. The reduction still exists; it simply has nothing of yours to read. The only public keys left in the system are the rotatable infrastructure keys described below.
This is not machinery we are inventing for the occasion. We have already built it for amounts: wallets hide values behind commitments and prove range and balance in the browser, and in our measurements a node batch-verifies those proofs at around 9 ms per transaction. That proof system already contains an ownership leg. To be precise about status, none of it is merged into the chain that runs the public testnet yet; it is built and tested, and it ships with the same upgrade. v2 extends it from the private lane to every transaction.
Signatures do not disappear from the design entirely. Consensus votes between authorities and the P2P handshake still need them. Our first plan, written this morning, was to keep HAWK there at 1024, on rotatable infrastructure keys that hold no user funds. The withdrawal note closes that door: the HAWK team themselves say that doubling parameters or moving to higher rank modules makes the scheme uncompetitive. So HAWK leaves our stack completely. Those keys are rotatable, they guard no user funds, and swapping them is an operational change rather than a consensus one, which is why this is a decision we can take calmly rather than urgently.
Signature abstraction
The useful way to say what changed: the chain no longer knows what a signature is, for user transactions. Validity is one proof relation, and what counts as owning an output is defined by the constraint builders that feed the prover. Today that means knowledge of a lattice commitment opening. The same relation can host other statements: a different signature scheme, two schemes at once during a migration, threshold custody where several parties jointly hold the opening.
That is the crypto-agility part, and it deserves honest scoping. Adding a scheme becomes a wallet-side change plus a versioned upgrade of the relation. The upgrade is still a coordinated network event; we will not pretend a version bump is free. And the relation speaks the language of lattices, so schemes whose key material fits short-vector statements slot in cleanly, while something like a hash-based scheme would need genuinely new proof machinery. Within those bounds, migrating off a weakened scheme stops being a rewrite of addresses and balances and becomes a software update. After 28 July, that property is not theoretical to us.
What it costs, and what is open
Proofs are not signatures. Our confidential proofs run to a few megabytes and take seconds to produce in a browser; an authorization-only proof will be smaller, but still orders of magnitude heavier than the few kilobytes of a HAWK signature. Verification batches to single-digit milliseconds per transaction, but bandwidth and mempool economics move to the center of the design, and the free lane where a transparent transaction cost almost nothing is gone.
Three problems sit at the top of the spec, and we are treating them at production grade from the first line rather than as testnet approximations. The authorization relation must be binding on its own: the ownership proof we are generalizing was designed to lean on the amount proof beside it, and as a standalone authorizer it needs its own binding analysis and a written soundness bound. The transaction signing message must be bound inside the proof transcript, or a proof authorizes a statement rather than a spend. And the proof lane needs honest pricing, in fees and in relay policy, before every transaction rides it; what a rate-limited confidential lane tolerates, a chain-wide default cannot.
Why now
Because it will never be cheaper. A testnet with no funds, no integrations and no address format to preserve can adopt a new trust boundary with a fresh genesis. The current testnet stays up until then; the upgrade starts from a fresh genesis, so nothing on it needs saving. Papers like this one will keep coming; that is post-quantum cryptanalysis working as intended, and none of this is criticism of HAWK's designers, whose scheme stood through years of analysis before someone found this seam. Our job is to build the rail so that when the next seam appears, the answer is a wallet update.
None of this starts from zero. The groundwork went in over the last couple of months, when we built the zero-knowledge machinery for post-quantum confidential transactions: amounts hidden behind lattice commitments, proofs built in the browser, verified in batches by the node. That work is finished and tested but not yet merged into the public testnet. v2 promotes the same machinery from one lane to every transaction, and a testnet upgrade carrying both is a few weeks out.