Główny dostawca stakowania został skompromitowany. Napastnik ominął audyty, testy penetracyjne i kontrole SOC 2. Oto co naprawdę poszło nie tak i dlaczego natywna architektura stakowania ma znaczenie 🧵

8 września wyrafinowany atakujący wprowadził złośliwy kod do API Kiln. Jedna instytucja myślała, że wycofuje swoje środki. Zamiast tego, nieświadomie przekazała kontrolę nad swoimi aktywami.

Problem? Podpisywali ślepo zserializowany ładunek transakcji, którego nie mogli przeczytać. Aplikacja dApp została skompromitowana. Backend zserializował atak. Ich rozwiązanie do przechowywania nie mogło tego zobaczyć. Zatwierdzili to mimo wszystko.

Kiedy instytucje polegają na zewnętrznych aplikacjach do stakowania, oto ryzyko: → Ufasz backendowi, którego nie kontrolujesz → Zatwierdzasz transakcje, których nie możesz zinterpretować → Podpisujesz z niepełnym kontekstem Bezpieczeństwo to nie tylko audyty. To także architektura.

Rodzime stakowanie Fireblocks eliminuje to ryzyko. ✅ Intencja uchwycona u źródła ✅ Silnik polityki specyficzny dla stakowania ✅ Zatwierdzenia w formie czytelnej dla ludzi ✅ Serializacja w bezpiecznej enklawie ✅ Brak surowych bajtów. Brak ślepego podpisywania.

Nawet na złożonych łańcuchach, takich jak Solana, Fireblocks zapewnia, że każda transakcja stakowania odzwierciedla twoje dokładne intencje. Napastnicy nie mogą wprowadzać złośliwych poleceń. Architektura na to nie pozwala.