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

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

¿El problema? Estaban firmando a ciegas una carga útil de transacción serializada que no podían leer. La dApp se vio comprometida. El backend serializó el ataque. Su solución de custodia no podía verlo. Lo aprobaron de todos modos.

Cuando las instituciones dependen de aplicaciones de participación externas, este es el riesgo: → Confías en un backend que no controlas → Aprueba transacciones que no puede 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 de staking ✅ Aprobaciones legibles por humanos ✅ Serialización segura de enclaves ✅ Sin bytes sin procesar. Sin señas ciegas.

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