Seguridad
Revisión de seguridad
Una revisión interna del código fuente de los contratos. Ningún tercero ha auditado todavía los contratos, y esta página no sustituye esa auditoría.
Qué se revisó
El código fuente del Exchange y de su módulo de administración, las librerías que enlaza, la lógica de órdenes, pagos y liquidaciones, los depósitos y retiros, las claves de sesión, el ejecutor por lotes, los proxies de depósito, el staking, el token y sus recompensas. El código se leyó tal como está en el commit e456c4d (2026-11-06). Los servicios fuera de la cadena, las aplicaciones y los scripts de despliegue quedaron fuera del alcance.
Resultado
La revisión no encontró ningún defecto de gravedad crítica o alta en el código de los contratos. Cada ruta que mueve fondos se leyó línea por línea y resistió. El código añadido más recientemente (el staking, el token y el cierre desde la wallet) es el que menos revisión ha tenido; se leyó completo, y la contabilidad del staking se probó además como se describe más abajo.
Qué resistió
- Control de acceso. Toda función que cambia el estado comprueba a quien la llama antes de cambiar nada. El módulo de administración no puede usarse por sí solo. La propiedad no se puede renunciar, y solo el propietario puede actualizar un contrato.
- Firmas. Los mensajes tipados llevan la cadena y el contrato verificador, rechazan firmas maleables, usan cada nonce una sola vez y solo después de comprobar la firma, y caducan. Una clave de sesión no puede firmar un mensaje reservado a la wallet, la wallet no puede firmar una operación, y revocar todas las claves de una vez funciona.
- Flujo de valor. La contabilidad entre el efectivo del pool, el pool contabilizado, la cola de pagos y el cubo lateral se mantiene coherente. No hay aritmética sin comprobar, las conversiones a tipos más estrechos se comprueban y cada redondeo va en el sentido que fija el diseño. Las comisiones tienen tope, y un retiro reduce el saldo antes de enviar la acción a Hyperliquid.
- Reentrada. Toda función que mueve fondos está protegida contra la reentrada, y el estado se escribe antes de las llamadas externas. El hook del token se ejecuta con una asignación fija de gas, así que quien llama no puede forzar que se aplace.
- Direcciones de depósito. Un proxy de depósito solo puede enviar acciones de HyperCore a través del Exchange, y su propietario solo puede sacar de él tokens EVM y HYPE nativo. La derivación de la dirección no ha cambiado.
- Patrones de código. No hay
selfdestruct,tx.origin,.transfer,.sendnicallcode. Las únicas delegatecall van al módulo de administración y a las librerías enlazadas. - El token que se quema. BACK queda en staking en el momento en que se acuña y se quema 7 días después, a la siguiente medianoche UTC. Nada empieza a contar hasta que el LP contable alcance $500,000 por primera vez. El día de vencimiento de cada lote, el recorrido perezoso por los lotes de una cuenta, el calendario global, los mints reproducidos y el inicio de la cuenta atrás concuerdan con este diseño, que describe Recompensas y cobro.
Cómo se probó la contabilidad del staking
Se escribió un modelo aparte, solo a partir de las reglas publicadas, sin leer la aritmética del contrato. Secuencias aleatorias de mints (con reproducciones tardías), el inicio de la cuenta atrás, distribuciones, reclamaciones y saltos en el tiempo (hasta un segundo antes de medianoche, justo a medianoche, por días y hasta 150 días de inactividad) se ejecutaron contra el contrato y contra el modelo, y se compararon tras cada paso. En 76,800 llamadas, y otras 38,400 con largas pausas, no hubo ninguna diferencia: los saldos vivos y la oferta coincidieron exactamente, las recompensas coincidieron dentro del polvo de redondeo, ninguna cuenta pudo reclamar más de lo reservado y cada reclamación pagó exactamente lo pendiente. Dos errores añadidos a propósito fueron detectados.
Hallazgos
| Gravedad | Hallazgo | Estado |
|---|---|---|
| Media (garantía) | Los analizadores estáticos y los fuzzers (Slither, Aderyn, Medusa, Echidna, Halmos, Gambit) se ejecutaron por última vez antes de reescribir el token. El código nuevo tiene la suite de pruebas, la campaña de invariantes con su duración por defecto y el modelo descrito arriba. | Se volverán a ejecutar antes de la auditoría externa. |
| Media (diseño, divulgado) | En el lanzamiento todas las protecciones de precio en la cadena están desactivadas: las ejecuciones usan el punto medio del mejor precio de compra y de venta en bruto de Hyperliquid, con apalancamiento alto. La protección viene de los límites del relayer, los keepers y el centinela, todo fuera de la cadena. | Divulgado; véase Riesgos. |
| Baja | El consentimiento de comisión de builder de una clave de sesión no se borra cuando la clave se registra de nuevo con el tipo de firma antiguo, ni cuando se revoca, así que un builder designado después podría ganar hasta la tasa consentida antes. El tope de las comisiones de builder lo acota. | Se corregirá antes del despliegue de producción. |
| Baja | La cola de mints diferidos no tiene forma de saltar una entrada. Si una entrada fallara en cada reproducción, los mints posteriores esperarían detrás de ella. Un cambio en los costes de gas en HyperEVM, o un error en una futura actualización, podría causarlo. | La recuperación es una actualización a través del timelock. |
| Media (económica, divulgada) | Desde el 2026-11-08 una pérdida acuña sobre toda su base de acuñación: las ganancias no se compensan con pérdidas posteriores y ningún tope limita a una cuenta. Un trader puede mantener posiciones opuestas y acuñar sobre la pata perdedora pase lo que pase en el mercado. Esta revisión leyó el código antes de ese cambio. |
Divulgado. Las comisiones, la quema tras la cuenta atrás y la parte que se llevan los demás tokens vivos de cada distribución son los únicos frenos; véase Riesgo. |
| Baja | El guardián puede pausar el trading, retirar un mercado para siempre, reemplazar al keeper de mercado y al keeper de fuera de horario, autorizar o quitar relayers, y subir la asignación de gas para las lecturas de precio. No puede mover fondos ni quitar la pausa. | Por diseño; véase Riesgos. |
| Info | El saldo y la oferta del token son exactos en todo momento, pero el evento de un token quemado solo se registra cuando la cuenta se toca de nuevo, así que las herramientas que suman eventos muestran los tokens quemados como vivos. | Lea los saldos, no los eventos. |
| Info | Momento de las recompensas: un mint justo antes de una distribución recibe una parte proporcional, el primer titular se lleva lo que no estaba asignado y, tras una larga inactividad, los lotes vencidos comparten las distribuciones hechas mientras tanto. Nunca se paga más de lo distribuido. | Documentado; solvente en las pruebas. |
| Info | La cadena de versión del Exchange indica una versión anterior a la de su interfaz. | Se corregirá antes del despliegue de producción. |
| Info | Una función del proxy de depósito nunca se llama. | Se mantiene, porque el código del proxy fija todas las direcciones de depósito. |
| Info | El propietario puede acreditar a una cuenta con un excedente de Hyperliquid que nadie ha reclamado. | Una suposición de confianza; detrás del timelock en producción. |
Qué no se cubrió
- Los contratos lens de solo lectura, la librería de administración de mercados y la librería de límites se recorrieron por encima, no se revisaron línea por línea.
- La suite de pruebas completa y las comprobaciones del diseño del almacenamiento, de la interfaz, del tamaño de los contratos y del código del proxy de depósito no se volvieron a ejecutar para esta revisión. Se confió en los resultados de la última ejecución completa.
- Las pruebas con fork contra Hyperliquid, los scripts de despliegue más allá de sus comprobaciones de roles, los servicios fuera de la cadena y las aplicaciones.
- La regla de acuñación del token tras el cambio del
2026-11-08(sin compensación de ganancias ni tope), el comportamiento de gas del hook del token y si los precompilados de Hyperliquid se comportan como suponen las pruebas.
Mantener esta página al día
Esta es una revisión en un momento concreto. No dice nada sobre los cambios hechos en los contratos después del commit indicado. Los contratos son actualizables detrás de un timelock, así que lo que esté desplegado en cada momento debe comprobarse con las direcciones de los contratos.