Hyperliquid clarifie point par point les dix accusations : dévoilement de la solvabilité, du mécanisme de l'Oracle Machine et de la vérité sur la conception de la gouvernance.

【Bloc律动】Récemment, un projet de fête bien connu, Hyperliquid, a répondu publiquement et en détail à une série de questions soulevées par l'extérieur. Ces accusations concernent des problèmes sensibles tels que la solvabilité du système, la transparence des transactions et le mécanisme de gouvernance, et les clarifications apportées par le projet de fête fournissent des informations importantes pour l'ensemble de l'écosystème.

En matière de solvabilité, des doutes ont été émis sur le système concernant un problème de sous-collatéralisation de 362 millions de dollars. Hyperliquid a nié cette affirmation, soulignant que les critiques ont omis un détail clé : les réserves de USDC via le pont Arbitrum sur HyperEVM. Selon les données du projet de fête, le montant total de USDC s'élève actuellement à 4,351 milliards de dollars, suffisant pour couvrir toutes les dettes. Cette différence de chiffres indique qu'une simple requête des données en chaîne peut facilement omettre l'image complète des actifs inter-chaînes.

Concernant les accusations de manipulation du volume des transactions, des critiques ont accusé le projet d'avoir utilisé la fonction TestnetSetYesterdayUserVlm pour réaliser des transactions frauduleuses. Le projet a répondu que c'était simplement du code fonctionnel pour le réseau de test, qui ne peut pas être appelé dans l'environnement de la chaîne principale. Ce type de fonctionnalité de sécurité est très courant pendant la phase de test, mais est mal compris comme une vulnérabilité dans l'environnement de production.

Concernant la question des privilèges des utilisateurs, le projet de fête souligne que tous les frais, soldes et enregistrements de transactions sont visibles sur la chaîne, sans mécanismes d'exemption cachés ni voies de manipulation de la distribution des airdrops. La transparence de l'ensemble du système rend toute anomalie inaperçue.

Dans la conception des autorisations des contrats intelligents, des inquiétudes ont été exprimées concernant le module CoreWriter qui disposerait d'un “mode Dieu”, capable de frapper des pièces et de transférer des fonds à sa guise. En réalité, ce composant n'est qu'un outil d'exécution pour la communication entre HyperEVM et HyperCore, et ne possède pas de soi-disant autorité absolue.

Concernant le mécanisme de gel de la chaîne, le projet de fête précise que cela ressemble à une mise à niveau de fork dur de la blockchain traditionnelle. Lors de l'événement POPCAT en novembre de cette année, le projet n'a pas gelé le réseau de première couche, mais a simplement activé des mesures de verrouillage de sécurité automatiquement sur le pont Arbitrum, ce qui est une opération standard de gestion des risques.

En ce qui concerne la tarification des oracles, une idée fausse technique courante est qu'une seule clé privée peut manipuler le prix instantanément. Dans la conception réelle, l'oracle HIP-3 est configuré de manière flexible par le déployeur, prenant en charge des solutions de signature multiple comme MPC. Le prix des contrats perpétuels utilise un algorithme de médiane pondérée, décidé par plusieurs validateurs, éliminant ainsi le risque de point unique.

Concernant les inquiétudes centralisées sur la soumission des transactions, le projet de fête indique que 8 adresses ne représentent que la configuration actuelle des nœuds d'envoi des transactions, certaines transactions ayant été directement traitées par les validateurs. À l'avenir, une protection MEV et une mise à niveau contre la censure seront également ajoutées.

En ce qui concerne le mécanisme de liquidation, le projet nie l'existence d'un cartel de liquidation injuste. Seuls les HLP (fournisseurs de liquidité) peuvent agir en tant que liquidateurs de secours, et la participation est sans seuil. La grande majorité des liquidations se fait par le biais d'un carnet d'ordres public, la concurrence est transparente.

Concernant les accusations liées aux protocoles de prêt cachés, le projet indique que la marge de garantie du portefeuille, les fonctions de prêt et le modèle HLP sont tous des versions pré-alpha publiées publiquement, et la documentation complète a été enregistrée. Ces fonctionnalités innovantes évoluent sous le regard de la communauté.

Enfin, concernant les préoccupations sur la fonction ModifyNonCirculatingSupply qui pourrait modifier l'offre de jetons, le projet a clarifié que HIP-1 stipule que l'offre totale est complètement fixe et que cette fonction est uniquement utilisée pour le calcul d'affichage, sans aucun impact sur la circulation réelle.