Um grande fornecedor de staking foi comprometido. O atacante contornou auditorias, testes de penetração e controles SOC 2. Aqui está o que realmente deu errado e por que a arquitetura de staking nativa é importante 🧵

No dia 8 de setembro, um atacante sofisticado inseriu código malicioso na API da Kiln. Uma instituição pensou que estava a retirar os seus ativos. Em vez disso, transferiu involuntariamente o controlo dos seus ativos.

O problema? Eles estavam a assinar de forma cega um payload de transação serializado que não conseguiam ler. A dApp foi comprometida. O backend serializou o ataque. A sua solução de custódia não conseguiu vê-lo. Eles aprovaram na mesma.

Quando as instituições dependem de aplicações de staking externas, aqui está o risco: → Você confia em um backend que não controla → Você aprova transações que não consegue interpretar → Você assina com contexto incompleto A segurança não se trata apenas de auditorias. Trata-se de arquitetura.

A staking nativo da Fireblocks elimina este risco. ✅ Intenção capturada na origem ✅ Motor de políticas específico para staking ✅ Aprovações legíveis por humanos ✅ Serialização em enclave seguro ✅ Sem bytes brutos. Sem assinaturas cegas.

Mesmo em cadeias complexas como a Solana, a Fireblocks garante que cada transação de staking reflete a sua intenção exata. Os atacantes não conseguem injetar comandos maliciosos. A arquitetura não permite isso.