Checklist de Seguridad de Smart Contracts: 30 Ítems que Verificamos Antes de la Auditoría Externa

No auditamos. Lanzamos y endurecemos código de smart contracts, luego firmas externas lo auditan. Antes de que se abra esa ventana de auditoría, corremos esta checklist pre-auditoría de 30 ítems en 6 categorías: compiler y toolchain, control de acceso y roles, aritmética y overflow, llamadas externas y reentrancy, upgradability y storage, superficies de gas y DoS. Cada ítem de abajo nos ha quemado a nosotros o a un peer en un engagement real. Limpiar los 30 ha recortado los conteos de findings de auditoría en nuestros handovers aproximadamente un 60 a 80 por ciento en nuestro historial de engagements, lo que significa auditorías más baratas y mainnet más rápido.

Esta es la lista que nos hubiera gustado que alguien nos pasara el día uno de Scramble Pay, Quivr, Lightbridge y nuestro trabajo de Account Abstraction. No lo llamamos auditoría. Es una revisión de hardening, diseñada para que la auditoría sea aburrida.

¿Qué chequea realmente una revisión de hardening pre-auditoría de smart contracts?

Seis categorías, cinco ítems cada una, treinta ítems en total. Tratamos la checklist como una puerta. Si un ítem falla, el contrato no sale de nuestro repo hasta que esté arreglado o explícitamente waivado por escrito por el cliente con una razón. Lo emparejamos con nuestro flujo TDD y nuestro servicio de QA para que cada fix aterrice con un test de regresión.

Categoría 1: Compiler y toolchain (ítems 1 a 5)

1. Versión de Solidity pinned. Bloquea una sola versión de compiler en foundry.toml o hardhat.config. Pragmas flotantes como ^0.8.20 significan que dos desarrolladores pueden compilar dos bytecodes distintos del mismo source.
2. Settings del optimizer declarados y reproducibles. Documenta el valor de optimizer runs. La verificación en Etherscan falla por mismatch y un auditor quemará una hora antes de señalarlo.
3. SMTChecker y Slither pasan con cero findings sin suprimir. Cada supresión tiene un comentario inline nombrando al auditor o ingeniero que la waivó. Sin supresiones silenciosas.
4. Tests Foundry fuzz e invariant corren en CI con alta cuenta de seeds. Requerimos al menos 10.000 fuzz runs y 256 invariant runs por función crítica antes del handoff de auditoría.
5. Lockfile de dependencias committeado y auditado. Versiones de OpenZeppelin y Solady pinned. Sin dependencias git apuntando a main. Hacemos diff de cada upgrade de dependencia.

Categoría 2: Control de acceso y roles (ítems 6 a 10)

6. Cada función privilegiada tiene un check de rol explícito. No onlyOwner por defecto. Mapeamos cada función a un rol y documentamos quién lo tiene en deployment.
7. Ningún EOA tiene admin keys en el launch a mainnet. Multisig o timelock. Punto. Hemos visto compromiso de admin single-key en proyectos peer y termina el proyecto.
8. Transferencia de ownership en dos pasos. Ownable2Step o equivalente. Un typo en una transferencia de un paso es irrecuperable.
9. Caminos de renounce y revoke de roles testeados. ¿Se puede renunciar realmente al DEFAULT_ADMIN_ROLE sin brickear el protocolo? Testealo.
10. Protección de initializer en contratos upgradeables. _disableInitializers() en el constructor de cada contrato de implementación, sin excepciones.

Categoría 3: Aritmética y overflow (ítems 11 a 15)

11. Solidity 0.8+ usado y bloques unchecked justificados inline. Cada bloque unchecked tiene un comentario explicando por qué el overflow es imposible en el call site.
12. Orden de división verificado. Multiplica antes de dividir donde la precisión importe. Hacemos grep de / en rutas financieras y revisamos cada una.
13. La matemática de fees y porcentajes usa basis points o una constante de precisión definida. Sin decimales raw. Documenta la constante y úsala en todos lados.
14. Mismatches de decimales de tokens manejados. USDC tiene 6 decimales, WETH tiene 18. Testeamos cada par con un fork test contra direcciones de tokens en mainnet.
15. Checks de casting. Cada uint256 a uint128 o menor tiene un check de bound explícito o SafeCast.

Categoría 4: Llamadas externas y reentrancy (ítems 16 a 20)

16. Checks-Effects-Interactions enforced. Las actualizaciones de estado ocurren antes de cualquier llamada externa. Revisamos cada llamada externa a mano.
17. ReentrancyGuard en cada función que hace una llamada externa y modifica estado. Por defecto on, opt out solo con justificación.
18. Reentrancy cross-function testeada. Una llamada reentrant a una función hermana con estado compartido es el clásico vector que se pasa por alto. Lo fuzzeamos.
19. Callbacks de tokens no confiables manejados. ERC777, ERC1155 onERC1155Received, ERC721 onERC721Received. Asume que cualquier token externo es hostil.
20. Longitud de return data chequeada en llamadas low-level. (bool ok, ) = target.call(...) sin check de return data es un fallo silencioso esperando a ocurrir.

"El hardening es lo que hace aburrida a la auditoría. Las auditorías aburridas salen a producción."

Categoría 5: Upgradability y storage (ítems 21 a 25)

21. Storage layout documentado y diffeado en cada upgrade. Corremos forge inspect storage layout antes y después, y rechazamos cualquier slot reordenado.
22. Storage gaps reservados en cada parent upgradeable. uint256[50] private __gap; según convención OpenZeppelin.
23. Lógica de constructor movida a initializer para proxies. Cualquier cosa en un constructor en un contrato upgradeable es un bug.
24. authorizeUpgrade de UUPS tiene un check de rol. El scaffolding por defecto de OpenZeppelin lo deja abstracto. Asegúrate de que esté implementado y protegido.
25. Camino de upgrade testeado end-to-end en un fork. Deploya V1, popula estado, hace upgrade a V2, verifica el estado intacto. Obligatorio.

Categoría 6: Superficies de gas y DoS (ítems 26 a 30)

26. Loops no acotados eliminados o paginados. Cualquier loop sobre un array que los usuarios puedan hacer crecer es un vector DoS. Refactorizamos a patrones pull-based.
27. Headroom del block gas limit verificado. Ninguna función única debería exceder aproximadamente el 30 por ciento del block gas limit bajo tamaño de estado realista.
28. Stipends de gas de llamadas externas manejados. Reenviar todo el gas a contratos no confiables puede habilitar griefing. Limitamos o usamos try/catch.
29. Escrituras de storage minimizadas en hot paths. Los slots de storage calientes se empaquetan. Medimos con forge snapshot y rechazamos regresiones de más del 5 por ciento.
30. Superficie de front-running y MEV documentada. Commit-reveal, params de slippage o params de deadline donde sea relevante. Si el protocolo está expuesto a ataques de sandwich, el usuario lo sabe antes de mainnet.

¿Por qué existe esta checklist en lugar de simplemente contratar un auditor?

Los auditores cobran por línea de código y por día. Enviar código no endurecido a una auditoría es pagar a ingenieros senior €2.000 a €4.000 por día para encontrar bugs que tu propio equipo podría haber atrapado con Slither y un fuzz harness. En nuestro historial de engagements, los proyectos que completaron los 30 ítems antes del handoff de auditoría volvieron con conteos de findings de auditor en un dígito, la mayoría informacionales. Los proyectos que se saltaron la checklist rutinariamente volvieron con 30+ findings incluyendo críticos, lo que luego requirió una re-auditoría a coste completo.

Esta es la diferencia entre Wavect y una shop generalista. Ver Wavect vs una agencia de desarrollo generalista para el contexto completo. Construimos sistemas Web3 con una cadencia security-first integrada en nuestro servicio blockchain, para que la auditoría se vuelva un sign-off en lugar de un rescate.

¿Quién es dueño de la checklist en un proyecto?

El tech lead de Wavect en el engagement. Firma cada ítem con una referencia a commit y una referencia a test. El cliente recibe la checklist firmada como parte del paquete de handover de auditoría, que el auditor externo recibe junto al código. A los auditores les encanta esto porque les dice dónde enfocar su atención.