Hyperliquid teste HIP-3 et ses listes blanches de wallets

Hyperliquid teste HIP-3*, une extension optionnelle de son cadre de perpétuels gérés par les builders, qui permet aux déployeurs de marché individuels d'imposer des listes blanches de portefeuille sur leurs propres venues. La fonctionnalité a été publiée dans une mise à jour développeur du 3 septembre sur le canal Hyperliquid API Announcements, et n'est actuellement disponible que sur le testnet, sans date de lancement sur le mainnet annoncée. Un déployeur HIP-3* peut agir au nom d'un utilisateur de cinq manières délimitées : ajouter ou retirer une approbation de liste blanche, annuler des ordres passifs spécifiques, annuler en masse des ordres passifs et des TWAPs sur la venue, passer des ordres reduce-only, et transférer des collatéraux vers un autre compte sur la même venue. Les ordres passés via proxy doivent être reduce-only, de sorte qu'un opérateur peut réduire une position, mais pas l'agrandir via la fonction proxy.

Pourquoi c'est important

HIP-3* est le premier outil de contrôle d'accès qu'Hyperliquid a livré pour son modèle builder-deployer, et le cadrage compte autant que la fonctionnalité. Les déployeurs qui exploitent un marché HIP-3 portent déjà la charge économique et opérationnelle : ils définissent les contrats, maintiennent les oracles, fixent les limites de levier, règlement les marchés, et doivent staker 500 000 HYPE, que les validateurs peuvent slasher pour des entrées irrégulières mettant en péril l'exactitude, la disponibilité ou les performances du protocole. HIP-3* ajoute une couche de filtrage par portefeuille au-dessus de ce modèle d'opérateur, sans transférer la responsabilité de la venue vers le protocole central ni imposer le KYC au reste du réseau. L'intention déclarée d'Hyperliquid est d'aider les déployeurs indépendants à satisfaire les exigences qui s'appliquent à eux, et non de servir elle-même de couche de conformité.

Cette séparation est ce qui rend la fonctionnalité lisible pour les contreparties institutionnelles. Une entreprise ayant des contraintes d'onboarding client, des exclusions de juridictions sanctionnées, ou des restrictions de flux partenaires dispose désormais d'un outil onchain pour filtrer sa propre venue, tandis que les déployeurs ouverts continuent de gérer des carnets sans permission. Ce n'est pas une approbation réglementaire, et ce n'est pas un lancement sur le mainnet, mais c'est le type de plomberie qu'un desk de trésorerie ou un prime broker demanderait avant de router du flux vers un DEX builder-deployer.

Impact sur le marché

La lecture immédiate est structurelle plutôt que réactive.