Exécuter un TWAP et un VWAP via l’API Hyperliquid

• twap vwap hyperliquid

• hyperliquid execution api

• trading algorithmique TWAP

• découpage de gros ordres sur Hyperliquid

• VWAP sur contrats perpétuels on-chain

Quand un ordre devient suffisamment important, l’exécuter directement au marché peut provoquer un fort impact de marché : ton achat pousse lui-même le prix vers le haut, et ton prix moyen finit nettement au-dessus de ce que tu avais prévu. Pour limiter ce problème, les acteurs professionnels utilisent depuis longtemps des algorithmes d’exécution. Les deux plus classiques sont le TWAP, ou prix moyen pondéré par le temps, et le VWAP, ou prix moyen pondéré par le volume.

Grâce à l’API ouverte de Hyperliquid, les développeurs individuels peuvent aussi mettre en place ce type d’exécution sur les marchés de contrats perpétuels on-chain. Dans cet article, on va voir le principe du TWAP et du VWAP, leur logique d’implémentation, leurs différences et les cas où chacun est le plus pertinent. Si tu ne veux pas coder toi-même, OneKey Perps offre une porte d’entrée plus simple pour trader des perpétuels on-chain sans devoir construire ton propre algorithme.

Qu’est-ce que le TWAP ?

Le TWAP repose sur une idée simple : découper un gros ordre en petites tranches régulières dans le temps, puis envoyer une tranche à intervalle fixe. Le prix final obtenu se rapproche ainsi du prix moyen pondéré par le temps sur la période d’exécution.

Exemple : tu veux acheter pour 1 million de dollars de contrats perpétuels BTC en 1 heure. Une stratégie TWAP peut découper l’ordre en 60 exécutions, avec environ 16 700 dollars exécutés chaque minute. Quelle que soit la variation du prix pendant cette heure, ton prix moyen sera proche de la moyenne temporelle de la période, tout en évitant l’impact brutal d’un seul gros ordre au marché.

Le principal avantage du TWAP est sa simplicité : il ne dépend pas de données de volume en temps réel. Son inconvénient est qu’il ne tient pas compte de l’activité du marché. Il peut donc continuer à envoyer des ordres pendant des périodes de faible liquidité, ce qui peut augmenter le slippage.

Qu’est-ce que le VWAP ?

Le VWAP va plus loin : il tient compte non seulement du temps, mais aussi du volume échangé. L’algorithme estime la répartition historique ou en temps réel du volume, puis exécute davantage pendant les périodes où le marché est actif et moins pendant les périodes creuses. L’objectif est d’obtenir un prix moyen proche du prix moyen pondéré par le volume du marché.

Le VWAP demande des données de volume en temps réel ou historiques, et il est donc plus complexe à implémenter qu’un TWAP. En revanche, sur des marchés où la liquidité est très inégale selon les périodes, il peut réduire les coûts d’exécution.

Pourquoi ces stratégies sont importantes on-chain

Sur les marchés de perpétuels on-chain, la profondeur de liquidité et l’efficacité de la découverte des prix varient fortement selon les moments. Les moteurs de matching on-chain ou hybrides ont aussi des caractéristiques qui peuvent rendre l’impact d’un gros ordre légèrement différent de celui observé sur une plateforme centralisée classique.

Pour Hyperliquid, il est utile de consulter la documentation officielle afin de comprendre la profondeur du carnet d’ordres, la structure de frais et les paramètres pertinents avant de définir un algorithme d’exécution.

TWAP vs VWAP

Pour la plupart des développeurs particuliers, le TWAP est souvent le meilleur point de départ. Le VWAP devient plus intéressant lorsque tu disposes déjà d’un historique fiable de données de volume et d’un système robuste de suivi du marché.

Implémenter un TWAP avec l’API REST de Hyperliquid

Logique de base

L’idée consiste à appeler l’endpoint d’ordre de Hyperliquid en boucle, puis à attendre un intervalle prédéfini entre chaque sous-ordre :

import time
import math

def execute_twap(exchange, info, coin, total_size, is_buy, duration_seconds, num_slices):
    """
    Exécute total_size en num_slices tranches égales sur duration_seconds secondes.
    """
    slice_size = total_size / num_slices
    interval = duration_seconds / num_slices

    for i in range(num_slices):
        # Récupérer le prix mark actuel
        ctx = info.meta_and_asset_ctxs()
        mark_px = get_mark_price(ctx, coin)

        # Ordre au marché avec une tolérance de slippage
        # Peut aussi être remplacé par un ordre limite proche du carnet
        result = exchange.market_open(
            coin=coin,
            is_buy=is_buy,
            sz=round(slice_size, 4),
            slippage=0.005  # 0,5 % de slippage toléré
        )

        print(f"[{i + 1}/{num_slices}] Exécuté : {result}")

        if i < num_slices - 1:
            time.sleep(interval)

    print("Exécution TWAP terminée")

En production, il faut ajouter au minimum une logique de retry en cas d’erreur, la gestion des exécutions partielles, le suivi des ordres ouverts, ainsi que des protections pour suspendre l’exécution en cas de volatilité extrême.

Amélioration : utiliser des ordres limite pour réduire les coûts

Remplacer chaque sous-ordre par un ordre limite légèrement plus favorable que le prix du carnet peut aider à réduire les frais, notamment si l’ordre bénéficie d’un tarif maker. En contrepartie, l’ordre peut ne pas être exécuté.

Une approche courante consiste à définir un timeout : si l’ordre limite n’est pas exécuté dans le délai prévu, il est annulé, puis remplacé par un ordre au marché pour compléter l’exécution.

def place_with_timeout(exchange, coin, is_buy, sz, limit_px, timeout_seconds=30):
    result = exchange.order(
        coin=coin,
        is_buy=is_buy,
        sz=sz,
        limit_px=limit_px,
        order_type={"limit": {"tif": "Gtc"}}
    )

    oid = result["response"]["data"]["statuses"][0]["resting"]["oid"]

    time.sleep(timeout_seconds)

    # Vérifier si l’ordre est toujours ouvert
    open_orders = get_open_orders(coin)

    if any(o["oid"] == oid for o in open_orders):
        exchange.cancel(coin=coin, oid=oid)

        # Repasser au marché pour la taille restante
        exchange.market_open(
            coin=coin,
            is_buy=is_buy,
            sz=get_remaining_size(oid),
            slippage=0.01
        )

Cette logique doit être testée avec prudence. En conditions réelles, les carnets peuvent bouger rapidement, et une limite trop agressive peut rester non exécutée alors qu’une limite trop proche du marché peut offrir peu d’avantage.

Calculer un VWAP en temps réel avec les données WebSocket

Le VWAP nécessite d’accumuler en temps réel le produit prix × volume, puis de le diviser par le volume total échangé :

class VWAPTracker:
    def __init__(self):
        self.cumulative_pv = 0.0  # cumul price * volume
        self.cumulative_v = 0.0   # cumul volume

    def on_trade(self, price, size):
        self.cumulative_pv += price * size
        self.cumulative_v += size

    @property
    def vwap(self):
        if self.cumulative_v == 0:
            return None
        return self.cumulative_pv / self.cumulative_v

Avec un abonnement WebSocket au flux de transactions de Hyperliquid, chaque trade déclenche un callback on_trade, ce qui permet de mettre à jour le VWAP en continu. L’algorithme d’exécution peut ensuite comparer ce VWAP au prix de marché actuel pour décider s’il doit envoyer la tranche suivante, réduire la taille de l’ordre ou attendre une meilleure fenêtre de liquidité.

Le format exact des abonnements WebSocket doit être vérifié dans la documentation officielle de Hyperliquid, car les champs et structures peuvent évoluer.

Suggestions de paramètres

Les paramètres dépendent de la taille de ton ordre, de la liquidité du marché, de ta tolérance au slippage et de l’urgence d’exécution. Quelques repères pratiques :

• Nombre de tranches : plus il est élevé, plus l’impact immédiat est réduit, mais plus l’exécution prend du temps.
• Durée totale : une durée plus longue peut lisser l’impact, mais augmente l’exposition au risque de marché.
• Slippage maximum : il doit être assez strict pour éviter une mauvaise exécution, mais pas trop bas au point de bloquer tous les ordres.
• Seuil de pause : si le prix s’écarte trop du prix de départ, l’algorithme peut suspendre ou arrêter l’exécution.
• Mode d’ordre : les ordres limite peuvent réduire les coûts, tandis que les ordres au marché privilégient la certitude d’exécution.

Commence toujours avec de petites tailles et un environnement de test ou une taille de risque très limitée avant d’utiliser une logique automatisée sur des montants significatifs.

Comparaison avec d’autres DEX

• dYdX prend également en charge les ordres via API REST, ce qui permet d’implémenter une logique TWAP similaire.
• GMX repose davantage sur une logique de prix via oracle, ce qui change la manière de concevoir les algorithmes d’exécution.
• Hyperliquid utilise un modèle de carnet d’ordres plus proche de celui des plateformes centralisées, ce qui rend les approches TWAP/VWAP plus directement transférables depuis les marchés traditionnels ou les CEX.

Tu ne veux pas coder ? Essaie OneKey Perps

Tout le monde n’a pas besoin de développer son propre moteur d’exécution. OneKey Perps propose une interface claire pour trader des contrats perpétuels on-chain, avec la sécurité de signature d’un hardware wallet OneKey.

Pour des ordres de taille moyenne, tu peux déjà réduire l’impact de marché en utilisant des ordres limite et en exécutant manuellement par tranches, sans écrire de script TWAP ou VWAP. C’est une approche plus simple, plus contrôlable, et souvent suffisante pour de nombreux utilisateurs.

Si tu cherches un workflow plus sûr et plus pratique pour accéder aux perpétuels on-chain, tu peux essayer ou télécharger OneKey, puis utiliser OneKey Perps comme point de départ pour tes transactions. Garde simplement en tête que la simplicité de l’interface ne réduit pas le risque propre aux perpétuels.

FAQ

Q1 : TWAP ou VWAP, lequel est le plus adapté sur Hyperliquid ?

Pour la plupart des développeurs individuels, le TWAP est plus simple à mettre en place et plus robuste au départ. Le VWAP peut être plus efficace lorsque la répartition du volume est relativement prévisible, mais il demande une meilleure collecte de données et une calibration plus avancée. Le plus raisonnable est souvent de commencer par un TWAP, puis de passer au VWAP après avoir accumulé suffisamment de données.

Q2 : Un algorithme d’exécution peut-il éliminer totalement l’impact de marché ?

Non. Il peut le réduire, parfois de manière significative, mais pas le supprimer. Le coût d’impact dépend toujours du rapport entre la taille de l’ordre et la liquidité disponible. L’algorithme sert à répartir cet impact dans le temps et, dans le cas du VWAP, à l’orienter vers les périodes les plus liquides.

Q3 : Comment mesurer la qualité d’exécution ?

On compare généralement le prix moyen réellement obtenu avec un benchmark comme le TWAP ou le VWAP de la période. L’écart est souvent analysé comme un coût d’exécution ou une forme d’implementation shortfall. Il est recommandé d’enregistrer le détail de chaque sous-ordre, puis d’analyser les résultats après l’exécution.

Q4 : Un hardware wallet OneKey peut-il être intégré à un script d’exécution ?

Oui. OneKey prend en charge les interfaces de signature Ethereum standard. Un script peut envoyer les messages à signer vers un service local de signature, les faire valider par le hardware wallet, puis soumettre les transactions ou ordres à Hyperliquid. Pour une exécution basse fréquence comme un TWAP, le délai de signature est généralement moins critique qu’en trading haute fréquence.

Q5 : Que faire si le marché bouge fortement pendant l’exécution ?

Il est préférable d’ajouter des protections de prix. Par exemple, si le prix de marché s’écarte de plus d’un seuil prédéfini par rapport au prix de départ, comme 2 %, l’algorithme peut suspendre l’exécution, attendre une stabilisation ou arrêter complètement la stratégie. Cela évite de continuer à accumuler une position dans un marché devenu fortement défavorable.

Conclusion

Le TWAP et le VWAP sont deux outils utiles pour réduire les coûts d’exécution des gros ordres. L’API ouverte de Hyperliquid permet de les appliquer aux contrats perpétuels on-chain avec une logique assez proche de celle utilisée sur les carnets d’ordres traditionnels.

Que tu passes par du code ou par une exécution manuelle en plusieurs tranches, le principe reste le même : répartir l’ordre dans le temps, limiter l’impact de marché et contrôler le prix moyen. Si tu veux une approche plus accessible pour trader des perpétuels on-chain sans développer ton propre algorithme, OneKey Perps est un point de départ pratique à tester avec prudence.

Avertissement sur les risques : les stratégies d’exécution algorithmique ne garantissent pas un prix d’exécution donné. La volatilité, le manque de liquidité, les erreurs de paramétrage ou les problèmes techniques peuvent entraîner un coût réel très différent de celui attendu. Le trading de contrats perpétuels comporte un risque élevé et peut entraîner une perte partielle ou totale des fonds. Cet article est fourni à titre informatif et technique uniquement ; il ne constitue pas un conseil financier, juridique ou d’investissement. Agis toujours en fonction de ta situation et de ta compréhension des risques.