Un important fournisseur de staking a été compromis. L'attaquant a contourné les audits, les tests de pénétration et les contrôles SOC 2. Voici ce qui a vraiment mal tourné et pourquoi l'architecture de staking native est importante 🧵

Le 8 septembre, un attaquant sophistiqué a inséré un code malveillant dans l'API de Kiln. Une institution pensait qu'elle était en train de désengager. Au lieu de cela, elle a transféré sans le savoir le contrôle de ses actifs.

Le problème ? Ils signaient à l'aveugle une charge utile de transaction sérialisée qu'ils ne pouvaient pas lire. Le dApp a été compromis. Le backend a sérialisé l'attaque. Leur solution de garde ne pouvait pas le voir. Ils l'ont approuvé quand même.

Lorsque les institutions s'appuient sur des applications de staking externes, voici le risque : → Vous faites confiance à un backend que vous ne contrôlez pas → Vous approuvez des transactions que vous ne pouvez pas interpréter → Vous signez avec un contexte incomplet La sécurité ne concerne pas seulement les audits. Il s'agit de l'architecture.

Le staking natif de Fireblocks élimine ce risque. ✅ Intention capturée à la source ✅ Moteur de politique spécifique au staking ✅ Approbations lisibles par l'homme ✅ Sérialisation dans une enclave sécurisée ✅ Pas de bytes bruts. Pas de signature aveugle.

Même sur des chaînes complexes comme Solana, Fireblocks s'assure que chaque transaction de staking reflète exactement votre intention. Les attaquants ne peuvent pas injecter de commandes malveillantes. L'architecture ne le permet pas.