Auteur | Azuma(@azuma_eth)
Le 12 août à l'heure de Pékin, Jeff Yan, le fondateur de Hyperliquid, a publié une mise à jour dans le canal Discord officiel. En raison d'une formulation initiale très technique, beaucoup ont négligé ou sous-estimé la portée de cette annonce.
Traduction littérale
Voici la traduction directe de l'annonce originale de Jeff Yan.
- Suite aux retours des développeurs (Builders), la proposition HIP-1 ajoutera la fonction suivante, contrôlée par le déployeur du jeton : scaleWei { token, totalWei, referenceToken, systemAddress }.
- Cette opération transférera automatiquement et proportionnellement le montant total (totalWei) du jeton 'token' depuis l'adresse 'systemAddress' vers les utilisateurs, en fonction du solde qu'ils détiennent du jeton 'referenceToken'. Les calculs arrondissent à l'inférieur et excluent l'adresse 'systemAddress' elle-même. Par exemple, lorsque token == referenceToken, cette fonctionnalité peut être utilisée pour une redénomination.
- L'adresse 'systemAddress' peut être de deux types : l'adresse système du Core → EVM ; ou une adresse de Trésorerie (Treasury) spécifiée par le déployeur et capable de fournir une signature. Il est important de noter que l'EVM lui-même ne dispose pas d'une telle fonctionnalité atomique. Par conséquent, si le jeton concerné existe également dans l'environnement EVM, le contrat intelligent correspondant devra peut-être intégrer une logique personnalisée pour synchroniser cette opération avec les soldes du jeton sur l'EVM.
- Lorsque 'token' et 'referenceToken' sont le même jeton : Tous les ordres non exécutés (Open Orders) seront annulés, puis recréés selon le ratio de redénomination réel, en arrondissant à la précision requise par szDecimals ; totalWei peut être négatif. Cela permet une redénomination dans le sens inverse.
- Nous accueillons vos retours pour que cette fonctionnalité puisse répondre au mieux aux besoins d'utilisation réelle.
Il est évident que sans une certaine compréhension des concepts de contrats intelligents, il est difficile de saisir la véritable signification de cette mise à jour de Hyperliquid.
Explication simplifiée
En termes simples, Hyperliquid est en train d'ajouter à HIP-1 une capacité jusqu'ici peu commune – la possibilité d'ajuster de manière programmatique et groupée les actifs des utilisateurs directement au « niveau des soldes » d'HyperCore.
Le plus important ici n'est pas le nom de la fonction scaleWei ou ses paramètres, mais bien ce qu'ils permettent de faire.
Supposons qu'un jeton A existe sur Hyperliquid. Alice en détient 100, Bob 50 et Charlie 10. Si une adresse contient 1600 jetons B, et que A est utilisé comme 'referenceToken', le système peut alors distribuer automatiquement ces 1600 jetons B à chacun proportionnellement à sa détention de A.
La répartition serait :
- Alice détient 62,5% de A, reçoit 1000 B ;
- Bob détient 31,25%, reçoit 500 B ;
- Charlie détient 6,25%, reçoit 100 B.
Les utilisateurs n'ont pas besoin de cliquer sur « Claim » ni d'appeler individuellement un contrat intelligent ; HyperCore peut directement modifier les soldes des comptes selon les règles définies.
Et si token == referenceToken, une « redénomination » (redenomination) sera exécutée, rendant le changement encore plus direct.
Par exemple, pour un jeton action dont les positions sont : Alice 100 actions, Bob 50, Charlie 10, si un split d'actions 1 pour 10 est effectué, le système peut directement ajuster les soldes.
Les nouvelles positions seraient :
- Alice détient 1000 actions ;
- Bob détient 500 actions ;
- Charlie détient 100 actions.
La proportion détenue par chacun reste inchangée, seule l'unité de compte change. L'inverse est également vrai.
La mise à jour de Hyperliquid prend également en compte le problème des ordres en cours. Si un actif subit un split 1:10, un ordre de vente de 100 actions placé précédemment ne peut rester tel quel, car il ne correspondrait plus au nouveau système de positions après le split. Par conséquent, le système annulera les anciens ordres et les recréera selon le nouveau ratio, en traitant la quantité selon la précision szDecimals. En d'autres termes, il s'agit de faire effectuer une redénomination conjointe des soldes, des ordres et d'autres états de transaction.
Une fois la logique de mise à jour comprise, à quoi peut bien servir cette « capacité programmable au niveau des soldes » ?
Scénarios d'application
Pour l'instant, le contenu publié par Jeff Yan décrit principalement la capacité fondamentale de scaleWei. Mais autour de cette capacité, nous pouvons déjà discerner plusieurs orientations d'application claires autour des jetons actions.
Scénario 1 : Dividendes
Les dividendes sont l'un des droits fondamentaux des actions traditionnelles. Dans les systèmes de courtage classiques, il s'agit d'une action d'entreprise standard ; dans le mode EVM typique, pour effectuer une opération similaire, il faut généralement enregistrer les adresses éligibles via un contrat intelligent, puis laisser les utilisateurs les réclamer activement, ou laisser l'équipe du projet procéder à la distribution une par une.
scaleWei offre une autre possibilité – distribuer directement les actifs de dividendes aux utilisateurs proportionnellement à leur solde de jetons actions sur HyperCore. Supposons qu'à l'avenir, un jeton action d'une société cotée apparaisse sur Hyperliquid, et que l'entreprise décide de verser un dividende de 1 dollar par action – Alice détenant 100 actions, Bob 50, Charlie 10, le système pourrait directement allouer l'actif de dividende à leurs comptes respectifs proportionnellement, sans que l'utilisateur n'ait à réclamer manuellement, ni que l'équipe du projet n'ait à appeler le contrat pour chaque individu ; HyperCore lui-même pourrait effectuer ce transfert groupé.
Scénario 2 : Split et regroupement d'actions
C'est en fait le scénario déjà explicitement associé à cette mise à jour. Lorsque 'token' et 'referenceToken' sont le même actif, scaleWei peut ajuster uniformément les soldes de tous les détenteurs selon un ratio.
Ainsi, à l'avenir, si un actif HIP-1 nécessite un split 1:10, un regroupement (reverse split) 10:1, ou même un ajustement de l'unité de transaction minimale, cela pourra être exécuté directement, et le système synchronisera l'annulation et la recréation des ordres non exécutés. Pour un système de transaction qui aspire vraiment à porter des actions ou des ETF, ce type d'« action d'entreprise » est une fonctionnalité standard.
Scénario 3 : Rebase
Un mécanisme similaire peut également servir au Rebase. Pour simplifier, il s'agit d'un ajustement de la quantité totale ou de l'unité de l'actif lui-même (fréquent notamment lors de la conversion d'actions pré-IPO, où le nombre d'actions peut être ajusté), tandis que les proportions relatives de détention entre utilisateurs restent inchangées.
Auparavant, ce type d'opération reposait souvent sur la logique propre du contrat de jeton, mais à l'avenir, cela pourrait devenir une capacité native d'HyperCore.
Scénario 4 : Airdrops
Un autre scénario assez intuitif est celui des airdrops. Le 'referenceToken' n'est pas obligatoirement égal au jeton distribué, donc en théorie, on peut directement distribuer un actif B proportionnellement à la détention de A.
Par exemple, si un projet décide de distribuer un autre jeton aux détenteurs d'un certain actif HIP-1, le système peut directement lire le solde de A des utilisateurs sur HyperCore, puis distribuer B proportionnellement depuis une adresse de Trésorerie spécifiée.
Cela signifie qu'au moins au sein d'HyperCore, certaines actions traditionnelles de « réclamation d'airdrops » pourraient à l'avenir être encore simplifiées en une distribution de solde effectuée directement par le système.
Combler le déficit des « actions d'entreprise » pour les actions symbolisées
Il est important de souligner que la mise à jour annoncée par Jeff Yan se concentre pour l'instant sur la fonctionnalité de base, et ne signifie pas que Hyperliquid a annoncé qu'il allait distribuer des dividendes sur les jetons actions de sa plateforme. Cependant, au niveau de l'infrastructure, le chemin technique pour la capacité nécessaire aux scénarios décrits ci-dessus – « distribuer des actifs aux comptes proportionnellement aux positions » – existe désormais.
En considérant les scénarios d'application potentiels, la véritable signification de cette mise à jour de Hyperliquid réside dans sa capacité potentielle à combler le déficit des « actions d'entreprise » pour les actifs sur chaîne.
Ces dernières années, lorsque l'industrie discutait de la tokenisation des actions, l'accent était souvent mis sur – « les actions peuvent-elles être placées sur la chaîne ? ». Mais si l'on veut vraiment mettre des actions sur chaîne, le problème va bien au-delà de cela. Après l'émission d'actions, une série d'actions d'entreprise se produisent continuellement : dividendes, splits, regroupements, augmentations de capital, distributions d'actifs, etc.
Par conséquent, une infrastructure complète d'actions sur chaîne nécessite non seulement de pouvoir « trader des actions », mais aussi de pouvoir gérer ces changements d'état de l'actif en dehors des transactions, et c'est précisément ce que commence à aborder la mise à jour de Hyperliquid.
Sous cet angle, scaleWei ressemble davantage à la pièce manquante d'une infrastructure pour l'étape suivante de Hyperliquid – permettre aux actifs financiers sur chaîne non seulement d'être « échangeables », mais aussi de subir diverses actions d'entreprise, à l'instar des actifs financiers du monde réel.
