Seguridad en LiquitX

Esta página describe el trabajo de seguridad detrás del protocolo LiquitX tal como está hoy: la disciplina de ingeniería, el arco de auditorías internas y lo que queda por delante. Todo lo que aparece aquí es trabajo interno. Ninguna auditoría externa se ha completado todavía, y lo decimos con claridad.

Disciplina de Desarrollo

Cada contrato comienza como una especificación. Comportamientos esperados, comportamientos no deseados, casos límite y vectores de ataque se registran primero, y los tests que codifican esa especificación se escriben antes de la implementación que restringen.

La suite de tests del protocolo se organiza en cinco categorías: unit, security, fuzz, adversarial e integration. Cada categoría corre por separado en CI, y los cambios no se integran mientras alguna categoría falle.

Arco de Auditorías Internas

De abril a junio de 2026 el protocolo pasó por auditorías internas de seguridad multi-agente: pases repetidos de revisión sobre la superficie de los contratos, con cada hallazgo seguido hasta su corrección. De ese trabajo salieron dos olas de remediación:

Estos números son hallazgos que encontramos y corregimos nosotros mismos, antes de cualquier revisión externa. Los publicamos porque un código se describe mejor por cómo se encuentran y cierran los problemas que por afirmar que no existen.

Modelo de Amenazas

Se mantiene un modelo de amenazas documentado para el protocolo: superficies de ataque, supuestos de confianza, roles privilegiados y los invariantes que cada contrato debe preservar. Se revisa a medida que el sistema evoluciona, en lugar de escribirse una vez y archivarse.

Auditoría Externa y Despliegue Actual

Se planea una auditoría externa antes de cualquier despliegue en mainnet. El protocolo actualmente opera solo en la testnet Base Sepolia.

Principios de Diseño

Algunas reglas se mantienen en todo el código:

• Orden checks-effects-interactions en cada función que cambia estado.
• Errores personalizados en lugar de reverts con strings, para que los modos de falla sean explícitos y decodificables por máquina.
• Máquinas de estado explícitas para el ciclo de vida de los activos: las transiciones se enumeran y prueban, nunca se dan por supuestas.
• Superficies administrativas fail-closed: las operaciones privilegiadas deniegan por defecto cuando no se cumplen las precondiciones.

Las preguntas sobre cualquiera de estos puntos son bienvenidas. Contáctanos