Checklist previa a la auditoría de smart contracts: 30 preguntas

Wavect no presenta esta lista como una auditoría independiente. Es una revisión de refuerzo previa a la auditoría para contratos EVM. Una checklist puede revelar evidencia ausente y riesgos comunes, pero no demuestra que un contrato sea seguro, económicamente sólido, esté bien integrado o sea seguro en cada cadena y despliegue.

Limita la revisión al código fuente, compilador, ajustes, dependencias, bytecode generado, patrón de proxy, cadena, direcciones, roles, activos, integraciones, scripts de despliegue y procedimientos operativos exactos. Usa documentación actual de Solidity, errores conocidos del compilador, un modelo de amenazas y un estándar más amplio. Son útiles las consideraciones de seguridad de Solidity, la lista de errores conocidos, el OWASP Smart Contract Security Verification Standard y la lista actual de la EEA de la especificación EthTrust Security Levels.

¿Cómo debe usarse la checklist?

Responde cada pregunta con una referencia de código, prueba, resultado de herramienta, artefacto de despliegue, control operativo o aceptación explícita del riesgo. Aprobar significa que la evidencia acordada respalda el requisito acotado, no que toda la categoría sea segura. Un fallo material debe corregirse, retirarse del alcance o ser aceptado por un responsable autorizado, registrando consecuencias, controles compensatorios y seguimiento.

Análisis estático, fuzzing, invariantes, métodos formales, pruebas de fork y revisión manual encuentran problemas distintos. Ningún número fijo de seeds ni regla de cero warnings sirve para todo código. Define propiedades y cobertura relevantes, clasifica falsos positivos, conserva versiones y configuraciones, y explica la incertidumbre residual.

Categoría 1: especificación y toolchain (preguntas 1 a 5)

1. ¿Está especificado el comportamiento? Identifica activos, actores, privilegios, supuestos de confianza, transiciones, invariantes, fallos y resultados prohibidos.
2. ¿Es reproducible el build? Fija compilador publicado, EVM, optimizer, IR, dependencias, generadores y comandos; compara bytecode y metadatos desplegados.
3. ¿Se comprobaron los riesgos del compilador? Contrasta la versión elegida con la lista actual legible por máquinas y la guía de actualización.
4. ¿Se resolvieron los findings automáticos? Ejecuta checks, linters y analizadores adecuados, clasifica cada resultado material y documenta supresiones justificadas.
5. ¿Las pruebas apuntan a propiedades? Combina ejemplos, límites, casos negativos, fuzzing, invariantes, integración y checks diferenciales o formales cuando aporten valor.

Categoría 2: privilegios y ciclo de vida (preguntas 6 a 10)

6. ¿Está mapeada cada acción privilegiada? Registra quién puede pausar, actualizar, acuñar, quemar, incautar, configurar, retirar, rescatar o cambiar dependencias.
7. ¿El control corresponde al riesgo? Evalúa custodia, quorum, independencia, timelocks, autoridad de emergencia, disponibilidad, recuperación y carga operativa, en vez de prohibir un tipo de cuenta.
8. ¿Son seguras las concesiones, transferencias, revocaciones y renuncias? Prueba transiciones intencionadas y erróneas, estados pendientes, firmantes perdidos y la ruta del último administrador.
9. ¿Están protegidos inicialización y despliegue? Evita inicialización no autorizada, front-running, parámetros o direcciones erróneos y estado de implementation o proxy sin verificar.
10. ¿Están acotados los controles de emergencia? Define disparadores, autoridad, impacto, comunicación, evidencia, reactivación o recuperación y qué ocurre si falla el propio control.

Categoría 3: activos, aritmética y economía (preguntas 11 a 15)

11. ¿Son explícitos los dominios numéricos? Comprueba unidades, precisión, dirección de redondeo, límites, casts, signos y bloques unchecked justificados.
12. ¿Están verificados los supuestos de tokens? Trata decimales, retornos, callbacks, tasas, rebasing, pausas, blocklists y comportamientos no estándar según cada integración.
13. ¿Se prueban propiedades de conservación? Define cómo cuadran depósitos, retiros, comisiones, recompensas, deuda, colateral y polvo en cada transición.
14. ¿Están acotados los supuestos de oráculo y mercado? Prueba frescura, coste de manipulación, conversión decimal, caída de secuenciador o mercado, fallback y liquidación.
15. ¿Se modeló conducta económica adversarial? Examina orden, MEV, liquidez flash, griefing, captura de gobernanza, bucles de incentivos y estados rentables que un check de código puede omitir.

Categoría 4: llamadas externas y composabilidad (preguntas 16 a 20)

16. ¿Puede reentrar alguna interacción externa? Analiza rutas de misma función, entre funciones y contratos, read-only, hooks, tokens y callbacks, sin confiar mecánicamente en un guard.
17. ¿Son correctos efectos y rollback? Usa checks-effects-interactions u otro diseño justificado y prueba fallos parciales y llamadas anidadas.
18. ¿Se interpreta el retorno según la interfaz real? Trata éxito, revert, datos vacíos o malformados y tokens no estándar según el contrato requerido, no una regla universal de longitud.
19. ¿Puede una dependencia bloquear el progreso? Prueba contratos externos no disponibles, con revert, caros, maliciosos, pausados o actualizados y define aislamiento o recuperación.
20. ¿Son seguros approvals y firmas? Revisa carreras de allowance, dominios de nonce y replay, plazos, vínculo a cadena y contrato, maleabilidad y validación de smart accounts.

"Una checklist previa a la auditoría sirve cuando cada respuesta apunta a evidencia y riesgo residual. Una fila de casillas verdes no es una prueba de seguridad."

Categoría 5: upgrades y storage (preguntas 21 a 25)

21. ¿Es explícito el modelo de upgrade? Registra tipo de proxy, descubrimiento de implementation, autoridad, demora, rollback, inicialización y límite de compatibilidad.
22. ¿Está validada la compatibilidad de storage? Compara layouts con herramientas que entiendan patrón, herencia, packing y namespaced storage; no asumas un gap fijo universal.
23. ¿Están protegidos los contratos de implementation? En patrones aplicables, bloquea su inicialización y valida parent initializers y reinitializers. Si usas ese stack, sigue la guía actual de OpenZeppelin.
24. ¿Es correcta la autorización para el patrón? Prueba quién selecciona y ejecuta un upgrade, por qué proxy o gobernanza, incluida la cancelación y una autoridad comprometida.
25. ¿Se ensayó la migración real? Carga estado representativo, actualiza por la ruta de producción, verifica invariantes e integraciones, prueba fallo y recuperación y conserva artefactos.

Categoría 6: disponibilidad, despliegue y operaciones (preguntas 26 a 30)

26. ¿Puede el crecimiento controlado por usuarios superar límites? Acota o pagina bucles y lotes, y prueba peores casos realistas frente a reglas actuales de la cadena objetivo.
27. ¿Puede gas o revert causar denegación de servicio? Analiza pagos push, callbacks, llamadas, reembolsos, atomicidad y griefing sin depender de un porcentaje arbitrario de gas del bloque.
28. ¿Es determinista y verificado el despliegue? Comprueba parámetros, salts, librerías, owners, roles, implementations, verificación de fuente, chain IDs, fondos y entrega.
29. ¿Están listos monitorización y respuesta? Define eventos, monitores de invariantes o balances, alertas, responsables, respuesta a claves comprometidas, criterios de pausa, comunicación y conservación de evidencia.
30. ¿Están controlados lanzamiento y salida? Establece límites de valor y tasa, rollout gradual, contingencias de dependencia y cadena, recuperación del usuario, efectos de upgrade o inmutabilidad y retirada.

¿Por qué no enviar código inacabado directamente al auditor?

El tiempo de revisión independiente suele aportar más cuando requisitos, artefactos, pruebas, findings conocidos, privilegios y planes son coherentes. Esto no justifica tarifas universales, una reducción prometida de findings ni un lanzamiento garantizado más barato o rápido. Alcance, complejidad, equipo, retests, política y calendario varían.

Pregunta qué debe congelarse, qué artefactos necesitan, cómo tratan cambios y retests, qué cadenas e integraciones cubren y cómo clasifican findings. Compara el mismo alcance por escrito. El revisor externo debe poder cuestionar libremente los supuestos.

¿Quién aprueba?

Asigna un responsable técnico por pregunta y un responsable de negocio o gobernanza autorizado por cada riesgo material aceptado. Incluye referencias de commit y bytecode, evidencia de pruebas y herramientas, configuración, supuestos abiertos y change log. El revisor independiente decide cuánto confiar en ese material.

Los cambios posteriores pueden invalidar la evidencia. Define cuáles exigen nuevo análisis o auditoría y condiciona el despliegue al artefacto aprobado actual, no a una checklist obsoleta.