a16z : Comment les jetons d'applications peuvent-ils construire un modèle financier générant des flux de trésorerie ?
TechFlow SélectionTechFlow Sélection
a16z : Comment les jetons d'applications peuvent-ils construire un modèle financier générant des flux de trésorerie ?
Le modèle commercial d'un jeton d'application devrait être aussi expressif que le logiciel sur lequel il repose.
Dédié à des analyses Web3 approfondiesAuteurs : Mason Hall, Porter Smith, Miles Jennings, Ross Shuel
Traduction : TechFlow
Pour les jetons d'infrastructure, comme les réseaux de niveau 1 (ou des composants voisins de la pile de calcul tels que les niveaux 2), les modèles économiques sont relativement matures et faciles à comprendre, principalement fondés sur l'offre et la demande d'espace-bloc. En revanche, pour les jetons applicatifs — protocoles de contrats intelligents déployés sur blockchain fournissant des services qui transmettent des droits au sein d'une « entreprise décentralisée » — les modèles économiques restent en cours d'exploration.
Le modèle commercial des jetons applicatifs devrait être aussi expressif que le logiciel sous-jacent. À cette fin, nous proposons un modèle de flux de trésorerie pour les jetons applicatifs — une méthode permettant aux applications de créer des modèles économiques flexibles et adaptables, tout en offrant aux utilisateurs le choix de la manière dont ils souhaitent être récompensés en fonction de la valeur fournie. Cette approche génère des frais par le biais d'activités légales, encourageant ainsi une meilleure conformité dans diverses juridictions. Elle maximise également la valeur accumulée par le protocole, tout en favorisant une gouvernance minimale.
Les principes que nous exposons ici s’appliquent à toutes les applications Web3 — allant de la finance décentralisée (DeFi) aux réseaux sociaux décentralisés, en passant par les réseaux physiques d’infrastructure décentralisés (DePIN) et autres domaines connexes.
Les défis des modèles de jetons
Les jetons d'infrastructure sont influencés par une relation intrinsèque entre offre et demande : lorsque la demande augmente, l'offre diminue, et le marché s'ajuste en conséquence. Cette base économique est renforcée dans de nombreux jetons d'infrastructure, notamment grâce à la proposition d'amélioration d'Ethereum 1559 (EIP-1559), qui implémente un mécanisme de brûlage des frais de base pour toutes les transactions Ethereum. Toutefois, malgré certaines tentatives de modèles d'achat et de destruction, les jetons applicatifs ne disposent pas d'un mécanisme équivalent à EIP-1559.
Les applications sont des utilisateurs, et non des fournisseurs, d'espace-bloc ; elles ne peuvent donc pas compter sur la collecte de frais de gaz provenant d'autres utilisateurs de cet espace. C’est pourquoi elles doivent élaborer leurs propres modèles économiques.
Des défis juridiques existent également : les modèles économiques des jetons d'infrastructure sont relativement peu exposés aux risques légaux en raison de la nature générale des transactions blockchain typiques et de leurs mécanismes programmés. En revanche, les modèles économiques des jetons applicatifs peuvent reposer sur la facilitation d’activités réglementées, nécessitant potentiellement une intervention des détenteurs de jetons de gouvernance — ce qui complexifie davantage le modèle économique. Par exemple, faciliter des transactions de produits dérivés via un exchange décentralisé est une activité fortement réglementée aux États-Unis, ce qui la distingue fondamentalement de projets comme Ethereum.
La combinaison de ces défis internes et externes signifie que les jetons applicatifs ont besoin de modèles économiques différents. Dans cette optique, nous proposons une solution possible : une méthode de conception de protocole visant à récompenser les détenteurs de jetons applicatifs, à maximiser les revenus du protocole, à inciter à la conformité et à intégrer une gouvernance minimale. Notre objectif est simple : doter les jetons applicatifs d’une assise économique similaire à celle des nombreux jetons d’infrastructure, grâce aux flux de trésorerie.
Notre solution se concentre sur trois problèmes spécifiques auxquels sont confrontés les jetons applicatifs :
-
Les défis liés à la gouvernance
-
Les défis liés à la distribution de la valeur
-
Les défis liés aux activités réglementées
1. Défis liés à la gouvernance
Les jetons applicatifs comportent souvent des droits de gouvernance, et la présence d'une organisation autonome décentralisée (DAO) peut introduire une incertitude que n'affrontent pas les jetons d'infrastructure. Pour une DAO opérant significativement aux États-Unis, des risques peuvent apparaître si celle-ci contrôle les revenus du protocole ou orchestre ses activités économiques de façon programmée. Pour éviter ces risques, les projets peuvent supprimer le pouvoir de contrôle de la DAO en minimisant sa gouvernance. Pour celles qui ne le peuvent pas, la nouvelle forme juridique du Wyoming, l'association décentralisée à but non lucratif (DUNA), propose une entité juridique décentralisée pouvant aider à atténuer ces risques et respecter la législation fiscale applicable.
2. Défis liés à la distribution de la valeur
Les applications doivent également faire preuve de prudence lorsqu'elles conçoivent les mécanismes de création de valeur pour les détenteurs de jetons. Le fait de combiner droits de vote et droits économiques peut susciter des inquiétudes au regard des lois américaines sur les valeurs mobilières, particulièrement pour des mécanismes simples et directs comme les distributions proportionnelles ou les rachats et destructions de jetons. Ces mécanismes ressemblent à des dividendes ou à des rachats d'actions, ce qui affaiblit l'argument selon lequel les jetons devraient bénéficier d’un cadre réglementaire distinct de celui des actions.
Les projets devraient explorer le capitalisme des parties prenantes — récompenser les détenteurs de jetons pour leur contribution au projet d'une manière bénéfique pour celui-ci. De nombreux projets encouragent une participation active, comme exploiter une interface utilisateur (par ex. Liquity), participer au protocole (par ex. Goldfinch) ou engager des collatéraux dans un module de sécurité (comme Aave). L’espace de conception est vaste, mais un bon point de départ consiste à recenser tous les acteurs concernés, identifier les comportements à encourager et décider de la valeur globale que le protocole peut créer grâce à ces incitations.
Par souci de simplicité, nous supposerons ici un modèle de compensation simple récompensant les détenteurs de jetons pour leur participation à la gouvernance, bien que d’autres schémas soient possibles.
3. Défis liés aux activités réglementées
Les applications facilitant des activités réglementées doivent également faire attention lorsqu'elles conçoivent des mécanismes d'accumulation de valeur pour les détenteurs de jetons. Si ces mécanismes accumulent de la valeur à partir de frontaux ou d'API qui n'opèrent pas selon les lois applicables, les détenteurs de jetons pourraient profiter d'activités illégales.
La plupart des solutions proposées à ce problème consistent à limiter l'accumulation de valeur aux activités autorisées aux États-Unis — par exemple, en activant les frais du protocole uniquement dans des pools de liquidité impliquant certains actifs spécifiques. Cela astreint les projets à la méthode réglementaire du plus petit dénominateur commun, affaiblissant ainsi la proposition de valeur d’un protocole logiciel autonome et global. Cela sapera également directement les efforts de minimisation de la gouvernance. Déterminer quelles stratégies tarifaires sont conformes relève mal d’une mission appropriée pour une DAO.
Dans un cas idéal, un projet devrait pouvoir percevoir des frais depuis toute juridiction où l’activité est autorisée, sans avoir à dépendre d’une DAO pour déterminer ce qui est permis. La solution n’est pas d’exiger une conformité au niveau du protocole, mais de s’assurer que les frais générés par le protocole ne sont transmis que si les frontaux ou API d’origine respectent les lois et règlements applicables. Si les États-Unis rendent illégal le fait de percevoir des frais sur certaines transactions facilitées par une application, même si cette activité est parfaitement légale ailleurs dans le monde, cela pourrait réduire à zéro la valeur économique du jeton de l’application. Une flexibilité dans l’accumulation et la distribution des frais signifie finalement une résilience face aux pressions réglementaires.
Une question centrale : la traçabilité des frais
La traçabilité des frais est cruciale pour atténuer les risques potentiels liés aux frontaux non conformes, tout en évitant d’introduire des risques de censure ou de rendre le protocole permisif. Grâce à cette traçabilité, une application peut garantir que tout frais accumulé par les détenteurs de jetons provient exclusivement de frontaux légaux et conformes dans la juridiction de ces détenteurs. Sans traçabilité, il est impossible d’isoler les détenteurs de jetons de la valeur accumulée via des frontaux non conformes (c’est-à-dire les frais perçus par ces frontaux), ce qui pourrait les exposer à des risques.
Pour rendre les frais traçables, le protocole peut adopter une conception en deux étapes du système de mise en gage de jetons applicatifs :
-
Première étape : Identifier le frontal à l’origine des frais
-
Deuxième étape : Router les frais vers différents pools selon une logique personnalisée
Cartographier les frontaux
La traçabilité des frais nécessite un mappage du nom de domaine vers une paire de clés publique/privée. Sans ce mappage, un frontal malveillant pourrait falsifier des transactions en prétendant qu’elles proviennent d’un domaine honnête. La cryptographie nous permet d’« enregistrer » un frontal, enregistrant de façon permanente le lien entre le nom de domaine et la clé publique, attestant que ce domaine contrôle effectivement la clé publique, et utilisant la clé privée correspondante pour signer les transactions. Cela nous permet d’attribuer chaque transaction (et donc les frais associés) à un domaine spécifique.
Router les frais
Une fois les frais traçables, le protocole peut décider comment les distribuer afin de protéger les détenteurs de jetons contre les frais issus de transactions illégales, sans alourdir la gouvernance décentralisée de la DAO. Pour illustrer cela, examinons l’éventail de conception des mises en gage de jetons applicatifs, allant d’un pool de gage par frontal à un seul pool commun à tous les frontaux.
Dans la construction la plus simple, les frais de chaque frontal peuvent être dirigés vers un module de gage indépendant spécifique à ce frontal. En choisissant sur quels frontaux miser, les détenteurs de jetons pourront décider quels frais recevoir, et éviter ceux qui pourraient les exposer à des risques juridiques. Par exemple, un détenteur de jetons pourrait choisir de ne miser que sur des modules associés à des frontaux déjà approuvés réglementairement en Europe. Bien que ce design semble simple, il est en réalité assez complexe. Il pourrait y avoir 50 pools de gage pour 50 frontaux différents, et la dilution des frais pourrait nuire à la valeur du jeton.
À l’autre extrémité du spectre, les frais de chaque frontal peuvent être regroupés ensemble — mais cela contredit précisément l’objectif de traçabilité. Si tous les frais sont agrégés, on ne peut plus distinguer ceux provenant de frontaux conformes de ceux venant de frontaux non conformes : un seul mauvais acteur peut corrompre l’ensemble. Les détenteurs seraient alors forcés de choisir entre ne recevoir aucun frais ou miser dans un pool unique où ils bénéficieraient indirectement d’activités illégales menées par des frontaux non conformes dans leur juridiction — une option qui découragerait probablement beaucoup de participants, ou ramènerait le système vers les modèles sous-optimaux actuels où la DAO doit évaluer où les frais peuvent être appliqués.
Résoudre la traçabilité des frais par la curation
Ces complexités peuvent être résolues par la curation. Imaginons un protocole d'application sans permission, basé sur un contrat intelligent, doté de frais et d’un jeton. N'importe qui peut créer un frontal pour cette application, et chaque frontal peut disposer de son propre module de mise en gage. Appelons frontend.app.xyz l’un de ces frontaux.
frontend.app.xyz peut suivre des règles de conformité spécifiques à sa juridiction. Les activités de l’application via frontend.app.xyz génèrent des frais de protocole. Ce frontal dispose de son propre module de mise en gage. Les détenteurs de jetons peuvent soit y miser directement leurs jetons, soit miser auprès de curateurs qui sélectionnent individuellement un panier de frontaux qu’ils jugent conformes. Ces participants seront récompensés par les frais générés par les frontaux sur lesquels ils ont misé. Si un frontal génère 100 dollars de frais, et que 100 entités ont chacune misé 1 jeton, chaque entité aura droit à 1 dollar. Initialement, les curateurs peuvent facturer un service. À l’avenir, les autorités pourraient certifier en chaîne la conformité des frontaux dans leur juridiction, protégeant ainsi les consommateurs tout en permettant une automatisation supplémentaire de la curation.
Un risque potentiel dans ce modèle est que les coûts d’exploitation d’un frontal non conforme puissent être inférieurs, faute de charges administratives liées à la conformité. Ils pourraient aussi concevoir des modèles redistribuant les frais aux traders, renforçant ainsi leur attractivité. Deux facteurs peuvent atténuer ce risque. Premièrement, la majorité des utilisateurs préfèrent en réalité les frontaux conformes aux réglementations locales, surtout les grandes institutions réglementées. Deuxièmement, la gouvernance peut jouer un rôle crucial en dernier recours ou en « droit de veto », en sanctionnant les frontaux non conformes qui violent répétitivement les règles et compromettent la viabilité de l’application.
Enfin, tous les frais issus de transactions non lancées via un frontal enregistré seront versés dans un module de mise en gage consolidé unique, permettant au protocole de capter les revenus générés par les robots et autres interactions directes avec les contrats intelligents du protocole.
De la théorie à la pratique : mettre la méthode en œuvre
Examinons plus en détail la pile de jetons applicatifs. Pour faciliter la mise en gage via les frontaux, le protocole doit mettre en place un contrat intelligent d’enregistrement, que les frontaux doivent utiliser pour s’enregistrer.
-
Chaque frontal ou API peut ajouter un enregistrement TXT spécial dans les DNS de son nom de domaine, similaire à l'intégration ENS DNS. Cet enregistrement TXT contient la clé publique d'une paire générée par le frontal, appelée certificat.
-
Le client frontal peut appeler la fonction register() et prouver qu’il possède bien le domaine. Le mappage entre le domaine et la clé publique du certificat, ainsi que le mappage inverse, sont alors stockés.
-
Lorsqu’un client crée une transaction, il signe également la charge utile avec la clé publique de son certificat. Celle-ci est ensuite empaquetée et transmise au contrat intelligent de l’application.
-
Le contrat intelligent de l’application vérifie le certificat, s’assure qu’il correspond au bon objet de transaction et qu’il est bien enregistré. Si c’est le cas, la transaction est traitée. Les frais générés sont alors envoyés au contrat FeeCollector, accompagnés du nom de domaine (issu du registre).
-
FeeCollector permet aux curateurs, utilisateurs, validateurs et autres de miser directement sur un domaine ou un groupe de domaines. Ces contrats doivent suivre le nombre de jetons misés par domaine, la part de chaque adresse dans ce gage, et la durée du gage. Des implémentations populaires d’exploitation de liquidité peuvent servir de point de départ pour cette logique contractuelle. Les utilisateurs ayant misé auprès d’un curateur (ou directement auprès du contrat de gestion des frais) peuvent retirer leur part proportionnelle des frais générés par les jetons misés sur ce domaine. L’architecture peut s’inspirer de MetaMorpho/Morpho Blue.
Cette solution peut être mise en œuvre sans alourdir la gouvernance de la DAO de l’application. En réalité, la responsabilité de gouvernance pourrait diminuer, car le commutateur de frais peut être activé de façon permanente pour toutes les transactions facilitées par le protocole, supprimant ainsi tout contrôle de la DAO sur le modèle économique du protocole.
Considérations supplémentaires selon le type d’application
Bien que ces principes s’appliquent largement aux modèles économiques des jetons applicatifs, d’autres considérations tarifaires peuvent intervenir selon le type d’application (par exemple, applications construites sur des couches 1 ou 2, chaînes applicatives, ou applications utilisant des rollups).
Considérations pour les applications L1/L2
Les applications sur blockchains de niveau 1 ou 2 déploient directement des contrats intelligents sur la chaîne. Lorsqu’un utilisateur interagit avec le contrat intelligent de l’application, des frais sont perçus. Généralement, cette interaction se fait via un frontal convivial (site web ou application) agissant comme interface entre l’utilisateur final et le contrat intelligent sous-jacent. Dans ce cas, tous les frais proviendront de ce frontal. L’exemple précédent avec app.xyz illustre comment le système de frais fonctionne dans une application de niveau 1.
Les applications peuvent aussi adopter une approche de liste blanche ou noire pour filtrer les frais des frontaux, plutôt que de s’appuyer sur des curateurs. L’objectif est ici d’empêcher les détenteurs de jetons et le protocole lui-même de tirer profit d’activités illégales, en respectant les lois et règlements de juridictions spécifiques.
Dans l’approche par liste blanche, l’application publie un ensemble de règles pour les frontaux, crée un registre des frontaux respectueux de ces règles, délivre des certificats aux frontaux qui adhèrent, et exige un gage de jetons pour accéder à une part des frais. Si un frontal ne suit pas les règles, il perd son droit aux frais et voit son certificat révoqué.
Dans l’approche par liste noire, aucune règle n’est imposée, mais la création d’un frontal n’est pas sans permission. L’application exige qu’un avis d’un cabinet juridique atteste que le frontal respecte la réglementation de sa juridiction. Une fois cet avis reçu, un certificat est délivré. Celui-ci n’est révoqué que si une autorité réglementaire notifie l’application d’un manquement.
Le canal de frais sera similaire à l’exemple donné précédemment.
Ces deux méthodes augmentent fortement la charge de gouvernance décentralisée, obligeant la DAO à établir des règles ou à évaluer des avis juridiques. Cela peut être acceptable dans certains cas, mais dans la plupart, il sera préférable de déléguer la conformité aux curateurs.
Considérations pour les chaînes applicatives
Les chaînes applicatives sont des blockchains dédiées à une application spécifique, dont les validateurs travaillent exclusivement pour cette application.
En contrepartie de leur travail, ces validateurs sont rémunérés. Contrairement aux validateurs de blockchain de niveau 1, qui sont souvent récompensés par l’émission inflationniste de jetons, certaines chaînes applicatives (comme dYdX) transfèrent directement les frais clients aux validateurs.
Dans ce modèle, les détenteurs de jetons doivent miser auprès des validateurs pour être récompensés. Les validateurs deviennent alors des modules de mise en gage curatoriels.
Leur rôle diffère de celui des validateurs de niveau 1 : ils traitent des transactions spécifiques à une application donnée. Cette particularité peut exposer les validateurs de chaînes applicatives à des risques juridiques accrus, en fonction de la nature des activités facilitées. Le protocole devrait donc permettre aux validateurs de choisir librement, selon leur juridiction et leur seuil de tolérance, les frontaux qu’ils souhaitent traiter. Tant que la répartition géographique des validateurs reste décentralisée, cela peut se faire sans compromettre l’accessibilité ou introduire de risques de censure importants.
L’architecture des chaînes applicatives souhaitant tirer parti de la traçabilité des frais sera similaire à celle des applications L1 jusqu’au canal de frais. Mais les validateurs pourront utiliser le mappage des frontaux pour choisir ceux qu’ils veulent traiter. Les frais de chaque transaction seront attribués à l’ensemble des validateurs actifs ; les validateurs inactifs ne percevront aucun frais. D’un point de vue tarifaire, les validateurs jouent le même rôle que les curateurs de modules de gage mentionnés précédemment. Les participants misant auprès de ces validateurs peuvent ainsi s’assurer de ne pas bénéficier d’activités illégales. Les validateurs peuvent aussi s’appuyer sur des curateurs pour déterminer quels frontaux sont conformes dans leurs juridictions respectives.
Considérations pour les Rollups applicatifs
Les rollups possèdent leur propre espace-bloc, mais héritent de la sécurité d’une autre chaîne. La plupart des rollups actuels sont gérés par un seul ordonnanceur (« sequencer ») chargé de classer et inclure les transactions, bien que celles-ci puissent être soumises directement à la couche 1 via un processus appelé « inclusion forcée ».
Si ces rollups sont dédiés à une application spécifique et que leur ordonnanceur est considéré comme le seul validateur, les frais générés par les transactions incluses peuvent être distribués aux participants selon un ensemble de frontaux conformes curatoriels, ou vers un pool général.
Si le rollup décentralise son ensemble d’ordonnanceurs, ceux-ci deviennent des modules de mise en gage curatoriels de facto, et le canal de frais ressemble à celui d’une chaîne applicative. L’ordonnanceur remplace le validateur dans la distribution des frais, chaque ordonnanceur pouvant décider quels frontaux il accepte.
Bien qu’il existe de nombreux modèles possibles pour les jetons applicatifs, fournir des pools de mise en gage curatoriels constitue une voie prometteuse pour relever les défis externes uniques aux applications. En reconnaissant les défis internes et externes auxquels elles font face, les fondateurs peuvent mieux concevoir dès le départ le modèle de jeton applicatif de leur projet.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
a16z
