Documentación de Hyperliquid: ¿Por dónde empezar para el acceso a API y RPC?

Qué cubre realmente la documentación de Hyperliquid

La documentación oficial de Hyperliquid está organizada en torno a los dos entornos de ejecución de la cadena. HyperCore contiene los libros de órdenes de futuros perpetuos y spot totalmente onchain, donde las órdenes, cancelaciones, operaciones y liquidaciones se procesan con finalidad de un bloque. HyperEVM es la capa de contratos inteligentes de propósito general que aporta herramientas compatibles con Ethereum al mismo estado unificado.

Esa división importa cuando lees la documentación. Una pregunta sobre libros de órdenes, posiciones o acciones del exchange pertenece a las secciones de HyperCore y API. Una pregunta sobre contratos Solidity, saldos ERC-20 o llamadas JSON-RPC estándar pertenece a la sección de HyperEVM. La documentación también enlaza a SDK, herramientas de construcción y recursos de soporte, que son útiles una vez que pasas de la lectura a la implementación.

• Acerca de y descripción técnica: consenso, modelo de estado y cómo se relacionan HyperCore y HyperEVM.
• Documentación de API: acciones del exchange, consultas de información e interfaces de streaming.
• Sección de HyperEVM: detalles de compatibilidad con EVM y contexto de despliegue de contratos.
• SDK y herramientas de construcción: clientes específicos de lenguaje y ayudantes de integración.
• Enlaces de soporte y comunidad: dónde hacer preguntas cuando la documentación es ambigua.

Guía de decisión: qué ruta de conexión se adapta a tu proyecto

Antes de escribir código de integración, decide cómo accederá tu aplicación a Hyperliquid. La documentación describe el protocolo; no elige tu infraestructura. Esa decisión depende de la carga de trabajo, cuánto control necesitas y si quieres operar nodos tú mismo.

Usa esta tabla como punto de partida. No es una clasificación de proveedores; es una forma de emparejar tu requisito con un modelo de conexión.

API de HyperCore vs JSON-RPC de HyperEVM: qué cambia en tu código

HyperEVM se comporta como una cadena compatible con Ethereum desde la perspectiva de las herramientas. Puedes usar métodos JSON-RPC estándar como eth_chainId, eth_blockNumber y eth_getBalance con bibliotecas familiares. Eso significa que tus hábitos existentes de desarrollo en Ethereum se mantienen en su mayoría para lecturas y escrituras de contratos.

HyperCore es diferente. Las acciones del exchange, el estado de las órdenes y los datos de mercado se exponen a través de API y streams específicos de Hyperliquid en lugar de métodos EVM genéricos. La documentación describe estas interfaces en detalle, incluida la firma y las comprobaciones previas. Si tu aplicación toca ambas capas, espera dos estilos de integración en el mismo código base: JSON-RPC de EVM para contratos y API de HyperCore para datos del exchange.

• Usa JSON-RPC de EVM para el estado de contratos, logs y consultas de cuentas estándar en HyperEVM.
• Usa las API de HyperCore para órdenes, posiciones, ejecuciones y datos del libro de órdenes.
• Consulta la documentación para las formas exactas de solicitud y respuesta; no asumas que los nombres de métodos EVM se aplican a las acciones del exchange.
• Mantén la lógica de firma separada de la configuración de transporte para que puedas cambiar endpoints sin reescribir la lógica de negocio.

Configuración de la cadena y del endpoint

Para HyperEVM, configurarás un ID de cadena, una URL de RPC y, normalmente, una URL de explorador de bloques en tu billetera o biblioteca. La documentación oficial y la información de cadena publicada por la red son la autoridad para estos valores. No copies IDs de cadena de publicaciones de blog de terceros sin verificarlos con la fuente oficial.

Para el acceso RPC a través de OnFinality, consulta la página de redes compatibles para ver la disponibilidad actual y los detalles exactos del endpoint. Si Hyperliquid está listado, usa el endpoint y la configuración de cadena proporcionados allí en lugar de adivinar una URL. Si aún no está listado, puedes seguir la documentación oficial para los detalles del protocolo y planificar tu infraestructura por separado.

Una comprobación mínima de solo lectura antes de seguir construyendo

Una vez que tengas un endpoint, confirma la conectividad básica antes de añadir firma o lógica de órdenes. Una simple llamada JSON-RPC verifica que tu URL, encabezados y configuración de cadena son correctos. El ejemplo siguiente usa un endpoint de marcador de posición; reemplázalo con la URL de tu proveedor o la página de redes compatibles de OnFinality.

Si la llamada devuelve un ID de cadena, tu transporte funciona. Si falla, revisa la URL, los encabezados de autenticación y si el endpoint espera una ruta diferente. Este paso ahorra tiempo después porque separa los problemas de transporte de los de lógica de aplicación.

• curl -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
• Confirma que el ID de cadena devuelto coincide con el valor oficial.
• Luego prueba eth_blockNumber para verificar que el nodo está sincronizado y responde.
• Solo después de que estas pruebas pasen deberías añadir la firma de billetera o las llamadas a la API del exchange.

Modos de fallo comunes al seguir la documentación de Hyperliquid

La mayoría de los problemas de integración provienen de mezclar capas u omitir la verificación. Un desarrollador lee un ejemplo de HyperEVM y luego intenta usar el mismo método para datos de órdenes de HyperCore, o copia un ID de cadena de un tutorial desactualizado. La documentación es detallada, pero asume que sabes en qué capa estás trabajando.

Otro problema común es tratar la documentación de un proveedor de RPC como sustituto de la documentación del protocolo. Los proveedores explican endpoints, límites y transporte; no redefinen cómo se firman las órdenes de Hyperliquid ni cómo se estructura el estado de HyperCore. Mantén ambas referencias abiertas y usa cada una para su propósito previsto.

Dónde encaja OnFinality junto a la documentación oficial

OnFinality proporciona API RPC e infraestructura de nodos dedicados para las redes compatibles. Para Hyperliquid, eso significa que puedes usar OnFinality como tu capa de transporte mientras confías en la documentación oficial para el comportamiento del protocolo, la firma y la semántica de la API. Esta separación mantiene tu integración mantenible: si cambias de proveedor, la lógica de tu aplicación sigue igual.

Antes de comprometerte, revisa los precios de RPC y la lista de redes compatibles para confirmar la disponibilidad y planificar la capacidad. Si necesitas recursos aislados o un endpoint privado, los nodos dedicados son una opción. Para un marco más amplio sobre la evaluación de proveedores, consulta la guía de selección de proveedores de RPC.

• Usa la documentación oficial para métodos de API, firma y arquitectura de la cadena.
• Usa OnFinality para acceso a endpoints, transporte y operaciones de nodos donde esté soportado.
• Consulta las redes compatibles y los precios antes de finalizar tu arquitectura.
• Ten en cuenta una ruta de conexión de respaldo para la resiliencia en producción.

Preguntas frecuentes