Exécuter une demande de prêt sur une chaîne typique peut nécessiter trois jetons distincts : le actif natif pour les frais de gaz, un second pour payer le service de relais qui récupère les données de crédit de l’emprunteur, et un troisième pour rémunérer le réseau de keepers qui déclenche la rappel une fois ces données récupérées. Cet exemple provient de la documentation d’exécution asynchrone de Rialo lui-même, et il décrit le coût réel d’exploitation de ce que la plupart des gens appellent une seule transaction. Trois actifs à acquérir, détenir, surveiller et recharger. Trois soldes à gérer. Trois points où le flux de travail peut se bloquer si l’un d’eux s’épuise au mauvais moment. Cette taxe multi-jetons est rarement mentionnée, car ce n’est pas une frais de protocole facturé par quelqu’un. C’est un coût émergent résultant de la externalisation de capacités vers des réseaux séparés, chacun ayant besoin de sa propre économie pour survivre. Personne ne l’a conçue intentionnellement. Elle s’est accumulée, couche de middleware après couche. Sur @RialoHQ, le même flux s’exécute comme une seule transaction asynchrone. Les validateurs interrogeant l’API externe via des appels web natifs. L’exécution s’interrompt et reprend sans qu’un keeper ne la déclenche. Un seul jeton, un seul solde, une seule chose à maintenir financée. Les discussions sur la conception des jetons portent généralement sur les calendriers d’offre et les courbes de distribution. La question plus utile est : combien de jetons différents un développeur doit-il détenir avant que son produit fonctionne du tout ? Pour la plupart de cette industrie, la réponse honnête a toujours été trois, et personne n’a jamais affiché ce chiffre dans un pitch deck.
