Empezar con el SDK de Python de Hyperliquid

Qué está montando en realidad

Tres cosas, y merece nombrarlas antes de tocar una terminal, porque la confusión entre ellas es toda la dificultad.

Su billetera principal es la cuenta. Sostiene los fondos y es la dirección contra la que se registra todo.

Una API wallet es un agente que ella autoriza. Firma órdenes. No puede retirar.

El SDK es un envoltorio de Python sobre la interfaz HTTP firmada. No hace nada que usted no pudiera hacer con requests y una librería de firma; solo le ahorra implementar el esquema de firma.

Instalar y configurar

1. Instale el paquete

   pip install hyperliquid-python-sdk. Es la implementación de referencia, mantenida en la organización hyperliquid-dex de GitHub.

   Debería ver hyperliquid-python-sdk disponible en su entorno

2. Genere una API wallet en la aplicación

   Haga esto en lugar de poner su clave privada principal en un archivo. El agente puede operar y no puede retirar, así que el peor caso si el archivo se filtra está acotado.

   Aprobar el agente es una acción en cadena firmada por su billetera principal, exactamente como el paso Establish Connection de la primera vez que se conectó.

   Debería ver una clave privada de un agente autorizado en su cuenta

3. Rellene la configuración con las dos direcciones distintas

   La secret_key es la clave privada de la API wallet. La account_address es la clave pública de su billetera principal.

   Esa asimetría es el fallo más común del primer intento, y el README lo señala explícitamente por la misma razón.

   Debería ver una configuración con la que el SDK pueda firmar y consultar

4. Lea algo antes de escribir nada

   Construya Info y consulte precios medios o un libro. Esto no necesita firma alguna, así que si funciona, su ruta de red y su elección de endpoint están bien, y cualquier fallo posterior es un problema de firma y no de conectividad.

   Debería ver datos de mercado en vivo impresos desde el endpoint de información

5. Coloque una orden pequeña con Exchange

   Use la aplicación real para confirmar que llegó. Ver su propia orden programática en la interfaz es el momento en que la instalación queda verificada de verdad.

   Debería ver una orden visible en el panel de órdenes abiertas de la aplicación

Las dos clases

Info es el lado de lectura. Metadatos de mercado, precios medios, libros, velas, posiciones y ejecuciones de una dirección. No necesita clave. Se construye con una URL de la API y, si no quiere WebSocket, con skip_ws=True.

Exchange es el lado de escritura. Órdenes, cancelaciones, cambios de apalancamiento, transferencias. Firma cada petición con la clave que configuró.

Mantenerlas separadas en su propio código es una buena costumbre por la misma razón por la que la API las separa: la ruta de lectura es inofensiva y la de escritura no, y un error en la primera nunca debería poder convertirse en una acción en la segunda.

Qué se rompe en el primer intento

Datos vacíos en todas las consultas. La account_address es la de la API wallet en vez de la maestra. Consulte por la dirección maestra; firme con el agente.

Órdenes rechazadas por tamaño. Por debajo del nocional mínimo de $10.00 , o sin alinear con los incrementos de precio y de lote del mercado. Ambos vienen de los metadatos del mercado y no son globales.

Limitación de peticiones enseguida. Normalmente un bucle sondeando el libro. Suscríbase por WebSocket en su lugar. Los límites, y por qué tienen esa forma.

Errores de nonce. Las acciones se ordenan por nonce y por agente. Dos procesos firmando con el mismo agente chocarán, y la solución es un agente por proceso y no una lógica ingeniosa de reintentos.

Todo funciona y deja de funcionar tras un redespliegue. Un agente dado de baja cuya dirección reutilizó. Genere uno nuevo: la documentación avisa de que un estado de nonces purgado convierte la reutilización en un riesgo de repetición.

De código que funciona a estrategia que funciona

El SDK le lleva a una orden colocada en una tarde. La distancia de ahí a algo que merezca correr es, sobre todo, no código.

Disciplina con los tipos de orden. Use post-only cuando quiera ser maker, y reduce-only en cada salida. Ambos evitan categorías enteras de accidentes caros, y ambos son un flag. La lista completa.

Dimensione contra el libro, no contra su saldo. Una estrategia que ignora la profundidad paga un deslizamiento que empequeñece la diferencia de comisiones que estaba optimizando.

Decida qué pasa cuando el proceso muera. Las órdenes en el libro siguen trabajando sin usted. Eso es o una ventaja o un peligro, y debería ser una decisión.

Correr un bot, y en qué pensar primero cubre el resto de esa lista.

Dónde seguir

La API en sí — endpoints, el modelo de agente y los límites de peticiones — y los tipos de orden que va a enviar por ella.