#opg $OPG On peut lire le livre blanc d’OpenGradient dans tous les sens : le vrai parcours du combattant, c’est la couche de règlement x402. Le projet fait tourner l’inférence IA on-chain, et le $OPG sert à payer le gas et au staking. Mais le sujet, ce n’est pas la technique : c’est le choix qu’on laisse aux développeurs entre trois options — PRIVATE, BATCH_HASHED et INDIVIDUAL_FULL. Ça a l’air attentionné, mais en réalité, on vous refile une bombe réglementaire et on vous laisse choisir quand elle explosera.
PRIVATE : aucune trace on-chain. La confidentialité est préservée, mais la promesse d’« IA vérifiable » part en miettes. Si les régulateurs viennent contrôler les comptes, comment prouver que votre agent n’a pas triché ? Par magie ?
INDIVIDUAL_FULL : les journaux complets sont inscrits définitivement sur la chaîne. Le livre blanc dit que c’est adapté aux « agents DeFi publiquement auditables ». En clair : le montant que les utilisateurs peuvent emprunter, les seuils de liquidation, le raisonnement de la stratégie… tout est exposé. Il suffit à un concurrent de scruter la chaîne pour viser vos positions avec précision. Un vrai régal, encore mieux que le délit d’initié.
BATCH_HASHED : agrégation de Merkle, option par défaut. Peu coûteux, vérifiable, confidentialité passable… mais c’est un compromis qui ne satisfait vraiment personne. Si les régulateurs exigent « les journaux bruts », vous leur donnez un hash : un juge va accepter ça ?
Petit exemple concret : imaginons que vous lanciez un agent de prêt en mode FULL. Le raisonnement derrière la requête d’un utilisateur — « quel est le montant maximal que je peux emprunter ? » — est entièrement inscrit sur la chaîne. Un concurrent peut alors calculer son exposition au risque et devancer la liquidation. Vous perdez de l’argent réel, et l’utilisateur vous poursuit pour atteinte à sa vie privée. Pendant ce temps, OpenGradient s’est déjà lavé les mains : un paramètre settlement_mode dans le SDK, à cocher par le développeur. En cas de pépin, ne vous retournez pas contre le projet.
Ma stratégie en conditions réelles, sans blabla : pendant les trois premiers mois après le lancement du mainnet, je ne fais tourner que des activités non essentielles, avec BATCH_HASHED imposé. Je surveille deux indicateurs : la fréquence des demandes d’audit on-chain et le volume de plaintes liées aux litiges pour chaque mode. À la fin du troisième mois, je verrai quel mode affiche le moins d’incidents et de frictions réglementaires, puis je déciderai quelle part de la logique métier migrer. D’ici là, toute l’inférence critique reste locale ; seul le hash de vérification est envoyé sur la chaîne.
À retenir : pour les traces d’inférence de l’IA on-chain, en stocker toujours plus ne rend pas les choses plus sûres. Il faut en garder juste assez pour pouvoir apporter la preuve nécessaire, sans enfreindre les règles. Personne ne tracera cette ligne à votre place ; il faudra tester avec vos propres positions. Mais avant de vous lancer, fixez d’abord votre limite de sécurité : tant que vous ne savez pas où vont les données, ne misez pas toutes vos cartes. @OpenGradient
PRIVATE : aucune trace on-chain. La confidentialité est préservée, mais la promesse d’« IA vérifiable » part en miettes. Si les régulateurs viennent contrôler les comptes, comment prouver que votre agent n’a pas triché ? Par magie ?
INDIVIDUAL_FULL : les journaux complets sont inscrits définitivement sur la chaîne. Le livre blanc dit que c’est adapté aux « agents DeFi publiquement auditables ». En clair : le montant que les utilisateurs peuvent emprunter, les seuils de liquidation, le raisonnement de la stratégie… tout est exposé. Il suffit à un concurrent de scruter la chaîne pour viser vos positions avec précision. Un vrai régal, encore mieux que le délit d’initié.
BATCH_HASHED : agrégation de Merkle, option par défaut. Peu coûteux, vérifiable, confidentialité passable… mais c’est un compromis qui ne satisfait vraiment personne. Si les régulateurs exigent « les journaux bruts », vous leur donnez un hash : un juge va accepter ça ?
Petit exemple concret : imaginons que vous lanciez un agent de prêt en mode FULL. Le raisonnement derrière la requête d’un utilisateur — « quel est le montant maximal que je peux emprunter ? » — est entièrement inscrit sur la chaîne. Un concurrent peut alors calculer son exposition au risque et devancer la liquidation. Vous perdez de l’argent réel, et l’utilisateur vous poursuit pour atteinte à sa vie privée. Pendant ce temps, OpenGradient s’est déjà lavé les mains : un paramètre settlement_mode dans le SDK, à cocher par le développeur. En cas de pépin, ne vous retournez pas contre le projet.
Ma stratégie en conditions réelles, sans blabla : pendant les trois premiers mois après le lancement du mainnet, je ne fais tourner que des activités non essentielles, avec BATCH_HASHED imposé. Je surveille deux indicateurs : la fréquence des demandes d’audit on-chain et le volume de plaintes liées aux litiges pour chaque mode. À la fin du troisième mois, je verrai quel mode affiche le moins d’incidents et de frictions réglementaires, puis je déciderai quelle part de la logique métier migrer. D’ici là, toute l’inférence critique reste locale ; seul le hash de vérification est envoyé sur la chaîne.
À retenir : pour les traces d’inférence de l’IA on-chain, en stocker toujours plus ne rend pas les choses plus sûres. Il faut en garder juste assez pour pouvoir apporter la preuve nécessaire, sans enfreindre les règles. Personne ne tracera cette ligne à votre place ; il faudra tester avec vos propres positions. Mais avant de vous lancer, fixez d’abord votre limite de sécurité : tant que vous ne savez pas où vont les données, ne misez pas toutes vos cartes. @OpenGradient