AI Research Agent Flags Zero-Key Signing Risk in SIMD-0376 Before Mainnet Activation

hackhack.ai's autonomous research agent identified a pre-activation incompatibility in SIMD-0376 that would have allowed anyone to submit valid signatures for Solana's all-zero public key (the System Program ID, displayed as 11111111111111111111111111111111) before the proposal reached mainnet. The finding was reported to Anza, which has prepared an implementation fix and proposed an amendment to the SIMD.

SIMD-0376 proposes replacing Solana's current strict Ed25519 signature check with the ZIP-215 standard, originally defined by the Zcash project. The change is motivated by throughput: the cofactored verification equation ZIP-215 uses enables batch signature verification, which the proposal estimates could reduce costs by around 40% for large signature batches. The SIMD remains in Review; neither the Agave implementation pull request nor the Solana SDK integration pull request had merged as of September 17, 2026.

Why ZIP-215's Cofactored Equation Makes the Zero Key Signable

ZIP-215 verifies a signature by checking whether [8][S]B = [8]R + [8][h]A, where B is the base point, A is the public key, R and S are the signature components, and h is the challenge scalar. Multiplying by eight enables batching, but it also eliminates every point in the curve's small torsion subgroup from the equation.

The all-zero 32-byte encoding decodes to an Edwards25519 point of order four. Set both A and R to that point and set S to zero: the left side of the equation is the identity, because 0 * B is zero. The right side is also the identity, because multiplying an order-four point by eight produces the identity. Since A has order four, [8][h]A is the identity for every h regardless of the message. That 64-byte all-zero signature therefore satisfies the equation for any message.

Current strict verification rejects this witness outright because it rejects small-order public keys and signature points. SIMD-0376, as written before the amendment, does not.

hackhack.ai's report includes a deterministic proof artifact that decodes the point, checks its order, computes the challenge for three independent messages, and confirms the equation passes each time. The upstream ed25519-zebra test suite provides an independent implementation reference for the same behavior.

433 Mutable Metaplex Accounts With Disabled Update Authorities

The 32-byte zero encoding has a second meaning on Solana beyond its cryptographic role. The runtime displays it as the System Program ID and exposes it as Pubkey::default(). Programs across the ecosystem assign this value to authority fields to signal that an authority is disabled or that a configuration is immutable. The safety guarantee comes entirely from today's strict verifier rejecting every attempted signature for those bytes.

Changing the verifier changes that guarantee globally. Once the zero key can occupy a required-signer position with an accepted signature, any program that checks only key equality plus the runtime signer bit receives is_signer=true for an account it previously treated as impossible to sign for.

hackhack.ai's writeup makes this concrete with Metaplex Token Metadata. The program's update_v1 processor requires the authority account to be a signer, then compares the caller key against the stored update authority. It does not test subgroup membership or special-case the System Program key. An attacker presenting the all-zero key as a required signer with a 64-byte zero signature could satisfy that equality check and rotate the update authority of any affected account.

To quantify current exposure, hackhack.ai queried the mainnet-beta JSON-RPC endpoint at finalized commitment using the MetadataV1 Borsh layout to filter by discriminator, update authority bytes, mutability flag, and creator count. The query returned 433 mutable accounts per hackhack.ai's finalized census, confirmed against a 100-account offline sample.

The realistic outcome, if the inferred transaction path held, would be attacker-controlled name, symbol, URI, or creator presentation for the 433 affected accounts: persistent metadata misrepresentation across wallets, marketplaces, and explorers that resolve those fields. hackhack.ai's report is explicit that no transaction was submitted, no account was modified, and no funds were at risk at any point.

Anza's Amendment: Reject Small-Order Keys, Keep Batch Verification

The finding was reported to Anza under responsible disclosure before any public writeup. Anza's prepared fix, submitted as pull request #121 to the anza-xyz/cryptography repository, adds per-signature canonical-encoding and small-order checks to the amended SIMD-0376 verifier. The corresponding SIMD amendment, pull request #616 to solana-foundation/solana-improvement-documents, replaces the pure ZIP-215 specification with a variant that rejects small-order public keys and signature points.

The fix does not require abandoning the proposal's core performance case. The cofactored equation, and the batch verification it enables, can be retained. Rejecting small-order public keys is a targeted check that excludes the all-zero witness and the other seven canonical torsion encodings on Edwards25519 without changing the equation itself. The paper Taming the many EdDSAs, cited in SIMD-0376 as a reference, describes exactly this approach: cofactored verification paired with small-order public key rejection. The original proposal listed that design as an alternative but did not adopt it. The amendment corrects that choice.

As of the September 17 writeup, both pull requests remain open and the SIMD has not been activated on mainnet.

hackhack.ai's report also recommends a pre-activation audit of authority fields across current program schemas, scanning for other constant or accidentally weak values beyond the all-zero encoding, and migrating or freezing affected state where authorized. For application developers, the recommendation is direct: if a special public-key value means "disabled authority," reject it explicitly in the application rather than relying solely on the network's accepted signature set.