Tu smart contract puede no tener bugs y aun así ser hackeado

Un contrato puede comportarse como fue programado y, aun así, el protocolo perder fondos. La razón es simple: la seguridad no termina en la lógica on-chain. También depende de quién gobierna, qué firmas y datos se aceptan, cómo se calculan los precios, quién conserva privilegios y qué supuestos sostienen las integraciones entre cadenas.

Una auditoría de código es una entrada importante, no una garantía completa. Antes de una revisión, el equipo debe convertir estas dependencias operativas y económicas en elementos explícitos del alcance.

1. Controles de gobernanza y tesorería

🔐 La gobernanza define quién puede cambiar parámetros o ejecutar acciones sobre la tesorería. Si esos controles permiten una toma de control, el riesgo no se limita a una función aislada del contrato.

El 13 de julio, Halborn reportó una toma de control de la gobernanza de BonkDAO sobre la tesorería, con una pérdida reportada de aproximadamente US$20 millones. El caso recuerda que los derechos de voto, los umbrales de aprobación y los caminos de ejecución son superficies de seguridad por derecho propio.

Incluye en el alcance:

• Identificar quién puede proponer, aprobar y ejecutar cambios sensibles.
• Revisar umbrales, retrasos y límites de las acciones de tesorería.
• Documentar qué ocurre si una cuenta o mecanismo de gobernanza es comprometido.
• Definir monitoreo y respuesta para propuestas y ejecuciones inusuales.

2. Integridad de oráculos y firmantes

📡 Un protocolo puede tener lógica correcta y aun así tomar decisiones equivocadas si confía en un dato o una firma comprometidos. Hay que revisar el origen del dato, la autoridad de firma, la vigencia y la respuesta ante un incidente.

El 15 de julio, Halborn y Cointelegraph reportaron un exploit de oráculo en Ostium vinculado a una clave de firma de oráculo comprometida. Las pérdidas reportadas se situaron entre aproximadamente US$18 millones y US$22 millones. La cifra y la causa siguen siendo reportes, no un diagnóstico definitivo.

Incluye en el alcance:

• Mapear cada dato externo y la entidad o clave que lo autoriza.
• Establecer controles de vigencia y condiciones para pausar o limitar acciones sensibles.
• Revisar la custodia, rotación y revocación de las claves de firma.
• Preparar un procedimiento de respuesta para datos o firmas anómalos.

3. Supuestos de mercado y solvencia

💸 La seguridad también depende de que los cálculos sigan siendo válidos bajo condiciones adversas de mercado. Precios, liquidez y reglas de solvencia deben evaluarse como supuestos que un atacante puede intentar alterar.

El 16 de julio, CertiK reportó manipulación de un pool ilíquido y un fallo en el cálculo de solvencia que afectó a DeFiTuna. El reporte subraya la necesidad de revisar qué condiciones de mercado requiere cada cálculo crítico.

Incluye en el alcance:

• Enumerar los precios, reservas y ratios que habilitan movimientos de fondos.
• Probar los cálculos ante liquidez reducida y variaciones adversas de precio.
• Definir límites para operaciones que dependen de un único pool o fuente de precio.
• Monitorear desviaciones que puedan afectar la solvencia o la liquidación.

4. Límites de bridge e integración

🌉 Las integraciones entre cadenas añaden traspasos de confianza, validación de mensajes y dependencias que no viven en un solo contrato. Estos límites deben evaluarse de forma explícita.

El 23 de julio, Cointelegraph reportó un exploit en un bridge de USDC operado por el protocolo que afectó a AFX Trade. El vector reportado está bajo investigación. El reporte no permite concluir la causa raíz.

Incluye en el alcance:

• Documentar los traspasos de confianza y las dependencias de cada flujo cross-chain.
• Revisar la validación de mensajes y las condiciones que autorizan movimientos de fondos.
• Probar casos alternativos y fallas de las dependencias en los flujos de fondos.
• Definir monitoreo y procedimientos de pausa para actividad anómala entre cadenas.

5. Propiedad privilegiada y rutas de emisión

🗝️ Los roles de propietario y administrador pueden modificar el estado o habilitar acciones críticas. Su poder, su custodia y su transferencia deben revisarse con la misma atención que la lógica de negocio.

El 26 de julio, Cointelegraph reportó un compromiso de la propiedad del contrato de WEMIX y una emisión no autorizada de tokens. La pérdida reportada fue de aproximadamente US$724.000. No basta con listar roles: el equipo debe entender qué puede hacer cada uno y cómo se responde si se compromete.

Incluye en el alcance:

• Inventariar cada rol privilegiado y las acciones que puede ejecutar.
• Revisar transferencias de propiedad, cambios de administrador y rutas de emergencia.
• Definir controles de custodia y revocación para accesos privilegiados.
• Alertar sobre emisiones, transferencias de propiedad y cambios administrativos inesperados.

Convierte las cinco superficies en un brief de revisión

Una revisión útil empieza antes de compartir el repositorio. Para cada superficie, documenta responsables, supuestos, pruebas relevantes, monitoreo y controles de respuesta. Así, la conversación deja de ser solo “¿hay bugs en el contrato?” y pasa a ser “¿qué tendría que fallar para que este sistema pierda fondos?”.

¿Estás preparando una auditoría o una revisión de seguridad? Mapea estas cinco superficies y contacta a Seclat para definir un alcance acorde con tu protocolo.

Fuentes

• Halborn, BonkDAO hack, julio de 2026
• Halborn, Ostium hack, julio de 2026
• Cointelegraph, Ostium pausa operaciones tras el exploit de oráculo reportado
• CertiK, análisis del incidente de DeFiTuna
• Cointelegraph, AFX Protocol pierde US$24M en un exploit de bridge, según reportes
• Cointelegraph, movimiento de US$724K tras la brecha de contrato de WEMIX