L'état des émetteurs de RWA : Brickken Research est disponible
Rapport sur l'état des émetteurs de RWA
Obtenez-le maintenant
L'interface de ligne de commande Brickken (CLI) est notre tentative de réduire au minimum cette couche manquante pour les développeurs et les opérateurs. Ce n'est ni une place de marché, ni un modèle, ni un portefeuille ; c'est une interface légère et prescriptive pour les opérations dont je pense que tout opérateur d'agent sérieux aura besoin à terme.
La première primitive est l'identité. La commande `brickken agent register` enregistre un agent autonome sur la blockchain selon la norme ERC-8004 pour les agents sans confiance, en y associant un point de terminaison de service, une référence de modèle d'IA et un portefeuille de contrôle. L'agent cesse d'être une simple entrée dans la base de données d'un fournisseur SaaS et devient un acteur à part entière sur la blockchain, avec une origine vérifiable. Le deuxième point concerne la réputation. Les fonctions de feedback des agents brickken permettent d'inscrire, d'ajouter et de révoquer des signaux de feedback dans le registre de réputation ERC-8004. Il ne s'agit pas d'étoiles Discord ni de scores gérés par le fournisseur. Ce feedback est immuable, horodaté et attribuable, et les systèmes en aval (autres agents, contrats intelligents ou tableaux de bord de conformité) peuvent le lire directement, sans avoir besoin d'un agrégateur intermédiaire. La confiance devient ainsi une propriété du réseau, et non d'une base de données privée. Le troisième point concerne l'économie. La fonction de création de token brickken, associée aux fonctions de création, de destruction, de transfert, de transfert depuis et d'approbation, déploie et exploite un token ERC-20 lié au portefeuille de l'agent. Il s'agit du pont entre les services de l'agent et les marchés de capitaux : un instrument permettant aux détenteurs de financer le développement, de partager les revenus d'utilisation ou de contrôler l'évolution de l'agent. C'est la différence entre subventionner un service d'IA par du capital-risque et le tarifer par le marché.
L'identité vous dit qui est un agent. La réputation vous dit comment il s'est comporté. Aucune des deux ne vous dit ce qu'il est autorisé à faire, pour le compte de qui et dans quelles limites — et c'est précisément la question qu'un régulateur se pose lorsqu'un système autonome exécute une transaction sur titres. C’est cette lacune que notre équipe chez Brickken a cherché à combler avec l’ERC-8226 (Regulated Agent Mandate Standard – RAMS), actuellement un brouillon d’ERC sur le processus de normalisation Ethereum. RAMS définit une couche de délégation de conformité pour les agents d’IA opérant sur des actifs réglementés tokenisés. Elle spécifie comment un principal vérifié KYC peut accorder à un agent on-chain une autorité limitée dans le temps et le budget – en d’autres termes, une procuration on-chain – et comment les contrats de tokens réglementés vérifient ce mandat de manière atomique dans leur mécanisme de conformité pré-transfert. Deux interfaces sous-tendent cette conception : IComplianceProvider, que tout opérateur KYC ou d’attestation peut implémenter pour garantir l’éligibilité du principal pour un périmètre donné ; et IAgentMandate, le registre qui enregistre les octrois, les prolongations, les révocations, les exécutions et les gels réglementaires des mandats. Les mandats sont assortis de plafonds de valeur par transaction et cumulés, de hachages de juridiction et de périodes de validité, et recordExecution applique ces plafonds dès qu'un jeton réglementé tente de régler un transfert.
L'objectif de RAMS n'est pas de remplacer ERC-8004 ni les cadres de conformité des jetons tels que ERC-3643 ou ERC-7943 ; il se situe entre eux. L'identité atteste de l'existence de l'agent. La conformité du jeton atteste que le mandant est autorisé à détenir cet actif spécifique. RAMS atteste que l'agent dispose de l'autorisation de ce mandant, pour ce périmètre, dans ces limites, jusqu'à cette date — la partie juridiquement contraignante qui, historiquement, n'existait que dans des fichiers PDF et des tableurs. L'interface de ligne de commande (CLI) de Brickken est conçue pour que l'enregistrement d'un agent Brickken aujourd'hui et l'octroi d'un mandat Brickken demain suivent le même flux de travail cohérent, utilisant les mêmes primitives on-chain et destinés au même public de conformité.
La décision architecturale la plus importante de la CLI, et la plus difficile à expliquer en une phrase, est l'absence de clés API. L'authentification et le paiement sont unifiés via x402, un protocole de paiement à la requête basé sur la signature et adossé à un stablecoin. Chaque requête effectuée par la CLI auprès du backend Brickken est payée avec une signature EIP-712 TransferWithAuthorization générée par le portefeuille de l'agent. Il n'y a ni secret partagé, ni liste de révocation centrale, ni rotation trimestrielle des clés.
Les implications vont bien au-delà de l'ergonomie pour les développeurs. Chaque action d'un agent est désormais cryptographiquement attribuable à un portefeuille spécifique, dans un bloc spécifique, pour une requête spécifique. Les équipes des achats, des finances et de la conformité cessent de traquer les fichiers journaux et commencent à analyser les règlements sur la blockchain. Le commerce inter-agents – le cas d'usage vers lequel se précipitent tous les acteurs de ce secteur – dispose enfin d'un mécanisme de règlement qui ne requiert pas que les deux parties fassent confiance au même processeur de paiement. Pour les institutions, il s'agit de la couche comptable manquante pour les logiciels autonomes.
Nous avons délibérément conservé un élément de l'interface de ligne de commande (CLI) afin d'éviter la tentation de tout simplifier en une seule commande. Par défaut, chaque commande de transaction prépare une charge utile non signée et l'affiche. La signature et la diffusion n'ont lieu que si l'utilisateur les active explicitement avec l'option `--execute`, ou en enchaînant manuellement les commandes `tx prepare`, `tx sign` et `tx send`.
Cette séparation n'est pas une contrainte. C'est le mécanisme de conformité. L'écart entre l'intention et la diffusion correspond précisément au rôle de l'examen institutionnel : un directeur financier approuvant une opération de trésorerie, un responsable de la conformité validant la création d'un jeton, un auditeur vérifiant les actions d'un agent avant leur diffusion sur la blockchain. C'est également là qu'intervient naturellement une vérification de mandat de type RAMS : la même charge utile préparée, examinée par un vérificateur humain, peut être validée par rapport au périmètre, aux plafonds de valeur et à la juridiction du mandat actif avant toute signature. La plupart des interfaces de ligne de commande (CLI) comblent cet écart par souci d'efficacité. Nous l'avons conservé car chaque institution avec laquelle nous avons échangé finit par le reconstruire entièrement lorsqu'elle constate son absence. L'interface de ligne de commande Brickken est un exemple concret d'infrastructure d'agents ; elle ne remplace ni le contenu vérifiable ERC-7007, ni le calcul confidentiel, ni la conformité des jetons ERC-3643 ou ERC-7943, ni les cadres de tokenisation plus larges dont les institutions ont toujours besoin. Elle s'intègre à leur architecture et rend la couche agent de la pile lisible par les équipes d'ingénierie qui doivent livrer au prochain trimestre, et non l'année prochaine. Les institutions qui définiront la prochaine étape de l'innovation sont celles qui considèrent leur IA autonome comme un actif inscrit à leur bilan plutôt que comme une simple ligne de facture cloud. Cela implique de doter chaque agent d'une identité vérifiable, d'une réputation enregistrée, d'un mandat délimité et d'une primitive de règlement qui résiste à l'audit. Aujourd'hui, cela se traduit par un registre d'agents brickken, une option `--execute` et un hachage de transaction que l'on peut coller dans un explorateur de blocs. Demain, avec la maturité de l'ERC-8226, ce sera le même flux de travail étendu par l'octroi de mandats brickken. La question est de savoir quelles institutions seront les premières à le mettre en œuvre.
