Pour les jetons d'infrastructure, qui correspondent à un réseau de couche 1 (ou à une partie adjacente de la pile informatique comme la couche 2), les modèles économiques sont bien développés et compris, enracinés dans l'offre et la demande d'espace de blocs. Mais pour les jetons d'application, les protocoles de contrats intelligents déployant des services sur les blockchains qui relaient des droits dans des "entreprises distribuées", les modèles économiques sont encore en cours de résolution.

Les modèles économiques de jetons d'application doivent être aussi expressifs que leur logiciel sous-jacent. À cette fin, nous introduisons des flux de trésorerie pour les jetons d'application - une approche qui permet aux applications de créer des modèles permissifs et flexibles et aux utilisateurs de choisir comment ils sont récompensés pour la valeur qu'ils fournissent. Cette méthode génère des frais à partir d'activités légitimes dans différentes juridictions, conformément aux exigences réglementaires, favorisant ainsi une plus grande conformité. Elle maximise également la valeur qui revient au protocole tout en encourageantminimisation de la gouvernance.

Les principes que nous partageons ici s'appliquent à toutes les applications web3 - de DeFi aux applications sociales décentralisées, aux réseaux DePIN, et partout entre les deux.

Défis pour les modèles de jetons

Les jetons d'infrastructure sont soumis à l'offre et à la demande intégrées : à mesure que la demande augmente, l'offre diminue et les marchés s'ajustent en conséquence. Cette base économique native pour de nombreux jetons d'infrastructure a été accélérée par la proposition d'amélioration Ethereum 1559 (EIP-1559), qui a mis en place des frais de base à brûler pour toutes les transactions Ethereum. Mais malgré des tentatives ponctuelles de modèles d'achat et de brûlage, il n'y a pas de parallèle à l'EIP-1559 pour les jetons d'application.

Les applications sont des utilisateurs, pas des fournisseurs, de l'espace de bloc, elles ne peuvent donc pas compter sur la collecte des frais de gaz des autres utilisant leur espace de bloc. C'est pourquoi elles ont besoin de développer leurs propres modèles économiques.

Il y a également des défis juridiques ici : les modèles économiques de jetons d'infrastructure sont plus isolés des risques juridiques, en raison de la nature générique des transactions typiques de la blockchain et des mécanismes programmables qu'ils utilisent. Mais pour les modèles économiques de jetons d'application, les applications impliquées peuvent dépendre de la facilitation d'une activité réglementée et peuvent nécessiter l'intermédiation des détenteurs de jetons de gouvernance, rendant l'économie plus compliquée. Une bourse décentralisée qui facilite la négociation de dérivés, une activité hautement réglementée aux États-Unis, est radicalement différente, disons, d'Ethereum.

La combinaison de ces défis intrinsèques et extrinsèques signifie que les jetons d'application nécessitent un modèle économique différent. Avec cela à l'esprit, nous présentons une solution possible : une méthode de conception de protocoles qui rémunère les détenteurs de jetons d'application pour leurs services tout en maximisant les revenus du protocole, en encourageant la conformité réglementaire et en intégrant minimisation de la gouvernance. Notre objectif est simple : donner aux jetons d'application le même fondement économique, à travers les flux de trésorerie, que de nombreux jetons d'infrastructure ont déjà.

Notre solution se concentre sur la résolution de trois problèmes auxquels sont confrontés les jetons d'application concernant:

1. Défis liés à la gouvernance
2. Défis liés à la distribution de la valeur
3. Défis liés à l'activité réglementée

1. Défis liés à la gouvernance

Les jetons d'application ont généralement des droits de gouvernance, et la présence d'une Organisation Autonome Décentralisée (DAO) peut introduireincertitudeque les jetons d'infrastructure ne rencontrent pas. Pour les DAO avec des opérations importantes aux États-Unis, des risques peuvent survenir si le DAO a le contrôle sur les revenus du protocole ou intermédie l'activité économique du protocole et rend une telle activité programmatique. Pour éviter ces risques, les projets peuvent éliminer le contrôle qu'un DAO a en minimisant la gouvernance. Pour les DAO où cela n'est pas possible, le nouveau WyomingDecentralized Unincorporated Nonprofit Association (DUNA)fournitunentité juridique décentralisée qui peut aider à atténuer ces risques et à se conformer aux lois fiscales applicables.

2. Défis liés à la distribution de la valeur

Les applications doivent également faire preuve de prudence dans la conception du mécanisme de distribution de la valeur aux détenteurs de jetons. Combinaison vote et droits économiquespeut soulever des préoccupations en vertu des lois sur les valeurs mobilières américaines, en particulier avec des mécanismes simples et directs comme les distributions pro rata et les rachats de jetons. Ces mécanismes ressemblent aux dividendes et aux rachats d'actions, et peuvent affaiblir les arguments selon lesquels les jetons méritent un cadre réglementaire différent de celui des actions.

Les projets devraient plutôt explorer le capitalisme des parties prenantes - récompenser les détenteurs de jetons pour leurs contributions au projet d'une manière qui bénéficie au projet. De nombreux projets ont encouragé la participation positive, y compris en exploitant un frontend (Liquity), participant au protocole (Goldfinch) et en engageant un collatéral dans le cadre d'un module de sécurité (Aave. L'espace de conception ici est grand ouvert, mais un bon point de départ est de cartographier tous les parties prenantes dans un projet, de déterminer quels comportements doivent être encouragés de chacun d'entre eux, et de décider quelle valeur globale le protocole peut créer via cette incitation.

Pour simplifier, dans ce post, nous supposerons un modèle de rémunération simple qui récompense les détenteurs de jetons pour leur participation à la gouvernance, bien que d'autres schémas existent.

3. Défis liés à l'activité réglementée

Les applications qui facilitent l'activité réglementée doivent également faire attention lors de la conception des mécanismes d'accumulation de valeur pour les détenteurs de jetons. Si de tels mécanismes accumulent de la valeur à partir de frontaux ou d'API qui ne sont pas exploités en conformité avec la loi applicable, les détenteurs de jetons pourraient tirer profit d'activités illicites.

La plupart des solutions proposées à ce problème ont cherché à limiter l'accumulation de valeur à l'activité autorisée aux États-Unis - par exemple, ne mettre en marche les frais de protocole qu'en ce qui concerne les pools de liquidité impliquant certains actifs. Cela soumet les projets au dénominateur commun le plus bas des approches réglementaires et mine la proposition de valeur des protocoles logiciels autonomes mondiaux. Cela mine également directement les efforts de minimisation de la gouvernance. Déterminer quelle stratégie de frais fonctionne d'un point de vue de la conformité réglementaire n'est pas une tâche appropriée pour les DAO.

Dans un monde idéal, les projets pourraient collecter des frais sur des activités autorisées dans n'importe quelle juridiction, sans avoir à se fier aux DAO pour déterminer ce qui est autorisé. Le solutionn'est pas de nécessiter la conformité réglementaire au niveau du protocole, mais de s'assurer que les frais générés par le protocole ne sont transmis que si le frontal ou l'API qui les ont générés respectent les lois et réglementations applicables là où se trouve le frontal. Si les États-Unis rendaient illégal de percevoir des frais sur un certain type de transaction facilitée par une application, cela pourrait réduire la valeur économique du jeton de cette application à zéro, même si l'activité était entièrement permise dans tous les autres pays du monde. La flexibilité en ce qui concerne l'accumulation et la distribution des frais équivaut en fin de compte à une résilience face aux pressions réglementaires.

Une question centrale : le suivi des frais

La traçabilité des frais est essentielle pour résoudre les risques potentiels découlant de frontaux non conformes sans introduire de risque de censure ou rendre un protocole autorisé. Grâce à la traçabilité, une application pourrait garantir que tous les frais qui reviennent aux détenteurs de jetons proviennent uniquement de frontaux légalement conformes dans la juridiction du détenteur de jetons. Si les frais sont indétectables, il n'y aurait aucun moyen d'isoler les détenteurs de jetons de l'accumulation de valeur provenant de frontaux non conformes (c'est-à-dire des frais collectés par des frontaux non conformes), ce qui pourrait exposer les détenteurs de jetons à des risques.

Pour rendre les frais traçables, un protocole pourrait utiliser une conception de système de mise en jeu de jetons d'application en deux étapes.

Étape 1 : identifier quel frontend a généré les frais, et

Étape 2 : acheminer les frais vers différents pools en fonction d'une logique personnalisée.

Mapping frontaux

La traçabilité des frais nécessite une correspondance un à un d'un domaine à une paire de clés publique/privée. Sans cette correspondance, un frontend malveillant pourrait usurper des transactions et prétendre qu'elles ont été soumises à partir d'un domaine honnête. La cryptographie nous permet de "enregistrer" les frontends, en enregistrant de manière immuable le domaine pour mapper la clé publique, prouvant que le domaine contrôle effectivement cette clé publique, et en signant les transactions avec ladite clé privée. Cela nous donne la capacité d'attribuer des transactions, et donc des frais, à un domaine donné.

Frais de routage

Une fois que la source des frais est traçable, le protocole peut déterminer comment distribuer ces frais de manière à isoler les détenteurs de jetons de la réception de frais provenant de transactions illicites, mais sans pour autant augmenter les charges de gouvernance décentralisée du DAO. Pour illustrer ce point, pensez au spectre des conceptions possibles pour le jalonnement des jetons d'application, allant d'un seul pool de jalonnement pour chaque frontend à un seul pool de jalonnement pour tous les frontends.

Dans sa construction la plus simple, les frais de chaque interface utilisateur pourraient être acheminés vers un module de jalonnement spécifique à l'interface utilisateur. En sélectionnant les interfaces utilisateur sur lesquelles miser, un détenteur de jetons pourrait décider des frais qu'il recevait et éviter tout frais qui placerait le détenteur de jetons en danger juridique. Par exemple, un détenteur de jetons pourrait uniquement miser sur le module associé à une interface utilisateur ayant reçu toutes les approbations réglementaires en Europe. Bien que cette conception semble simple, elle est en réalité assez compliquée. Il pourrait y avoir 50 pools de jalonnement pour 50 interfaces utilisateur différentes, et la dilution des frais pourrait être préjudiciable à la valeur du jeton.

À l’autre extrémité du spectre, les frais de chaque front-end pourraient être mis en commun, mais cela va à l’encontre de l’objectif de traçabilité des frais. Si tous les frais sont mis en commun, il n’y a aucun moyen de différencier les frais des frontends conformes de ceux qui ne le sont pas – une pomme pourrie gâcherait le baril. Les détenteurs de tokens seraient contraints de choisir entre ne pas recevoir de frais ou de participation dans un pool où ils bénéficieraient des activités illégales de frontends non conformes dans leur juridiction – une option qui pourrait dissuader de nombreux détenteurs de tokens de participer ou pourrait ramener le système à des conceptions sous-optimales actuelles, où une DAO doit évaluer où des frais peuvent être appliqués.

Traçabilité des frais de traitement grâce à la curation

Ces complexités pourraient être résolues par la curation. Considérons une application de protocole de contrat intelligent sans permission qui a des frais et un jeton. N'importe qui peut créer une interface pour l'application et chaque interface peut avoir son propre module de mise en jeu. Appelons une interface de cette application du protocole app.xyz.

App.xyz pourrait suivre des règles de conformité spécifiques pour la juridiction dans laquelle elle est située. L'activité de l'application qui a été générée à partir de l'application xyz génère des frais de protocole. App.xyz possède son propre module de mise en jeu, et les détenteurs de jetons peuvent miser leurs jetons sur ce module directement ou sur un conservateur qui souhaite choisir individuellement un panier de frontaux qu'ils jugent conformes. Ces détenteurs de jetons gagneraient un rendement sous forme de frais provenant de l'ensemble des frontaux sur lesquels ils misent. Si un frontal génère 100 $ de frais, et que 100 entités misent chacune 1 jeton, alors chaque entité a droit à 1 $. Les conservateurs pourraient initialement facturer des frais pour leurs services. À l'avenir, les gouvernements pourraient faire des attestations onchain sur la conformité des frontaux dans leur juridiction pour aider à protéger les consommateurs, avec l'avantage accessoire étant l'automatisation de la curation.

L’un des risques potentiels de ce modèle est que les frontends non conformes pourraient être moins coûteux à exploiter, car ils n’ont pas les frais administratifs des frontends conformes. Ils pourraient également concevoir des modèles pour recycler les frais d’entrée aux traders afin d’encourager davantage leur solution de contournement. Deux facteurs atténuent ce risque. Tout d’abord, la plupart des utilisateurs veulent que les frontends conformes respectent les lois et réglementations locales. Cela s’applique particulièrement aux grandes institutions réglementées. Deuxièmement, la gouvernance pourrait jouer un rôle essentiel en dernier recours ou en tant qu'« autorité de veto » sur les frontends non conformes qui enfreignent les règles de manière répétée et mettent en danger la viabilité de l’application, décourageant ainsi les mauvais comportements.

Enfin, toutes les frais des transactions qui ne sont pas initiées via une interface enregistrée seraient déposées dans un module de mise en jeu globale unique, permettant au protocole de capturer les revenus des transactions initiées par des robots et d'autres interactions directes avec les contrats intelligents du protocole.

De la théorie à la mise en œuvre: Mettre la méthode en pratique

Revisitons en détail la pile de jetons d'application. Pour qu'un protocole facilite le jalonnement frontal, il devrait établir un contrat intelligent de registre auquel les frontends devraient s'inscrire.

1. Chaque interface utilisateur ou API peut ajouter un enregistrement TXT spécial à l'enregistrement DNS de leur domaine comme le Intégration ENS DNSCe fichier TXT contient la clé publique d'une paire de clés générée une fois par le frontend, appelée le certificat.

1. Le client frontal peut ensuite appeler une fonction register() et prouver qu'il possède son nom de domaine. Une correspondance du domaine avec la clé publique du certificat, et vice versa, est stockée.
2. Lorsque des transactions sont créées par le client, il signe également la charge utile de la transaction avec sa clé publique de certificat. Celles-ci sont transmises aux contrats intelligents de l'application dans un ensemble.
3. Les contrats intelligents de l'application valident le certificat, vérifient qu'il correspond au bon corps de transaction et a été enregistré. Si oui, la transaction est traitée. Les frais générés par la transaction sont ensuite envoyés à un contrat de collecte de frais avec le nom de domaine (du registre).
4. Le FeeCollector permet aux curateurs, utilisateurs, validateurs et autres, de mettre en jeu des jetons directement sur un domaine ou un ensemble de domaines. Ces contrats doivent suivre le montant des jetons mis en jeu sur chaque domaine, la part de mise en jeu de chaque adresse et la durée pendant laquelle ils ont été mis en jeu. Les implémentations populaires de l'exploitation de la liquidité peuvent être utilisées comme point de départ pour cette logique de contrat.
5. Les utilisateurs qui ont mis en jeu des curateurs (ou directement les contrats de gestion des frais eux-mêmes) peuvent ensuite retirer la part proportionnelle des frais en fonction de la quantité de jeton d'application mis en jeu sur le domaine. L'architecture pourrait être similaire à Gate.MetaMorpho/Bleu Morpho.

Ceci pourrait être introduit sans augmenter la charge de gouvernance du DAO d'une application. En fait, les responsabilités de gouvernance pourraient être réduites car le commutateur de frais pourrait être activé en permanence pour toutes les transactions facilitées par le protocole, ce qui éliminerait tout contrôle du DAO sur le modèle économique du protocole.

Considérations supplémentaires en fonction du type d'application

Bien que ces principes s'appliquent largement aux modèles économiques des jetons d'application, il peut y avoir d'autres considérations de frais en fonction du type d'application : applications construites sur des couches 1 ou 2, des chaînes d'applications et des applications construites à l'aide de rollups.

Considérations pour les applications L1/L2

Les applications sur les chaînes de blocs de couche 1 ou de couche 2 ont des contrats intelligents déployés directement onchain. Les frais seraient perçus lorsque les utilisateurs interagissent avec les contrats intelligents des applications. Habituellement, cela se fait via une interface facile à utiliser (comme une application ou un site Web) qui sert d'interface entre un utilisateur final et les contrats intelligents sous-jacents. Dans ce cas, les frais proviendraient de cette interface. L'exemple ci-dessus concernant l'application app.xyz illustre comment un système de frais pourrait fonctionner pour une application de couche 1.

Au lieu de compter sur des curateurs pour filtrer les frais du frontend, les applications pourraient également adopter une approche de liste blanche ou de liste noire pour les frontends contribuant aux frais de réseau. Encore une fois, le but ici serait de s'assurer que les détenteurs de jetons, et le protocole dans son ensemble, ne tirent pas profit ou ne bénéficient pas d'activités illicites et respectent les lois et réglementations spécifiques à chaque juridiction.

Dans l'approche de la liste blanche, l'application publierait un ensemble de règles pour les interfaces, créerait un registre de ces interfaces qui respectent les règles, délivrerait un certificat aux interfaces qui y adhèrent, et exigerait des interfaces qu'elles misent des jetons pour recevoir une partie des frais d'application. Si les interfaces ne respectent pas ces règles, elles seraient réduites, et leur certificat de contributions aux frais serait retiré.

Dans l'approche de la liste noire, les applications n'auraient pas à créer de règles, mais le lancement d'une interface pour l'application ne serait pas sans autorisation. Au lieu de cela, l'application exigerait que toute interface utilisateur fournisse un avis d'un cabinet d'avocats confirmant que l'interface est conforme à sa juridiction avant de permettre à cette interface d'utiliser l'application. Une fois l'avis reçu, l'application délivrerait un certificat à l'interface utilisateur pour les contributions financières qui ne seraient retirées que si l'application reçoit un avis d'un régulateur selon lequel l'interface utilisateur n'est pas conforme.

Le pipeline de frais refléterait les exemples fournis dans les sections précédentes.

Les deux approches augmentent considérablement le fardeau de la gouvernance décentralisée, obligeant les DAO à établir et maintenir un ensemble de règles ou à évaluer des avis juridiques sur la conformité. Dans certains cas, cela peut être acceptable, mais dans la plupart des cas, externaliser ce fardeau de conformité à un conservateur serait préférable.

Considérations pour les appchains

Les Appchains sont des blockchains spécifiques à une application avec des validateurs qui ne fonctionnent que pour cette application.

En retour de leur travail, ces validateurs reçoivent un paiement. Contrairement aux blockchains de couche 1 où les validateurs sont souvent récompensés par l'émission inflationniste de jetons, certaines appchains (dYdX) transmettent plutôt les frais des clients aux validateurs.

Dans ce modèle, les détenteurs de jetons doivent miser sur des validateurs pour recevoir des récompenses. Les validateurs deviennent les modules d'enjeu sélectionnés.

Cet ensemble de travail est différent d'un validateur de couche 1. Les validateurs d'Appchain règlent des transactions spécifiques d'une application spécifique. En raison de cette différence, les validateurs d'Appchain pourraient supporter un degré plus élevé de risque juridique concernant l'activité sous-jacente qu'ils facilitent. Par conséquent, les protocoles devraient accorder aux validateurs la liberté d'effectuer le travail qu'ils peuvent accomplir conformément aux lois de leur juridiction et à leur propre niveau de confort. Il est important de noter que cela peut être fait sans compromettre le caractère sans permission de l'Appchain ou en le soumettant à un risque de censure important à condition que son ensemble de validateurs soit géographiquement décentralisé.

L'architecture des appchains souhaitant tirer parti des avantages de la traçabilité des frais serait similaire à celle des applications de couche 1 jusqu'au pipeline de frais. Mais les validateurs pourraient utiliser la cartographie frontend pour déterminer à partir de quels frontaux ils souhaitent traiter les transactions. Les frais pour une transaction donnée iraient ensuite à l'ensemble des validateurs actifs, les validateurs inactifs qui choisissent de ne pas participer ne percevant pas de tels frais. D'un point de vue des frais, le validateur remplit la même fonction que les conservateurs du module de mise en jeu mentionnés ci-dessus et les miseurs sur ces validateurs pourraient s'assurer qu'ils ne perçoivent pas de revenus provenant d'activités illicites. Les validateurs pourraient également élire un conservateur pour déterminer quels frontaux sont conformes par juridiction.

Considérations pour les rollups d'application

Les Rollups ont leur propre espace de blocs mais peuvent hériter de la sécurité d'une autre chaîne. La plupart des Rollups d'aujourd'hui ont un seul séquenceur qui est responsable de la séquence et de l'inclusion des transactions, bien que les transactions puissent être soumises directement à la couche 1 par le biais d'un processus appelé...inclusion forcée.”

Si ces cumuls sont spécifiques à l’application et consacrent leur séquenceur en tant que validateur unique, les frais générés par les transactions incluses par ce séquenceur peuvent être distribués aux stakers en fonction de l’ensemble organisé de frontends conformes ou en tant que pool général.

Si les rollups décentralisent leur ensemble de séquenceurs, les séquenceurs deviennent de facto les modules de mise en jeu sélectionnés et le pipeline des frais refléterait celui des appchains. Les séquenceurs remplacent les validateurs pour la distribution des frais, et chaque séquenceur peut prendre ses propres décisions sur les frontends à partir desquels accepter les frais.

Alors qu'il existe de nombreux modèles possibles pour les jetons d'application, la fourniture de pools d'enjeu sélectionnés est une voie à suivre qui aide à résoudre les problèmes extrinsèques propres aux applications. En reconnaissant les défis intrinsèques et extrinsèques auxquels sont confrontées les applications, les fondateurs peuvent mieux concevoir des modèles de jetons d'application dès le départ pour leur projet.

Avertissement :

1. Cet article est repris de [Gatea16zcrypto]. Tous les droits d'auteur appartiennent à l'auteur original [Mason HallPorter SmithMiles Jennings et Ross Shuel]. Si des objections sont formulées à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.