Un importante proveedor de staking fue comprometido. El atacante eludió auditorías, pruebas de penetración y controles SOC 2. Aquí está lo que realmente salió mal y por qué la arquitectura de staking nativa es importante 🧵

El 8 de septiembre, un atacante sofisticado insertó código malicioso en la API de Kiln. Una institución pensó que estaba deshaciendo su participación. En cambio, sin saberlo, transfirieron el control de sus activos.

¿El problema? Estaban firmando ciegamente una carga útil de transacción serializada que no podían leer. La dApp fue comprometida. El backend serializó el ataque. Su solución de custodia no pudo verlo. Aun así, lo aprobaron.

Cuando las instituciones dependen de aplicaciones de staking externas, aquí está el riesgo: → Confías en un backend que no controlas → Apruebas transacciones que no puedes interpretar → Firmas con un contexto incompleto La seguridad no se trata solo de auditorías. Se trata de arquitectura.

El staking nativo de Fireblocks elimina este riesgo. ✅ Intención capturada en la fuente ✅ Motor de políticas específico para staking ✅ Aprobaciones legibles por humanos ✅ Serialización en enclave seguro ✅ Sin bytes en bruto. Sin firma ciega.

Incluso en cadenas complejas como Solana, Fireblocks asegura que cada transacción de staking refleje tu intención exacta. Los atacantes no pueden inyectar comandos maliciosos. La arquitectura no lo permite.