Un furnizor important de staking a fost compromis. Atacatorul a ocolit auditurile, testele și controalele SOC 2. Iată ce a mers prost cu adevărat și de ce arhitectura nativă de miză contează 🧵

Pe 8 septembrie, un atacator sofisticat a introdus cod rău intenționat în API-ul Kiln. O instituție a crezut că nu mizează. În schimb, au transferat fără să știe controlul asupra activelor lor.

Problema? Semnau orbește o încărcătură utilă de tranzacție serializată pe care nu o puteau citi. DApp a fost compromisă. Backend-ul a serializat atacul. Soluția lor de custodie nu a putut vedea asta. Au aprobat-o oricum.

Când instituțiile se bazează pe aplicații de staking externe, iată riscul: → Ai încredere într-un backend pe care nu îl controlezi → aprobați tranzacții pe care nu le puteți interpreta → Semnați cu context incomplet Securitatea nu se referă doar la audituri. Este vorba despre arhitectură.

Miza nativă Fireblocks elimină acest risc. ✅ Intenție capturată la sursă ✅ Motor de politică specific Staking ✅ Aprobări care pot fi citite de om ✅ Serializare securizată a enclavei ✅ Fără octeți bruti. Fără semnături oarbe.

Chiar și pe lanțuri complexe precum Solana, Fireblocks se asigură că fiecare tranzacție de miză reflectă intenția ta exactă. Atacatorii nu pot injecta comenzi rău intenționate. Arhitectura nu permite acest lucru.