Les perp multi-actifs peuvent-ils devenir une catégorie indépendante ? À l’heure actuelle, personne ne peut répondre à cette question.
Mais on peut remonter à partir de trois défis de conception pour déduire si, après le lancement du réseau principal de Hertzflow, il sera possible de les franchir.
Premier défi : le pool LP doit-il être isolé
La volatilité des cryptomonnaies n’est pas du tout du même ordre de grandeur que celle des changes (FX). Une baisse quotidienne de 15 % du BTC est monnaie courante, tandis qu’une baisse quotidienne de 1,5 % sur USDJPY correspond à un gros mouvement.
Si on place tout dans le même pool de liquidité (LP), quand les positions crypto sont liquidées en masse, le moteur de liquidation consomme la liquidité LP, alors que les positions FX n’ont presque pas bougé. Résultat : la liquidité LP est “capturée” par la volatilité crypto.
Le plan de @Hertzflow_xyz est une isolation en couches : chaque actif tourne dans son propre pool, et les LP choisissent eux-mêmes le niveau de risque qu’ils acceptent d’endosser. La direction est la bonne.
Mais l’isolation crée un nouveau problème. Les fluctuations quotidiennes de la devise (FX) et de l’or sont faibles, et les volumes de trading sont sur le long terme plutôt bas. Des pools isolés risquent donc de s’amincir ; quand de grosses positions entrent, le slippage devient élevé, voire le système refuse directement la transaction.
D’où la nécessité de définir, pour chaque catégorie d’actifs, des seuils minimaux de profondeur différenciés ; ou bien d’offrir aux LP des commissions plus élevées sur les pools à faible volatilité pour attirer la liquidité. On pourrait même autoriser un emprunt de liquidité limité entre pools.
En outre, la couche d’agrégation Vault présente un problème de latence de reéquilibrage dans les conditions extrêmes. Comme les pools de stratégies dépendent au niveau inférieur de chaque pool isolé, quand le pool crypto “explose”, il faut vérifier si les ordres de reéquilibrage peuvent s’exécuter immédiatement, s’ils risquent de se bloquer sur la chaîne — des tests de résistance (stress tests) sont nécessaires.
Deuxième défi : la compensation/clearing multi-actifs doit-elle être liée
La documentation insiste sur l’isolation du marché, mais il peut néanmoins exister des contrôles de risque au niveau du compte, même dans le cadre d’un même compte.
Quand le BTC explose (liquidation), est-ce que cela déclenchera des contrôles de vérification forcée sur les positions en or, ou entraînera une réduction (diminution) liée des positions ? Si on fait un lien entre actifs, il faut fournir aux traders un interrupteur clair d’ouverture/fermeture des garanties de marge indépendante. Si on ne fait pas de lien, il faut s’assurer qu’une explosion d’un seul pool ne puisse pas affecter indirectement les autres pools via un oracle partagé ou le moteur de liquidation.
À l’heure actuelle, la documentation publique ne précise pas clairement l’implémentation finale de l’isolation des risques au niveau du compte et au niveau des positions. Après le lancement du réseau principal, il faudra juger selon le comportement réel des contrats.
Des utilisateurs ayant testé sur le testnet ont remonté que lors de la fermeture à fort effet de levier, le prix de liquidation affiché à l’interface et le prix d’exécution réel dérivent de 2 à 3 secondes. La cause serait que l’UI ne suit pas assez vite les événements on-chain.
Sur le réseau principal, il faut optimiser jusqu’au niveau de la milliseconde ; sinon, l’expérience des utilisateurs à fort levier s’effondre immédiatement.
Le scénario de “double massacre” extrême doit aussi être conçu à l’avance. Le 5 août 2024, le Nikkei a chuté de 12 % ; ce jour-là, le BTC est passé de 60 000 à 49 000. USDJPY est passé de 146 à 141.
S’il y avait alors un perp multi-actifs en cours d’exécution, il faudrait que le système tienne : le débit de liquidation, la fréquence de mise à jour de l’oracle et la capacité de réapprovisionnement immédiate des LP. Je recommande de traiter en priorité les actifs à forte volatilité et d’ajouter un mécanisme de coupe-circuit (fuse/frenage).
Troisième défi : l’oracle peut-il servir en même temps autant d’actifs
Hertzflow utilise une validation croisée via plusieurs oracles, principalement Pyth.
Mais les taux de mise à jour des FX, actions et matières premières, les règles de fermeture pendant les vacances, la gestion des sauts (gap) anormaux — tout cela est totalement différent de celui des cryptomonnaies.
Pendant la période du testnet, une panne de Pyth a déjà déclenché des opérations de maintenance. Ce qu’il faut faire : définir des pondérations d’oracle dédiées par catégorie d’actifs, ajuster dynamiquement les intervalles de confiance, et basculer automatiquement vers des sources de secours.
Il faut aussi rester réaliste sur le levier. Le site officiel annonce jusqu’à 1000x ; la documentation GitBook parle de 500x. En pratique, les limites varient selon les actifs et les modes. Sur le réseau principal, les paramètres finaux suivront les informations officielles.
Pour les actifs non crypto, il faut forcer une baisse de plafond : 100x à 200x pour les FX est raisonnable, tandis que seul le crypto peut autoriser un levier plus élevé. Sinon, le retard de l’oracle, combiné au levier élevé, deviendra un amplificateur de catastrophes.
Les “portes dures” avant le lancement du réseau principal
Premièrement : au début d’août 2026, il n’y a toujours aucun rapport d’audit public par un tiers. Couvrir entièrement les modules clés — liquidation, reéquilibrage, limites de retraits, rôles et permissions — c’est une exigence minimale. C’est l’une des barrières les plus dures avant le lancement du réseau principal.
Deuxièmement : quand l’utilisation est élevée ou quand les traders ont un floating profit important, les retraits ont un plafond. Il faut donc afficher de manière plus transparente le solde réellement disponible en temps réel, et simuler des scénarios de stress du type : “les traders gagnent tous en même temps et tout le monde demande à retirer” (collective盈利+同时提款).
Troisièmement : même si le testnet est excellent sur le plan numérique, la profondeur au lancement du réseau principal pourrait ne pas être suffisante. Les mécanismes d’incitation des LP au début — des récompenses plus élevées, des programmes de minage de profondeur à durée limitée — détermineront si, après le lancement du réseau principal, il y a réellement de la liquidité… ou si l’histoire est racontée puis l’argent se retire.
Revenons à la question initiale : les perp multi-actifs peuvent-ils devenir une catégorie indépendante ?
Le besoin est réel. Pour ceux qui font du trading macro, il faut naturellement observer simultanément plusieurs marchés ; le fait qu’un seul terminal gère toutes les positions est une amélioration concrète.
Mais la question vitale est de savoir si la liquidation (clearing) et les LP peuvent maîtriser en même temps des volatilités différentes. Tant que ces ajustements ne sont pas faits avant l’exécution en conditions réelles sur le réseau principal, le risque est bien plus grand que l’efficience apparente.
À l’inverse, si tout fonctionne, ce n’est pas seulement Hertzflow qui est défini : c’est l’ensemble de la catégorie, avec sa norme.
https://testnet.hertzflow.xyz
@Hertzflow_xyz
Mais on peut remonter à partir de trois défis de conception pour déduire si, après le lancement du réseau principal de Hertzflow, il sera possible de les franchir.
Premier défi : le pool LP doit-il être isolé
La volatilité des cryptomonnaies n’est pas du tout du même ordre de grandeur que celle des changes (FX). Une baisse quotidienne de 15 % du BTC est monnaie courante, tandis qu’une baisse quotidienne de 1,5 % sur USDJPY correspond à un gros mouvement.
Si on place tout dans le même pool de liquidité (LP), quand les positions crypto sont liquidées en masse, le moteur de liquidation consomme la liquidité LP, alors que les positions FX n’ont presque pas bougé. Résultat : la liquidité LP est “capturée” par la volatilité crypto.
Le plan de @Hertzflow_xyz est une isolation en couches : chaque actif tourne dans son propre pool, et les LP choisissent eux-mêmes le niveau de risque qu’ils acceptent d’endosser. La direction est la bonne.
Mais l’isolation crée un nouveau problème. Les fluctuations quotidiennes de la devise (FX) et de l’or sont faibles, et les volumes de trading sont sur le long terme plutôt bas. Des pools isolés risquent donc de s’amincir ; quand de grosses positions entrent, le slippage devient élevé, voire le système refuse directement la transaction.
D’où la nécessité de définir, pour chaque catégorie d’actifs, des seuils minimaux de profondeur différenciés ; ou bien d’offrir aux LP des commissions plus élevées sur les pools à faible volatilité pour attirer la liquidité. On pourrait même autoriser un emprunt de liquidité limité entre pools.
En outre, la couche d’agrégation Vault présente un problème de latence de reéquilibrage dans les conditions extrêmes. Comme les pools de stratégies dépendent au niveau inférieur de chaque pool isolé, quand le pool crypto “explose”, il faut vérifier si les ordres de reéquilibrage peuvent s’exécuter immédiatement, s’ils risquent de se bloquer sur la chaîne — des tests de résistance (stress tests) sont nécessaires.
Deuxième défi : la compensation/clearing multi-actifs doit-elle être liée
La documentation insiste sur l’isolation du marché, mais il peut néanmoins exister des contrôles de risque au niveau du compte, même dans le cadre d’un même compte.
Quand le BTC explose (liquidation), est-ce que cela déclenchera des contrôles de vérification forcée sur les positions en or, ou entraînera une réduction (diminution) liée des positions ? Si on fait un lien entre actifs, il faut fournir aux traders un interrupteur clair d’ouverture/fermeture des garanties de marge indépendante. Si on ne fait pas de lien, il faut s’assurer qu’une explosion d’un seul pool ne puisse pas affecter indirectement les autres pools via un oracle partagé ou le moteur de liquidation.
À l’heure actuelle, la documentation publique ne précise pas clairement l’implémentation finale de l’isolation des risques au niveau du compte et au niveau des positions. Après le lancement du réseau principal, il faudra juger selon le comportement réel des contrats.
Des utilisateurs ayant testé sur le testnet ont remonté que lors de la fermeture à fort effet de levier, le prix de liquidation affiché à l’interface et le prix d’exécution réel dérivent de 2 à 3 secondes. La cause serait que l’UI ne suit pas assez vite les événements on-chain.
Sur le réseau principal, il faut optimiser jusqu’au niveau de la milliseconde ; sinon, l’expérience des utilisateurs à fort levier s’effondre immédiatement.
Le scénario de “double massacre” extrême doit aussi être conçu à l’avance. Le 5 août 2024, le Nikkei a chuté de 12 % ; ce jour-là, le BTC est passé de 60 000 à 49 000. USDJPY est passé de 146 à 141.
S’il y avait alors un perp multi-actifs en cours d’exécution, il faudrait que le système tienne : le débit de liquidation, la fréquence de mise à jour de l’oracle et la capacité de réapprovisionnement immédiate des LP. Je recommande de traiter en priorité les actifs à forte volatilité et d’ajouter un mécanisme de coupe-circuit (fuse/frenage).
Troisième défi : l’oracle peut-il servir en même temps autant d’actifs
Hertzflow utilise une validation croisée via plusieurs oracles, principalement Pyth.
Mais les taux de mise à jour des FX, actions et matières premières, les règles de fermeture pendant les vacances, la gestion des sauts (gap) anormaux — tout cela est totalement différent de celui des cryptomonnaies.
Pendant la période du testnet, une panne de Pyth a déjà déclenché des opérations de maintenance. Ce qu’il faut faire : définir des pondérations d’oracle dédiées par catégorie d’actifs, ajuster dynamiquement les intervalles de confiance, et basculer automatiquement vers des sources de secours.
Il faut aussi rester réaliste sur le levier. Le site officiel annonce jusqu’à 1000x ; la documentation GitBook parle de 500x. En pratique, les limites varient selon les actifs et les modes. Sur le réseau principal, les paramètres finaux suivront les informations officielles.
Pour les actifs non crypto, il faut forcer une baisse de plafond : 100x à 200x pour les FX est raisonnable, tandis que seul le crypto peut autoriser un levier plus élevé. Sinon, le retard de l’oracle, combiné au levier élevé, deviendra un amplificateur de catastrophes.
Les “portes dures” avant le lancement du réseau principal
Premièrement : au début d’août 2026, il n’y a toujours aucun rapport d’audit public par un tiers. Couvrir entièrement les modules clés — liquidation, reéquilibrage, limites de retraits, rôles et permissions — c’est une exigence minimale. C’est l’une des barrières les plus dures avant le lancement du réseau principal.
Deuxièmement : quand l’utilisation est élevée ou quand les traders ont un floating profit important, les retraits ont un plafond. Il faut donc afficher de manière plus transparente le solde réellement disponible en temps réel, et simuler des scénarios de stress du type : “les traders gagnent tous en même temps et tout le monde demande à retirer” (collective盈利+同时提款).
Troisièmement : même si le testnet est excellent sur le plan numérique, la profondeur au lancement du réseau principal pourrait ne pas être suffisante. Les mécanismes d’incitation des LP au début — des récompenses plus élevées, des programmes de minage de profondeur à durée limitée — détermineront si, après le lancement du réseau principal, il y a réellement de la liquidité… ou si l’histoire est racontée puis l’argent se retire.
Revenons à la question initiale : les perp multi-actifs peuvent-ils devenir une catégorie indépendante ?
Le besoin est réel. Pour ceux qui font du trading macro, il faut naturellement observer simultanément plusieurs marchés ; le fait qu’un seul terminal gère toutes les positions est une amélioration concrète.
Mais la question vitale est de savoir si la liquidation (clearing) et les LP peuvent maîtriser en même temps des volatilités différentes. Tant que ces ajustements ne sont pas faits avant l’exécution en conditions réelles sur le réseau principal, le risque est bien plus grand que l’efficience apparente.
À l’inverse, si tout fonctionne, ce n’est pas seulement Hertzflow qui est défini : c’est l’ensemble de la catégorie, avec sa norme.
https://testnet.hertzflow.xyz
@Hertzflow_xyz