Крупный провайдер стейкинга был скомпрометирован. Злоумышленник обошел аудиты, тесты на проникновение и контроль SOC 2. Вот что на самом деле пошло не так и почему важна нативная архитектура стейкинга 🧵

8 сентября опытный злоумышленник вставил вредоносный код в API Kiln. Одно учреждение думало, что они снимают ставку. Вместо этого они незаметно передали контроль над своими активами.

Проблема? Они подписывали сериализованный полезный груз транзакции, который не могли прочитать. dApp был скомпрометирован. Бэкэнд сериализовал атаку. Их решение по хранению не могло это увидеть. Тем не менее, они это одобрили.

Когда учреждения полагаются на внешние приложения для стекинга, вот в чем риск: → Вы доверяете бэкенду, который не контролируете → Вы одобряете транзакции, которые не можете интерпретировать → Вы подписываете с неполным контекстом Безопасность — это не только аудиты. Это архитектура.

Нативный стейкинг Fireblocks устраняет этот риск. ✅ Намерение зафиксировано на источнике ✅ Специфичный для стейкинга движок политик ✅ Читаемые человеком одобрения ✅ Сериализация в защищенной области ✅ Никаких сырых байтов. Никакой слепой подписи.

Даже на сложных цепочках, таких как Solana, Fireblocks гарантирует, что каждая транзакция по ставке отражает ваше точное намерение. Злоумышленники не могут внедрить вредоносные команды. Архитектура этого не позволяет.