Un exploit de smart contract aprovecha un fallo del código, del diseño económico, de los permisos o de una dependencia externa para provocar un resultado imprevisto, a menudo el vaciado o bloqueo de activos. Se diferencia de un robo de claves corriente porque el atacante puede utilizar reglas válidas del contrato en una secuencia inesperada.
Empieza por el modelo de riesgo#
Entre los exploits habituales se encuentran los fallos de control de acceso, la manipulación de oráculos de precios, la reentrada, los errores contables, las actualizaciones inseguras y las claves administrativas comprometidas. La pérdida visible puede ser el último paso de un fallo más largo entre dependencias.
Comprobación final#
El usuario debe evaluar la contención y la autoridad: ¿puede el protocolo pausar, actualizar o recuperar activos, y quién controla esas facultades? Esos mismos controles pueden reducir el riesgo o crearlo.
Completa la tarea paso a paso#
- Identifica el contrato afectado y la versión desplegada. La respuesta determina qué activo, autoridad y modelo de riesgo se aplican; resuelve cualquier ambigüedad antes de continuar.
- Pausa las interacciones y revoca las aprobaciones relacionadas si así lo indican fuentes verificadas. Hazlo desde la interfaz oficial y comprueba el resultado en vez de suponer que está activo.
- Averigua si el incidente afecta al front end, al contrato o a una clave administrativa. Contrasta dominio, dirección, red y permisos exactos con una fuente oficial independiente.
- Sigue las actualizaciones oficiales del incidente y conserva las pruebas de las transacciones. Guarda fechas, identificadores y registros íntegros para que otra persona pueda reproducir la conclusión.
- No confíes en enlaces no solicitados que prometan reembolso o recuperación. Verifica toda solicitud antes de transferir valor o autoridad de firma y revisa después el estado resultante.
Dónde se equivocan los usuarios#
- Suponer que una auditoría cubrió todas las dependencias. Omite un dato necesario y hace que la evaluación aparente del exploit sea poco fiable.
- Depositar durante un incidente sin resolver para obtener una rentabilidad mayor. Amplía la exposición justo cuando los controles o dependencias pueden estar fallando.
- Firmar una “migración de emergencia” publicada en respuestas sociales. La marca puede copiarse; vuelve a abrir el proceso desde un canal oficial verificado de forma independiente.
- Confundir una pérdida de mercado con un exploit del código. Son causas distintas y exigen respuestas diferentes; una mala clasificación puede aumentar el daño.
Un resultado correcto no es solo una transacción o un ajuste completado. Debe poder verificarse, reproducirse y recuperarse de forma independiente si falla el servicio circundante.
Confirma el resultado#
No juzgues la respuesta al incidente únicamente porque una interfaz muestre éxito. Usa pruebas que sigan siendo comprobables después de cerrar la página.
| Punto de control | Prueba | Condición para detenerse |
|---|---|---|
| Identificar el contrato afectado y la versión desplegada | URL o dirección de contrato exacta cotejada con documentación oficial | Suponer que una auditoría cubrió todas las dependencias |
| Pausar interacciones y revocar aprobaciones si lo recomiendan fuentes verificadas | ID de transacción o retiro y registro correspondiente | Depositar durante un incidente sin resolver por más rentabilidad |
| Comprobar si están afectados el front end, el contrato o la clave administrativa | URL o dirección de contrato exacta cotejada con documentación oficial | Firmar una “migración de emergencia” desde respuestas sociales |
Conserva hashes de transacción, números de caso oficiales o capturas fechadas cuando ayuden a documentar el exploit, pero excluye frases semilla, claves privadas y códigos de autenticación.
Preguntas frecuentes#
¿Puede corregirse un contrato explotado?
Los sistemas actualizables pueden modificarse, mientras que un despliegue inmutable quizá requiera una migración. La recuperación depende del diseño y del control que aún quede.
¿El código abierto evita los exploits?
No. Permite revisarlo, pero no garantiza que se detecten todos los errores o interacciones económicas.
¿Debo revocar aprobaciones después de un exploit?
Si el contrato autorizado aún podría utilizarlas, revocarlas puede reducir la exposición futura. Verifica la red y las instrucciones oficiales.
Guías relacionadas#
- Cómo revocar una aprobación ilimitada de tokens
- Cómo consultar el historial de autorizaciones de una wallet
Fuentes#
Aviso de riesgo: Las acciones con criptoactivos pueden ser irreversibles. Nunca compartas una frase semilla, clave privada, contraseña o código de autenticación, y verifica por separado cada dominio y solicitud de la wallet.
Criterio editorial
Esta guía es educativa y se apoya en fuentes. Los controles de seguridad, las reglas de los exchanges y los requisitos legales pueden cambiar; confirma los pasos importantes en fuentes oficiales.
