¿Cuánto cuesta una auditoría de smart contract?

Qué estás comprando (y por qué eso define el precio)

Antes de discutir números, conviene alinear qué es una auditoría de smart contract. No es un escaneo automático de cinco minutos, ni un sello. Es una revisión de seguridad realizada por especialistas humanos sobre el código que va a correr de forma inmutable en la blockchain, controlando dinero real. El entregable es un informe que lista cada vulnerabilidad encontrada, su severidad, cómo explotarla (prueba de concepto) y cómo corregirla, seguido de un retest que confirma si las correcciones funcionaron. El precio varía tanto porque lo que se compra varía tanto: revisar un token ERC-20 de 200 líneas es fundamentalmente distinto de auditar un protocolo de préstamos con oráculos, gobernanza y puentes cross-chain.

La razón por la que los smart contracts justifican una auditoría cara y dedicada es su característica más peligrosa: la inmutabilidad y la custodia directa de fondos. Una aplicación web común con un bug puede corregirse con un deploy de urgencia; un smart contract, una vez publicado, con frecuencia no puede modificarse, y sostiene el dinero de los usuarios directamente, sin banco intermediario, sin chargeback, sin soporte para revertir. Cuando alguien explota la falla, el saldo sale de la billetera del contrato en una sola transacción y cae en una dirección del atacante, normalmente para nunca más volver. No existe 'llamar al banco y cancelar'.

Esto cambia la economía de la decisión de compra. En seguridad de aplicaciones tradicional, ponderas el costo de la prueba contra la probabilidad y el impacto de un incidente. En Web3, el impacto de un solo bug crítico es, con frecuencia, el 100% del TVL (Total Value Locked, el valor total bloqueado en el contrato). Si tu protocolo va a custodiar US$ 10 millones, ahorrar US$ 30 mil en una auditoría superficial para luego perder los US$ 10 millones no es ahorro: es la peor asignación de capital posible. El precio de la auditoría debe leerse como una fracción de lo que protege, no como un gasto aislado de TI.

Los factores que determinan el precio, uno a uno

El primer y más importante factor es el tamaño del código, medido en nSLOC (non-comment source lines of code, líneas de código fuente sin comentarios). Casi todo auditor y plataforma cotiza por nSLOC, porque aproxima el tiempo de lectura humana. Las referencias de mercado mapean tamaño a plazo de forma casi lineal: cerca de 500 nSLOC consumen ~3 días de auditoría; 3.000 nSLOC, ~18 días; 6.000 nSLOC, ~38 días. Como el costo es mayoritariamente horas de especialista, el precio escala junto. Por eso la primera pregunta honesta de cualquier proveedor serio es '¿cuántas nSLOC hay en el alcance?', y por eso debes enviar el repositorio (o el commit hash exacto) para recibir un presupuesto real, no una estimación al azar.

El segundo factor es la complejidad de la lógica, que no se captura solo por el número de líneas. Mil líneas de un token estándar son triviales; mil líneas de un AMM con matemática de curvas, rebase y hooks son una pesadilla. La lógica de negocio sofisticada —préstamos colateralizados, oráculos de precio, gobernanza, staking, puentes cross-chain, contratos actualizables vía proxy— multiplica el número de estados posibles y de interacciones entre contratos, que es exactamente donde viven las fallas más caras. En la edición 2025 del OWASP Smart Contract Top 10, la manipulación de oráculo de precio (SC02) y los errores de lógica de negocio (SC03) aparecen en el tope justamente porque esas fallas pasan por controles de bajo nivel correctos y aun así permiten la extracción de valor.

El tercer factor es el lenguaje y la cadena. Solidity (EVM) es el baseline porque tiene el mayor pool de auditores. Todo lo que se aparta de él cobra prima por escasez de especialistas: Rust/Solana cuesta típicamente entre 25 y 40% más; Cairo (StarkNet) y Move (Sui/Aptos), entre 30 y 45% más; y los circuitos de conocimiento cero (ZK) llegan a estar entre 80 y 120% por encima del baseline EVM, porque exigen auditores que entiendan criptografía avanzada además de programación. Trata estas primas como órdenes de magnitud, no como tarifa: el multiplicador real depende de la firma y de la oferta de especialistas en ese momento. El cuarto factor es la profundidad de los métodos: una revisión solo manual es más barata y más superficial; sumar verificación formal (probar matemáticamente propiedades del contrato), fuzzing (bombardear el código con entradas aleatorias para hallar estados rotos) y prueba de invariantes encarece, pero es lo que separa una auditoría de estante de una a la altura de un protocolo que sostiene millones.

El quinto factor es el retest posterior a la corrección (re-audit), que mucha gente olvida presupuestar y que cuesta típicamente US$ 5.000–20.000 por ronda. No es opcional: corregir un bug puede introducir otro, y sin el retest estás haciendo deploy de código que nadie validó después del último cambio. El sexto es la urgencia: pedir resultados en una semana en lugar de cuatro agrega típicamente entre 20 y 40% al valor, porque obliga al proveedor a reasignar equipo. Y el séptimo es la reputación y el historial del auditor: firmas e investigadores con track record comprobado, con vulnerabilidades reales documentadas y su nombre en juego, cobran más, y entregan un nivel de rigor (y de credibilidad ante inversionistas y usuarios) que justifica la diferencia.

Rangos reales de precio por complejidad y alcance

La tabla de referencia trae rangos honestos del mercado, en dólares —moneda estándar de cotización en el sector Web3, incluso para proyectos brasileños, porque el pool de auditores es global y los equipos de élite cobran en USD—. Trata estos valores como puntos de partida para dimensionar tu presupuesto, no como tarifa fija: el precio final siempre depende del alcance exacto (nSLOC, lenguaje, profundidad, plazo). Un número cerrado solo se define después de que el proveedor lea el repositorio en el commit que va a producción. Desconfía de cualquier cotización 'a ciegas' que llegue antes de eso: un precio dado sin ver el código es marketing, no presupuesto.

Nota que la mayoría de los protocolos DeFi de complejidad media —el caso más común de quien está leyendo esto— aterriza entre US$ 25.000 y US$ 100.000 para la auditoría inicial, y una reserva prudente para 2026 es separar US$ 60.000–120.000 incluyendo ya al menos una ronda de retest. Cuando el presupuesto aprieta, el error clásico es recortar la profundidad (quitar fuzzing y verificación formal) o saltarse el retest. Ambos recortes atacan justamente las etapas que atrapan los bugs más caros. Si el presupuesto no soporta la auditoría que tu TVL exige, la respuesta correcta rara vez es una auditoría peor: es reducir la superficie (lanzar con TVL limitado, con timelock y con circuit breakers) hasta poder pagar la revisión a la altura.

Conviene también separar 'auditoría' de 'pre-auditoría' o 'revisión rápida'. Una pre-auditoría de un contrato de 500 líneas puede salir por US$ 1.500–3.000 y sirve para atrapar lo obvio antes de la auditoría de verdad, pero no sustituye la auditoría completa, y presentarla como tal a inversionistas o usuarios es, en el mejor de los casos, engañoso. Los programas de bug bounty (recompensa por fallas encontradas por la comunidad) y las auditorías en formato de concurso son complementos válidos después del lanzamiento, no sustitutos de la auditoría inicial dirigida a tu código antes del deploy.

Por qué la auditoría barata es la más cara que existe

La tentación de tomar el presupuesto más bajo es comprensible, y casi siempre es un error de cálculo. Los datos del sector lo dejan brutalmente claro. Según Chainalysis, el robo de criptoactivos sumó cerca de US$ 2,2 mil millones en 2024 y superó los US$ 3,4 mil millones en 2025, un récord histórico. A nivel de falla de código, la edición 2025 del OWASP Smart Contract Top 10 (compilada a partir de incidentes documentados en 2024) muestra que la categoría de control de acceso (SC01) representó por sí sola aproximadamente US$ 953 millones en pérdidas; los errores de lógica de negocio, ~US$ 63,8 millones; la reentrada, ~US$ 35,7 millones; los ataques vía flash loan, ~US$ 33,8 millones. Son exactamente las clases de bug que una auditoría profunda encuentra y una superficial deja pasar.

La asimetría es el punto central. Una falla de control de acceso —una función privilegiada que cualquiera puede llamar, un proxy mal configurado, un inicializador que puede reejecutarse— no genera un perjuicio proporcional al bug. Genera el 100% del contrato. El atacante no 'rasguña' el protocolo; lo vacía. Y como la transacción es on-chain, final e irreversible, no hay SLA de incidente, no hay restauración de backup, no hay negociación con la operadora de tarjeta. El dinero se va y, según Chainalysis, fluye de inmediato hacia el lavado vía otros protocolos DeFi, que fueron la ruta de entrada de lavado con mayor crecimiento (+370%) en los primeros días tras los grandes robos del período.

Hay además un costo que no aparece en el balance: la confianza. Un protocolo que sufre un exploit pierde no solo el TVL de ese momento, sino la credibilidad que sostenía el TVL futuro. Los usuarios se van, los socios retroceden, las listings se traban, y el equipo gasta meses en post mortem, comunicación de crisis y, muchas veces, en intentar reembolsar de su propio bolsillo. Suma todo y el 'ahorro' de US$ 50 mil en una auditoría adecuada se convierte en un perjuicio de siete u ocho dígitos. La lectura honesta es simple: el precio de la auditoría correcta es siempre una fracción del precio de no haberla hecho.

Qué entrega un buen informe de auditoría

Saber qué contiene un buen informe es tu mejor defensa contra pagar caro por poco. Primero, un alcance explícito y verificable: qué archivos y qué commit hash fueron auditados. Parece obvio, pero es donde los proveedores flojos resbalan: auditan un commit y el equipo hace deploy de otro. El informe necesita fijar exactamente lo que se revisó, para que nadie pueda alegar una cobertura que no existió.

Segundo, cada hallazgo debe traer severidad clasificada (crítica/alta/media/baja/informativa, idealmente anclada en impacto y probabilidad, en el espíritu del CVSS), una descripción técnica precisa, una prueba de concepto (PoC) que demuestre la explotación —no apenas 'esto parece riesgoso', sino el paso a paso que drena los fondos— y una recomendación de corrección accionable. El buen informe también mapea los hallazgos a un referencial reconocido, como el OWASP Smart Contract Top 10. En la edición 2025, el orden es SC01 control de acceso, SC02 manipulación de oráculo de precio, SC03 errores de lógica, SC04 falta de validación de entrada, SC05 reentrada, SC06 llamadas externas no verificadas, SC07 flash loans, SC08 overflow/underflow de enteros, SC09 aleatoriedad insegura y SC10 denegación de servicio; ese mapeo permite a cualquier tercero auditar la auditoría.

Tercero, y lo más importante para la decisión de compra: la carta de retest (re-audit). Un informe que lista 12 problemas y termina ahí está a mitad de camino. El entregable completo incluye una segunda ronda, después de que tu equipo corrigió, confirmando hallazgo por hallazgo qué fue remediado, qué fue mitigado parcialmente y qué el equipo decidió aceptar como riesgo residual (con justificación). Es esa carta final, y no el informe inicial, la que muestras a inversionistas, socios y usuarios. Sin ella, tienes un diagnóstico, no una garantía de que el paciente fue tratado.

Por último, transparencia y reputación verificable. Los buenos auditores publican informes anteriores, tienen vulnerabilidades reales documentadas a su nombre y aceptan que el informe final sea público. Desconfía de proveedores que ofrecen 'sello' sin informe, que se niegan a divulgar el alcance, o que prometen 'aprobación garantizada': una auditoría seria no promete aprobación, promete rigor; y un informe que no encuentra nada en un protocolo complejo es, en sí mismo, motivo de sospecha, no de celebración.

Cómo contratar bien: dimensionar y comparar proveedores

Comienza dimensionando tu propio alcance antes de pedir cotización, para conversar de igual a igual. Cuenta las nSLOC de lo que realmente va a producción (herramientas como solidity-metrics o cloc lo resuelven), lista el lenguaje/cadena, identifica si hay lógica de alto riesgo (oráculos, gobernanza, puentes, proxies actualizables) y estima el TVL objetivo. Esos cuatro números —tamaño, lenguaje, complejidad y valor protegido— definen la mayor parte del precio y te permiten comparar propuestas sobre la misma base, en lugar de comparar peras con manzanas.

Al comparar proveedores, pide siempre: dos o tres informes anteriores de complejidad parecida a la tuya; la metodología explícita (¿solo manual? ¿manual + fuzzing + verificación formal?); quién exactamente va a auditar (¿el sénior que vendió o un júnior que nadie vio?); el plazo realista; y si el retest está incluido o se cobra aparte. Un diferencial honesto: pregunta por hallazgos críticos reales que hayan encontrado en auditorías pasadas. Quien tiene track record responde con ejemplos concretos; quien vende sello desvía la conversación. Las cotizaciones muy por debajo del rango de mercado para tu nSLOC no son ganga: son señal de profundidad insuficiente o de subcontratación opaca.

Por último, encaja la auditoría en el ciclo de seguridad correcto, porque por sí sola no cubre todo. La auditoría de smart contract mira el código on-chain, pero, como muestran los propios datos de Chainalysis, buena parte de las mayores pérdidas de 2025 vino de fuera del contrato: compromiso de claves privadas, secuestro de multisig, ataques a la cadena de suministro, phishing a operadores y malware drenador. El mayor robo de la historia hasta ahora, el de Bybit (US$ 1,5 mil millones, en febrero de 2025), no fue un bug de smart contract: fue el compromiso del proceso operativo de firma. Por eso Decripte trata la seguridad Web3 como un conjunto. Para el código on-chain, el frente es la auditoría de smart contract en /plano/web3-security. Para la infraestructura, la custodia, la gestión de claves y la operación del exchange o del tesoro, entra la prueba ofensiva en /plano/seguranca-ofensiva, que ataca justamente los vectores off-chain que la auditoría de código no ve. Y para el monitoreo continuo de amenazas, exposición de credenciales y actividad sospechosa ligada a tu protocolo, equipo y direcciones on-chain, el /intelligence-center cierra el ciclo entre el deploy auditado y la operación del día a día.

Rangos de precio de auditoría de smart contract por tamaño y alcance (USD, 2025–2026)

Términos clave

nSLOC (non-comment source lines of code)

Líneas de código fuente sin comentarios ni líneas en blanco. Es la unidad estándar de precificación de auditorías, porque aproxima el tiempo de lectura humana del código. Referencia de mercado: ~500 nSLOC ≈ 3 días de auditoría; ~3.000 nSLOC ≈ 18 días; ~6.000 nSLOC ≈ 38 días.

TVL (Total Value Locked)

Valor total bloqueado/custodiado por un smart contract o protocolo. Es la métrica que debe anclar el presupuesto de auditoría: el impacto de un solo bug crítico suele ser el 100% del TVL, así que el precio de la revisión debe leerse como una fracción de lo que protege.

Retest posterior a la corrección (re-audit)

Segunda ronda de revisión hecha después de que el equipo corrigió los hallazgos, confirmando, ítem por ítem, qué fue remediado, mitigado parcialmente o aceptado como riesgo residual. Cuesta típicamente US$ 5.000–20.000 por ronda. Es la carta final que se muestra a inversionistas y usuarios; sin ella tienes diagnóstico, no garantía de tratamiento.

Prueba de concepto (PoC)

Demostración ejecutable de cómo se explota una vulnerabilidad: el paso a paso que efectivamente drena o manipula los fondos, no apenas la observación de que 'parece riesgoso'. Un hallazgo sin PoC es una sospecha; con PoC, es una falla comprobada.

OWASP Smart Contract Top 10

Referencial público de las diez clases de falla más críticas en contratos inteligentes. En la edición 2025: SC01 control de acceso, SC02 manipulación de oráculo de precio, SC03 errores de lógica, SC04 falta de validación de entrada, SC05 reentrada, SC06 llamadas externas no verificadas, SC07 flash loans, SC08 overflow/underflow, SC09 aleatoriedad insegura y SC10 denegación de servicio. Un buen informe mapea cada hallazgo a estas categorías.

Verificación formal

Método que prueba matemáticamente que el contrato satisface propiedades definidas (ej.: 'el saldo total nunca puede disminuir sin un retiro autorizado'). Encarece la auditoría, pero es lo que atrapa clases de bug que las pruebas y la revisión manual dejan pasar.

Fuzzing / prueba de invariantes

Técnica que bombardea el contrato con miles de entradas y secuencias aleatorias para encontrar estados que violan invariantes (reglas que deberían cumplirse siempre). Complementa la revisión manual y es decisiva en lógica financiera compleja, como AMMs y protocolos de préstamo.

Cómo decidir y contratar bien

1. Dimensiona el alcance antes de cotizar: cuenta las nSLOC de lo que va a producción (solidity-metrics o cloc), anota el lenguaje/cadena, marca la lógica de alto riesgo (oráculos, gobernanza, puentes, proxies) y estima el TVL objetivo.
2. Usa los rangos de mercado para calibrar la expectativa, no para cerrar precio: ERC-20 simple US$ 5–20 mil, DeFi medio US$ 40–100 mil, complejo/multi-chain US$ 150 mil+; y reserva US$ 5–20 mil por ronda de retest.
3. Envía siempre el repositorio en el commit hash exacto que irá a producción y rechaza cotizaciones 'a ciegas' dadas sin ver el código.
4. Pide a cada proveedor: 2–3 informes anteriores de complejidad parecida, la metodología explícita (¿manual + fuzzing + verificación formal?), quién exactamente va a auditar y hallazgos críticos reales que ya hayan encontrado.
5. Confirma por escrito si el retest posterior a la corrección está incluido o se cobra aparte, y jamás hagas deploy sin la carta de retest que valida las correcciones.
6. Compara propuestas sobre la misma base (nSLOC, lenguaje, profundidad, plazo) y desconfía de cotizaciones muy por debajo del rango para tu tamaño: suelen significar profundidad insuficiente o subcontratación opaca.
7. Si el presupuesto no cubre la auditoría que el TVL exige, reduce la superficie (TVL limitado, timelock, circuit breakers) en lugar de comprar una auditoría más superficial.
8. Trata la auditoría on-chain (/plano/web3-security) como un frente de un conjunto: contrata también la prueba ofensiva (/plano/seguranca-ofensiva) para claves, custodia y operación off-chain, y monitoreo continuo (/intelligence-center) para amenazas y exposición de credenciales.

Preguntas frecuentes

Referencias

• ›Chainalysis — 2025 Crypto Theft Reaches $3.4 Billion (y US$ 2,2 mil millones en 2024; ruta de lavado vía DeFi +370%; Bybit US$ 1,5 mil millones) — https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2026/
• ›OWASP Smart Contract Top 10 (edición 2025) — orden de las categorías SC01–SC10 — https://scs.owasp.org/sctop10/archive/2025/Top10:2025/
• ›OWASP / SolidityScan Web3HackHub — pérdidas por categoría en 2024 (SC01 US$ 953,2M; lógica US$ 63,8M; reentrada US$ 35,7M; flash loan US$ 33,8M) — https://owasp.org/www-project-smart-contract-top-10/2025/en/src/SC01-access-control.html
• ›Sherlock — Smart Contract Audit Pricing: A Market Reference for 2026 (rangos, nSLOC→plazo, retest, urgencia) — https://sherlock.xyz/post/smart-contract-audit-pricing-a-market-reference-for-2026
• ›LGPD — Ley n.º 13.709/2018, art. 52 (multa simple hasta 2% de la facturación en Brasil, excluidos tributos, limitada a R$ 50 millones por infracción) — https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm