Auteur : James Evans (@jimbo_evans)
Compilation : Deep Tide TechFlow
Guide Deep Tide : Il s'agit d'une proposition d'amélioration complète de Hyperliquid, suggérant l'introduction d'un mécanisme d'enchères de liquidation continue au niveau protocolaire, permettant aux nouveaux projets de tokens de réaliser entièrement sur la chaîne la collecte de capitaux et le lancement de liquidités, sans dépendre d'échanges centralisés ou de plateformes tierces.
L'auteur s'est inspiré du modèle d'enchères de liquidation continue d'Uniswap et l'a repensé pour l'environnement de carnet d'ordres de Hyperliquid. La proposition est extrêmement détaillée sur le plan technique, couvrant chaque aspect de la configuration au règlement en passant par les considérations de sécurité.
Texte intégral :
Remerciements spéciaux à @fiegemax pour les idées, les conseils et les retours, ainsi qu'à @arnx813, @0xBroze, @0xOmnia, @xenoflux, @happenwah, @const_hom et @DougieDeLuca pour leur relecture et leurs commentaires.
Divulgation : Je détiens $HYPE sur mon compte personnel. Je travaille chez @recvcx, mais cet article représente uniquement mon opinion personnelle et non la position de Reciprocal Ventures.
Résumé
Le HIP-6 introduit un mécanisme d'enchères de token sans autorisation pour les actifs HIP-1, conçu spécifiquement pour les équipes qui lancent des tokens nativement sur @HyperliquidX. Ce mécanisme adapte les enchères de liquidation continue (CCA) de @Uniswap à l'environnement natif du carnet d'ordres (CLOB) de Hyperliquid. Lors de l'inscription aux enchères, les projets choisissent un actif de cotation parmi les actifs de cotation alignés reconnus par le protocole (comme USDH), créant ainsi de nouvelles sources de demande et d'utilité pour ces actifs. Les revenus des enchères reviennent aux projets, dont une partie configurable est automatiquement injectée dans HIP-2 pour la liquidité via le prix moyen pondéré par le volume pendant la fenêtre de clôture des enchères. Toute la logique des enchères s'exécute dans la transition de blocs de HyperCore, sans besoin d'opérateur externe.
Motivation
HIP-1 et HIP-2 prennent en charge le déploiement de tokens sans autorisation et la liquidité automatisée, mais offrent un soutien insuffisant à la formation de capital et à la découverte de prix pour les nouveaux tokens. Les équipes qui lancent des tokens nativement sur @HyperliquidX sont encore largement contraintes de lever des fonds hors chaîne, d'injecter manuellement des liquidités dans HIP-2 avec leurs propres fonds, et/ou de faire leur introduction sur un carnet d'ordres peu fourni. En raison de ces frictions, Hyperliquid n'a pas encore atteint la parité produit en termes de capacités ICO avec d'autres écosystèmes et échanges haute performance. @solana a @metadao, @base a le Liquidity Launchpad de @Uniswap et @dopplerprotocol, @coinbase a @echodotxyz. HIP-6 est optionnel, mais en permettant une formation de capital et une découverte de prix plus efficaces, HIP-6 soutient les fondateurs qui souhaitent construire le cycle de vie complet de leur projet sur Hyperliquid et fait avancer l'objectif de Hyperliquid de devenir la blockchain qui accueille toute la finance.
HIP-6 améliore Hyperliquid de la manière suivante :
Formation de capital sur chaîne : Les équipes peuvent lever des fonds nativement sur Hyperliquid en un seul processus, les revenus étant répartis entre le projet et l'injection automatique de liquidités HIP-2.
Découverte de prix équitable : Les enchères de liquidation continue découvrent le prix de marché sur plusieurs blocs, minimisant l'impact du jeu temporel courant dans les enchères traditionnelles.
Croissance des actifs de cotation alignés : Crée de l'utilité pour les actifs de cotation alignés, augmentant ainsi leur TVL et générant des revenus pour le fonds d'aide.
Attraction des bâtisseurs : Les équipes peuvent accomplir le cycle de vie complet du token sur Hyperliquid. Plus de tokens émis sur Hyperliquid signifie plus de frais de transaction pour le fonds d'aide.
Protection des participants : Les fonds engagés sont détenus en séquestre par l'état de HyperCore pendant la durée des enchères, ils ne sont pas sous la garde du projet ni d'un tiers de confiance.
À propos de la dénomination : Cette proposition est numérotée HIP-6 car HIP-5 avait précédemment été attribué à une autre proposition indépendante.
Sur quoi nous construisons
HIP-6 adapte les enchères de liquidation continue de @Uniswap à l'environnement natif CLOB de Hyperliquid. Les CCA décomposent une grande enchère en N petites enchères progressives. À chaque bloc, le protocole libère un lot de tokens et calcule un prix de liquidation uniforme. La découverte de prix se fait progressivement, et non en un seul instant, et les enchérisseurs sont incités à participer plus tôt plutôt qu'à attendre.
Diverses alternatives présentent des défauts évidents :
Ventes à prix fixe : Mauvaise découverte de prix, car quelqu'un doit deviner le bon prix à l'ouverture. Si le prix est trop bas, le projet perd la différence ; s'il est trop élevé, la vente échoue.
Ventes à répartition proportionnelle plafonnées : Corrigent les fuites de valeur, mais créent une spirale de sursouscription. En pratique, si une vente est 2 fois sursouscrite, les participants rationnels déposeront 2 fois le quota cible, la rendant encore plus sursouscrite, et ainsi de suite. C'est une mauvaise expérience utilisateur.
Ventes sans plafond : Évitent la spirale, mais conduisent à un surfinancement. Un projet qui pourrait être construit avec 5 millions lève 50 millions car rien ne l'en empêche. La vague d'ICO de 2017 a montré les conséquences de cette approche.
Enchères traditionnelles : Laissent le marché découvrir le prix, mais créent un jeu temporel. La stratégie optimale est d'attendre le plus possible jusqu'à la fin. Cela crée une pire expérience utilisateur pour les participants non institutionnels.
Courbes de liaison dynamiques : Combinent les enchères hollandaises avec des courbes de liaison sensibles à la demande. Cela fonctionne bien dans un environnement natif AMM, mais n'est pas adapté à l'environnement natif CLOB de Hyperliquid.
Ce qui peut être construit sur HIP-6
HIP-6 résout les problèmes de formation de capital et de découverte de prix : comment les nouveaux projets lèvent des fonds et injectent des liquidités sur Hyperliquid. Il ne traite pas des mécanismes spécifiques d'accumulation de valeur des tokens, des mesures de protection des détenteurs de tokens, ou de la gouvernance spécifique au projet. Ce sont des problèmes indépendants, et nous nous attendons à ce que les équipes construisent sur HIP-6 pour les résoudre.
Exemples de ce que les futurs projets pourraient construire sur HIP-6 :
Mécanismes d'accumulation de valeur : Définissent comment les revenus du protocole reviennent aux détenteurs de tokens (comme la distribution de frais, les rachats, les récompenses de jalonnement).
Cadres de gouvernance : Donnent aux détenteurs de tokens le droit de vote sur l'allocation du trésor, les changements de paramètres et/ou les mises à niveau du protocole.
Protection des détenteurs de tokens : Fournissent des outils comme le verrouillage du trésor, des exigences de reporting sur chaîne et/ou des mécanismes de vesting, appliquant des verrous à la fois aux acheteurs et aux quotas de l'équipe.
L'objectif de HIP-6 est de rendre l'enchère initiale aussi équitable et efficace que possible. Ce qui se passe après l'enchère est un espace de conception pour la communauté Hyperliquid. HIP-6 n'empêche pas les équipes de collaborer avec des market makers pour renforcer la liquidité de leur projet sur le carnet d'ordres.
Brouillon de document public
Voici un brouillon de la façon dont HIP-6 pourrait être présenté dans la documentation publique de Hyperliquid. Il est inclus ici pour permettre aux relecteurs de prévisualiser la description orientée utilisateur.
HIP-6 : Enchères d'émission de tokens
HIP-6 introduit des enchères d'émission de tokens sans autorisation pour les actifs HIP-1. Les projets offrent une partie de leur offre de tokens à la vente via des enchères de liquidation continue. Les enchérisseurs engagent des fonds dans un actif de cotation aligné (actuellement USDH). Les enchérisseurs spécifient leur budget total et le prix maximum qu'ils sont prêts à payer par token. L'enchère répartit ensuite cette offre sur les blocs restants de l'enchère. À chaque bloc de l'enchère, le protocole libère des tokens à un taux fixe. Le protocole fait ensuite correspondre l'offre de tokens libérés à la demande des enchérisseurs, trouvant un prix de liquidation uniforme pour chaque bloc. Au règlement, des frais de protocole sont envoyés au fonds d'aide, une partie des revenus est automatiquement injectée dans HIP-2 Hyperliquidity au prix découvert pendant la fenêtre finale de l'enchère, et le reste revient au projet. Toute la logique des enchères s'exécute dans la transition de blocs de HyperCore.
Déploiement des enchères
Le projet appelle registerAuction après avoir terminé les étapes standard de déploiement HIP-1 (registerToken2, userGenesis (le cas échéant), genesis et registerSpot). Le projet spécifie les paramètres suivants :
auctionSupply : Quantité totale de tokens vendus. Transférée sous séquestre du protocole depuis le compte spot du projet lors de l'inscription.
duration : Durée de l'enchère en blocs, maximum 3 024 000 (environ 1 semaine à 0,2 s/bloc).
floorPx : Prix de liquidation minimum, par défaut 0.
startDelay : Nombre de blocs entre l'inscription et le premier bloc de liquidation, minimum 1, par défaut 1.
minRaise : Montant minimum d'actif de cotation à lever pour que l'enchère réussisse, par défaut 0.
quoteAsset : Doit être un actif de cotation aligné reconnu par le protocole (comme USDH).
hip2Seed : Partie en points de base des revenus nets (après frais de protocole) automatiquement injectée dans HIP-2. Plage de 2 000 à 10 000, par défaut 2 000.
hip2OrderSz et hip2NOrders : Taille et nombre d'ordres HIP-2, requis.
Tous les paramètres sont immuables une fois enregistrés. Le gel des transferts du token est activé à l'inscription, bloquant toutes les commandes spot, transferts et opérations HyperEVM pour ce token jusqu'au règlement. Le projet peut annuler l'enchère via cancelAuction avant le startBlock de l'enchère (c'est-à-dire pendant la période de startDelay).
Soumission d'offres
L'enchérisseur appelle submitBid, en spécifiant un budget (minimum 100 unités de l'actif de cotation) et maxPx (prix maximum par token, arrondi à la baisse sur la grille des ticks de l'enchère). Le budget est mis sous séquestre à la soumission. Chaque soumission d'offre entraîne des frais irrécupérables de 1 unité de l'actif de cotation. Le budget est automatiquement réparti uniformément sur les blocs d'enchère restants. Les offres soumises dans le bloc h participent activement à la liquidation à partir du bloc h+1. Les offres soumises pendant la période de startDelay sont activées au premier bloc de liquidation.
Les enchérisseurs peuvent soumettre plusieurs offres avec des prix maximums différents pour exprimer une courbe de demande, mais chaque enchère est limitée à 100 000 offres. Les enchérisseurs ne peuvent retirer leurs offres que si le maxPx de l'offre est strictement inférieur au dernier prix de liquidation.
Liquidation
À chaque bloc pendant l'enchère, le protocole libère des tokens à un taux fixe (auctionSupply / duration par bloc) et calcule le prix de liquidation uniforme en parcourant les ticks de prix occupés du plus haut au plus bas jusqu'à ce que la demande cumulée satisfasse l'offre. Les offres au-dessus du prix de liquidation obtiennent leur quota complet. Les offres exactement au prix de liquidation se partagent le reste au prorata de leur budget par bloc. Les offres en dessous du prix de liquidation n'obtiennent rien. La grille des prix de l'enchère utilise un espacement de tick géométrique de 1,003, cohérent avec HIP-2.
Règlement, activation HIP-2 et réclamation
Dans le premier bloc après la fin de l'enchère, si minRaise est défini mais n'est pas atteint, l'enchère échoue. Tous les actifs de cotation alignés sont remboursés, tous les tokens sont rendus au projet et le gel est levé. Si totalQuoteSpent est zéro, l'enchère échoue quel que soit minRaise.
En cas de succès, le protocole effectue atomiquement :
Déduit 500 bp de frais de protocole du total des quotes dépensés, envoyés au fonds d'aide.
Alloue hip2Seed pour l'activation de HIP-2.
Transfère la partie restante vers le portefeuille du projet.
Renvoie les tokens invendus au projet.
Lève le gel du token, reprenant les transactions spot, transferts et opérations EVM.
Active HIP-2, en utilisant les paramètres d'ordre hip2OrderSz et hip2NOrders spécifiés par le projet. hip2Seed est utilisé pour injecter nSeededLevels niveaux. Le prix de départ est seedPx, calculé via la moyenne pondérée par le volume (VWAP) sur les derniers 5 % de la durée de l'enchère.
Après le règlement, les enchérisseurs réclament les tokens achetés et les actifs de cotation non utilisés via claimAuction.
Frais
Des frais d'inscription de 10 HYPE sont prélevés lors de registerAuction. Chaque submitBid coûte 1 unité de l'actif de cotation. Un frais de protocole de 500 bp est prélevé sur le revenu total au règlement. Tous les frais vont au fonds d'aide. Le setDeployerTradingFeeShare existant du projet s'applique normalement aux transactions spot après l'enchère.
Sur quoi nous construisons
HIP-6 Hy-CO est une enchère de liquidation continue intégrée dans la logique de transition de blocs de HyperCore. Les enchérisseurs soumettent des offres dans un actif de cotation aligné (comme USDH), chaque offre spécifiant un budget et un prix maximum. À chaque bloc, le protocole libère un lot de tokens et calcule un prix de liquidation uniforme pour ce bloc. Les enchérisseurs dont le prix maximum est strictement supérieur au prix de liquidation obtiennent un quota complet ; ceux exactement au prix de liquidation obtiennent le reste, pouvant être partiellement exécutés. À la fin de l'enchère, le protocole prélève des frais envoyés au fonds d'aide, injecte une proportion configurable des revenus restants dans HIP-2 Hyperliquidity au prix moyen pondéré par le volume calculé sur la fenêtre finale de l'enchère, et envoie le reste au portefeuille du projet. Le règlement à la fin de l'enchère est atomique.
Cycle de vie de Hy-CO
Hy-CO a trois phases :
Pré-enchère : Configuration. Le projet appelle registerAuction après avoir terminé les étapes standard de déploiement HIP-1. Le protocole valide les paramètres, séquestre l'offre de tokens et l'offre du vendeur, active le gel du token et attribue un ID d'enchère.
Pendant l'enchère : Soumission d'offres. Les enchérisseurs peuvent soumettre des offres via submitBid pendant la période de startDelay ou à tout moment pendant l'enchère. Le budget est séquestré à la soumission, quelle que soit la date de soumission de l'offre. Liquidation. À chaque bloc de l'enchère à partir de startBlock, le protocole libère des tokens et calcule le prix de liquidation uniforme.
Post-enchère : Règlement. Dans le premier bloc après endBlock, le protocole évalue si l'enchère a réussi et alloue les revenus. Activation HIP-2. Après un règlement réussi, HIP-2 est automatiquement activé en utilisant seedPx et les paramètres d'ordre spécifiés par le projet. Réclamation. Après le règlement, les enchérisseurs réclament les tokens achetés et les actifs de cotation non utilisés via claimAuction. La période de réclamation permet des transactions normales.
Annulation : cancelAuction peut être exécuté à tout moment avant startBlock. Il renvoie auctionSupply et hip2AskSupply au projet, lève le gel et libère l'emplacement d'enchère. Si des offres ont été soumises pendant la période de startDelay, l'enchère suit le chemin d'échec : les enchérisseurs récupèrent leurs actifs de cotation séquestrés via claimAuction (même chemin de remboursement extractif que pour une enchère échouée). Les auctionRegistrationFee ne sont pas remboursables. Une fois la liquidation commencée, l'enchère est irrévocable.
Décisions clés de conception
Pourquoi un nouveau HIP et non un produit tiers : L'émission de tokens est une infrastructure, pas une application. Si chaque équipe construit son propre mécanisme d'émission, l'écosystème se fragmentera. Un HIP signifie que chaque token émis sur Hyperliquid (s'il choisit d'utiliser HIP-6) bénéficie de la même découverte de prix équitable et de la même injection automatique HIP-2, sans dépendance externe. Cela signifie également que le mécanisme est garanti par le validateur consensus, et non par un tiers.
Pourquoi HyperCore et non HyperEVM : Tout ce dont HIP-6 a besoin existe déjà sur HyperCore. Construire sur HyperEVM introduirait une complexité inutile, dégradant l'expérience utilisateur en ajoutant des étapes et de la latence.
Pourquoi des enchères de liquidation continue : Les enchères traditionnelles créent un jeu temporel qui récompense la vitesse plutôt que l'évaluation ; les courbes de liaison dépendent du chemin ; les ventes à prix fixe nécessitent de deviner le bon prix. Les CCA répartissent les offres dans le temps, liquident à un prix uniforme par bloc et convergent sur des milliers de blocs, plutôt que de se résoudre en un instant unique.
Pourquoi n'autoriser que les actifs de cotation alignés : Les enchères sont libellées dans un actif de cotation aligné (actuellement USDH). Chaque enchère verrouille l'actif de cotation pendant sa durée, augmentant la TVL et générant des revenus pour l'écosystème. Prendre en charge des actifs non alignés comme USDC diluerait cet effet pour un bénéfice d'adoption marginal. Les enchérisseurs détenant USDC peuvent convertir via l'interface standard.
Pourquoi un calendrier de libération linéaire prédéfini : La linéarité garantit que le prix de liquidation est monotone non décroissant, ce qui permet une comptabilisation efficace au moment de la réclamation via des points de contrôle cumulatifs. Les calendriers non linéaires (pondérés en fin, pondérés en début) pourraient faire baisser le prix de liquidation lorsque l'offre par bloc augmente soudainement, compliquant la comptabilisation au niveau de l'offre. Ceux-ci pourraient être introduits dans de futurs HIP, sous réserve d'une extension du schéma de comptabilisation.
Considérations de sécurité
Auto-transaction du projet : Le projet pourrait enchérir sur sa propre enchère via un portefeuille indépendant pour gonfler le prix de liquidation et le VWAP, puis récupérer les tokens invendus après le règlement. Mesures d'atténuation : Les frais de protocole rendent l'auto-transaction coûteuse sur tout le volume auto-transigé ; seedPx est calculé sur une fenêtre VWAP couvrant les derniers 5% de l'enchère, nécessitant une dépense soutenue pour la manipulation ; minRaise fait échouer l'enchère si la demande réelle est insuffisante ; toutes les offres sont visibles sur la chaîne, rendant l'auto-transaction détectable. Quantitativement, un projet exécutant une enchère de 1 million USDH (protocolFee = 500, hip2Seed = 2000), enchérissant via un portefeuille indépendant de 400 000 USDH (40% du total) : perd environ 20 000 USDH vers le fonds d'aide (5% de frais de protocole, non récupérables), environ 76 000 USDH sont verrouillés dans l'injection HIP-2 (non rendus au projet). La perte sèche totale est d'environ 96 000 USDH, soit 24% des fonds auto-transigés. Le coût augmente linéairement avec le volume d'auto-transaction.
Manipulation du prix de départ : Le seedPx de HIP-2 utilise un VWAP fenêtré couvrant environ les derniers 5% de la durée de l'enchère, et non le prix de liquidation du dernier bloc. Manipuler le VWAP nécessite une dépense soutenue sur plusieurs blocs dans la fenêtre, plutôt qu'une injection tardive unique, rendant le coût proportionnel au volume total de la fenêtre.
Sécurité des fonds : Les actifs de cotation des enchérisseurs et les tokens d'enchère sont séquestrés par le protocole tout au long du processus. Les fonds ne sont jamais sous la garde du projet. En cas d'échec, tous les actifs de cotation sont remboursés via claimAuction, tous les tokens sont rendus au projet.
Application du gel des tokens : Tous les transferts de tokens (carnet d'ordres spot, pair-à-pair, HyperEVM) sont gelés pendant une enchère active. Cela empêche les initiés détenant des quotas userGenesis ou l'offre réservée du projet de vendre des tokens par des canaux non enchères pendant la découverte de prix.
Délai d'activation des offres : Les offres ne participent à la liquidation qu'à partir du bloc suivant leur soumission. Cela empêche le proposant de bloc ou les participants à faible latence d'observer les offres en attente et d'insérer des offres réactives dans le même bloc pour influencer le prix de liquidation.
Analyse d'impact sur les parties
Projets de tokens : Hy-CO offre aux projets un moyen natif de lever des fonds et d'injecter des liquidités en un seul processus. Le projet configure l'enchère avec le déploiement HIP-1, reçoit les revenus sur son portefeuille (moins la partie allouée à HIP-2 via hip2Seed) et obtient une injection de liquidité automatique au prix découvert par le marché. Le compromis est un contrôle réduit sur le prix initial.
Utilisateurs de Hyperliquid : Les utilisateurs obtiennent la capacité de participer directement à l'émission de tokens des nouvelles équipes construisant sur Hyperliquid. Actuellement, il n'existe pas de moyen natif d'acheter un projet à son lancement ; les utilisateurs soit manquent la distribution initiale, soit achètent sur le carnet d'ordres public après l'injection HIP-2. Hy-CO offre aux utilisateurs un accès équitable avec un prix uniforme et une répartition des offres, accessible via la même interface qu'ils utilisent déjà. Après le règlement, les enchérisseurs doivent appeler claimAuction pour déplacer les tokens achetés et les actifs de cotation non utilisés vers leur compte spot avant de pouvoir trader. Les tokens ne sont pas distribués automatiquement. Le carnet d'ordres spot ouvre uniquement avec la liquidité HIP-2 ; aucune profondeur d'ordres limite organique n'existe avant que les market makers et autres participants passent des ordres. Si de nombreux participants à l'enchère vendent immédiatement après la réclamation, les niveaux d'achat de HIP-2 pourraient s'épuiser rapidement. Ceci est un comportement attendu pour toute nouvelle introduction, pas unique à HIP-6, mais les interfaces devraient afficher clairement l'état de la réclamation et définir l'attente que l'écart sera plus large au début après l'enchère que sur un marché mature.
Détenteurs de HYPE : Hy-CO profite aux détenteurs de HYPE de deux manières. Premièrement, le mécanisme d'émission natif incite les nouvelles équipes à construire et émettre sur Hyperliquid plutôt que sur des chaînes concurrentes, faisant croître l'écosystème et dirigeant l'activité vers le carnet d'ordres de Hyperliquid. Deuxièmement, les enchères libellées dans un actif de cotation aligné (comme USDH) augmentent son utilité et ses réserves, servant de source de revenus cyclique complétant les frais de transaction de Hyperliquid via le fonds d'aide.
Fournisseurs de liquidité et market makers : Après l'enchère, le carnet d'ordres démarre avec une profondeur d'achat réelle financée par les revenus de l'enchère (via hip2Seed), et non avec une mince injection HIP-2. Cela fournit aux LP et market makers un prix de départ plus crédible et une liquidité plus profonde pour trader dès le premier jour.
Validateurs et croissance de l'état : Le coût de liquidation par bloc pour une seule enchère est O(T), où T est le nombre de ticks de prix occupés. Avec tickSpacingFactor = 1.003, T est limité à quelques milliers de ticks, mais en pratique la plupart des enchères auront quelques centaines de ticks occupés. Avec maxActiveAuctions = 16, la charge de travail par bloc dans le pire des cas est de 16 × O(T). Chaque opération est une comparaison et une addition du budget de tick agrégé, comparable au coût de correspondance du carnet d'ordres spot existant. Aucune nouvelle opération cryptographique ou lecture externe n'est nécessaire.
Projets de travail futurs
Les éléments ci-dessous dépassent le cadre de ce HIP, mais sont des extensions naturelles à évaluer à mesure que HIP-6 mûrit : Examen des constantes du protocole par la gouvernance ; Liquidation par lots (tous les K blocs) ; Calendriers de libération non linéaires ; Injection HIP-2 échelonnée ; Mécanisme de réserve HIP-2 ; Expiration de la réclamation et nettoyage de l'état ; Intégration de l'interface utilisateur.
