Prix de Highstreet (HIGH)

Highstreet est un projet construit autour de Highstreet World ; HIGH est le jeton utilitaire de son écosystème, utilisé notamment pour des achats sur le marché. Le dépôt de code du projet définit Highstreet Market comme un produit du monde virtuel, et non HIGH lui-même comme un titre de propriété sur un article particulier. Dans cette conception du marché, les utilisateurs peuvent utiliser HIGH pour acheter des produits en quantité limitée ; les jetons de produit constituent une autre catégorie associée aux marchandises spécifiques. Il convient donc de distinguer HIGH du jeton d’un produit donné et du droit de rachat éventuel de ce produit.

Highstreet Market est un marché conçu pour des produits en quantité limitée, que le projet décrit comme accessible à la fois sur le web et comme lieu au sein de Highstreet World. Sa conception vise à permettre l’achat, l’échange et le rachat de jetons de produit associés à des biens physiques ou à certains articles en édition limitée. Cela signifie que les jetons on-chain présents sur le marché ne sont pas de simples certificats d’affichage : dans le processus décrit par le README, les jetons de produit sont liés à l’étape de rachat des biens correspondants. L’existence d’un produit donné, sa quantité et ses conditions précises d’échange dépendent toujours de la configuration effective de son pool de produits.

Selon la conception initiale de ce marché, le prix des jetons de produit est calculé conjointement à partir d’un pool de réserves et d’une courbe de prix, plutôt que déterminé par l’appariement direct d’acheteurs et de vendeurs dans un carnet d’ordres. Après qu’un utilisateur a déposé des actifs de réserve dans le pool de réserves d’un produit, le contrat crée des jetons de produit conformément à la fonction de prix ; les achats et les ventes modifient le solde des réserves et l’offre de jetons, déclenchant ainsi le recalcul du prix suivant. Le README définit le ratio de réserve comme un rapport fixe entre la capitalisation des jetons de produit et le solde des réserves, et indique que ce ratio influe sur la sensibilité du prix : lorsque le ratio de réserve est plus élevé, le prix est moins sensible aux variations causées par les transactions. Cette conception traite également spécifiquement le fait que les jetons de produit sont indivisibles et que leur prix initial ne peut pas être nul ; le mécanisme de courbe ne doit donc pas être interprété comme une garantie de hausse du prix ou de sortie à tout moment à un prix donné.

HIGH est le jeton utilitaire de l’écosystème, tandis qu’un jeton de produit correspond à un produit particulier en quantité limitée ; leurs rôles sont différents. Selon le README, les jetons de produit sont créés conformément à une fonction de prix après qu’un utilisateur a déposé du DAI ou de l’ETH dans le pool de réserves du produit concerné. Le rachat d’un jeton de produit modifie son offre : lorsqu’un utilisateur rachète un produit, le jeton est envoyé à l’adresse zéro et retiré définitivement de la circulation. L’usage de HIGH pour des achats sur le marché ne le rend pas automatiquement équivalent à un jeton de produit donné, et la détention de HIGH ne donne pas droit au rachat d’une marchandise.

Le README a proposé un minage de liquidité « Proof of Play » : les utilisateurs devaient d’abord rejoindre le service d’abonnement Viveport, puis réaliser des activités désignées dans le monde virtuel, comme acheter ou vendre des produits sur le marché, afin de recevoir des HIGH. La source des récompenses, l’éligibilité et le règlement sont tous liés à l’intégration au service et aux conditions de mission indiquées dans ce programme initial. Le même README indique également que l’utilisation de HIGH pour acheter des produits peut déclencher des récompenses de staking liées au pool de produits ; sur les frais de 4% prélevés pour chaque achat, 1% devait être attribué aux stakers de HIGH de ce pool, avec des récompenses payées en HIGH lors de la vente ou du rachat de jetons de produit. La documentation emploie aussi des formulations telles que « future release » et « goal » ; ces éléments doivent donc être considérés comme une conception de mécanisme initiale, sans permettre d’affirmer qu’ils sont actuellement déployés, applicables à tous les utilisateurs ou à tous les pools de produits.