Ein großer Staking-Anbieter wurde kompromittiert. Der Angreifer umging Audits, Penetrationstests und SOC 2-Kontrollen. Hier ist, was wirklich schiefgelaufen ist und warum die native Staking-Architektur wichtig ist 🧵

Am 8. September fügte ein ausgeklügelter Angreifer bösartigen Code in die API von Kiln ein. Eine Institution dachte, sie würde ihre Staking-Anteile abziehen. Stattdessen übertrugen sie unwissentlich die Kontrolle über ihre Vermögenswerte.

Das Problem? Sie haben eine serialisierte Transaktionslast blind signiert, die sie nicht lesen konnten. Die dApp wurde kompromittiert. Der Backend hat den Angriff serialisiert. Ihre Verwahrungslösung konnte es nicht sehen. Sie haben es trotzdem genehmigt.

Wenn Institutionen auf externe Staking-Apps angewiesen sind, besteht folgendes Risiko: → Sie vertrauen auf ein Backend, das Sie nicht kontrollieren → Sie genehmigen Transaktionen, die Sie nicht interpretieren können → Sie unterschreiben mit unvollständigem Kontext Sicherheit geht nicht nur um Audits. Es geht um Architektur.

Das native Staking von Fireblocks beseitigt dieses Risiko. ✅ Absicht am Ursprung erfasst ✅ Staking-spezifische Richtlinien-Engine ✅ Menschlich lesbare Genehmigungen ✅ Sichere Enklave-Serialisierung ✅ Keine Rohdaten. Keine blinde Unterzeichnung.

Selbst bei komplexen Chains wie Solana stellt Fireblocks sicher, dass jede Staking-Transaktion genau Ihrem Wunsch entspricht. Angreifer können keine bösartigen Befehle einschleusen. Die Architektur lässt dies nicht zu.