Paiements d’agents : les standards d’identité et de plafond
Vous pouvez déjà vérifier qui est un agent et ce qu’il peut dépenser. Il manque une règle : ne payer que si une condition est prouvée.
EN 30 SECONDES
Une pile de paiement d’agent est l’ensemble des couches qu’un paiement peut traverser ; ici, une identité on-chain qui nomme le donneur d’ordre, des règles de transfert et un smart account qui peut plafonner la dépense. ERC-8203, brouillon de la PR ouverte n° 1614, non fusionnée, vise à ajouter le règlement sur preuve.
À RETENIR · 3
- Les pièces existent : OnchainID (ERC-734/735), ERC-3643 et ERC-4337/7579. Leur combinaison pour des agents reste à construire et à tester.
- Je les ai livrées chez Tokeny et chez Biconomy, où les rails ont fait transiter 441 millions de dollars sur plus de 38 millions de transactions. Ces totaux décrivent ce travail plus large : ni un banc d’essai de cette proposition, ni la preuve qu’elle est prête pour la production.
- ERC-8203, brouillon dans la PR ouverte n° 1614, non fusionnée, vise le règlement sur preuve. J’en suis le deuxième des trois auteurs nommés ; Xianrui Qin, l’auteur principal.
Sur cette page
Les trois pièces que j’ai déjà livrées
EN BREF Identité, règles de transfert, permissions de compte : ces standards existent, je les ai tous livrés. Leur combinaison n’est pas sûre pour autant.
LES MOTS À CONNAÎTRE
- Identité on-chain
- Un contrat d’identité sur une blockchain, qui porte des déclarations signées sur son titulaire, lisibles par d’autres contrats et services.
- Smart account
- Un wallet piloté par du code sur la blockchain. Il peut imposer des règles, comme un plafond de dépense, si ses modules les prévoient.
- PR (pull request)
- Une demande de modification d’un dépôt de code, ici celui des ERC. « Ouverte, non fusionnée » : pas encore intégrée.
Les banques contrôlent l’identité de leurs clients : c’est le KYC. J’ai aidé à le mettre sur une blockchain. Je plaide ici pour faire de même avec les agents.
ÉTAPE PAR ÉTAPE
Étape 1. Identité. OnchainID répond : qui est cet agent, et qui s’en porte garant ?
- Identité OnchainID répond : qui est cet agent, et qui s’en porte garant ?
- Règles de transfert ERC-3643 demande : ce détenteur peut-il recevoir le token ?
- Règle de dépense Le smart account vérifie ce que l’agent peut dépenser, via son code ou ses modules.
- Au-dessus du plafond Un paiement au-dessus du plafond est refusé, mais seulement si le code du compte ou un module installé impose ce plafond.
D’abord l’identité. OnchainID est un contrat d’Identité on-chain Un contrat d’identité sur une blockchain, qui porte des déclarations signées sur son titulaire, lisibles par d’autres contrats et services. Voir le glossaire qui contient des attestations signées par des émetteurs de confiance ; j’ai construit cette couche chez Tokeny. Pour un agent, l’attestation nomme son donneur d’ordre, à vérifier (validité, lien avec l’action) : une conception possible, pas la seule.
Sur un transfert ordinaire, ERC-3643 vérifie l’identité et la conformité voulues par l’émetteur. Les actions privilégiées, comme un transfert forcé, suivent d’autres règles. Je suis l’un de ses cinq auteurs nommés.
ATTENTION
ERC-3643 ne définit pas de mandat d’agent : ce serait un autre chantier. Et un Smart account Un wallet piloté par du code sur la blockchain. Il peut imposer des règles, comme un plafond de dépense, si ses modules les prévoient. Voir le glossaire peut imposer des règles de dépense par son propre code ou des modules installés. ERC-4337 et ERC-7579 ne garantissent pas à eux seuls des plafonds de session.
Totaux déclarés de mon travail chez Biconomy (ERC-4337/7579) : ce travail au sens large, pas cette proposition, ni la preuve qu’elle est prête pour la production.
32 Md$ et plus
tokenisés sur ERC-3643, filtrés par l’identité
Chiffre mis en avant par erc3643.org.
OBJET OBTENU
Trois couches, trois questions
Dans la section suivante : Alors, que ne dit aucune des trois couches ?
ERC-8203 (brouillon, PR ouverte n° 1614, non fusionnée) : payer sur preuve
EN BREF ERC-8203, encore un brouillon dans la PR ouverte n° 1614, non fusionnée, vise à standardiser l’étape manquante : payer seulement sur preuve.
Il manque une règle : ne payer que si une condition off-chain est prouvée plus tard. Ni l’identité ni le compte limité ne la donnent. À mon avis, une bonne part du commerce réel des agents en a besoin.
ERC-8203 est un brouillon à un stade précoce, encore dans la PR (pull request) Une demande de modification d’un dépôt de code, ici celui des ERC. « Ouverte, non fusionnée » : pas encore intégrée. Voir le glossaire, non fusionnée. Xianrui Qin en est l’auteur principal. Je suis le deuxième des trois auteurs nommés, et j’ai écrit l’implémentation de référence.
EN CLAIR
Le brouillon ne se préoccupe pas du type de signataire : des humains ou d’autres systèmes automatisés peuvent s’en servir. Il laisse l’identité à d’autres standards et ne dit rien de x402. Relier les deux, c’est ma proposition, pas le brouillon.
Mes trois autres standards, ERC-3643, ERC-6960 et ERC-7410, sont fusionnés dans le dépôt des ERC. ERC-8203, ma quatrième participation comme auteur, reste un brouillon dans la PR ouverte n° 1614, ni fini ni fusionné. Ne construisez pas dessus aujourd’hui.
Sources : brouillon ERC-8203, PR ouverte n° 1614, non fusionnée.
FAQ
D’autres services peuvent y vérifier une attestation signée sur le donneur d’ordre. Encore faut-il se fier à l’émetteur, qu’elle soit valide et qu’une règle relie identité et droits. ERC-3643 ne définit ni mandat d’agent ni responsabilité ; des justificatifs signés off-chain sont une autre option.
Pas dans leur ensemble : l’identité et les comptes tournent déjà en production, mais leur combinaison reste à construire, relire et tester. ERC-8203 reste un brouillon dans la PR ouverte n° 1614, non fusionnée. Ce qui marche ailleurs ne rend pas ce système prêt pour la production.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- ERC-4337 et ERC-7579 ne plafonnent rien à eux seuls : le code du compte ou un module installé doit imposer la limite.
- ERC-8203, brouillon dans la PR ouverte n° 1614, non fusionnée, vise à ne régler un paiement qu’une fois une condition prouvée.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Votre agent paie depuis un smart account ERC-4337 sans module de dépense installé. Pouvez-vous partir du principe qu’il est plafonné ?
Non. Un plafond n’existe que si le code du compte ou un module installé l’impose : vérifiez l’implémentation.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.