zkAPI es una solución tecnológica de privacidad que aplica pruebas de conocimiento cero (Zero-Knowledge Proof, ZKP) al control de acceso a API y la verificación de pagos. Su objetivo es reducir la exposición directa de las identidades, cuentas y registros de pago de los usuarios cuando acceden a servicios en línea, como los modelos de IA. A diferencia de los modelos de acceso tradicionales, que dependen de cuentas verificadas, claves API y sistemas de facturación centralizados, zkAPI pretende permitir que los usuarios demuestren criptográficamente que tienen derechos de acceso válidos o credenciales de pago suficientes sin revelar su identidad completa al proveedor del servicio.
A medida que los agentes de IA, las aplicaciones automatizadas y los servicios de modelos de pago por uso siguen desarrollándose, los pagos mediante API se están convirtiendo en una infraestructura importante para la economía digital. Aunque los modelos de facturación tradicionales están maduros, por lo general exigen que los proveedores de servicios conserven durante largos periodos los registros de cuentas, solicitudes y pagos, lo que facilita asociar el comportamiento con los usuarios. Las pruebas de conocimiento cero ofrecen un nuevo enfoque técnico para este problema: separar, hasta cierto punto, las credenciales de pago del uso real del servicio, al tiempo que se mantienen las capacidades necesarias de verificación de autorización y prevención del abuso.
Este artículo comienza con el concepto de zkAPI y explica cómo pueden utilizarse las pruebas de conocimiento cero para la autorización de acceso a API de IA, la verificación de credenciales de pago y la gestión de cuotas de uso. También analiza las posibles funciones de los contratos inteligentes de Ethereum, los pagos en cadena y las tecnologías de privacidad. Además, el artículo analiza la diferencia entre los pagos anónimos y el anonimato completo, así como las limitaciones técnicas y comerciales a las que se enfrenta zkAPI en implementaciones reales.
zkAPI es un protocolo de pagos de API centrado en la privacidad, desarrollado conjuntamente por Open Anonymity Project y la Ethereum Foundation. Está diseñado para permitir que los usuarios paguen por modelos de IA y otros servicios de pago por uso mediante pruebas de conocimiento cero, sin asociar directamente cada solicitud de API con su identidad real o su dirección de financiación en cadena. El 1 de octubre de 2026, la Ethereum Foundation anunció que zkAPI se había lanzado en la red principal de Ethereum y publicó implementaciones para el cliente, el servidor y el contrato inteligente. El proyecto se originó a partir del diseño ZK API Usage Credits, propuesto anteriormente por Vitalik Buterin y Davide Crapis, responsable del equipo dAI de la Ethereum Foundation.
Los servicios de API de IA tradicionales suelen utilizar claves API para asociar las solicitudes de los usuarios con sus cuentas, y esas cuentas están vinculadas a tarjetas bancarias u otros métodos de pago. A medida que los usuarios siguen utilizando los modelos, los proveedores de servicios pueden combinar las indicaciones históricas, los horarios de uso, los importes gastados y la información de la cuenta en registros a largo plazo. Aunque los usuarios no proporcionen activamente sus nombres en las indicaciones, la información de cuenta vinculada de forma continua puede crear un perfil de uso relativamente completo. En aplicaciones de IA relacionadas con la investigación y el desarrollo corporativos, el análisis financiero personal u otra información sensible, este tipo de asociación de datos puede generar problemas de privacidad adicionales.
zkAPI intenta cambiar no los propios modelos de IA, sino el método de autorización de pagos utilizado por los servicios de modelos. Primero, los usuarios depositan fondos en un contrato inteligente de Ethereum y, posteriormente, utilizan una prueba de conocimiento cero para demostrar al servidor de pagos que disponen de crédito suficiente. El servidor puede confirmar que cumplen los requisitos de pago sin saber qué depósito concreto respalda la solicitud actual. Al mismo tiempo, el proveedor del servicio de IA puede procesar las indicaciones enviadas por el usuario sin conocer la identidad de financiación en cadena asociada a la solicitud.
Por tanto, el objetivo central de zkAPI es desvincular las identidades de pago de los registros de uso de las API, no cifrar ni anonimizar por completo de forma automática todas las solicitudes de IA. Esta distinción es fundamental para comprender el valor técnico del protocolo.
Una prueba de conocimiento cero es una tecnología criptográfica que permite al probador demostrar al verificador que una afirmación es verdadera sin revelar toda la información secreta utilizada para generar la prueba. Por ejemplo, un usuario puede demostrar que dispone de fondos suficientes para pagar un servicio sin revelar de qué credencial de saldo privada concreta proceden esos fondos.
En zkAPI, después de que los usuarios depositen ETH u otros activos compatibles en un contrato inteligente Vault de Ethereum, el sistema representa el saldo disponible mediante una Private Note. Una Note puede entenderse como una credencial de pago digital controlada por la información secreta del usuario. El protocolo utiliza Commitments criptográficos para registrar las credenciales válidas y organiza estos Commitments mediante un Merkle Tree. Esto permite a los usuarios demostrar que sus credenciales pertenecen a un conjunto válido sin revelar qué credencial concreta poseen.
Cuando un usuario necesita llamar a una API de IA, el cliente local genera una prueba de conocimiento cero que demuestra que la Note correspondiente es válida, tiene capacidad de pago suficiente y cumple las condiciones de uso especificadas por el protocolo. Después de verificar la prueba, el servidor de pagos puede emitir al usuario una clave API temporal. Este proceso no requiere que el servidor obtenga la información secreta original del usuario ni que vincule directamente cada solicitud con una dirección pública de financiación.
Para evitar que se utilice repetidamente el mismo saldo, zkAPI introduce un mecanismo Nullifier. Un Nullifier es un identificador único generado a partir de información secreta y se utiliza para detectar si el mismo crédito disponible se ha utilizado más de una vez. Si el sistema detecta un Nullifier duplicado, puede identificar un posible comportamiento de doble gasto sin revelar la identidad completa del usuario ni sus registros de financiación. La implementación oficial utiliza componentes técnicos como las pruebas de conocimiento cero Groth16, la curva BN254, el hash Poseidon y los Merkle Trees.

El proceso de zkAPI puede dividirse en cinco etapas: financiación, prueba de pago, autorización temporal, invocación del modelo y facturación final. A diferencia de los sistemas que inician una transacción en cadena para cada solicitud de API, zkAPI permite a los usuarios depositar fondos previamente en Ethereum y completar después varias autorizaciones de acceso a API mediante pruebas fuera de la cadena, evitando tener que esperar a la confirmación de la cadena de bloques cada vez que se llama a un modelo.
En primer lugar, el usuario financia un contrato Vault en Ethereum y recibe un saldo disponible representado por una Private Note. Cuando necesita llamar a un modelo de IA, el cliente local genera una prueba de pago y la envía al servidor de zkAPI. Después de verificar que la prueba es válida, el servidor genera una clave API temporal para la sesión actual, con un periodo de validez y un límite de gasto definidos. El usuario puede utilizar esta clave para acceder a los servicios de IA compatibles sin utilizar directamente una clave API vinculada permanentemente a su cuenta de pago personal.
En el modelo Runtime-Key descrito en los materiales oficiales, la indicación del usuario se envía directamente al proveedor del servicio del modelo de IA, en lugar de retransmitirse a través del servidor de pagos de zkAPI. El servidor de pagos verifica que se cumplen los requisitos de pago y gestiona la facturación, mientras que el proveedor del servicio de IA se encarga de la inferencia del modelo. Cuando finaliza la sesión, el sistema calcula la comisión real a partir de los registros de uso firmados y deduce el importe correspondiente del saldo privado del usuario. El límite de gasto de la clave temporal es un importe reservado y no significa que necesariamente se cobre al usuario todo el importe reservado.
zkAPI también ofrece un modo Proxy relativamente sencillo, en el que un servidor proxy retransmite las solicitudes. Este enfoque puede ser más fácil de integrar, pero el servidor proxy puede acceder al tráfico de las solicitudes, lo que da lugar a un límite de privacidad diferente del del modelo Runtime-Key. Por tanto, al analizar las capacidades de privacidad de zkAPI, es necesario distinguir entre los distintos modos de funcionamiento, en lugar de considerar que todos los métodos de implementación ofrecen el mismo nivel de aislamiento de datos.
Vault es la infraestructura de contrato inteligente que zkAPI utiliza para gestionar los fondos de los usuarios en Ethereum. Los usuarios depositan activos en Vault mediante transacciones públicas en cadena y, posteriormente, pueden utilizar sus saldos privados para pagar servicios de API de acuerdo con las reglas del protocolo. A diferencia de la transferencia directa de fondos a la cuenta de un proveedor de servicios centralizado, la gestión de fondos y las reglas de retirada de Vault se implementan mediante contratos inteligentes. El diseño oficial permite a los usuarios retirar los fondos restantes mediante el proceso de salida en cadena correspondiente, lo que reduce la dependencia de que un único servidor de pagos permanezca conectado.
Private Note representa el saldo privado que el usuario puede controlar. No es una criptomoneda nueva, sino una credencial criptográfica utilizada para controlar y demostrar que se cumplen los requisitos de pago. Mediante Note y Merkle Tree, los usuarios pueden demostrar que poseen un saldo válido sin revelar los registros de financiación correspondientes a cada pago. Esto significa que ya no es necesaria una relación directa de uno a uno entre la financiación pública en cadena y un uso concreto de los servicios de IA.
Nullifier evita el doble gasto. Si un sistema de pagos privados oculta las credenciales de saldo, pero no puede detectar su uso repetido, un usuario podría gastar potencialmente los mismos fondos varias veces. Por ello, zkAPI utiliza Nullifiers para mantener las comprobaciones de unicidad necesarias y, al mismo tiempo, proteger la privacidad de las credenciales. Estos tres componentes gestionan, respectivamente, la administración de fondos, las pruebas privadas de elegibilidad para pagos y la detección del doble gasto, y juntos forman el mecanismo de pagos básico del protocolo.
Es importante señalar que la financiación y las retiradas de Vault siguen siendo transacciones públicas en Ethereum. zkAPI oculta principalmente la relación entre transacciones de financiación específicas y el uso posterior de las API, en lugar de hacer completamente invisibles las direcciones de financiación, los importes de las transacciones o toda la actividad en cadena.
Las API de IA tradicionales suelen utilizar saldos de cuenta o facturación pospago. Después de registrar una cuenta, los desarrolladores reciben una clave API y el sistema utiliza esa clave para identificar el origen de la solicitud, realizar un seguimiento del uso de tokens y calcular las comisiones. Este modelo ofrece herramientas de desarrollo, gestión de facturación y sistemas de atención al cliente maduros, pero los proveedores de servicios también pueden asociar los registros de uso de las API con la información de la cuenta durante largos periodos.
zkAPI utiliza credenciales de saldo privadas y pruebas de conocimiento cero para verificar que se cumplen los requisitos de pago, con el objetivo de separar la identidad del usuario, el origen del pago y las solicitudes específicas. Su principal diferencia no es si utiliza ETH para los pagos, sino si el proveedor del servicio puede establecer directamente una relación entre la cuenta de pago y las solicitudes al modelo.
| Dimensión de comparación | API de IA tradicional | zkAPI |
|---|---|---|
| Identidad de pago | Normalmente vinculada a una cuenta registrada | Utiliza credenciales de pago privadas |
| Autorización de API | Clave API o token de cuenta a largo plazo | Prueba de conocimiento cero y clave API temporal |
| Método de facturación | Saldo de cuenta o facturación periódica | Crédito privado y registros de uso real |
| Vinculación de la información de pago | Los proveedores de servicios normalmente pueden vincular las cuentas y las solicitudes | Diseñado para separar los orígenes de pago de las solicitudes |
| Dependencia de la cadena de bloques | Normalmente no es necesaria | Utiliza un contrato de financiación de Ethereum |
| Privacidad del contenido de las solicitudes | Normalmente visible para el proveedor del servicio del modelo | Sigue siendo visible para el proveedor del servicio del modelo |
| Principales limitaciones | Centralización de los datos de cuenta y vinculación de identidades | Costes de las pruebas, complejidad del protocolo y límites de privacidad |
Por tanto, zkAPI no pretende sustituir por completo las claves API tradicionales. En su lugar, utiliza autorizaciones temporales y credenciales de pago privadas para cambiar la relación entre las claves API y las identidades de pago a largo plazo. Para las aplicaciones que solo necesitan facturación y gestión de acceso estándar, el modelo tradicional puede seguir siendo más sencillo. Para los usuarios o las aplicaciones que desean reducir la exposición de las identidades de pago, zkAPI ofrece otra opción técnica.
zkAPI puede reducir el vínculo directo entre las identidades de pago y las solicitudes de API, pero no puede garantizar conversaciones de IA completamente anónimas. La Ethereum Foundation ha declarado claramente en su anuncio oficial que los proveedores de servicios de IA todavía pueden leer las indicaciones enviadas por los usuarios y las respuestas generadas por los modelos, ya que la inferencia del modelo requiere procesar este contenido. En otras palabras, zkAPI protege la privacidad de la vinculación con los pagos, pero no proporciona automáticamente inferencia de IA cifrada de extremo a extremo.
Los metadatos de red también representan un posible riesgo para la privacidad. Si un usuario accede continuamente a un servicio desde una dirección IP fija, la pasarela de pagos o el proveedor del modelo todavía pueden analizar su comportamiento mediante los horarios de conexión, la frecuencia de las solicitudes y otras características de red. Aunque la credencial de pago no pueda vincularse directamente, los patrones repetidos en la capa de red pueden reducir el anonimato. Por ello, los materiales oficiales consideran el anonimato de red una cuestión que requiere medidas técnicas adicionales, no una capacidad que zkAPI ya haya resuelto por completo.
Además, las propias indicaciones pueden revelar la identidad. Por ejemplo, si un usuario proporciona repetidamente los mismos antecedentes personales, el nombre de un proyecto corporativo o el contenido de conversaciones anteriores en distintas sesiones, el proveedor del servicio del modelo puede volver a vincular esas solicitudes basándose en las características del contenido. Incluso sin un nombre de cuenta, un estilo de escritura distintivo y la información contextual continua pueden proporcionar indicios identificativos.
Por tanto, una interpretación más precisa es que zkAPI puede reducir, en el diseño del protocolo, la asociación entre las identidades de pago y los registros de uso de las API, pero la protección integral de la privacidad en la IA todavía requiere otras tecnologías, como el anonimato de red, la minimización de datos y la computación con preservación de la privacidad.
Los agentes de IA utilizan las API de forma diferente a los usuarios habituales en algunos aspectos. Los usuarios tradicionales suelen adquirir suscripciones manualmente a través de sitios web o aplicaciones, mientras que los agentes de IA pueden necesitar llamar automáticamente a varios modelos, bases de datos o servicios informáticos en función de una tarea. Si cada servicio requiere una cuenta, un método de pago y una clave API a largo plazo independientes, la gestión de pagos y permisos puede volverse compleja para los sistemas automatizados.
Los mecanismos de crédito privado y autorización temporal que ofrece zkAPI proporcionan un enfoque técnico para pagar servicios entre máquinas de pago por uso. Un agente de IA puede obtener acceso a una API dentro de un importe de financiación y un límite de gasto predefinidos, y llamar posteriormente a los servicios pertinentes según la tarea real. Mediante pruebas de conocimiento cero, el servidor de pagos puede verificar el crédito autorizado sin exigir que cada llamada se asocie directamente con una cuenta de pago a largo plazo.
Además de la inferencia de modelos de IA, la Ethereum Foundation ha señalado como posibles casos de uso las consultas RPC de cadena de bloques, la generación de imágenes y vídeos, los servicios de ancho de banda VPN y otros servicios de facturación entre máquinas. Estos servicios comparten características comunes: normalmente se facturan por llamada, tarea informática, tiempo o volumen de tráfico y, por tanto, pueden utilizar mecanismos similares de autorización de crédito y liquidación basada en registros de uso.
Sin embargo, los pagos automatizados de los agentes de IA también requieren controles estrictos sobre los fondos y los permisos. Aunque la identidad de pago esté protegida, unas configuraciones de tareas incorrectas, llamadas anómalas a las API o entradas maliciosas todavía podrían provocar que los fondos se agoten rápidamente. Por ello, las implementaciones reales deben establecer límites por llamada, presupuestos de sesión, listas de servicios permitidos y mecanismos de supervisión del uso anómalo. Los pagos privados no deben equipararse a la seguridad de los pagos automatizados.
La primera categoría de desafíos procede de las pruebas criptográficas y de la complejidad del sistema. Aunque las pruebas de conocimiento cero pueden ocultar parte de la información subyacente, la generación y verificación de pruebas, así como la gestión de credenciales, siguen aumentando los costes de desarrollo y operación. El protocolo debe garantizar que los saldos privados de los usuarios se actualicen correctamente y evitar el doble gasto, al tiempo que gestiona la caducidad de las claves temporales, la liquidación de los registros de uso, las salidas anómalas y otras situaciones. En comparación con una base de datos de facturación centralizada tradicional, este diseño requiere que funcionen conjuntamente más componentes criptográficos y de contratos inteligentes.
La segunda categoría se refiere a la seguridad de los contratos inteligentes y los servicios de pago. El contrato Vault gestiona los fondos en cadena. Si existen vulnerabilidades en el contrato, en la lógica de verificación de pruebas o en la implementación del cliente, la seguridad de los fondos de los usuarios podría verse afectada. Aunque el proyecto oficial ha publicado su código fuente y ha implementado componentes relacionados en la red principal de Ethereum, su repositorio de GitHub todavía etiqueta el protocolo como una implementación experimental. Esto significa que los usuarios y desarrolladores no deben asumir que el protocolo cuenta con todas las protecciones de seguridad de un sistema de pagos comercial maduro simplemente porque está activo en la red principal.
La tercera categoría es el equilibrio entre la protección de la privacidad y las operaciones de los servicios en el mundo real. Los proveedores de servicios de IA todavía necesitan identificar los abusos, aplicar límites de frecuencia y gestionar las disputas de facturación, mientras que los mecanismos de pago anónimo pueden dificultar la aplicación directa de los controles de riesgo tradicionales basados en cuentas. zkAPI conserva las restricciones de facturación necesarias mediante claves temporales, límites de gasto y registros de uso firmados, pero los proveedores de servicios todavía deben desarrollar mecanismos de prevención del abuso adecuados para los entornos de pagos privados.
Además, el protocolo no resuelve automáticamente el anonimato de red ni la filtración del contenido de las indicaciones. Para las aplicaciones de IA que procesan información altamente sensible, utilizar zkAPI por sí solo no es suficiente para lograr una confidencialidad integral de los datos. También es necesario evaluar las políticas de tratamiento de datos del proveedor del modelo, los métodos de conexión de red y las tecnologías adicionales de computación con preservación de la privacidad.
El lanzamiento de zkAPI refleja cómo la exploración de Ethereum en el ámbito de las aplicaciones de IA se está ampliando desde los pagos de activos hacia la autorización privada y la facturación de servicios. Los pagos tradicionales mediante cadenas de bloques se centran generalmente en la capacidad de transferir activos entre distintas direcciones. zkAPI va más allá al examinar cómo realizar pagos reduciendo al mismo tiempo el vínculo informativo entre las identidades de pago y el uso real de los servicios. Esto significa que los contratos inteligentes de Ethereum pueden servir no solo como infraestructura de transferencia de pagos, sino también como parte del control de acceso y la gestión de fondos de los servicios digitales.
Desde el punto de vista de la arquitectura técnica, zkAPI combina la gestión de fondos en cadena con la autorización de API fuera de la cadena. Ethereum gestiona el contrato de fondos y la lógica de verificación necesaria, las pruebas de conocimiento cero ocultan el vínculo entre las credenciales de pago y comportamientos de uso específicos, y los proveedores de servicios de IA siguen realizando la inferencia de los modelos. Esta división evita colocar cada llamada a una API directamente en la cadena de bloques y ofrece un diseño de referencia para futuros servicios de pago por uso.
Sin embargo, zkAPI todavía se encuentra en las primeras fases de adopción en el mundo real. Su desarrollo a largo plazo dependerá no solo de la madurez de la tecnología de pruebas de conocimiento cero, sino también de si los proveedores de servicios de IA están dispuestos a integrarla, de si los desarrolladores pueden integrarla fácilmente y de si los usuarios realmente necesitan separar las identidades de pago de los registros de uso de los modelos. Para Ethereum, la importancia más relevante de zkAPI es que demuestra una arquitectura operativa de pagos privados, no que todos los servicios de API de IA vayan a pasar a utilizar pagos en cadena.
zkAPI es un protocolo de pagos de API centrado en la privacidad, lanzado mediante una colaboración entre la Ethereum Foundation y Open Anonymity Project. A través de contratos inteligentes Vault, Private Notes, pruebas de conocimiento cero y claves API temporales, separa las identidades de pago de los usuarios de sus registros de uso de servicios de IA. Los usuarios pueden depositar fondos previamente en Ethereum y obtener después acceso a las API mediante pruebas criptográficas, sin revelar el origen de la financiación correspondiente en cada solicitud.
En comparación con los métodos tradicionales de pago de API de IA, la principal innovación de zkAPI no consiste simplemente en utilizar ETH o stablecoins para comprar servicios de modelos. En su lugar, intenta abordar la asociación a largo plazo entre las cuentas de pago y el contenido de las solicitudes. Al combinar la gestión de fondos en cadena con la facturación del uso fuera de la cadena, el protocolo puede mantener la verificación de cuotas y la detección del doble gasto, al tiempo que mejora la protección de la privacidad en la capa de pagos.
Sin embargo, zkAPI no significa que los servicios de IA se vuelvan completamente anónimos. Los proveedores de modelos todavía pueden leer las indicaciones, mientras que los metadatos de red y las características del contenido también pueden revelar información del usuario. Para determinar si este tipo de tecnología puede aplicarse ampliamente a los agentes de IA, la inferencia de modelos y otros servicios de pago por uso, será necesario validar más a fondo su seguridad, escalabilidad y viabilidad comercial.
zkAPI es un protocolo de pagos de API centrado en la privacidad y basado en pruebas de conocimiento cero. Permite a los usuarios demostrar que disponen de crédito suficiente para utilizar un servicio mediante credenciales de pago privadas, sin revelar al servidor de pagos el origen específico de la financiación ni su identidad de pago a largo plazo.
zkAPI fue desarrollado conjuntamente por Open Anonymity Project y la Ethereum Foundation, y se anunció como activo en la red principal de Ethereum el 1 de octubre de 2026. Es una implementación técnica experimental desarrollada mediante esta colaboración y no un protocolo obligatorio de la capa base de la red Ethereum.
Los materiales oficiales de la Ethereum Foundation indican que activos como ETH y USDC pueden utilizarse en escenarios relacionados de financiación y pagos. Sin embargo, los activos concretos compatibles con el cliente, el contrato Vault y la versión implementada deben determinarse según la documentación más reciente de la implementación correspondiente.
No. zkAPI oculta principalmente la relación entre las identidades de pago y los registros de uso de las API. Los proveedores de servicios de modelos de IA todavía necesitan leer las indicaciones para generar respuestas, por lo que el contenido de las indicaciones no se cifra automáticamente por el mero hecho de utilizar zkAPI.
Los Nullifiers se utilizan para detectar si las credenciales de saldo privadas se han gastado más de una vez. El sistema puede evitar que se reutilice el mismo crédito comprobando identificadores únicos y evitando, al mismo tiempo, revelar directamente toda la información secreta de las credenciales.
zkAPI puede proporcionar a los agentes de IA facturación de pago por uso, autorización temporal y credenciales de pago privadas. Sin embargo, las implementaciones reales todavía necesitan límites presupuestarios, permisos de acceso y controles de uso anómalo para reducir los riesgos financieros asociados a las llamadas automatizadas.
* La información no pretende ser ni constituye un consejo financiero ni ninguna otra recomendación de ningún tipo ofrecida o respaldada por Gate.
* Este artículo no se puede reproducir, transmitir ni copiar sin hacer referencia a Gate. La contravención es una infracción de la Ley de derechos de autor y puede estar sujeta a acciones legales.





