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

Em 8 de setembro, um invasor sofisticado inseriu código malicioso na API do Kiln. Uma instituição pensou que eles estavam desapostando. Em vez disso, eles transferiram inconscientemente o controle de seus ativos.

O problema? Eles estavam assinando às cegas uma carga útil de transação serializada que não conseguiam ler. O dApp foi comprometido. O back-end serializou o ataque. Sua solução de custódia não conseguia ver. Eles aprovaram de qualquer maneira.

Quando as instituições dependem de aplicativos de staking externos, aqui está o risco: → Você confia em um back-end que não controla → Você aprova transações que não pode interpretar → Você assina com contexto incompleto A segurança não se trata apenas de auditorias. É sobre arquitetura.

O staking nativo do Fireblocks elimina esse risco. ✅ Intenção capturada na origem ✅ Mecanismo de política específico de staking ✅ Aprovações legíveis por humanos ✅ Serialização segura de enclave ✅ Sem bytes brutos. Sem assinatura cega.

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