ZkAPI Ethereum Cache Le Payeur, Pas Le Prompt IA

Vous avez déjà collé un contrat, un extrait médical ou le nom d’un projet non publié dans une fenêtre de chat, puis refermé l’onglet en vous disant que « personne ne saura que c’était vous » ? Le 1er octobre 2026, la Fondation Ethereum et l’Open Anonymity Project ont mis en ligne sur le réseau principal un dispositif qui répond à une partie seulement de cette inquiétude. Baptisé zkAPI, il permet de déposer des crédits, puis de prouver qu’une requête d’interface d’intelligence artificielle est payée, sans livrer au serveur de paiement une identité ni au fournisseur du modèle l’adresse qui a financé le coffre. Le texte envoyé, lui, arrive intact. Cette frontière, étroite mais réelle, mérite d’être lue avant qu’un slogan de paiement privé ne soit pris pour une conversation invisible.

L’annonce technique est inhabituellement nette sur ce point. La preuve dissimule quelle note règle l’usage. L’opérateur du modèle reçoit la demande, la traite, et peut la conserver. Le métadonnées réseau et le contenu du message restent des fils de corrélation. Dit autrement : cacher qui paie n’est pas cacher ce qui est demandé. Un dépôt remplace une pile de factures nominatives. Il ne transforme pas un prompt en lettre anonyme.

Un coffre, une note, une clé qui expire

Les interfaces commerciales classiques attachent une clé à un compte, puis ce compte à un moyen de paiement. Même si l’utilisateur ne signe jamais son texte d’un nom, le fournisseur peut rattacher les appels à une identité de facturation. zkAPI inverse cette habitude. L’utilisateur verse des actifs pris en charge, notamment des crédits en USDC, dans un contrat. Un logiciel local produit ensuite une preuve à divulgation nulle de connaissance : une note financée et valide peut couvrir un usage borné, sans révéler laquelle.

Le serveur de paiement vérifie cette preuve et délivre une clé d’API courte, plafonnée en dollars. Dans le mode dit de clé d’exécution directe, les prompts partent de l’appareil vers le fournisseur, munis de cette clé temporaire. À la fin de la session, un reçu signé consigne la consommation mesurée. Le solde privé est débité du montant réellement utilisé, et non du plafond réservé. Une seule preuve peut donc couvrir plusieurs requêtes. La chaîne n’enregistre pas chaque phrase. Elle voit les dépôts, les clôtures et les retraits. Le serveur, hors chaîne, contrôle les preuves de dépense.

Il existe un second chemin, plus simple et moins discret : le mode proxy. Le serveur zkAPI relaie alors la requête vers le fournisseur. Selon la description du projet, ce relais peut voir le trafic. Deux interfaces locales peuvent sembler identiques et acheminer pourtant les messages de façons opposées. Avant d’envoyer quoi que ce soit de sensible, la question utile n’est pas « est-ce privé ? ». Elle est : qui, dans ce mode précis, tient le contenu, et qui ne fait que valider une preuve de paiement ?

Ce que chaque partie est censée voir

Dessiner les registres d’une session, sans supposer de tricherie, clarifie le propos mieux qu’un adjectif marketing. Ethereum conserve la transaction de dépôt et l’adresse qui a alimenté le coffre. L’appareil de l’utilisateur garde le secret de la note et envoie une preuve au serveur de paiement. Ce serveur note la validité, un nullifier et l’émission d’une clé plafonnée. Le fournisseur du modèle enregistre cette clé, les requêtes et l’usage facturé. Le reçu signé relie la clé à un total mesuré. À la clôture, le contrat peut inscrire une sortie.

La propriété visée est qu’aucun registre honnête, pris seul, ne colle directement l’adresse de financement aux prompts du fournisseur. Une coalition, une fuite ou un observateur muni d’horodatages peut en savoir davantage. Si le dépôt est d’un montant rare et qu’une requête tout aussi rare part dans la foulée, le rapprochement devient plus facile. Si le document envoyé nomme déjà la personne, le fournisseur sait qui a demandé, sans jamais avoir vu l’adresse du coffre. C’est un problème de composition, pas une preuve cassée.

Acteur	Ce qu’il reçoit	Ce qu’il n’est pas censé recevoir
Chaîne Ethereum	Dépôts, clôtures, retraits, montants publics	Le texte du prompt et l’identifiant de session
Serveur de paiement, mode direct	Preuve valide, nullifier, total mesuré	Le prompt et l’adresse précise de la note
Serveur en mode proxy	Le trafic relayé, donc le contenu	Rien de garanti : le relais voit passer les messages
Fournisseur du modèle	Prompt, réponse, clé éphémère, usage	L’adresse qui a financé le coffre
Appareil de l’utilisateur	Secret de note, reçus, historique local éventuel	Une invisibilité automatique face au réseau

Ce tableau décrit l’architecture annoncée, pas une garantie que les journaux d’un déploiement donné ne puissent jamais rapprocher des utilisateurs. Un logiciel vivant a des valeurs par défaut, des sondes, des délais. La mise en ligne prouve qu’il existe du code et un contrat à inspecter. Elle ne prouve ni l’adoption, ni le périmètre d’un audit, ni l’anonymat de chaque configuration cliente.

La note prouve une valeur sans nommer le déposant

La construction s’appuie sur des engagements dans un arbre de Merkle. La preuve affirme que la note figure parmi les notes financées valides, sans désigner la feuille. Un nullifier, dérivé d’un secret de note, empêche de dépenser deux fois le même solde. Les auteurs citent des preuves Groth16 sur la courbe BN254, des empreintes Poseidon et un arbre à 32 niveaux. Ces choix importent aux implémenteurs. Le principe financier est plus simple : vérifier l’appartenance et le droit résiduel de dépenser, sans publier le compte qui a fourni le crédit.

Masquer une identité ne donne pas un usage gratuit. Le serveur doit contrôler la preuve et réserver un plafond avant d’émettre la clé temporaire. Le fournisseur mesure la consommation. Le reçu règle le montant réel après expiration de la clé. Si un plafond de 10 dollars est réservé et que 3 dollars de service sont consommés, le mécanisme est conçu pour débiter 3 dollars, pas 10. Cet exemple illustre la logique de réservation. Ce n’est ni un tarif publié ni un plancher garanti. Le reliquat demeure dans la note privée, selon les règles de l’implémentation.

Une preuve à divulgation nulle de connaissance énonce un fait défini sans livrer le témoin. Elle n’est pas un manteau d’invisibilité général, et ses garanties ne s’étendent pas d’elles-mêmes aux données qui voyagent à côté de la transaction.

Le nullifier traite un échec précis : tenter de dépenser une note deux fois. Il ne prouve pas que le modèle a répondu juste. Il ne préserve pas la confidentialité du prompt. Il n’empêche pas le fournisseur d’enregistrer les demandes. Confondre ces couches est l’erreur la plus fréquente dès qu’un projet associe « zéro connaissance » et « intelligence artificielle » dans la même phrase.

Trois couches, un seul outil

Un test de confidentialité tient en trois questions, et zkAPI n’en traite vraiment qu’une.

• Couche paiement. Une facture peut-elle être rattachée à une note ou à une personne ? C’est le terrain du dispositif.
• Couche réseau. Le service peut-il reconnaître une connexion par adresse IP, horaire ou empreinte d’appareil ? Le projet ne fournit pas cette anonymisation.
• Couche contenu. Quiconque fait tourner le modèle peut-il lire le prompt ? Oui, par conception, puisqu’il doit le traiter.

Le gain possible est donc de réduire le lien de compte entre le journal d’usage du fournisseur et la source de paiement. Ce n’est pas un défaut caché dans les petites lignes. L’annonce elle-même dit que le fournisseur voit les requêtes. Cette franchise est plus utile qu’un slogan d’anonymat large, parce qu’elle indique où placer les précautions supplémentaires. Poser des questions génériques peut offrir une vraie dissociation de facturation. Coller un contrat signé et un nom complet divulgue l’identité dans le contenu, quel que soit le circuit de paiement.

Le fournisseur reconnaît ce que la preuve ne peut pas cacher

Un corps de requête peut contenir un nom, un employeur, un historique médical ou du code propriétaire. Un fournisseur qui lit le prompt peut le rattacher à des sessions antérieures par des tournures répétées, des fichiers versés, un fil de conversation ou des faits très distinctifs. Aucun lien de portefeuille n’est nécessaire. Trois sessions qui citent le même nom interne d’un produit non publié se désignent elles-mêmes.

Les métadonnées réseau ouvrent un second chemin. En mode clé directe, le fournisseur peut voir l’adresse IP depuis laquelle l’appareil se connecte. En mode proxy, l’intermédiaire peut voir le trafic et, potentiellement, des informations sur le réseau d’origine. Les auteurs signalent qu’une IP stable et des horaires corrélés affaiblissent la confidentialité, et suggèrent des outils d’anonymat réseau à qui veut aller plus loin. Un VPN ou Tor modifie le chemin. Ni l’un ni l’autre n’efface un nom tapé dans le message.

Il y a aussi l’ensemble des requêtes qui partagent une même clé éphémère. Cette clé relie les appels à l’intérieur de sa session plafonnée, même si elle ne désigne pas le dépôt. C’est inhérent au mesurage. Si le client renvoie les mêmes documents lors de sessions suivantes, le fournisseur peut les rattacher d’une clé à l’autre. Cacher le compte de facturation a de la valeur. Cela n’oblige pas le fournisseur à oublier ce qu’il a lu.

L’ensemble d’anonymat peut rester étroit

La cryptographie peut masquer laquelle de plusieurs notes a payé. La foule réelle compte davantage. Si une seule personne alimente un coffre dans une fenêtre de temps étroite, avec un montant inhabituel, et qu’un retrait tout aussi distinctif suit la session, un observateur peut former une corrélation plausible à partir des horaires et des sommes publics. La preuve peut rester valide et non cassée. L’inférence à partir d’informations extérieures est une attaque séparée.

L’arbre à 32 niveaux est un paramètre de capacité, pas la preuve que des milliards d’utilisateurs distincts mélangent leurs crédits aujourd’hui. Un service tout juste lancé peut n’avoir qu’un petit ensemble de notes financées. Pour juger l’anonymat en pratique, il faudrait des comptes datés de dépôts, de notes actives et de schémas de retrait, agrégés sans exposer les personnes. Un dépôt de code ou une taille théorique d’arbre ne fournit pas ces chiffres.

Imaginez dix notes éligibles pour une session, et des faits publics qui en écartent neuf. La preuve mathématique peut encore cacher parfaitement son témoin, tandis que le contexte désigne la dixième. Cet exemple jouet explique pourquoi la taille et la diversité de l’ensemble plausible pèsent plus que le nombre brut de transactions dans le coffre. Standardiser les montants, retarder l’activité et utiliser le service de façon régulière peut aider. Le comportement des utilisateurs et la conception du service décident de ce qui reste corrélable.

La durée de la clé est déjà un choix de lien

Un justificatif de session regroupe volontairement toutes les requêtes qu’il autorise, afin que le fournisseur puisse les mesurer. Un plafond de 50 dollars peut couvrir de nombreux prompts sous une seule clé. Des plafonds plus bas et des sessions plus courtes réduisent le volume de contenu lié à un même justificatif. Ils exigent aussi des preuves plus fréquentes, donc parfois plus de latence ou de coût. Il n’existe pas de réglage universellement privé. L’utilisateur et le fournisseur arbitrent entre confort, prix et possibilité de rapprochement.

Un modèle de menace public devrait nommer exactement quels enregistrements sont conservés, et pendant combien de temps. Le serveur journalise-t-il l’adresse source lors de la soumission de preuve ? Stocke-t-il les nullifiers sans limite ? Le fournisseur peut-il associer des identifiants de reçu au contenu après le règlement ? Effacer un nom de facturation d’une base est utile. C’est insuffisant si un identifiant d’appareil persistant recrée le même profil en silence.

Le reçu signé déplace la confiance vers le compteur

Le fournisseur ou le serveur a besoin d’un moyen de facturer le travail réellement effectué. Le dispositif s’appuie sur un reçu signé, associé à la clé éphémère et à son usage. La question commerciale centrale glisse alors vers l’exactitude du mesurage. Si un fournisseur surcompte des jetons, des requêtes ou du temps, une preuve de paiement valide ne corrige pas la facture sous-jacente. La signature rend un total affirmé difficile à réécrire après coup. Elle n’établit pas que l’usage affirmé était juste au regard du barème.

Un client devrait demander quelle unité est facturée, qui signe le reçu, comment la réservation inutilisée est libérée, et ce qui se passe lorsqu’une requête échoue à mi-chemin. Ce sont des questions de facturation ordinaires, habillées d’une cryptographie inhabituelle. Un plafond limite la taille d’un débit inattendu dans une session. Beaucoup de petites sessions peuvent tout de même accumuler un coût notable. Limites de débit et contestations appelleraient un processus de litige qui préserve la vie privée. Rien, dans la mise en ligne du 1er octobre, ne décrit un tel guichet comme déjà mûr.

Le compromis est opérationnel. Les comptes d’API classiques simplifient le support, les remboursements et les enquêtes d’abus, parce que le fournisseur peut identifier l’acheteur. zkAPI retire une identité de facturation persistante du chemin de paiement visé. Les fournisseurs peuvent encore avoir besoin de contrôles d’abus, de filtrages liés aux sanctions lorsque le droit l’exige, et d’une application des limites d’usage. Les auteurs indiquent que prix et plafonds de débit peuvent demeurer. Les intégrations réelles montreront comment les services équilibrent des paiements sans compte et leurs obligations.

Un essai pratique consiste à interrompre volontairement une session. Le client obtient une clé plafonnée, envoie plusieurs requêtes, perd le réseau, puis se reconnecte. Le reçu ne reflète-t-il que l’usage délivré ? L’utilisateur peut-il auditer le montant mesuré localement, sans renvoyer le prompt au serveur de paiement ? Si le serveur disparaît, le solde inutilisé est-il récupérable via le contrat, comme annoncé ? Ces tests dépassent la question de savoir si une preuve vérifie. Ils demandent si le produit tient la séparation promise en cas de panne.

Le contrat est une trappe de sortie, pas un bouclier

Le contrat de coffre peut vérifier des preuves pour les opérations de dépôt, de clôture et d’échappée, selon les auteurs. Une voie de sortie sur la chaîne importe, parce qu’un arrêt du fournisseur ne devrait pas bloquer des fonds dans une base d’opérateur. Le contrat remplace une part de confiance institutionnelle par un risque de contrat intelligent. Un défaut dans la vérification de preuve, la comptabilité ou la logique de retrait pourrait affecter les fonds malgré une idée de confidentialité saine. Une adresse en ligne est une preuve de déploiement, pas un certificat d’audit.

Dépôts et retraits publics ont aussi un coût en vie privée. Quelqu’un qui connaît l’adresse de financement d’un utilisateur peut observer qu’elle a interagi avec le coffre. Il ne voit pas forcément quelle session d’API a été payée, mais il voit la participation et les montants. Si le même utilisateur retire vite une somme inhabituelle vers une adresse déjà associée à lui, une partie de l’anonymat périphérique se rétracte. La note privée casse un lien de facturation déterministe. Elle n’efface pas la transaction publique de financement.

Les auteurs indiquent qu’un utilisateur peut clôturer le solde du coffre et retirer sur la chaîne même si les serveurs zkAPI disparaissent. Cela évite de faire du serveur de paiement l’unique route pour récupérer les fonds. Cela ne rend pas les sorties invisibles : Ethereum enregistre les transactions concernées. La capacité de sortir dépend du contrat et de la possession du secret nécessaire. Avant d’y affecter une valeur importante, inspecter les adresses de déploiement, les permissions et toute revue indépendante reste la prudence minimale.

Une idée de recherche devenue déploiement testable

Le projet s’enracine dans un dessin de recherche sur des crédits d’API à divulgation nulle de connaissance, que la Fondation rattache aux travaux de Davide Crapis et de Vitalik Buterin. Une proposition de recherche et un système en production ne répondent pas aux mêmes questions. La première pose une construction. Le second doit gérer le stockage des clés, le comportement de l’interface, les pannes, les litiges de reçus, les mises à jour et des adversaires réels. La publication du 1er octobre fait passer l’idée dans un déploiement que l’on peut examiner. C’est là le fait neuf.

Les autres efforts de confidentialité autour d’Ethereum ne sont pas ce produit. Un dessin de protocole natif encore à l’état de brouillon, un portefeuille de transferts privés lancé dans un autre environnement, une feuille de route plus large : aucun de ces chantiers ne prouve qu’un prompt envoyé via zkAPI est dissimulé à son fournisseur de modèle. Mélanger ces dossiers produit une impression de couverture que le logiciel réel ne tient pas.

Comment une revue indépendante pourrait trancher

Un examinateur pourrait créer deux notes financées depuis des adresses sans lien, ouvrir de courtes sessions chez le même fournisseur, puis inspecter chaque paquet et chaque journal visibles côté client, serveur de paiement et fournisseur. Les modes direct et proxy devraient être testés séparément. Si, en mode direct, le serveur de paiement reçoit un prompt, la séparation décrite est contredite. Si le fournisseur reçoit une adresse de dépôt ou un identifiant de compte de facturation durable, le découplage visé a échoué à la couche d’intégration, même si le circuit de preuve est sain.

Le test plus dur est statistique. Multiplier les sessions avec des montants et des horaires variés, puis demander si une partie qui ne dispose que des données publiques de la chaîne et des journaux serveur peut corréler financement et usage mieux que le hasard. Le seuil dépend de l’ensemble d’anonymat réel et des données auxiliaires de l’adversaire. Une démonstration de laboratoire réussie n’établit pas la confidentialité sous une base d’utilisateurs minuscule. Elle crée toutefois une méthode pour mesurer si les déploiements s’améliorent.

Le test de contenu est simple et sobre. Soumettre le même document distinctif sous deux clés de session neuves. Si un fournisseur le reconnaît dans les deux cas, la dissociation de paiement n’a pas donné une dissociation de conversation. Une affirmation sur le paiement se juge aux deux premiers tests. Une affirmation sur un usage anonyme de l’IA doit aussi survivre au troisième. Publier le mode, le modèle de menace et les résultats permettrait à chacun de choisir l’outil qui correspond à son souci réel.

Le cas le plus solide : délier la facture d’un contenu utile

Il existe de bonnes raisons de poser à un fournisseur une question sensible sans constituer un dossier d’usage lié à un compte permanent. Un journaliste qui teste un document public, une chercheuse qui explore une hypothèse controversée, un développeur qui appelle une interface depuis un agent : tous peuvent vouloir que le fournisseur voie la requête du moment, tout en coupant la relation de facturation durable. Le dessin de zkAPI vise ce besoin plus étroit. Il permet aussi à une machine de payer des services mesurés sans gérer un compte personnel de longue durée pour chaque appel.

Le cas contre la survente est aussi net. Les fournisseurs voient les prompts, et certains prompts révèlent nécessairement une identité. Une organisation soumise à des exigences strictes de confidentialité peut avoir besoin de clauses contractuelles, de modèles locaux ou de calcul confidentiel, en plus d’un paiement découplé. D’autres préféreront un compte ordinaire, avec support et remboursements établis, à une couche de paiement cryptographique dont les mécanismes de litige sont encore jeunes. Le choix dépend du modèle de menace réel, pas du mot « privé » placé dans un titre.

La meilleure preuve contraire à une lecture sceptique serait un usage mesuré sans lien d’identité persistant, des étiquettes de mode claires, une revue de sécurité indépendante et un modèle de menace publié couvrant l’IP, la télémétrie du navigateur et les reçus. La meilleure preuve contraire à une revendication marketing large figure déjà dans l’annonce : le fournisseur voit le prompt. Les deux observations peuvent être vraies en même temps.

Quand la machine paie à la place de la personne

Les auteurs citent les paiements d’API de machine à machine comme application possible. Un agent autonome peut envoyer des centaines d’appels avec une note financée, ou avec de nombreuses sessions courtes. Si ses tâches transportent des dossiers de clients, le fournisseur du modèle peut apprendre des choses sur ces clients, alors même que la source de paiement de l’agent reste privée. Le bénéfice de confidentialité appartient au lien de facturation. Il ne se transmet pas à chaque sujet nommé dans une requête.

Un agent a aussi besoin de contrôles de budget. Un plafond par clé limite une session, mais une boucle peut obtenir des clés répétées jusqu’à vider la note, sauf si le client impose une politique de dépense plus large. L’opérateur devrait définir une limite quotidienne ou par tâche, une alerte et une pause, séparées de la preuve cryptographique. La preuve vérifie un crédit autorisé. Elle ne dit pas si l’appel était nécessaire ou économique.

Lorsque plusieurs agents partagent un même pool de crédits, la comptabilité interne peut devenir le système de facturation caché. L’opérateur peut avoir à répartir les charges entre équipes ou clients sans exporter leurs identités vers le fournisseur d’API. Un grand livre local peut le faire. Il crée un autre jeu de données sensible à protéger. Passer de la facturation par compte à la facturation par note n’abolit pas le rapprochement comptable. Il le déplace.

Enfin, un agent peut se trahir par son comportement. Des appels répétés au même horaire, les mêmes en-têtes d’outils et les mêmes tournures propres à une tâche peuvent rendre des clés éphémères faciles à regrouper. Cacher une note de financement sur la chaîne est utile contre une surveillance des paiements. Ce n’est pas une défense contre une empreinte comportementale que l’agent envoie avec chaque requête.

Ce qu’un audit de modèle de menace devrait encore lire

Au 2 octobre 2026, les auteurs indiquent que le code, le serveur, le client et le coffre sont en ligne, avec un contrat de réseau principal et un dépôt public. L’annonce ne publie pas un nombre définitif d’utilisateurs, une valeur totale auditée, l’ensemble des intégrations tierces, ni une garantie que chaque configuration cliente utilise le mode de clé directe. Rien ici n’affirme une faille ou un mauvais comportement d’un fournisseur nommé. Il s’agit de nommer l’information que chaque partie est censée recevoir, et les fuites supplémentaires que les auteurs reconnaissent.

Une évaluation extérieure devrait inspecter les valeurs par défaut du client et les connexions sortantes. La démonstration dans le navigateur envoie-t-elle de la télémétrie vers des domaines sans rapport ? Le client local conserve-t-il des clés ou des journaux de prompts ? Le serveur de paiement peut-il joindre les horodatages d’émission à des adresses réseau ? Les reçus sont-ils rapprochables d’une session à l’autre ? Comment les mises à jour de circuit et de contrat sont-elles gouvernées ? Une preuve peut être mathématiquement saine pendant qu’une interface livre par accident l’identité qu’elle était censée séparer.

La même évaluation devrait regarder le point de vue du fournisseur d’IA. Il verra le contenu qu’il traite et un justificatif de session. Il peut collecter des métadonnées d’appareil ou de réseau selon le chemin de la requête. Sa politique de conservation et les clauses contractuelles restent centrales. La couche de paiement peut réduire une source d’information identifiante sans contraindre toutes les autres.

zkAPI constitue une avance réelle s’il empêche de façon fiable un fournisseur de modèle de lier des requêtes utiles à un compte de facturation, tout en préservant la capacité de l’utilisateur à récupérer ses fonds. Il décevra quiconque attend une conversation privée simplement parce que le paiement a été prouvé sans divulgation du témoin. Les deux affirmations doivent être jugées à part.

Cinq points à surveiller dans les semaines qui viennent

• Étiquetage du mode. Chaque client indique-t-il, avant l’envoi, s’il route en clé directe ou en proxy ?
• Activité sur le réseau principal. Des comptes datés de notes financées et d’usage, publiés sans compromettre l’anonymat.
• Revues de sécurité. Le périmètre des évaluations indépendantes sur les sorties du contrat, les circuits, le stockage client et le règlement des reçus.
• Contrôles de métadonnées. Traitement des IP, télémétrie, durée de vie des clés, conservation chez le fournisseur.
• Litiges de facturation. Requêtes échouées, libération du plafond, reçus contestés, sans forcer une divulgation d’identité.

Les questions que l’on se pose avant le premier dépôt

Le coffre et les logiciels d’accompagnement sont présentés comme actifs depuis le 1er octobre, avec un contrat de réseau principal et un dépôt de code liés depuis l’annonce. Cela répond à la question de la mise en ligne. Cela ne répond pas à celle de la maturité.

Le prompt n’est pas caché au fournisseur d’IA. Il le reçoit pour faire tourner le modèle. La preuve de paiement est conçue pour dissimuler la source des crédits d’usage. En mode direct décrit, le serveur de paiement apprend qu’un paiement valide existe et quel est le total mesuré de la session, sans recevoir le prompt ni identifier le dépôt précis. Le mode proxy n’est pas aussi discret : le relais voit le trafic. Une adresse IP peut aider à corréler des sessions, surtout avec l’horaire et le contenu. Le dispositif ne fournit pas, à lui seul, un anonymat réseau.

Si le serveur s’arrête, les auteurs disent que le contrat offre une sortie sur la chaîne pour clôturer et retirer sans dépendre de ce serveur. L’implémentation mérite tout de même une lecture. Les dépôts et retraits ne sont pas invisibles : les transactions publiques révèlent les interactions avec le coffre. La preuve vise à couper le lien entre une note financée et l’usage d’API mesuré ensuite. Discuter d’un matériau confidentiel avec n’importe quel modèle ne devient pas privé par ce seul mécanisme. Le fournisseur voit le contenu. Rétention, métadonnées réseau et sensibilité de chaque prompt restent à évaluer. Ceci est une lecture technique, pas un conseil d’investissement.

Le geste le plus utile, après cette mise en ligne, n’est pas de déclarer le paiement de l’IA « résolu ». C’est de séparer, dans sa propre pratique, ce que l’on accepte de montrer au modèle et ce que l’on refuse de laisser coller à une facture durable. zkAPI rend le second choix techniquement envisageable. Le premier reste entre les mains de la personne qui tape.