Qu’est-ce que zkAPI ? Comment Ethereum utilise les preuves à divulgation nulle de connaissance pour les paiements privés liés à l’IA

zkAPI est une solution technologique de protection de la vie privée qui applique les preuves à divulgation nulle de connaissance (ZKP) au contrôle d’accès aux interfaces de programmation d’applications (API) et à la vérification des paiements. Son objectif est de réduire l’exposition directe de l’identité, des comptes et des historiques de paiement des utilisateurs lorsqu’ils accèdent à des services en ligne, tels que des modèles d’IA. Contrairement aux modèles d’accès traditionnels, qui reposent sur des comptes vérifiés, des clés API et des systèmes de facturation centralisés, zkAPI vise à permettre aux utilisateurs de prouver cryptographiquement qu’ils disposent de droits d’accès ou de justificatifs de paiement valides, sans divulguer leur identité complète au fournisseur de services.

Avec le développement des agents d’IA, des applications automatisées et des services de modèles facturés à l’usage, les paiements liés aux API deviennent une infrastructure importante de l’économie numérique. Bien que les modèles de facturation traditionnels soient matures, ils exigent généralement que les fournisseurs de services conservent les historiques des comptes, des requêtes et des paiements pendant de longues périodes, ce qui facilite le rapprochement des comportements des utilisateurs. Les preuves à divulgation nulle de connaissance offrent une nouvelle approche technique de ce problème : dissocier, dans une certaine mesure, les justificatifs de paiement de l’utilisation réelle des services, tout en conservant les capacités nécessaires de vérification des autorisations et de prévention des abus.

Cet article présente d’abord le concept de zkAPI et explique comment les preuves à divulgation nulle de connaissance peuvent servir à autoriser l’accès aux API d’IA, à vérifier les justificatifs de paiement et à gérer les quotas d’utilisation. Il analyse également les rôles potentiels des smart contracts Ethereum, des paiements on-chain et des technologies de protection de la vie privée. Il examine enfin la différence entre les paiements anonymes et l’anonymat complet, ainsi que les limites techniques et commerciales auxquelles zkAPI se heurte dans les déploiements réels.

Points clés

• zkAPI est une solution technique qui explore l’utilisation des preuves à divulgation nulle de connaissance pour l’accès aux API, la vérification d’identité et l’autorisation des paiements. Elle vise à réduire l’exposition des informations d’identité et de paiement des utilisateurs lorsqu’ils utilisent des services d’IA.

• Les API d’IA traditionnelles reposent généralement sur des comptes, des clés API et des systèmes de facturation centralisés, ce qui permet aux fournisseurs de services de relier les historiques de requêtes à des comptes précis.

• Les preuves à divulgation nulle de connaissance permettent aux utilisateurs de prouver qu’ils remplissent les conditions d’accès à un service ou disposent d’une capacité de paiement suffisante, sans divulguer toutes les informations sous-jacentes utilisées pour la vérification.

• Ethereum et ses réseaux de couche 2 peuvent fournir une infrastructure de paiement, de smart contracts et de vérification des justificatifs pour les solutions concernées. Cela ne signifie toutefois pas que les requêtes d’inférence d’IA ou toutes les informations relatives aux transactions bénéficient automatiquement d’une protection de la vie privée.

• Les applications réelles de zkAPI doivent encore résoudre des problèmes tels que la réutilisation des justificatifs, la gestion des quotas, les requêtes abusives, les coûts de génération des preuves et la facturation côté serveur.

Qu’est-ce que zkAPI ? Pourquoi Ethereum a-t-il introduit une solution de paiement anonyme pour l’IA ?

zkAPI est un protocole de paiement pour API axé sur la protection de la vie privée, développé conjointement par l’Open Anonymity Project (projet pour un anonymat ouvert) et l’Ethereum Foundation (fondation Ethereum). Il est conçu pour permettre aux utilisateurs de payer des modèles d’IA et d’autres services facturés à l’usage au moyen de preuves à divulgation nulle de connaissance, sans associer directement chaque requête API à leur identité réelle ou à leur adresse de financement on-chain. Le 1er octobre 2026, l’Ethereum Foundation a annoncé le lancement de zkAPI sur le réseau principal Ethereum et publié les implémentations du client, du serveur et du smart contract. Le projet est issu de la conception ZK API Usage Credits, précédemment proposée par Vitalik Buterin et Davide Crapis, responsable de l’équipe dAI de l’Ethereum Foundation.

Les services d’API d’IA traditionnels utilisent généralement des clés API pour associer les requêtes des utilisateurs à des comptes, eux-mêmes liés à des cartes bancaires ou à d’autres moyens de paiement. À mesure que les utilisateurs se servent des modèles, les fournisseurs de services peuvent regrouper l’historique des prompts, les heures d’utilisation, les montants dépensés et les informations de compte dans des dossiers conservés à long terme. Même si les utilisateurs ne communiquent pas volontairement leur nom dans les prompts, les informations de compte reliées en continu peuvent néanmoins constituer un profil d’utilisation relativement complet. Pour les applications d’IA qui traitent des activités de recherche et développement en entreprise, des analyses financières personnelles ou d’autres informations sensibles, ce type de rapprochement des données peut soulever des préoccupations supplémentaires en matière de vie privée.

zkAPI ne cherche pas à modifier les modèles d’IA eux-mêmes, mais la méthode d’autorisation des paiements utilisée par les services de modèles. Les utilisateurs déposent d’abord des fonds dans un smart contract Ethereum, puis utilisent une preuve à divulgation nulle de connaissance pour démontrer au serveur de paiement qu’ils disposent d’un crédit disponible suffisant. Le serveur peut confirmer leur capacité à payer sans savoir quel dépôt précis couvre la requête en cours. Parallèlement, le fournisseur de services d’IA peut traiter les prompts soumis par l’utilisateur sans connaître l’identité de financement on-chain associée à la requête.

L’objectif central de zkAPI est donc de rendre impossible le rapprochement entre les identités de paiement et les historiques d’utilisation des API, et non de chiffrer automatiquement ou d’anonymiser entièrement toutes les requêtes d’IA. Cette distinction est fondamentale pour comprendre la valeur technique du protocole.

Comment les preuves à divulgation nulle de connaissance permettent-elles des paiements confidentiels pour les API d’IA ?

Une preuve à divulgation nulle de connaissance est une technologie cryptographique qui permet à un prouveur de démontrer à un vérificateur qu’une affirmation est vraie, sans divulguer toutes les informations secrètes utilisées pour générer la preuve. Par exemple, un utilisateur peut prouver qu’il dispose de fonds suffisants pour payer un service sans révéler de quel justificatif de solde privé précis proviennent ces fonds.

Dans zkAPI, après le dépôt d’ETH ou d’autres actifs pris en charge dans un smart contract Vault sur Ethereum, le système représente le solde disponible au moyen d’une Private Note, ou note privée. Une note peut être comprise comme un justificatif de paiement numérique contrôlé par les informations secrètes de l’utilisateur. Le protocole utilise des engagements cryptographiques pour enregistrer les justificatifs valides et organise ces engagements dans un arbre de Merkle. Les utilisateurs peuvent ainsi prouver que leurs justificatifs appartiennent à un ensemble valide sans révéler lequel ils détiennent précisément.

Lorsqu’un utilisateur doit appeler une API d’IA, le client local génère une preuve à divulgation nulle de connaissance démontrant que la note correspondante est valide, qu’elle offre une capacité de paiement suffisante et qu’elle respecte les conditions d’utilisation définies par le protocole. Après avoir vérifié la preuve, le serveur de paiement peut délivrer une clé API temporaire à l’utilisateur. Ce processus n’exige pas que le serveur obtienne les informations secrètes d’origine de l’utilisateur ou relie directement chaque requête à une adresse de financement publique.

Pour empêcher l’utilisation répétée d’un même solde, zkAPI introduit un mécanisme de nullificateur. Un nullificateur est un identifiant unique généré à partir d’informations secrètes, qui sert à détecter si un même crédit disponible a été utilisé plusieurs fois. Si le système détecte un nullificateur en double, il peut repérer une tentative potentielle de double dépense sans divulguer l’identité complète de l’utilisateur ni son historique de financement. L’implémentation officielle utilise notamment les preuves à divulgation nulle de connaissance Groth16, la courbe BN254, le hachage Poseidon et les arbres de Merkle.

Comment zkAPI gère-t-il les paiements, du financement sur Ethereum aux appels des modèles d’IA ?

Le processus zkAPI peut être divisé en cinq étapes : financement, preuve de paiement, autorisation temporaire, appel du modèle et facturation finale. Contrairement aux systèmes qui déclenchent une transaction on-chain pour chaque requête API, zkAPI permet aux utilisateurs de déposer des fonds sur Ethereum à l’avance, puis d’obtenir plusieurs autorisations d’accès aux API au moyen de preuves off-chain. Il évite ainsi d’attendre une confirmation de la blockchain à chaque appel d’un modèle.

L’utilisateur approvisionne d’abord un contrat Vault sur Ethereum et reçoit un solde disponible représenté par une note privée. Lorsqu’il doit appeler un modèle d’IA, le client local génère une preuve de paiement et l’envoie au serveur zkAPI. Après avoir vérifié la validité de la preuve, le serveur génère une clé API temporaire pour la session en cours, avec une durée de validité et une limite de dépenses définies. L’utilisateur peut utiliser cette clé pour accéder aux services d’IA pris en charge sans employer directement une clé API liée en permanence à son compte de paiement personnel.

Dans le modèle Runtime-Key décrit dans la documentation officielle, le prompt de l’utilisateur est envoyé directement au fournisseur du service de modèle d’IA, sans transiter par le serveur de paiement zkAPI. Le serveur de paiement vérifie la capacité à payer et gère la facturation, tandis que le fournisseur de services d’IA prend en charge l’inférence du modèle. Une fois la session terminée, le système calcule les frais réels à partir des relevés d’utilisation signés et déduit le montant correspondant du solde privé de l’utilisateur. La limite de dépenses de la clé temporaire correspond à un montant réservé et ne signifie pas que l’intégralité de ce montant sera nécessairement facturée à l’utilisateur.

zkAPI propose également un mode proxy relativement simple, dans lequel un serveur proxy relaie les requêtes. Cette approche peut être plus facile à intégrer, mais le serveur proxy peut accéder au trafic des requêtes : son périmètre de confidentialité diffère donc de celui du modèle Runtime-Key. Pour analyser les capacités de protection de la vie privée de zkAPI, il faut ainsi distinguer les modes de fonctionnement précis, plutôt que considérer que toutes les méthodes de déploiement offrent le même niveau d’isolation des données.

Quels rôles jouent le Vault, la note privée et le nullificateur ?

Le Vault est l’infrastructure de smart contracts utilisée par zkAPI pour gérer les fonds des utilisateurs sur Ethereum. Les utilisateurs y déposent des actifs par des transactions on-chain publiques, puis peuvent utiliser leurs soldes privés pour payer des services d’API conformément aux règles du protocole. Contrairement à un transfert direct vers le compte d’un fournisseur de services centralisé, les règles de gestion des fonds et de retrait du Vault sont mises en œuvre par des smart contracts. La conception officielle permet aux utilisateurs de retirer leurs fonds restants par la procédure de sortie on-chain correspondante, ce qui réduit la dépendance au maintien en ligne d’un seul serveur de paiement.

La note privée représente le solde privé que l’utilisateur peut contrôler. Il ne s’agit pas d’une nouvelle cryptomonnaie, mais d’un justificatif cryptographique servant à contrôler et à prouver la capacité à payer. Grâce à la note et à l’arbre de Merkle, les utilisateurs peuvent prouver qu’ils détiennent un solde valide sans divulguer l’historique de financement correspondant à chaque paiement. Une relation directe et individuelle entre le financement public on-chain et une utilisation précise d’un service d’IA n’est donc plus nécessaire.

Le nullificateur empêche la double dépense. Si un système de paiement confidentiel masque les justificatifs de solde, mais ne peut pas détecter leur réutilisation, un utilisateur pourrait potentiellement dépenser les mêmes fonds plusieurs fois. zkAPI utilise donc des nullificateurs pour maintenir les contrôles d’unicité nécessaires tout en protégeant la confidentialité des justificatifs. Ces trois composants assurent respectivement la gestion des fonds, les preuves privées de capacité à payer et la détection des doubles dépenses. Ensemble, ils constituent le mécanisme de paiement de base du protocole.

Il est important de noter que les opérations de financement et de retrait du Vault restent des transactions publiques sur Ethereum. zkAPI masque principalement le lien entre des transactions de financement précises et l’utilisation ultérieure des API, plutôt que de rendre totalement invisibles les adresses de financement, les montants des transactions ou l’ensemble de l’activité on-chain.

En quoi zkAPI diffère-t-il des méthodes de paiement traditionnelles des API d’IA ?

Les API d’IA traditionnelles utilisent généralement des soldes de compte ou une facturation postpayée. Après avoir créé un compte, les développeurs reçoivent une clé API, que le système utilise pour identifier la source des requêtes, suivre la consommation de tokens et calculer les frais. Ce modèle offre des outils de développement, une gestion de la facturation et des systèmes d’assistance client matures. Toutefois, les fournisseurs de services peuvent également relier les historiques d’utilisation des API aux informations de compte sur de longues périodes.

zkAPI utilise des justificatifs de solde privés et des preuves à divulgation nulle de connaissance pour vérifier la capacité à payer, en cherchant à dissocier l’identité de l’utilisateur, la source du paiement et les requêtes précises. La principale différence ne réside pas dans l’utilisation ou non d’ETH pour le paiement, mais dans la possibilité pour le fournisseur de services d’établir directement un lien entre le compte de paiement et les requêtes adressées aux modèles.

zkAPI n’a donc pas vocation à remplacer entièrement les clés API traditionnelles. Il utilise plutôt des autorisations temporaires et des justificatifs de paiement privés pour modifier la relation entre les clés API et les identités de paiement à long terme. Pour les applications qui ont uniquement besoin d’une facturation et d’une gestion des accès standard, le modèle traditionnel peut rester plus simple. Pour les utilisateurs ou les applications qui souhaitent réduire l’exposition des identités de paiement, zkAPI offre une autre option technique.

zkAPI peut-il réellement permettre des conversations avec l’IA entièrement anonymes ?

zkAPI peut réduire le lien direct entre les identités de paiement et les requêtes API, mais il ne peut pas garantir des conversations avec l’IA totalement anonymes. Dans son annonce officielle, l’Ethereum Foundation a clairement indiqué que les fournisseurs de services d’IA peuvent toujours lire les prompts soumis par les utilisateurs et les réponses générées par les modèles, car l’inférence nécessite de traiter ces contenus. Autrement dit, zkAPI protège la confidentialité des liens associés aux paiements ; il ne fournit pas automatiquement une inférence d’IA chiffrée de bout en bout.

Les métadonnées réseau constituent également un risque potentiel pour la vie privée. Si un utilisateur accède régulièrement à un service depuis une adresse de protocole Internet (IP) fixe, la passerelle de paiement ou le fournisseur du modèle peut encore analyser son comportement à partir des heures de connexion, de la fréquence des requêtes et d’autres caractéristiques réseau. Même si le justificatif de paiement lui-même ne peut pas être directement relié à l’utilisateur, des schémas récurrents au niveau de la couche réseau peuvent réduire l’anonymat. La documentation officielle considère donc l’anonymat réseau comme une question nécessitant des mesures techniques supplémentaires, et non comme une capacité déjà entièrement prise en charge par zkAPI.

Les prompts eux-mêmes peuvent aussi révéler l’identité. Par exemple, si un utilisateur fournit à plusieurs reprises les mêmes informations personnelles, le même nom de projet d’entreprise ou le même historique de conversation dans différentes sessions, le fournisseur du service de modèle peut être en mesure de relier à nouveau ces requêtes à partir des caractéristiques de leur contenu. Même en l’absence de nom de compte, un style d’écriture distinctif et des informations contextuelles continues peuvent fournir des indices d’identification.

Il est donc plus exact de considérer que zkAPI peut réduire le rapprochement entre les identités de paiement et les historiques d’utilisation des API au niveau de la conception du protocole. Une protection globale de la vie privée dans les usages de l’IA nécessite toutefois d’autres technologies, notamment l’anonymat réseau, la minimisation des données et le calcul préservant la confidentialité.

Pourquoi zkAPI convient-il aux agents d’IA et aux paiements entre machines ?

À certains égards, les agents d’IA utilisent les API différemment des utilisateurs ordinaires. Ces derniers souscrivent généralement des abonnements manuellement sur des sites web ou dans des applications, tandis que les agents d’IA peuvent avoir besoin d’appeler automatiquement plusieurs modèles, bases de données ou services de calcul en fonction d’une tâche. Si chaque service exige un compte, un moyen de paiement et une clé API à long terme distincts, la gestion des paiements et des autorisations peut devenir complexe pour les systèmes automatisés.

Les mécanismes de crédit privé et d’autorisation temporaire fournis par zkAPI offrent une approche technique pour les services entre machines facturés à l’usage. Un agent d’IA peut obtenir un accès aux API dans les limites d’un montant de financement et d’un plafond de dépenses prédéfinis, puis appeler les services concernés selon la tâche réelle. Grâce aux preuves à divulgation nulle de connaissance, le serveur de paiement peut vérifier le crédit autorisé sans exiger que chaque appel soit directement associé à un compte de paiement à long terme.

Outre l’inférence des modèles d’IA, l’Ethereum Foundation a cité comme cas d’utilisation potentiels les requêtes d’appel de procédure à distance (RPC) sur blockchain, la génération d’images et de vidéos, les services de bande passante pour réseaux privés virtuels (VPN) et d’autres formes de facturation entre machines. Ces services présentent des caractéristiques communes : ils sont généralement facturés par appel, tâche de calcul, durée ou volume de trafic. Ils peuvent donc utiliser des mécanismes similaires d’autorisation de crédit et de règlement fondé sur les relevés d’utilisation.

Les paiements automatisés effectués par des agents d’IA nécessitent néanmoins des contrôles stricts des fonds et des autorisations. Même si l’identité de paiement est protégée, des configurations de tâches incorrectes, des appels API anormaux ou des entrées malveillantes peuvent épuiser rapidement les fonds. Les déploiements réels doivent donc définir des limites par appel, des budgets de session, des listes de services autorisés et une surveillance des usages anormaux. Les paiements confidentiels ne doivent pas être assimilés à la sécurité des paiements automatisés.

Quelles limites techniques et quels risques de sécurité zkAPI rencontre-t-il ?

La première catégorie de difficultés tient aux preuves cryptographiques et à la complexité du système. Bien que les preuves à divulgation nulle de connaissance puissent masquer certaines informations sous-jacentes, leur génération, leur vérification et la gestion des justificatifs augmentent les coûts de développement et d’exploitation. Le protocole doit assurer la mise à jour correcte des soldes privés des utilisateurs et empêcher la double dépense. Il doit également gérer l’expiration des clés temporaires, le règlement fondé sur les relevés d’utilisation, les sorties anormales et d’autres situations. Par rapport à une base de données de facturation centralisée traditionnelle, cette conception exige que davantage de composants cryptographiques et de smart contracts fonctionnent ensemble.

La deuxième catégorie concerne la sécurité des smart contracts et des services de paiement. Le contrat Vault gère les fonds on-chain. Des vulnérabilités dans le contrat, la logique de vérification des preuves ou l’implémentation du client pourraient compromettre la sécurité des fonds des utilisateurs. Bien que le projet officiel ait publié son code source et déployé les composants concernés sur le réseau principal Ethereum, son dépôt GitHub qualifie encore le protocole d’implémentation expérimentale. Les utilisateurs et les développeurs ne doivent donc pas supposer qu’il dispose de toutes les protections de sécurité d’un système de paiement commercial mature simplement parce qu’il est en service sur le réseau principal.

La troisième catégorie concerne l’équilibre entre la protection de la vie privée et l’exploitation réelle des services. Les fournisseurs de services d’IA doivent toujours détecter les abus, appliquer des limites de fréquence et traiter les litiges de facturation. Les mécanismes de paiement anonyme peuvent toutefois compliquer l’application directe des contrôles des risques traditionnels fondés sur les comptes. zkAPI conserve les contraintes de facturation nécessaires grâce aux clés temporaires, aux limites de dépenses et aux relevés d’utilisation signés, mais les fournisseurs de services doivent encore développer des mécanismes de prévention des abus adaptés aux environnements de paiement confidentiel.

Le protocole ne résout pas non plus automatiquement les questions d’anonymat réseau ou de fuite du contenu des prompts. Pour les applications d’IA qui traitent des informations très sensibles, l’utilisation de zkAPI seule ne suffit pas à assurer une confidentialité globale des données. Il faut également évaluer les politiques de traitement des données du fournisseur du modèle, les méthodes de connexion réseau et les technologies supplémentaires de calcul préservant la confidentialité.

Que représente zkAPI pour Ethereum et l’infrastructure de paiement de l’IA ?

Le lancement de zkAPI montre que l’exploration des applications d’IA par Ethereum s’étend des paiements en actifs aux autorisations préservant la confidentialité et à la facturation des services. Les paiements traditionnels sur blockchain se concentrent généralement sur la possibilité de transférer des actifs entre différentes adresses. zkAPI va plus loin en examinant comment effectuer des paiements tout en réduisant le lien informationnel entre les identités de paiement et l’utilisation réelle des services. Les smart contracts Ethereum peuvent ainsi servir non seulement d’infrastructure de transfert des paiements, mais aussi de composant du contrôle d’accès et de la gestion des fonds pour les services numériques.

Sur le plan de l’architecture technique, zkAPI combine la gestion des fonds on-chain et l’autorisation d’accès aux API off-chain. Ethereum prend en charge le contrat de gestion des fonds et la logique de vérification nécessaire, les preuves à divulgation nulle de connaissance masquent le lien entre les justificatifs de paiement et les comportements d’utilisation précis, et les fournisseurs de services d’IA continuent d’effectuer l’inférence des modèles. Cette répartition évite d’inscrire directement chaque appel API sur la blockchain et fournit une conception de référence pour les futurs services facturés à l’usage.

L’adoption réelle de zkAPI reste toutefois à un stade précoce. Son développement à long terme dépendra non seulement de la maturité des preuves à divulgation nulle de connaissance, mais aussi de la volonté des fournisseurs de services d’IA de l’intégrer, de la facilité d’intégration pour les développeurs et du besoin réel des utilisateurs de dissocier les identités de paiement des historiques d’utilisation des modèles. Pour Ethereum, l’intérêt principal de zkAPI est de démontrer une architecture opérationnelle de paiement confidentiel, et non d’annoncer que tous les services d’API d’IA passeront aux paiements on-chain.

Conclusion

zkAPI est un protocole de paiement pour API axé sur la protection de la vie privée, lancé dans le cadre d’une collaboration entre l’Ethereum Foundation et l’Open Anonymity Project. Grâce aux smart contracts Vault, aux notes privées, aux preuves à divulgation nulle de connaissance et aux clés API temporaires, il dissocie les identités de paiement des utilisateurs de leurs historiques d’utilisation des services d’IA. Les utilisateurs peuvent déposer des fonds sur Ethereum à l’avance, puis obtenir un accès aux API au moyen de preuves cryptographiques, sans divulguer la source du financement correspondant à chaque requête.

Par rapport aux méthodes de paiement traditionnelles des API d’IA, l’innovation centrale de zkAPI ne consiste pas simplement à utiliser de l’ETH ou des stablecoins pour acheter des services de modèles. Le protocole cherche plutôt à résoudre le problème du rapprochement durable entre les comptes de paiement et le contenu des requêtes. En combinant la gestion des fonds on-chain et la facturation de l’utilisation off-chain, il peut conserver la vérification des quotas et la détection des doubles dépenses tout en améliorant la protection de la vie privée au niveau des paiements.

zkAPI ne signifie toutefois pas que les services d’IA deviennent entièrement anonymes. Les fournisseurs de modèles peuvent toujours lire les prompts, tandis que les métadonnées réseau et les caractéristiques du contenu peuvent également révéler des informations sur les utilisateurs. L’application à grande échelle de ce type de technologie aux agents d’IA, à l’inférence des modèles et à d’autres services facturés à l’usage nécessitera de valider davantage sa sécurité, sa capacité à évoluer et sa viabilité commerciale.

Questions fréquentes

1. Qu’est-ce que zkAPI ?

zkAPI est un protocole de paiement pour API axé sur la protection de la vie privée et fondé sur les preuves à divulgation nulle de connaissance. Il permet aux utilisateurs de prouver qu’ils disposent d’un crédit suffisant pour accéder à un service au moyen de justificatifs de paiement privés, sans divulguer au serveur de paiement la source de financement précise ou leur identité de paiement à long terme.

2. zkAPI a-t-il été officiellement lancé par Ethereum ?

zkAPI a été développé conjointement par l’Open Anonymity Project et l’Ethereum Foundation, et sa mise en service sur le réseau principal Ethereum a été annoncée le 1er octobre 2026. Il s’agit d’une implémentation technique expérimentale issue de cette collaboration, et non d’un protocole obligatoire de la couche de base du réseau Ethereum.

3. Peut-on utiliser zkAPI pour payer en ETH ou en USDC ?

La documentation officielle de l’Ethereum Foundation indique que des actifs tels que l’ETH et l’USDC peuvent être utilisés dans les scénarios de financement et de paiement concernés. Les actifs effectivement pris en charge par le client, le contrat Vault et la version déployée doivent toutefois être vérifiés dans la documentation la plus récente de l’implémentation concernée.

4. zkAPI peut-il masquer les prompts que les utilisateurs soumettent à l’IA ?

Non. zkAPI masque principalement le lien entre les identités de paiement et les historiques d’utilisation des API. Les fournisseurs de services de modèles d’IA doivent toujours lire les prompts pour générer des réponses : leur contenu n’est donc pas automatiquement chiffré du seul fait de l’utilisation de zkAPI.

5. Pourquoi zkAPI a-t-il besoin de nullificateurs ?

Les nullificateurs servent à détecter si des justificatifs de solde privés ont été utilisés pour dépenser le même crédit plusieurs fois. En vérifiant des identifiants uniques, le système peut empêcher la réutilisation d’un même crédit tout en évitant de divulguer directement l’intégralité des informations secrètes des justificatifs.

6. zkAPI convient-il aux paiements automatisés effectués par des agents d’IA ?

zkAPI peut fournir aux agents d’IA une facturation à l’usage, des autorisations temporaires et des justificatifs de paiement privés. Les déploiements réels nécessitent toutefois des limites budgétaires, des autorisations d’accès et des contrôles des usages anormaux pour réduire les risques financiers liés aux appels automatisés.