Un importante fornitore di staking è stato compromesso. L'attaccante ha eluso audit, test di penetrazione e controlli SOC 2. Ecco cosa è andato realmente storto e perché l'architettura di staking nativa è importante 🧵

L'8 settembre, un attaccante sofisticato ha inserito codice malevolo nell'API di Kiln. Un'istituzione pensava di disinvestire. Invece, ha trasferito involontariamente il controllo dei propri asset.

Il problema? Stavano firmando in modo cieco un payload di transazione serializzato che non potevano leggere. L'app decentralizzata era compromessa. Il backend ha serializzato l'attacco. La loro soluzione di custodia non riusciva a vederlo. L'hanno approvato comunque.

Quando le istituzioni si affidano a app di staking esterne, ecco il rischio: → Ti fidi di un backend che non controlli → Approvi transazioni che non puoi interpretare → Firmi con un contesto incompleto La sicurezza non riguarda solo le verifiche. Riguarda l'architettura.

Il staking nativo di Fireblocks elimina questo rischio. ✅ Intento catturato alla fonte ✅ Motore di policy specifico per lo staking ✅ Approvazioni leggibili dall'uomo ✅ Serializzazione in enclave sicure ✅ Niente byte grezzi. Niente firme cieche.

Anche su catene complesse come Solana, Fireblocks garantisce che ogni transazione di staking rifletta esattamente la tua intenzione. Gli attaccanti non possono iniettare comandi dannosi. L'architettura non lo consente.