Aujourd’hui, j’ai lu de bout en bout la documentation destinée aux développeurs de Kite, et ce qui m’a marqué, ce n’est ni la vitesse ni les frais. C’est la façon dont l’autorité est répartie en trois niveaux. L’utilisateur détient l’autorité racine, chaque agent possède sa propre adresse dérivée du portefeuille de l’utilisateur via BIP-32, et chaque session repose sur une clé aléatoire qui expire après utilisation. Si une session est compromise, vous perdez une délégation. Si un agent est compromis, les dégâts restent dans les limites fixées par l’utilisateur. Seule la clé racine peut entraîner des pertes illimitées, d’où la consigne de la conserver dans un enclave local.
La conception des paiements suit la même logique. Au lieu de régler chaque requête sur la chaîne, deux parties ouvrent un canal, échangent hors chaîne des milliers de mises à jour signées, puis le ferment au moyen d’une seconde transaction.
La documentation indique une latence inférieure à 100 ms et un coût d’environ 1 $ par million de requêtes.
Voici ce qui tempère mon enthousiasme. La documentation décrit aussi des règles conditionnelles, comme la réduction de la limite d’un agent en cas de pic de volatilité. Une telle règle nécessite une donnée externe, mais je n’ai pas trouvé qui la fournit ni ce qui se passe si cette source est erronée. De plus, les chiffres élevés du testnet (des centaines de millions de transactions) proviennent d’un environnement de test. Ils en disent donc peu sur la demande récurrente sur le mainnet, lancé le 30 avril 2026.
Voici ce que je vais suivre : le nombre d’Agent Passports actifs sur KiteScan, la proportion des transactions d’agents correspondant à de véritables paiements de services plutôt qu’à du trafic de test, et la mention, dans la documentation, de la source de données qui détermine les limites de dépenses conditionnelles.
Une économie d’agents ne fonctionne que si une personne peut confier son portefeuille et dormir sur ses deux oreilles. Cela dépend moins de la vitesse de paiement des agents que du comportement des règles lorsque leurs données d’entrée ne sont plus fiables.
#KiteBBW $KITE @KITE AI 中文 #KiteBBW
La conception des paiements suit la même logique. Au lieu de régler chaque requête sur la chaîne, deux parties ouvrent un canal, échangent hors chaîne des milliers de mises à jour signées, puis le ferment au moyen d’une seconde transaction.
La documentation indique une latence inférieure à 100 ms et un coût d’environ 1 $ par million de requêtes.
Voici ce qui tempère mon enthousiasme. La documentation décrit aussi des règles conditionnelles, comme la réduction de la limite d’un agent en cas de pic de volatilité. Une telle règle nécessite une donnée externe, mais je n’ai pas trouvé qui la fournit ni ce qui se passe si cette source est erronée. De plus, les chiffres élevés du testnet (des centaines de millions de transactions) proviennent d’un environnement de test. Ils en disent donc peu sur la demande récurrente sur le mainnet, lancé le 30 avril 2026.
Voici ce que je vais suivre : le nombre d’Agent Passports actifs sur KiteScan, la proportion des transactions d’agents correspondant à de véritables paiements de services plutôt qu’à du trafic de test, et la mention, dans la documentation, de la source de données qui détermine les limites de dépenses conditionnelles.
Une économie d’agents ne fonctionne que si une personne peut confier son portefeuille et dormir sur ses deux oreilles. Cela dépend moins de la vitesse de paiement des agents que du comportement des règles lorsque leurs données d’entrée ne sont plus fiables.
#KiteBBW $KITE @KITE AI 中文 #KiteBBW
