Solvencia y contabilidad
Por dónde entra y sale el valor, cómo se calcula cada saldo, hacia dónde redondea cada división y quién absorbe la diferencia.
Revisión de diseño de protocolos DeFi, antes de fijar el diseño en código
Los bugs más caros son los de diseño. Una dirección de redondeo, una suposición sobre el oráculo o una vía de liquidación decididas al principio son difíciles de cambiar cuando ya existe el código, e imposibles de cambiar tras un despliegue inmutable. Revisamos tu arquitectura mientras todavía es barato cambiarla.
01 / PARA QUIÉN ES
Para quién es
- Equipos con un whitepaper, una especificación o un código inicial que quieren una visión externa antes de cerrar el diseño
- Fundadores que necesitan entender los riesgos de un diseño antes de levantar financiación o contratar
- Equipos que preparan una auditoría y quieren resolver antes las cuestiones de diseño
02 / QUÉ REVISAMOS
Qué revisamos
Oráculos y precios
En qué precios confía el sistema, qué pasa cuando una fuente está desactualizada, es poco fiable o se equivoca, y hasta dónde puede propagarse un precio erróneo.
Liquidaciones y deuda incobrable
Si las posiciones se pueden cerrar cuando hace falta, quién tiene incentivos para cerrarlas y dónde acaba la deuda incobrable cuando no se puede.
Controles de emergencia
Qué se puede pausar, quién puede pausarlo y si los usuarios pueden salir mientras está pausado.
Roles y actualizaciones
Permisos de administración, vías de actualización y gestión de claves, y qué podría hacer cada rol si su clave quedara comprometida.
Casos límite económicos
Incentivos, parámetros y los casos que rompen los diseños simplistas, como pools vacíos, primeros depositantes o una utilización extrema.
03 / CÓMO FUNCIONA
Cómo funciona
- 01ArranqueUna llamada, acceso a tus documentos y tu código, y las preguntas que debe responder la revisión.
- 02RevisiónDe una a dos semanas de análisis, con preguntas a tu equipo a medida que surgen.
- 03InformeHallazgos por escrito ordenados por impacto, cada uno con una recomendación concreta.
- 04RepasoUna llamada para recorrer el informe y las opciones con tu equipo.
04 / QUÉ RECIBES
Qué recibes
| ENTREGABLE | FORMATO |
|---|---|
| Un informe escrito con los hallazgos ordenados por impacto y recomendaciones concretas | Documento |
| La lista de invariantes que debe cumplir el sistema, lista para convertirse en tests | Documento |
| Una llamada de repaso con tu equipo | Llamada |
| Respuestas a preguntas de seguimiento durante las dos semanas siguientes a la entrega | Asíncrono |
06 / FAQ
Preguntas sobre la revisión de diseño
¿Una revisión de diseño es lo mismo que una auditoría?
No. Una auditoría revisa el código línea a línea en busca de vulnerabilidades. Una revisión de diseño mira la arquitectura y la economía, idealmente antes o mientras se escribe el código. Se complementan.
¿Qué necesitáis de nosotros?
Lo que exista, desde un whitepaper o una especificación hasta diagramas o código. Si el diseño todavía no está por escrito, basta una llamada para empezar.
¿La revisión puede cubrir código existente?
Sí. Si el diseño vive sobre todo en el código, lo revisamos desde ahí. Para un hardening línea a línea antes de la auditoría, mira nuestra preparación para auditoría (Pre-Audit Hardening).
¿Qué pasa después de la revisión?
Tu equipo implementa los cambios, o podemos ayudar con nuestro servicio de desarrollo (Smart Contract & Protocol Development).