Saltar al contenido

    Pulsa / para buscar, y [ o ] para ir a la página anterior o siguiente.

    Cómo funciona por dentro

    Panorama de la arquitectura

    El protocolo es un conjunto pequeño de contratos en HyperEVM que lee HyperCore, la capa de Hyperliquid, mediante precompiladas para obtener precios y mueve USDC en ella. Esta página muestra los contratos y cómo encajan.

    Arquitectura on-chainLas intenciones firmadas van del relayer, a través del BatchExecutor, al Exchange, que lee los precios de Hyperliquid de las precompiladas de HyperCore y mueve USDC con CoreWriter. Staking, Tokenomics y el token están a su lado.Off-chaintu billetera o clave de sesiónfirmarelayerHyperEVMenvía lotesBatchExecutorExchangelibrerías de trading, cola, fondos y administraciónSessionKeyManagerlentes (solo lectura)StakingTokenomicstokenDepositProxyFactoryHyperCorelee preciosmueve USDCBBOmarca y oráculoCoreWriterUSDC spot
    Arquitectura on-chain. Las intenciones firmadas van del relayer, a través del BatchExecutor, al Exchange, que lee los precios de Hyperliquid de las precompiladas de HyperCore y mueve USDC con CoreWriter. Staking, Tokenomics y el token están a su lado.

    Contratos (HyperEVM)

    • Exchange: el contrato de trading. Lleva cada saldo, abre y cierra posiciones, salda resultados, gestiona la cola de pagos y guarda el LP y las cuentas de comisiones. Un punto de entrada mínimo delega en cuatro librerías (trading, cola, fondos, administración). Las aperturas y los cierres llegan solo a través del BatchExecutor; los retiros y las llamadas de mantenimiento pueden venir de cualquiera.
    • BatchExecutor: la única vía de entrada del relayer. Acepta lotes solo de las claves de relayer configuradas y reenvía cada llamada firmada, únicamente a una lista fija de funciones.
    • SessionKeyManager: registra claves de sesión, verifica cada firma y cada nonce para el Exchange y gestiona la revocación. El registro llega a través del relayer; la revocación también puede ser una llamada directa desde tu billetera.
    • Token, Staking, Tokenomics: el token BACK (con la transferencia desactivada en el lanzamiento), el contrato de staking con su acumulador de recompensas y el contrato que calcula y acuña BACK por las pérdidas y lleva el LP contable.
    • BuilderRegistry: los builders aprobados y la tasa única de comisión de builder, con un tope de 15%. No es actualizable: reemplazarlo es un despliegue nuevo al que se apunta el SessionKeyManager.
    • DepositProxyFactory y DepositProxy: derivan la dirección de depósito determinista de cada cuenta y despliegan el pequeño contrato que hay detrás, que solo puede enviar USDC en HyperCore al Exchange. Ninguno de los dos es actualizable: una dirección de depósito nunca debe cambiar.
    • Lentes y PriceOracle: vistas de solo lectura sobre el Exchange y HyperCore, y un helper de precios, para apps y servicios. El Exchange lee las precompiladas directamente, no a través de ellos.

    Las direcciones están en direcciones de los contratos.

    Precompiladas (HyperCore)

    • BBO 0x000000000000000000000000000000000000080e: el mejor precio de compra y el mejor precio de venta; su punto medio es el precio de ejecución.
    • Mark 0x0000000000000000000000000000000000000806: el precio de marca de Hyperliquid, que leen las protecciones de precio inactivas y que sirve de respaldo cuando se retira un mercado.
    • Oracle 0x0000000000000000000000000000000000000807: el precio del oráculo de Hyperliquid, con los mismos usos que el de marca.
    • CoreWriter 0x3333333333333333333333333333333333333333: el contrato de sistema que envía acciones a HyperCore. Los proxies de depósito lo usan para enviar USDC a la cuenta del Exchange en HyperCore, y el Exchange lo usa para pagar los retiros a tu cuenta de HyperCore.

    Las precompiladas de saldos permiten al Exchange comprobar que un depósito realmente llegó antes de acreditarlo (Depósitos: proxies CREATE2).

    Una operación de punta a punta

    Firmas una intención con tu clave de sesión y la app la envía al relayer, que la comprueba y la pone en cola. El relayer agrupa las intenciones en cola en un lote y lo envía al BatchExecutor, que llama al Exchange una vez por intención. El Exchange verifica la firma a través del SessionKeyManager, lee el BBO para el precio de ejecución, abre la posición o salda el cierre con el LP, actualiza tu saldo y, si hay pérdida, hace que Tokenomics te acuñe BACK. Las intenciones de muchas cuentas comparten una transacción, pero cada una se salda por separado: el relayer marca cada llamada como autorizada a fallar, así que una intención que falla no detiene a las demás.

    Frontends

    Cada apertura y cada cierre los envía nuestro relayer. Otro frontend puede producir las mismas firmas y enviarlas a través de la API del relayer (API de intenciones), pero no puede enviar aperturas ni cierres directamente a los contratos.

    Servicios off-chain

    Servicio Función
    Intake del relayer Acepta intenciones firmadas, las comprueba y reserva saldos.
    Motor del relayer Programa las intenciones en cola y las envía en lotes.
    Indexador Sigue la cadena bloque a bloque, comprueba los invariantes contables en cada bloque y transmite las actualizaciones de las cuentas.
    API de lectura y stream Sirven a la app el estado del mercado, el historial y el stream en vivo de la cuenta.
    Keepers Liquidan, recolectan la cola, distribuyen las recompensas de staking, mueven los topes de interés abierto, cambian la curva de pago según su calendario y reproducen las acuñaciones diferidas.
    Sweeper y worker de fondos Barren los depósitos y reenvían los retiros a otras cadenas.

    Ninguno de estos servicios puede firmar por ti ni mover tus fondos sin tu firma. Si se detienen, el trading se detiene, pero tu saldo libre se puede seguir retirando desde tu billetera.

    Gobernanza

    El dueño de cada contrato actualizable es un timelock: una actualización o un cambio de parámetros lo programa el multisig de gobernanza y solo se puede ejecutar después de 2 días. Un segundo timelock, con un retraso de 7 días, controla quién tiene los roles del primero. Un multisig guardián puede actuar de inmediato en una emergencia, dentro de los límites estrechos que se detallan en Riesgos.

    Última actualización: