Al auditor le pagas por reconstruir contexto. Esto puedes darle de entrada

Antes de nada, una salvedad: no tenemos contratos propios que hayan pasado una auditoría. Lo que tenemos es una herramienta que lee 166 contratos de terceros: un registro de contratos de DFK Chain, la red que ya se apagó, y un escáner que muestra qué activos quedaron atrapados en una dirección cualquiera. Nosotros estamos al otro lado de la mesa: durante un mes hicimos justo aquello por lo que el auditor cobra en sus primeros días, reconstruir el contexto de un código ajeno que no lo tenía.

De ahí sale esta lista de lo que conviene entregar el primer día. Cada punto lo hicimos para nosotros y cada uno tiene un precio que pagamos mientras no lo tuvimos.

1. Procedencia, no una lista de direcciones

Nuestro registro está partido en dos, y esa división resultó ser lo importante.

La parte grande es la procedencia: un archivo de 196 KB en el que cada dirección lleva o bien un enlace a la documentación y una marca de que se comprobó leyéndola en la red, o bien un explícito «no se pudo establecer». La otra es una vista reducida de 166 contratos, que es la que el código consume; se genera a partir de la primera y no se edita a mano.

La regla que sostiene esto se escribió ya en la primera fase del trabajo: cada afirmación termina en un enlace a la fuente o en un «no se pudo establecer, excluido» dejado por escrito. La segunda opción es igual de válida, y se usa: el RPC de respaldo está marcado como no establecido porque no hay documentación que lo respalde.

Lo que el auditor necesita es esa primera parte, la procedencia. La lista de direcciones la saca de tu despliegue en diez minutos; lo que no saca es qué justifica cada una y cuáles no supiste justificar tú.

2. Auditar tu propia aritmética antes de que alguien audite el código

Dos semanas antes del apagado de la red nos sentamos a revisar la fórmula que calcula la participación del usuario en un pool de liquidez. Teníamos tres hipótesis:

1. la participación se calcula con dieciocho decimales fijos, escritos a mano en el código;
2. si el precio solo se conoce para un lado del pool, el código lo multiplica por dos;
3. el precio de un token sale del último pool con USDC que aparezca, sin tener en cuenta la profundidad del pool.

Los datos desmintieron dos de las tres. Los dieciocho decimales están tanto en el numerador como en el denominador: el factor se cancela y la participación es correcta con cualquier número de decimales del token LP. La rama que multiplica por dos no llegó a ejecutarse ni una vez en un mes: los catorce pares documentados tienen precio en los dos lados y el desequilibrio entre ellos nunca pasó del 1 %. La salvedad hay que decirla en la misma frase: esa evidencia cubre solo los pares documentados. En los no documentados esa rama nunca se midió, y ahí es justo donde apareció el defecto real.

El defecto real no estaba en la fórmula, sino en el origen de sus datos de entrada. Para los pares no documentados, las reservas se leían en tiempo real desde la red mientras que totalSupply venía de una caché del registro generada semanas antes. Numerador reciente, denominador viejo. Medido contra la red, la desviación media de totalSupply fue del 13,2 % y la máxima del 61 %. La cuenta es esta: el suministro real había bajado al 39 % del valor en caché, así que dividir por el denominador viejo divide la participación por 2,6. Y la subestima en la dirección peligrosa, la de no reclamar tu dinero porque creíste que había poco.

Lo útil no es el fallo, sino el orden de los pasos: tres hipótesis escritas antes de comprobarlas y dos que los datos refutaron limpiamente. Ese es el segundo documento que conviene darle a un auditor: la lista de lo que ya has comprobado y con qué datos, exactamente, has descartado cada hipótesis.

3. Un informe que declara sus propias lagunas

Nuestro informe lleva un campo obligatorio notCovered: la lista de lo que la comprobación no cubre, como los ítems depositados en contratos de subasta, las clases de activos sin guía oficial y los contratos que no respondieron.

El README lo dice sin rodeos: un escáner que se salta en silencio una clase de contratos y emite un informe sin hallazgos es peor que no tener escáner. Con la preparación de una auditoría pasa exactamente lo mismo. «Aquí está la cobertura de pruebas, aquí lo que queda fuera y por qué» le ahorra al auditor los dos primeros días; «aquí está la cobertura de pruebas» sin la segunda mitad se los hace perder, porque va a buscar los límites de la cobertura igualmente, solo que a tu costa.

Nosotros incumplimos este principio y conocemos el precio: un defecto nuestro convirtió una lectura fallida en «aquí no hay nada», y el informe salió limpio justo donde la comprobación no había llegado a ejecutarse.

4. Aislamiento por módulos y un bloque fijo

Dos puntos técnicos, y los dos le ahorran tiempo a otra persona.

Aislamiento. La comprobación está partida en ocho módulos, y un módulo que falla aporta una línea de error al informe en vez de invalidar la ejecución entera. Con una ejecución monolítica, un fallo en cualquiera de los ocho pasos tira toda la corrida; con módulos aislados, solo se pierde ese módulo.

Un bloque fijo. Todas nuestras mediciones se hacen a la altura de un bloque concreto, y por eso cualquiera puede reproducirlas. Esa misma propiedad permite detectar errores: una discrepancia en datos históricos no se puede achacar al movimiento del mercado, porque ahí los datos no se mueven.

Qué preparar, y en qué orden

De mayor a menor retorno; el primer punto es trabajo de una tarde y los otros tres caben en un par de semanas:

1. Una lista de afirmaciones con sus fuentes y una línea honesta de «no verificado» allí donde no lo esté. Esto es un documento, no código, y es lo más rápido de todo.
2. Un repaso de tus propias hipótesis: qué sospechabas, qué comprobaste y qué refutó cada hipótesis. Aunque ninguna se confirmara, y sobre todo en ese caso.
3. Los límites explícitos de la cobertura, junto con las pruebas.
4. Una ejecución reproducible: bloque fijo, módulos aislados y errores visibles en la salida, no enterrados en un log.

Ninguno de los cuatro puntos exige tocar el contrato. De lo que se trata es de que la persona a la que pagas por encontrar defectos dedique su tiempo a encontrar defectos.