Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

Una auditoría de un contrato inteligente es una revisión independiente del código y la arquitectura dentro de un alcance definido. Su objetivo es identificar vulnerabilidades, errores de implementación y diferencias entre el comportamiento previsto y el real.

Una auditoría puede reducir la incertidumbre, pero no elimina todos los riesgos de un contrato. La guía oficial de seguridad de Ethereum describe las auditorías como una revisión adicional, no como una solución infalible que detecta todos los errores.

Este artículo tiene únicamente fines educativos. Una auditoría no garantiza la seguridad, la recuperación de fondos ni la obtención de rendimientos.

El alcance es lo primero

Un informe útil identifica exactamente qué se revisó:

• repositorio y hash del commit;
• archivos y contratos;
• versión del compilador y configuración de compilación;
• dependencias;
• arquitectura y funciones con privilegios;
• rama o versión;
• exclusiones, limitaciones y supuestos;
• fecha de la revisión.

Esto es importante porque una auditoría auténtica puede abarcar una versión antigua, un despliegue diferente o solo una parte de un sistema más amplio.

Qué suelen examinar los auditores

1. Comportamiento previsto e invariantes

Los auditores comparan el código con su especificación:

• quién puede llamar a cada función;
• cómo se calculan los importes y las comisiones;
• cuándo se producen los cambios de estado;
• qué propiedades deben cumplirse siempre;
• cómo se gestionan los casos límite y los fallos.

Si la especificación omite un requisito importante, un código técnicamente correcto puede implementar un diseño inseguro o no deseado.

2. Control de acceso

Los revisores inspeccionan los roles de propietario, administrador, operador y otros roles privilegiados, incluidas las facultades para:

• conceder o revocar permisos;
• pausar el sistema;
• cambiar las comisiones y los límites;
• acuñar tokens;
• retirar activos;
• actualizar una implementación.

También se evalúa si una sola clave puede realizar un cambio crítico y si el diseño incorpora controles como una multifirma o un bloqueo temporal.

3. Llamadas externas y reentrada

Durante la ejecución, un contrato puede ceder el control a otro contrato. Esto puede permitir la reentrada, cuando el contrato externo vuelve a llamar antes de que finalice la transición de estado original. La guía oficial de Solidity recomienda ordenar cuidadosamente las comprobaciones, los efectos sobre el estado y las interacciones externas cuando corresponda.

4. Cálculos y unidades

Los auditores buscan:

• redondeo y pérdida de precisión;
• discordancia en los decimales del token;
• orden incorrecto de las operaciones;
• valores límite;
• división por cero;
• unsafe unchecked arithmetic;
• discrepancias entre las unidades internas y las mostradas.

5. Denegación de servicio y gas

Los bucles sin límite, los arrays que crecen, las llamadas externas fallidas o las operaciones costosas pueden hacer inviable la ejecución de una función. Los revisores comprueban si el diseño sigue siendo utilizable a medida que aumentan los datos y ante entradas inusuales.

6. Proxies y actualizaciones

En los sistemas actualizables, la revisión debe abarcar:

• contratos proxy y de implementación;
• permisos de actualización o administración;
• inicialización;
• compatibilidad de la disposición del almacenamiento;
• vías de actualización no autorizadas;
• el efecto de modificar la lógica después de la auditoría.

Un proxy puede conservar la misma dirección visible para el usuario mientras delega en una lógica nueva. Por tanto, las afirmaciones de que «el contrato no puede cambiar» deben contrastarse con la arquitectura real.

7. Integraciones

Los contratos pueden depender de tokens, oráculos de precios, puentes, DEX, firmas u otros contratos. Los auditores examinan las suposiciones sobre esas dependencias, los datos obsoletos, el comportamiento inusual de los tokens y los modos de fallo externos.

8. Eventos y supervisión

Los revisores pueden comprobar si los eventos muestran con precisión acciones importantes, como cambios de roles, actualizaciones, pausas y transferencias. Los eventos facilitan la supervisión, pero no sustituyen la inspección del estado.

Métodos utilizados en una auditoría

Una revisión suele combinar:

• análisis manual del código y la arquitectura;
• pruebas unitarias y de integración;
• análisis estático y dinámico;
• pruebas de fuzzing con entradas generadas;
• pruebas basadas en propiedades;
• comprobaciones de clases de vulnerabilidades conocidas;
• revisión de la compilación y el despliegue;
• en algunos casos, verificación formal de determinadas propiedades.

Ningún método por sí solo lo abarca todo. La verificación formal puede demostrar que el código cumple una especificación formal, pero no puede demostrar una propiedad que la especificación no haya expresado.

Cómo debe interpretar una auditoría el usuario

1. Comparar con la versión revisada

Busque el hash del commit y determine:

• si la implementación actual se compiló a partir de ese código;
• si se realizaron actualizaciones después de la fecha del informe;
• si la cadena y las direcciones desplegadas coinciden;
• si las dependencias críticas estaban incluidas en el alcance.

Si esto no puede determinarse, el informe aporta pruebas limitadas sobre el despliegue activo.

2. Leer los hallazgos, no solo el resumen

Para cada hallazgo, revise:

• gravedad y escenario;
• código afectado;
• recomendación;
• respuesta de los desarrolladores;
• estado actual;
• si el auditor volvió a probar la corrección.

Arreglado o Resuelto is meaningful only when tied to a specific corrected version.

3. Leer las limitaciones

Los informes pueden excluir:

• sistemas de frontend y backend;
• gestión de claves;
• diseño económico;
• contratos de terceros;
• infraestructura de despliegue;
• configuración de producción;
• cuestiones jurídicas y operativas.

Los usuarios interactúan con todo el sistema, no solo con sus archivos de Solidity.

4. Revisar el riesgo administrativo

Pregunte:

• quién controla las actualizaciones;
• si las operaciones pueden pausarse;
• si pueden cambiar las comisiones o las direcciones vinculadas;
• si existe un bloqueo temporal;
• si se utiliza una multifirma;
• cómo se informa a los usuarios de los cambios.

Estas son cuestiones de gobernanza y confianza incluso cuando no se ha detectado ninguna vulnerabilidad en el código.

5. Comprobar la seguridad después de la auditoría

Entre las medidas continuas útiles se incluyen:

• pruebas de cada versión;
• revisión de actualizaciones importantes;
• un programa de recompensas por errores;
• supervisión de funciones e implementaciones;
• procedimientos de respuesta ante incidentes;
• limitar la cantidad de activos expuestos.

Lo que una auditoría no garantiza

Una auditoría no garantiza:

• la ausencia de todos los errores;
• seguridad del código modificado después de la revisión;
• seguridad del sitio web, la billetera, el DNS o los servidores;
• seguridad de las claves con privilegios;
• corrección de los tokens, oráculos y puentes externos;
• resistencia frente a cualquier ataque económico;
• integridad de un equipo;
• cumplimiento normativo;
• liquidez del token;
• devolución de fondos;
• rendimientos fijos o de cualquier otro tipo.

Preguntas que debe formular un usuario prudente

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

Lista de comprobación del informe

• El informe está disponible a través del auditor.
• Se indican el repositorio y el hash del commit.
• Los contratos y las dependencias críticos están dentro del alcance.
• La versión revisada coincide con el despliegue activo.
• El proxy, la implementación y el administrador están cubiertos.
• El estado de los hallazgos y las nuevas pruebas están documentados.
• Se leyeron las suposiciones y exclusiones.
• Los riesgos externos al código se evaluaron por separado.

Fuentes y lecturas adicionales

1. Ethereum.org — Seguridad de contratos inteligentes
2. Ethereum.org — Pruebas de contratos inteligentes
3. Ethereum.org — Verificación formal de contratos inteligentes
4. Solidity Documentation — Consideraciones de seguridad
5. OpenZeppelin Docs — Patrón de actualización mediante proxy