Hackhackai identifies critical flaw in Solana’s SIMD-0376 proposal

Solana’s ongoing effort to modernize its signature verification system just hit a speed bump, and it came from an unexpected source: an autonomous AI research agent.

The agent, operating under the alias @hackhackai on the Solana blockchain, identified a potential vulnerability in SIMD-0376, a proposal designed to reform how the network handles transaction signature verification. The flaw, if left unaddressed, could allow signing at the zero address, putting 433 metadata accounts at risk.

What SIMD-0376 actually proposes

Currently, Solana verifies Ed25519 signatures using the ed25519-dalek library. SIMD-0376 wants to replace that with a ZIP-215 cofactored EdDSA verification standard, a different implementation of the same underlying cryptographic curve.

The practical upside of the switch is real. The proposal aims to enable batch signature processing, which could reduce computational costs for validators by around 40% when handling large volumes of signatures.

David Rubin from Syndica introduced the proposal on October 6, 2025. It was subsequently refined and merged into the Solana Improvement Documents repository on January 28, 2026.

The zero-address problem

The vulnerability @hackhackai surfaced centers on a specific edge case introduced by the ZIP-215 standard: the possibility of signing with or for the zero address. Under normal Ed25519 rules, such a signature would be outright rejected. Under ZIP-215’s more permissive verification logic, it may not be.

That permissiveness is actually intentional in ZIP-215’s design. The standard was built to accept a broader range of valid signature representations, which makes batch processing more straightforward. The tradeoff is that it also relaxes certain boundary checks that previously served as implicit security guardrails.

The result, according to @hackhackai’s findings, is that 433 metadata accounts linked to the Solana ecosystem could be exposed to signing operations that should never be possible.

Hackhackai describes itself as an AI-focused research agent built specifically to isolate vulnerabilities in Solana protocols.

Why the timing matters

The proposal was introduced in October 2025, merged in January 2026, and the zero-address vulnerability surfaced without meaningful coverage from mainstream crypto news outlets in the months that followed.

The metadata accounts flagged in @hackhackai’s findings are not generic user wallets. Metadata accounts in Solana’s architecture typically store program-level data, token configurations, or NFT attributes. A signing anomaly affecting these accounts could, in a worst-case scenario, enable unauthorized modifications to program state or asset ownership records, depending on how individual programs handle incoming signed instructions.

For developers building on Solana, particularly those whose programs interact with metadata accounts, the practical question is whether their instruction validation logic assumes current Ed25519 rejection behavior or explicitly checks for zero-address inputs. Programs written before SIMD-0376 was proposed would have no reason to include the latter check, since it was never needed.

The proposal’s authors and the Solana Foundation have not publicly commented on the flaw as of the time of writing.