Solanas Bemühungen, die Verifizierung von Transaktionssignaturen zu modernisieren, haben einen unerwarteten Rückschlag erlitten – und der kam aus einer ungewöhnlichen Quelle: einem autonomen KI-Forschungsagenten, der auf der Solana-Blockchain unter dem Alias @hackhackai agiert. Der Agent identifizierte eine potenzielle Schwachstelle in SIMD-0376, dem Vorschlag, der die Handhabung der Transaktionssignaturverifizierung des Netzwerks reformieren soll.

Den Ergebnissen des Agents zufolge könnte der Fehler – falls er nicht behoben wird – das Signieren an der Zero-Address ermöglichen, ein Szenario, das nach den aktuellen Regeln unmöglich sein sollte, wodurch 433 Metadata-Accounts gefährdet wären.

Was SIMD-0376 vorschlägt

Solana verifiziert Ed25519-Signaturen derzeit mithilfe der ed25519-dalek-Bibliothek. SIMD-0376 würde diese durch den ZIP-215-Cofactored-EdDSA-Verifizierungsstandard ersetzen, eine andere Implementierung derselben zugrunde liegenden kryptografischen Kurve – ein Standard, der ursprünglich als Zcash-Verbesserungsvorschlag entstanden ist.

Die Signaturverifizierung läuft bei jeder Transaktion, die das Netzwerk verarbeitet – deshalb wirken sich Effizienzgewinne auf dieser Ebene auf den gesamten Durchsatz von Solana aus. Der praktische Nutzen des Wechsels ist greifbar: Der Vorschlag zielt darauf ab, die Batch-Verarbeitung von Signaturen zu ermöglichen, was die Rechenkosten für Validatoren bei großen Signaturmengen um rund 40 % senken könnte.

David Rubin von Syndica brachte den Vorschlag am 6. Oktober 2025 ein. Nach anschließender Überarbeitung wurde er am 28. Januar 2026 in das Solana Improvement Documents Repository gemergt.

Das Zero-Address-Problem

Die Schwachstelle dreht sich um einen speziellen Grenzfall, der durch den ZIP-215-Standard eingeführt wurde: die Möglichkeit, mit oder für die Zero-Address zu signieren. Nach den normalen Ed25519-Regeln würde eine solche Signaturheraus abgelehnt. Unter der toleranteren Verifizierungslogik von ZIP-215 ist das möglicherweise nicht der Fall.

Die Zero-Address ist nicht irgendein Grenzfall. Sie fungiert als Null-Identität – eine Adresse, die ausschließlich aus Nullen besteht und für die es in der Praxis keinen privaten Schlüssel gibt. Deshalb behandeln die aktuellen Regeln jede Signatur dagegen als von vornherein ungültig – und deshalb würde eine verifizierbare Zero-Address-Signatur eine Grundannahme kontobasierter Systeme wie Solana untergraben.

Diese Toleranz ist beabsichtigt. ZIP-215 wurde so konzipiert, dass es ein breiteres Spektrum gültiger Signaturrepräsentationen akzeptiert, was die Batch-Verarbeitung erleichtert. Der Nachteil: Dabei werden bestimmte Grenzprüfungen gelockert, die zuvor als implizite Sicherheitsleitplanken dienten.

Das Ergebnis ist laut den Erkenntnissen von @hackhackai, dass 433 Metadata-Accounts im Solana-Ökosystem Signieroperationen ausgesetzt sein könnten, die niemals möglich sein dürften. Hackhackai beschreibt sich selbst als einen KI-fokussierten Forschungsagenten, der speziell entwickelt wurde, um Schwachstellen in Solana-Protokollen aufzuspüren.

Warum das Timing wichtig ist

Der Vorschlag wurde im Oktober 2025 eingereicht und im Januar 2026 gemergt, doch die Zero-Address-Schwachstelle kam ans Licht, ohne dass sie in den folgenden Monaten von großen Krypto-Nachrichtenportalen nennenswert behandelt wurde. Diese Lücke zeigt auch, wie Protokollforschung heute abläuft: Ein autonomer, On-Chain operierender Agent kann einen Vorschlagsproblem deutlich vor der Berichterstattung oder offiziellen Reaktionen aufdecken.

Bei den in den Erkenntnissen markierten Metadata-Accounts handelt es sich nicht um gewöhnliche User-Wallets. In Solanas Architektur speichern Metadata-Accounts typischerweise Daten auf Programmebene, Token-Konfigurationen oder NFT-Attribute. Im schlimmsten Fall könnte eine Signaturanomalie, die diese Accounts betrifft, unautorisierte Änderungen am Programmzustand oder an Eigentumsaufzeichnungen von Assets ermöglichen – je nachdem, wie einzelne Programme eingehende signierte Anweisungen verarbeiten.

Für Entwickler, die auf Solana bauen – insbesondere deren Programme mit Metadata-Accounts interagieren – stellt sich die praktische Frage, ob ihre Anweisungsvalidierungslogik das aktuelle Ed25519-Ablehnungsverhalten voraussetzt oder explizit auf Zero-Address-Eingaben prüft. Programme, die vor dem Vorschlag von SIMD-0376 geschrieben wurden, hätten keinen Grund, Letztere Prüfung zu enthalten, da sie nie nötig war.

Zum Zeitpunkt der Veröffentlichung haben die Autoren des Vorschlags und die Solana Foundation den Fehler nicht öffentlich kommentiert. Jede Überarbeitung des SIMD-Texts, eine formelle Stellungnahme der Autoren oder von Solana-Core-Engineers oder neue Leitlinien für Programme, die mit Metadata-Accounts interagieren, wären die nächsten konkreten Signale dafür, wie dieser Kompromiss zwischen Batch-Effizienz und strenger Verifizierung gelöst wird.