---
title: "Cómo leer una auditoría de smart contracts"
description: "Una auditoría de smart contracts es una revisión acotada de código, compilaciones, despliegues, supuestos y propiedades concretos; sus hallazgos y correcciones deben conciliarse con el sistema en producción."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Cómo leer una auditoría de smart contracts
> Solo con fines educativos; no constituye asesoramiento de inversión ni de seguridad. Un informe de auditoría, resultado de una herramienta, hallazgo resuelto o archivo fuente coincidente no es una certificación, seguro, indemnización ni prueba de que un despliegue en producción sea seguro.
## Respuesta directa
Una auditoría de smart contracts examina durante un periodo declarado requisitos, código fuente, entradas de compilación, lógica de despliegue y supuestos de seguridad concretos. Los revisores combinan métodos para detectar defectos, demostrar rutas de explotación, valorar el impacto y comprobar correcciones. La conclusión solo se aplica a la instantánea y las pruebas descritas.
La instantánea debe fijar repositorio y commit o hash de árbol, submódulos y dependencias, compilador y opciones, código generado, scripts de despliegue, redes y direcciones, proxy, implementación o beacon, datos del constructor o inicializador, bibliotecas, administradores, timelocks y bloque u hora. Las exclusiones importan tanto como las inclusiones: frontend, keeper, oracle, bridge, gobernanza o firmante externo pueden dominar el riesgo sin ser auditados.
La auditoría requiere modelo de amenazas y especificación. Identifique activos, actores, roles privilegiados, fronteras de confianza, capacidades del atacante, supuestos de ordenación y reorganización, dependencias externas, transiciones y propiedades precisas de seguridad y disponibilidad. Un invariante sin unidades, precondiciones, cuantificadores y excepciones puede probar perfectamente la conducta equivocada.
Use cuatro registros: identidad de alcance, compilación y despliegue; requisitos, amenazas e invariantes; hallazgos, pruebas y retest; riesgo residual, aceptación y divulgación. Que no haya hallazgos `critical` no certifica seguridad, que uno esté `resolved` no implica que esté desplegado y una prueba solo cubre su propiedad, modelo y supuestos codificados.
## Cómo funciona
La revisión manual sigue arquitectura, fondos, estado entre funciones e intención económica. El análisis estático detecta patrones y flujos, pero genera falsos positivos y negativos. Pruebas unitarias, de integración, fork y diferenciales comparan conductas concretas. Fuzzing con estado y pruebas de invariantes exploran secuencias generadas, pero dependen de handlers, selectores, semillas, corpus, ejecuciones, profundidad y entorno modelado.
La ejecución simbólica y la verificación formal pueden demostrar ciertas aserciones bajo semánticas y supuestos compatibles. Un resultado `unknown`, timeout o conducta no compatible no es una prueba. Incluso una propiedad demostrada puede omitir economía del oracle, gobernanza, configuración, conducta de la red o el requisito realmente pretendido. La revisión humana controla especificación e interpretación; una observación generada por IA no es un método de aseguramiento independiente.
Cada hallazgo debe identificar artefacto y despliegue afectados, prerrequisito, prueba mínima, ruta, accesibilidad, privilegios, capital, repetibilidad, impacto económico, rúbrica y recomendación. Explotabilidad o probabilidad e impacto son dimensiones distintas. Un máximo teórico, nombre de vulnerabilidad o etiqueta de herramienta no establece pérdida ejecutable.
Estados como `open`, `acknowledged`, `risk accepted`, `partially fixed`, `resolved` y `retested` no son estándares universales. Un cierre defendible vincula el problema al commit exacto, registra rutas modificadas y adyacentes probadas y quién volvió a probar qué y cuándo. El riesgo aceptado sigue siendo riesgo y un retest limitado no amplía el alcance al código nuevo.
Los despliegues actualizables requieren conciliación especial. Resuelva slots de proxy, implementación o beacon y administrador; verifique inicializador y reinicializador, bloqueo de implementación, compatibilidad de almacenamiento, autorización de upgrade, timelock o bypass, migración y reversión. Reproduzca bytecode de creación y runtime y compare bibliotecas, parámetros, roles y estado inicializado en cada red.
El informe final debe indicar revisión, auditores, fechas, alcance, métodos y configuraciones, límites, hallazgos, pruebas, remediación, riesgos abiertos o aceptados y términos de divulgación. Después, supervise hashes de implementación, roles, parámetros, dependencias e incidentes. Todo cambio material crea un delta nuevo; un distintivo antiguo no acompaña automáticamente al código futuro.
Proceso:
1. Congele manifiesto: repositorio, commit, dependencias, compilador, opciones, código generado y de despliegue, redes, direcciones, pila proxy, parámetros, bloque, revisión, inclusiones y exclusiones.
2. Defina activos, actores, roles, fronteras, capacidades, ciclo de vida, supuestos de ordenación y disponibilidad, dependencias e invariantes medibles.
3. Reproduzca la compilación y mapee arquitectura, almacenamiento, datos, fondos y control; concilie fuente, artefactos, bibliotecas, bytecode, inicializador, roles y despliegue.
4. Ejecute revisión manual, análisis estático, pruebas unitarias, integración, fork, diferenciales, fuzz, invariantes, métodos simbólicos o formales, registrando versiones, configuración, semillas, corpus, cobertura, timeouts e incógnitas.
5. Registre artefacto, prerrequisito, prueba, explotabilidad, impacto, método de gravedad, exposición, recomendación y pruebas confidenciales sin sustituir juicio por etiqueta de herramienta.
6. Congele el commit de corrección y vuelva a probar problema, rutas e invariantes; valide almacenamiento proxy, inicialización, migración, rollback, compilación reproducible y recibos antes de asignar estado.
7. Publique alcance, métodos, límites y riesgos; concilie artefactos con cada red y mantenga actualizados supervisión, divulgación, respuesta y bug bounty al cambiar el sistema.
## Ejemplos
- **Una inflación de vault exige un registro completo.** El atacante deposita `1 asset` y recibe `1 share`; dona `1,000,000 assets`, quedando `1,000,001 assets` y `1 share`. La víctima deposita `500,000 assets` y el redondeo inseguro da `floor(500,000 * 1 / 1,000,001) = 0 shares`. Si se acepta, el vault guarda `1,500,001 assets`; el atacante los rescata y gana `500,000 assets` sobre su aportación de `1,000,001-asset`. Si revierte con cero shares, esta pérdida no se ejecuta.
- **Cobertura de archivos no es cobertura del despliegue.** El manifiesto contiene `24 source units`, `4 deployment scripts` y `3 keeper services`: `31 items`. Se incluyen `20 source units` y `2 scripts`; cobertura `22 / 31 = 70.96774194%`, con `9 items` excluidos. Si el proxy usa una unidad excluida, la cobertura de esa implementación es `0%` pese al titular `70.96774194%`.
- **Las observaciones fuzz no prueban ausencia.** Una ejecución hace `2,000 sequences * 64 calls = 128,000 calls`; falla en `3 sequences`, un `3 / 2,000 = 0.15%`. Tras corregir, `10,000 sequences * 64 calls = 640,000 calls` no fallan. Es cero en ese corpus, no una prueba; suponiendo independencia y generador estable, el límite superior aproximado al `95%` por regla de tres es `3 / 10,000 = 0.03%` por secuencia.
- **Cierre e identidad del despliegue son independientes.** Hay `12 findings`: `2 critical`, `3 high`, `4 medium` y `3 low`. El retest cierra `2 + 2 + 3 + 2 = 9`: `9 / 12 = 75%`; queda uno high, uno medium y uno low. El hash auditado es `H1`, pero la implementación en producción es `H2`; la verificación falla. Sustituirla por `H1` y conciliar slot, inicializador y roles prueba identidad solo en el bloque comprobado.
## Riesgos
- Repositorio, commit, submódulo o fuente generada son obsoletos o ambiguos.
- Compilador, optimizador, bibliotecas o dependencias no están fijados.
- Scripts, constructor, inicializador o salt CREATE2 quedan excluidos.
- Se inspecciona red, dirección, proxy, beacon o implementación equivocados.
- Fuente, artefacto y bytecode de creación y runtime no concilian.
- El modelo omite actor, privilegio, activo o frontera de confianza.
- La especificación o invariante tiene unidades, precondiciones o excepciones erróneas.
- Se omiten rutas de admin, guardian, timelock, pausa, upgrade o migración.
- Fallan supuestos de oracle, token, bridge, keeper, gobernanza o red.
- El análisis estático produce un falso positivo no triado.
- Revisión, pruebas o fuzzing omiten una ruta no generada.
- Harness, selector, semilla, corpus, profundidad o modelo están sesgados.
- Timeout, semántica no compatible o `unknown` se confunden con prueba.
- Una prueba correcta formaliza un requisito o sistema incompleto.
- La gravedad se ancla al nombre y no a explotabilidad e impacto.
- El valor teórico se confunde con pérdida alcanzable o beneficio.
- Una corrección introduce regresión o rompe un invariante económico.
- Almacenamiento, inicializador, upgrade o migración corrompen el estado.
- Un problema aceptado, abierto o parcial queda oculto por el distintivo.
- El informe se trata como seguro, certificación, indemnización o cobertura permanente.
## Errores comunes
- **«Sin hallazgos críticos, el contrato es seguro».** Solo describe hallazgos en un alcance, tiempo y métodos limitados.
- **«Alta cobertura o cero fallos fuzz prueban que no hay errores».** Miden código seleccionado y rutas generadas, no ausencia.
- **«La verificación formal demuestra que todo el protocolo es seguro».** Demuestra propiedades del modelo bajo supuestos; especificación y entorno aún pueden fallar.
- **«Resuelto significa que todos los despliegues están corregidos».** Exige retest independiente y conciliación de compilación, bytecode, proxy, parámetros y roles.
- **«Un auditor reputado garantiza indemnización o upgrades futuros».** La responsabilidad depende del contrato y el código posterior queda fuera de la instantánea.
## Temas relacionados
- [Smart contract](/es/crypto/smart-contract/)
- [Contrato actualizable](/es/crypto/upgradeable-contract/)
- [Bug bounty](/es/crypto/bug-bounty/)
## Fuentes
- [OWASP Smart Contract Security Verification Standard (SCSVS)](https://scs.owasp.org/SCSVS/) - OWASP (consultado: 2026-08-13)
- [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity (consultado: 2026-08-13)
- [Slither, the smart contract static analyzer](https://github.com/crytic/slither) - Crytic (consultado: 2026-08-13)
- [Invariant Testing](https://www.getfoundry.sh/guides/invariant-testing) - Foundry (consultado: 2026-08-13)
- [Certora User's Guide](https://docs.certora.com/en/latest/docs/user-guide/index.html) - Certora (consultado: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultado: 2026-08-13)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (consultado: 2026-08-13)
- [Contract Metadata](https://docs.soliditylang.org/en/latest/metadata.html) - Solidity (consultado: 2026-08-13)
Source: https://wiki.fcontext.com/es/crypto/contract-audit/index.mdx