Великий провайдер стейкінгу був скомпрометований. Зловмисник обійшов аудити, тести на проникнення та контроль SOC 2. Ось що насправді пішло не так і чому рідна архітектура 🧵 стейкінгу має значення

8 вересня витончений зловмисник вставив шкідливий код в API Kiln. Одна установа вважала, що вони розв'язують. Натомість вони несвідомо передали контроль над своїми активами.

У чому проблема? Вони підписували наосліп серіалізоване корисне навантаження транзакцій, яке не могли прочитати. Додаток dApp було скомпрометовано. Бекенд серіалізував атаку. Їхнє рішення про опіку не могло цього побачити. Вони все одно його затвердили.

Коли установи покладаються на зовнішні додатки для стейкінгу, ось ризик: → Ви довіряєте серверній частині, яку не контролюєте → Ви схвалюєте транзакції, які не можете інтерпретувати → Ви підписуєте з неповним контекстом Безпека – це не лише аудити. Йдеться про архітектуру.

Нативний стейкінг Fireblocks усуває цей ризик. ✅ Намір зафіксовано в джерелі ✅ Механізм політики для стейкінгу ✅ Схвалення, зрозумілі людині ✅ Безпечна серіалізація анклаву ✅ Ніяких сирих байтів. Ніякого сліпого підписання.

Навіть у складних ланцюжках, таких як Solana, Fireblocks гарантує, що кожна транзакція стейкінгу відображає ваші точні наміри. Зловмисники не можуть впроваджувати шкідливі команди. Архітектура цього не дозволяє.