TL;DR

  • un pequeño conjunto de clases recurrentes es responsable de la mayoría de las pérdidas en la capa de contratos: reentrancia, manipulación de oráculos, fallos en el control de acceso, errores aritméticos y de validación, y una lógica de negocio defectuosa que funciona exactamente tal y como está escrita. Cada clase tiene asociado un caso famoso, que es como el sector ha aprendido a nombrarlas.
  • una auditoría examina una instantánea congelada del código comparándola con clases de vulnerabilidades conocidas y las intenciones declaradas por el equipo, dentro de un presupuesto de horas de trabajo de los expertos; casi todo lo demás —la economía, los oráculos, la gobernanza, las operaciones, las dependencias, el futuro— queda fuera del marco. Leer la sección de alcance de un informe de auditoría es más informativo que leer su insignia.
  • porque la distribución de las pérdidas sigue lo que las auditorías dejan fuera: cambios posteriores a la auditoría, componentes excluidos, interacciones entre protocolos, operaciones comprometidas y diseño económico, además de los errores residuales que el muestreo inevitablemente pasa por alto. La lista de «auditados y hackeados» es lo suficientemente larga como para constituir un género en sí misma.
  • por capas y asumiendo que habrá fallos: múltiples revisiones independientes, métodos formales y fuzzing donde más duele, supervisión continua, cortacircuitos económicos, cambios con bloqueo temporal, programas de recompensa por errores y un plan ensayado para el día en que algo se cuele. Cada capa detecta un perfil de fallos diferente, que es precisamente el objetivo de la estructura por capas.
en una cuadra

Una auditoría de contratos inteligentes es una revisión estructurada por expertos del código del contrato que busca clases de vulnerabilidades conocidas, desviaciones respecto a las especificaciones y patrones peligrosos antes de su implementación. Se trata de una evaluación puntual de una versión del código bajo supuestos establecidos.

¿Qué es lo que realmente falla en los contratos inteligentes?

Respuesta rápida

un pequeño conjunto de clases recurrentes es responsable de la mayoría de las pérdidas en la capa de contratos: reentrancia, manipulación de oráculos, fallos en el control de acceso, errores aritméticos y de validación, y una lógica de negocio defectuosa que funciona exactamente tal y como está escrita. Cada clase tiene asociado un caso famoso, que es como el sector ha aprendido a nombrarlas.

La reentrancia es el caso clásico. Un contrato envía valor a una dirección externa antes de actualizar su propio estado, y el destinatario, al ser también un contrato, vuelve a llamar antes de que se complete la actualización, vaciando los fondos en un bucle. El hackeo de The DAO de 2016, que supuso unos 60 millones de dólares en aquel momento, consolidó esta categoría y dividió a Ethereum en dos. Una década después, la reentrancia sigue apareciendo, a veces en formas exóticas: el incidente de Curve de 2023, que supuso unos 70 millones de dólares en todos los pools, surgió de un fallo en la protección contra la reentrancia dentro de versiones específicas del propio compilador Vyper, lo que significa que contratos cuya lógica fuente era sólida se compilaron en bytecode defectuoso. Los auditores que leían el código fuente podían detectarlo a simple vista.

La manipulación de oráculos ataca las entradas. Un contrato que confía en una fuente de precios puede ser objeto de un robo mediante la distorsión del precio, y los préstamos relámpago proporcionan el capital necesario para dicha distorsión en una única transacción atómica. Mango Markets, con unos 114 millones de dólares en 2022, es el caso canónico y la mecánica sigue siendo habitual; el pilar de este grupo analiza este patrón.

Los fallos de control de acceso constituyen la categoría más vergonzosa: funciones que cualquiera puede invocar porque falta un modificador, inicializadores que se dejan abiertos, roles privilegiados retenidos por las claves de implementación. Los incidentes de la cartera Parity de 2017, con decenas de millones robados y más de 150 millones de dólares congelados de forma permanente, tienen su origen aquí.

Los errores aritméticos y de validación persisten a pesar de los lenguajes más seguros. Cetus, el mayor DEX de Sui, sufrió una explotación de unos 223 millones de dólares en mayo de 2025 porque una comprobación de desbordamiento se comparó con una constante errónea, lo que permitió que un valor manipulado superara la validación y corrompiera la contabilidad de la liquidez. El contrato había sido auditado más de una vez, según los análisis posteriores al incidente. Las consecuencias son importantes para que conste: aproximadamente 162 millones de dólares quedaron congelados gracias a una acción coordinada de los validadores y se destinaron a un proceso de recuperación y compensación mediante votación de la comunidad. El valor bruto explotado y el valor congelado o destinado a la recuperación deben informarse por separado, y la cifra final de pérdida neta debe indicarse solo cuando exista una contabilidad fechada, en lugar de basarse en suposiciones.

Por último, un error de lógica pura: código que se compila, supera las pruebas, hace lo que dice y dice lo incorrecto. La pérdida de 197 millones de dólares de Euler Finance en 2023 combinó un mecanismo de donación con la lógica de liquidación de una forma que ninguna línea individual dejaba clara. Esta clase no tiene escáner, porque técnicamente nada está roto, salvo la idea.

¿Qué examina realmente una auditoría y qué queda fuera de su alcance por diseño?

Respuesta rápida

una auditoría examina una instantánea congelada del código comparándola con clases de vulnerabilidades conocidas y las intenciones declaradas por el equipo, dentro de un presupuesto de horas de trabajo de los expertos; casi todo lo demás —la economía, los oráculos, la gobernanza, las operaciones, las dependencias, el futuro— queda fuera del marco. Leer la sección de alcance de un informe de auditoría es más informativo que leer su insignia.

Una auditoría seria incluye una revisión manual por parte de investigadores experimentados, análisis estático, pruebas frente a la especificación y un informe que clasifica los hallazgos por gravedad. Cuando la especificación del equipo es errónea, la auditoría comprueba el código frente a un objetivo erróneo; cuando la especificación no se pronuncia, los auditores deducen la intención. Ambas son fuentes silenciosas de omisiones.

Vale la pena enumerar claramente los límites estructurales. Una auditoría es puntual: se examina la versión revisada en ese momento, pero no la actualización lanzada tres meses después. Tiene un alcance limitado: los contratos periféricos, los scripts de implementación, las herramientas de administración y las integraciones suelen excluirse por motivos presupuestarios. Está cargada de suposiciones: los informes suelen dar por sentado que los oráculos son honestos, que los tokens son válidos y que las claves de administración son fiables, que son precisamente las suposiciones que los atacantes se niegan a compartir. Es ciega desde el punto de vista económico, a menos que se contrate por separado una revisión económica: la solvencia bajo manipulación, el fallo de incentivos y la composibilidad tóxica con otros protocolos activos constituyen una disciplina diferente. Y tiene un alcance limitado en la pila: el compilador, la máquina virtual y el software del nodo subyacente casi nunca entran en el ámbito de la auditoría, que es precisamente donde se produjo el incidente de Curve.

La presión del tiempo agrava todo ello. Las empresas de auditoría examinan una muestra del espacio de búsqueda en el que los atacantes, tras el despliegue, disponen de tiempo ilimitado, el estado en tiempo real y la composibilidad de toda la cadena como instrumentos. La asimetría es estructural: los revisores deben tener en cuenta todo dentro de un encargo fijo; un atacante solo necesita una cosa que todos hayan pasado por alto, para siempre.

Nada de esto es un argumento en contra de las auditorías. Es un argumento a favor de interpretar «auditado» como «muestreado por expertos bajo restricciones», lo que ajusta el sello a lo que realmente puede abarcar.

Diagram of smart contract audit scope showing reviewed code at the centre surrounded by out-of-scope risks including oracles, upgrades, governance, economics, compiler and operations
Figura 1. Lo que abarca una auditoría de contratos inteligentes y la superficie de fallo fuera de su marco.

¿Por qué los protocolos auditados siguen perdiendo cientos de millones?

Respuesta rápida

porque la distribución de las pérdidas sigue lo que las auditorías dejan fuera: cambios posteriores a la auditoría, componentes excluidos, interacciones entre protocolos, operaciones comprometidas y diseño económico, además de los errores residuales que el muestreo inevitablemente pasa por alto. La lista de «auditados y hackeados» es lo suficientemente larga como para constituir un género en sí misma.

Los datos recientes cuantifican esta tendencia. TRM Labs contabilizó 207 incidentes en el primer semestre de 2026, una cifra récord, aunque con unas pérdidas totales inferiores a mil millones de dólares, lo que supone un descenso del 58 % respecto al año anterior; los ataques a contratos inteligentes representaron alrededor del 60 % de los incidentes y una pequeña fracción del valor, mientras que los ataques a la infraestructura, las claves, los entornos de firma y el acceso operativo se llevaron aproximadamente el 76 % del dinero a partir de alrededor del 15 % de los incidentes. Las cifras de 2025 reflejaban la misma realidad de forma más cruda: se sustrajeron alrededor de 3.4 mil millones de dólares, una cifra dominada por el robo de 1.5 mil millones de dólares a Bybit, que atacó un flujo de trabajo de firma en lugar de un contrato concreto. Los atacantes se dirigen a la capa más vulnerable, y años de auditorías han hecho que los errores en los contratos sean el objetivo más difícil en comparación con las operaciones.

Cuando el propio código auditado falla, la taxonomía de las secciones anteriores suele explicar el motivo. Cetus: una sutileza de validación en un contexto lingüístico inusual, detectada anteriormente por varias empresas, en la que la mayor parte del valor explotado se congeló posteriormente y se destinó a la recuperación. Euler: lógica emergente entre funciones, cada una de ellas correcta a nivel local. Curve: la capa situada debajo del código fuente. Más allá de estos, se produce un flujo constante de incidentes menores derivados de actualizaciones lanzadas tras la revisión, de claves de administrador gestionadas de forma descuidada a pesar de contratos impecables, y de protocolos que interactúan con tokens y mercados que su modelo nunca imaginó.

También existe una economía de la escasez: la capacidad de revisión de primer nivel es limitada y costosa, por lo que los proyectos se lanzan con una sola auditoría cuando el riesgo justificaría tres, o con una revisión de carácter comercial realizada por una empresa elegida por su rapidez de respuesta. El sello de auditoría condensa toda esta variabilidad en una sola palabra, razón por la cual los inversores sofisticados leen los informes, comparan los hash de las confirmaciones con lo que se ha desplegado y tratan una actualización no auditada de un protocolo auditado como código no auditado.

Chart comparing smart contract exploits at sixty percent of incidents with a small share of losses against infrastructure and key compromises at fifteen percent of incidents and seventy-six percent of value, per TRM Labs
Figura 2. Primer semestre de 2026: proporción de incidentes frente a proporción de valor por tipo de ataque.

¿Cómo es una infraestructura de seguridad sólida más allá de la auditoría?

Respuesta rápida

por capas y asumiendo que habrá fallos: múltiples revisiones independientes, métodos formales y fuzzing donde más duele, supervisión continua, cortacircuitos económicos, cambios con bloqueo temporal, programas de recompensa por errores y un plan ensayado para el día en que algo se cuele. Cada capa detecta un perfil de fallos diferente, que es precisamente el objetivo de la estructura por capas.

Las revisiones redundantes detectan las lagunas propias de los revisores: diferentes empresas, diferentes métodos, diferentes puntos ciegos, además de plataformas de concursos que ponen a cientos de investigadores independientes a analizar el mismo código. La verificación formal demuestra propiedades específicas —conservación, invariantes de acceso— frente a un modelo matemático; su límite es que verifica las propiedades que alguien se ha molestado en enunciar. El fuzzing y las pruebas de invariantes analizan mecánicamente el espacio de estados y destacan en la clase Cetus de validación de límites; son lo suficientemente económicos como para que su ausencia sea ahora una señal de alerta.

Las recompensas por errores cambian el mercado: una oferta permanente, cuantificada de forma significativa en función del valor en riesgo, ofrece al investigador que detecte el fallo una recompensa legal competitiva con la del delito. Las mayores recompensas de DeFi han pagado millones y han resultado baratas a cambio.

Las defensas en tiempo de ejecución asumen que la prevención termina en el momento del despliegue. La monitorización vigila los mempools y el estado en busca de patrones de ataque; los cortacircuitos limitan las salidas por bloque o se detienen ante anomalías; los bloqueos temporales en las actualizaciones y los cambios de parámetros dan al mundo días para inspeccionar lo que la gobernanza ha aprobado antes de que entre en funcionamiento, convirtiendo los cambios ocultos en públicos. Los límites de tasa convierten las fugas totales en parciales, la misma filosofía de radio de impacto limitado que impregna los artículos sobre custodia de esta academia.

Y dado que los datos sobre pérdidas indican que las operaciones ahora superan en importancia al código: las claves que administran los contratos merecen un rigor propio de los contratos. Autoridad de firma distribuida, aprobación por quórum, firma clara en dispositivos independientes y que ningún operador pueda actualizar por sí solo un contrato de tesorería. El incidente de Bybit es el recordatorio constante de que un contrato perfecto administrado a través de un flujo de trabajo vulnerable a la corrupción es un contrato perfecto con una puerta trasera.

Para un usuario o un asignador, la lista de comprobación se reduce a unas preguntas: ¿cuántas revisiones independientes se realizan del commit desplegado?; ¿qué pueden hacer las claves de administrador, con qué retraso y qué quórum?; ¿qué rompe el protocolo desde el punto de vista económico, y publica el equipo ese análisis?; ¿cuál es la recompensa?; ¿cuál es el plan de pausa? Los protocolos que responden a estas preguntas en documentación pública te están revelando su cultura de seguridad; los protocolos que responden con una insignia también te están diciendo algo.

¿Cómo debería leer un experto un informe de auditoría?

Respuesta rápida

al revés: primero el alcance y los supuestos; en segundo lugar, los hallazgos sin resolver; en tercer lugar, la correspondencia con el commit desplegado; y, por último, el resumen de marketing, si es que lo hay. Un informe es una prueba de la calidad del proceso, y se lee de forma más útil como un mapa de lo que NO se ha cubierto.

Empieza por el alcance. ¿Qué contratos, qué commit, qué se ha excluido? ¿Se corresponde el bytecode implementado con el código revisado? Los exploradores de bloques facilitan la verificación, y las discrepancias son lo suficientemente habituales como para comprobarlas de forma rutinaria. Una auditoría del commit A no dice nada sobre el commit B.

Lee las suposiciones como una lista de superficies de ataque. «Suponemos que el administrador es honesto» significa que el riesgo de que se comprometa la clave de administrador es algo que debes valorar. «El comportamiento de Oracle queda fuera del alcance» significa que el patrón Mango no se ha examinado. Cada suposición expresada es un límite en el que se detuvo la revisión, y los límites son donde los atacantes buscan oportunidades.

Valora los hallazgos en función de la respuesta, más que por su número. Un informe con una docena de fallos críticos resueltos puede reflejar un equipo comprometido y revisores minuciosos; un informe limpio puede reflejar una revisión superficial. El patrón alarmante es que los hallazgos se reconozcan y se lancen de todos modos, o se corrijan de formas que los auditores nunca han vuelto a revisar. Comprueba si se ha realizado una nueva auditoría de las correcciones; el error introducido por la corrección es una especie recurrente.

Por último, sitúe el informe en su contexto temporal. ¿Cuánto tiempo tiene?, ¿cuántas actualizaciones se han lanzado desde entonces? y ¿respeta el registro de cambios del protocolo el principio de que el código modificado es código no auditado? Para un protocolo en desarrollo activo, lo relevante es un proceso de seguridad —revisión en cada lanzamiento, recompensa permanente, supervisión— más que un único documento. Un informe sólido de hace años es un artefacto, y los artefactos no protegen los sistemas en funcionamiento.

El resumen conciso: las auditorías son necesarias, informativas e insuficientes, y los profesionales que las encargan dirían lo mismo. Su verdadero resultado es una reducción de las incógnitas, y las incógnitas se gestionan, nunca se eliminan.

Preguntas frecuentes

¿Es seguro utilizar un protocolo auditado?

Más seguro, con amplios márgenes de error. Una auditoría reduce la probabilidad de que clases de vulnerabilidades conocidas persistan en el código revisado. Sin embargo, deja fuera del análisis el diseño económico, los oráculos, las actualizaciones, las operaciones y las clases de vulnerabilidades aún por descubrir, y los datos recientes sobre pérdidas muestran que la mayor parte del valor sustraído sale ahora por esas vías. Considera la auditoría como un factor más, junto con la política de claves de administrador, los bloqueos temporales, la cuantía de las recompensas, la supervisión y el historial.

¿Por qué no limitarse a auditar hasta que no quede nada por encontrar?

Porque la revisión examina una muestra de un espacio de búsqueda prácticamente ilimitado con un presupuesto limitado, mientras que los atacantes lo exploran indefinidamente en condiciones reales. Una mayor revisión reduce el riesgo residual con rendimientos decrecientes; no puede llegar a cero, y las clases a las que las auditorías son estructuralmente ciegas —cambios futuros, composibilidad emergente, operadores comprometidos— no se reducen con horas adicionales de revisión. Por eso, las pilas maduras invierten cada libra marginal en recompensas, fuzzing, monitorización y límites del radio de impacto, en lugar de en una quinta auditoría idéntica.

¿Cuál es la diferencia entre una auditoría y la verificación formal?

Una auditoría es una revisión realizada por expertos: personas y herramientas que buscan problemas. La verificación formal es la prueba matemática de que el código cumple las propiedades explícitamente establecidas en un modelo. La verificación es más sólida allí donde se aplica y su validez depende exclusivamente de las propiedades y del modelo; un contrato cuya corrección se ha demostrado, pero que contiene una propiedad no declarada o una especificación errónea, falla formalmente aunque esté intacto. Los procesos más sólidos utilizan ambos métodos en los componentes que más importan.

¿Funcionan realmente los programas de recompensas por errores?

La lógica del incentivo es sólida y los datos lo respaldan: las principales plataformas han mediado en pagos de millones por hallazgos críticos que habrían costado a los protocolos cientos de millones en condiciones reales. La credibilidad de un programa de recompensas importa más que su titular: un alcance claro, una clasificación rápida, un pago fiable y que no haya antecedentes de estafar a los investigadores. Un programa de recompensas sin financiación o hostil es peor que ninguno, porque enseña a los investigadores a vender sus hallazgos a otros.

Como usuario, ¿cuál es el mejor indicador de la cultura de seguridad de un protocolo?

Fíjate en qué ocurre con el poder: qué pueden hacer las claves de administrador, quién las posee, qué mecanismo de bloqueo temporal y de quórum las protege, y si todo ello está documentado públicamente. Los equipos que se imponen restricciones visibles, retrasan las actualizaciones, utilizan la firma distribuida, publican análisis económicos y financian programas de recompensas te están mostrando una cultura. El recuento de insignias es la cifra menos informativa de la página.

Fuentes y lecturas recomendadas

Referencias clave para este artículo, actualizadas a julio de 2026. Las cifras volátiles se vuelven a comprobar en cada revisión trimestral.

Prueba rápida: ¿se mantuvo?

Llegaron algunas preguntas para comprobar los fundamentos. Siguen respuestas con explicaciones y nadie lo califica excepto su futuro portafolio.

1/5 pregunta
¿Qué es, exactamente, una auditoría de contratos inteligentes?

¿Fue esto útil?