La répartition documentée du grand livre d'un agent IA nommé Bucks — dans une discussion sur Ethereum Magicians consacrée à un projet de standard pour les états de revenus des agents — montre la facilité avec laquelle les flux entrants d'un portefeuille peuvent passer pour une activité, et la brièveté avec laquelle un score de crédit conçu pour mesurer cette activité a compté trop peu.

Les registres font état de 30,33 USDG reçus par Bucks, ventilés par source, l'argent des clients ne représentant qu'une partie du total.

L'état de revenus, ligne par ligne

Bucks est l'agent #8811 au titre d'ERC-8004, un standard Ethereum proposé qui confère aux agents IA une identité onchain, et il est rémunéré en stablecoin USDG sur Robinhood Chain. L'argent de ses clients provient d'une seule adresse payante. Pris ensemble, ces éléments esquissent la pile de paiements pour agents en construction : l'identité issue d'un standard Ethereum proposé, le paiement intégré dans une requête web, le règlement en stablecoin — chaque couche conservant sa propre trace des mêmes flux.

Les paiements de test comptent tout autant. Le protocole x402 permet aux logiciels de payer au sein d'une requête web, et un propriétaire payant pour son propre service est indiscernable onchain d'un inconnu qui le ferait. Comme Coindoo l'a souligné, un paiement crypto réglé ne prouve pas un achat autonome.

En retirant l'argent du propriétaire, le prêt et les échanges, l'activité de Bucks se réduit à un client et 3 USDG. C'est le chiffre qu'attendrait un prêteur. La ligne du prêt est elle-même une dette, et la compter comme un revenu permettrait à de l'argent emprunté de garantir davantage d'emprunts.

Trois questions soulevées par les chiffres

Pourquoi le score de crédit affichait-il 1 USDG, et non 3 ?

Le score provient de Priors, un pool de crédit où les agents ERC-8004 sur Robinhood Chain empruntent des USDG et obtiennent une notation de crédit publique, le revenu valant jusqu'à 150 de ses 1 000 points. Il ne compte que les paiements x402 des 30 derniers jours, si bien que le paiement de 2 USDG pour une tâche n'a jamais été pris en compte. Pendant un temps, il n'affichait rien du tout : les mises à jour des développeurs de Priors indiquent qu'un traitement en arrière-plan a empêché la vérification des transferts du payeur d'aboutir. Après un correctif, le propriétaire a confirmé le 1 USDG le 25 octobre. Lorsque Priors a publié ses règles de notation le 26 septembre, il notait qu'aucun agent ne générait encore de revenus x402. Cet écart importe au-delà de la comptabilité : la notation est publique et s'inscrit dans un pool de prêt, de sorte que ce que Priors compte comme revenu constitue actuellement le signal plus visible pour quiconque évalue le crédit d'un agent.

Ses filtres sont-ils trop stricts ou trop laxistes ?

Les deux. Selon les règles publiées par Priors, un payeur n'est pris en compte qu'après avoir dépensé 1 USDG dans la fenêtre considérée, l'argent qui lui est renvoyé est soustrait, chaque payeur est plafonné à 20 USDG, les portefeuilles inconnus comptent pour moitié, et les portefeuilles liés à l'agent sont exclus au moyen d'une liste que Priors garde privée. Un client authentique achetant un service à 0,10 USDG devrait effectuer dix achats par mois pour être comptabilisé, tandis que les mêmes règles admettent que les payeurs s'auto-alimentant via un portefeuille intermédiaire ne sont pas encore détectés. Cette liste étant privée, nul hors de Priors ne peut recalculer intégralement le score d'un agent.

Le standard proposé réglerait-il ce problème ?

Pour moitié seulement. Le projet, publié sous la même organisation GitHub que le score de Priors, verrouillerait chaque transfert entrant dans un engagement cryptographique appelé racine de Merkle, permettant à quiconque de reconstruire le total et d'en vérifier le contenu. Les états seraient déposés via le registre de réputation d'ERC-8004, chaque fenêtre de rapport étant clôturée dès que le propriétaire de l'agent ou son portefeuille de paiement change. Le projet qualifie le résultat de recettes brutes, non de revenus, et son implémentation de référence n'a pas été auditée.

Il peut exclure l'adresse enregistrée du propriétaire, mais pas les portefeuilles que celui-ci contrôle ailleurs, et le plus important flux entrant de Bucks est passé par un bridge. Un état prouverait ce qui est arrivé, pas qui a payé.

Les éléments en mouvement sont tous publics : le texte du projet sur GitHub, les règles de notation publiées et les mises à jour des développeurs de Priors, ainsi que le statut d'audit d'une implémentation de référence qui n'en a actuellement aucun.

Tant que les états ne pourront pas identifier de manière fiable le financement du propriétaire, les prêts et les échanges, le chiffre utile pour quiconque évalue le crédit d'un agent reste celui qu'il a fallu décomposer le grand livre de Bucks pour trouver : les paiements répétés de clients qui ne sont pas le propriétaire.

Cet article est fourni à titre purement informatif et ne constitue pas un conseil financier ou d'investissement. Les classifications des transferts relèvent du compte du propriétaire de l'agent.