Virtuals en colaboración con la Fundación Ethereum publica ERC-8183: protocolo comercial en cadena sin confianza

Autor: Virtuals Protocol

Compilación: Deep潮 TechFlow

Deep潮 Guía: Virtuals Protocol en colaboración con el equipo dAI de la Fundación Ethereum ha presentado la propuesta de estándar ERC-8183, cuyo núcleo es establecer un conjunto de protocolos comerciales en la cadena sin necesidad de confianza entre los AI Agents para facilitar su interacción económica. Esto no es solo un protocolo de pago, sino toda una infraestructura comercial que abarca especificaciones de tareas, custodia, validación de entregas y evaluación de reputación. En conjunto con el estándar previo ERC-8004 (Identidad y Reputación de Agentes), forman un ciclo completo: descubrimiento, transacción, acumulación de reputación, mejor descubrimiento y más transacciones sin confianza. Si te interesa la implementación de la economía de AI Agents en la cadena, este artículo merece una lectura detallada.

El texto completo a continuación:

Desarrollado por Virtuals Protocol en colaboración con el equipo dAI de la Fundación Ethereum

Especificaciones del estándar:

Foro de discusión: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

Únete a la comunidad Builder:

Condiciones para negocios: Los fundamentos de la IA descentralizada

Si queremos que los AI Agents sean accesibles, descentralizados, sin control de una sola plataforma, sin depender de un único proveedor y sin puntos únicos de fallo, el aspecto comercial es imprescindible. La infraestructura comercial no puede ser una idea posterior; debe ser la base misma. Además, esta infraestructura debe ser siempre abierta y sin permisos. Esto es precisamente lo que @ethereum busca construir: un «espacio digital compartido sin propietarios».

¿Por qué? Porque la descentralización en los niveles de IA y Agentes requiere una gran cantidad de Agentes y servicios independientes. Por ejemplo, si solo hay un Agente capaz de generar imágenes y deja de ofrecer servicio, sin importar en qué protocolo opere, la generación de imágenes se vuelve centralizada. Si solo un proveedor controla la ejecución de transacciones, la gestión de fondos depende de su voluntad. Si solo una plataforma controla la infraestructura de liquidación, todos los proveedores y clientes están sujetos a sus reglas, incluso si hay mil Agentes en esa plataforma.

Por eso, se necesita un comercio abierto: cualquier Agente debería poder comprar servicios y ofrecer servicios. Sin guardianes, sin jardines amurallados, sin intermediarios forzados.

¿Por qué blockchain?

La clave está en que el comercio solo funciona cuando todas las partes confían en que las transacciones se cumplirán. Si el cliente paga primero, ¿cómo sabe que el proveedor entregará? Si el proveedor entrega primero, ¿cómo sabe que el cliente pagará? Se necesita alguien que tenga fondos, rastree la finalización del trabajo y ejecute los resultados: liberar el pago al completarse, reembolsar en caso de fallo. La confianza (o su ausencia) ha llevado fundamentalmente a la centralización: entidades o guardianes que controlan todo.

En la arquitectura tradicional, esa «persona» es la plataforma. Una empresa que mantiene fondos en custodia, controla el estado de la máquina y decide quién recibe qué y cuándo. Este esquema funciona —hasta que deja de funcionar—. La plataforma puede cambiar reglas, congelar fondos, eliminar proveedores o cerrar servicios. Cada participante depende de la buena voluntad continua de la plataforma. Esto es centralización, no solo en el nivel del protocolo, sino en la ejecución. No está mal, pero en sistemas sin confianza, es necesario. Nuestro objetivo es la «descentralización total» (de-totalization): impedir que una sola entidad tenga control absoluto sobre las transacciones de los Agentes. Queremos una infraestructura en la que los desarrolladores puedan confiar, pero sin depender de la buena voluntad de una única plataforma.

Las smart contracts en cadena son una solución a esto. La custodia, los estados y la evaluación de la reputación existen en código abierto, inmutable y sin pertenencia a nadie. Los contratos son actores neutrales que generan señales de reputación significativas para todas las partes.

La liquidación en cadena también produce cosas que las plataformas centralizadas no pueden ofrecer: registros portátiles, verificables e inalterables. Cada tarea completada, cada evaluación, cada hash de entrega queda registrado en la cadena, visible para cualquier Agente, plataforma o interfaz. Estos registros alimentan los sistemas de reputación y las identidades de los Agentes. Sin liquidación en cadena, no hay historia verificable. Sin historia verificable, no hay reputación portátil. Sin reputación portátil, cada interacción de Agentes comienza desde cero en confianza.

Por eso, se necesita un estándar en cadena. Custodia, transiciones de estado y certificación deben ser neutrales, seguras y ejecutables.

El descubrimiento, la negociación y la comunicación pueden realizarse en cadena o fuera de ella, a través de interfaces naturales. Los Agentes pueden interactuar mediante HTTP usando el protocolo x402, con una experiencia similar a APIs o solicitudes HTTPS. No es obligatorio que los Agentes interactúen directamente con la cadena. Pueden firmar un mensaje, que será gestionado por un facilitador para liquidación y cumplimiento en cadena. O también pueden comunicarse directamente mediante MCP o A2A. La interfaz es flexible, pero la liquidación central debe ser sin confianza, programática y en cadena. Esto es una infraestructura que un sistema centralizado no puede ofrecer, ya que reduciría su control.

Economía de los Agentes

Los modelos y Agentes de IA avanzan rápidamente cada mes, volviéndose más poderosos. Tareas que hace un año requerían experiencia humana —como escribir código de producción, generar contenido especializado, analizar datos financieros o coordinar flujos de trabajo complejos— ahora pueden ser realizadas por Agentes con igual o mayor calidad. Además, su capacidad sigue acelerándose. La trayectoria del desarrollo de IA hace inevitable una nueva economía.

A medida que los Agentes se vuelven más fuertes, el valor de su trabajo aumenta. Un Agente que genera imágenes indistinguibles de las fotografías profesionales, es un servicio valioso. Uno que analiza carteras y ejecuta operaciones de optimización, maneja dinero real. Uno que revisa documentos legales y marca riesgos, realiza tareas que cobran cientos de dólares por hora a humanos.

Este es el cambio clave: la IA y los Agentes se convierten en participantes económicos que crean valor y ofrecen servicios.

Cuando la IA se vuelve accesible para todos, cada persona, organización y dispositivo puede operar mediante Agentes. La economía cambiará. Los Agentes no solo interactúan y sirven a humanos, sino que también interactúan entre sí. Por ejemplo, un Agente que coordina campañas de marketing puede firmar contenido, distribuirlo y analizar resultados con otros Agentes. La economía se transforma en una red de transacciones entre Agentes, operando a velocidad de máquina y escalando globalmente.

Con Agentes capaces de realizar trabajos valiosos y cada persona teniendo su propio Agente, la mayor parte de la actividad comercial fluye a través de sistemas autónomos. Este es el futuro que estamos construyendo.

El problema: comercio sin confianza entre Agentes

La economía de Agentes requiere un comercio entre Agentes. Pero cuando Agentes de diferentes organizaciones y cadenas interactúan por primera vez, ese comercio debe ser sin confianza.

En las transacciones humanas, la confianza es central. Se basa en plataformas, reputación, sistemas legales y normas sociales. Cuando un Agente contrata a otro, estos mecanismos no aplican. No hay reputación social verificable, ni leyes o mecanismos de reclamación en tiempo real, ni plataformas o reguladores que hagan cumplir.

Entonces, ¿cómo lograr un comercio entre Agentes sin confianza?

No basta con transferir tokens y esperar lo mejor. Una transferencia no es un negocio; es solo un pago sin garantías. No hay registros que definan los acuerdos, mecanismos que retengan fondos hasta la satisfacción, ni señales verificables para que otros Agentes evalúen. Si el proveedor no entrega, no hay reclamación.

Se necesita un mecanismo estructurado de colaboración: fondos en custodia programable y descentralizada, entregables verificables, evaluación de cumplimiento, resultados deterministas. Los fondos se liberan al completar, se reembolsan en caso de rechazo, y se recuperan si expiran. Todo esto contribuye a la identidad y reputación de las partes.

ERC-8183: Primitive de Trabajo

En colaboración con @ethereumfndn dAI, formalizamos esto en un estándar. ERC-8183: Agentic Commerce, es un estándar abierto y sin permisos para aplicaciones comerciales de Agentes, implementado mediante contratos inteligentes en cadena para custodia y evaluación.

Este estándar define una unidad central: el Job. Cada Job involucra tres partes: Cliente (Client), Proveedor (Provider) y Evaluador (Evaluator). Cada parte se identifica solo por su dirección de wallet, permitiendo amplia aplicabilidad.

Los componentes y principios clave del Job incluyen: (i) especificación y descripción de tareas —registro claro de tareas, servicios o trabajos vinculados a pagos; (ii) pago en custodia —guardado en un contrato programable hasta el estado final, con liberación automática; (iii) entregables verificables y trazables —protegiendo a cliente y proveedor; (iv) evaluación por parte del evaluador —generando señales de identidad y reputación, alineando incentivos para liquidación sin confianza.

Este proceso implica cuatro estados clave:

Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)

Resumen: el cliente crea un Job con el proveedor, inyecta fondos y bloquea el pago en custodia. El proveedor, tras completar el trabajo, llama a submit, sube la entrega (o referencia). El evaluador revisa, llama a complete (liberando fondos al proveedor) o reject (reembolsando al cliente). Si no hay acción antes de la fecha límite, el Job expira y el cliente recupera fondos.

El estándar mantiene un diseño mínimo, formando una primitive atómica. No regula negociación, tarifas, resolución de disputas, comunicación o descubrimiento. Solo define el ciclo de vida básico del Job —el mínimo para comercio sin confianza.

Evaluadores

Un concepto clave en ERC-8183 es el evaluador (Evaluator), definido solo por una dirección. Siempre es un Agente, en su definición más amplia.

Para tareas subjetivas como escritura, diseño o análisis, el evaluador puede ser un Agente IA que lee la entrega, compara con la solicitud y decide. Para tareas determinísticas como cálculos, generación de pruebas o transformación de datos, puede ser un contrato inteligente con ZK Verifier. El proveedor presenta una prueba, el evaluador la verifica en cadena y llama a complete o reject automáticamente. En escenarios de alto riesgo, puede ser multisig, DAO o un verificador con staking.

El estándar no distingue estos casos. Solo importa la dirección que llama a complete o reject. La misma interfaz puede gestionar tareas de $0.1 en generación de imágenes o de $100,000 en gestión de fondos.

Hooks: modularidad y extensión

El primitive Job está intencionadamente minimalista. Pero el comercio no lo está. Las aplicaciones reales requieren validación personalizada, actualización de reputación, distribución de tarifas, transferencia de fondos, mecanismos de pujas y lógica específica del caso.

ERC-8183 resuelve esto con Hooks. Un Hook es un contrato inteligente opcional adjunto en la creación del Job. Recibe callbacks antes y después de cada operación, permitiendo lógica personalizada sin modificar el ciclo principal. Se identifica mediante un selector de función, recibe parámetros relevantes y puede ejecutar condiciones previas, bloquear acciones inválidas, disparar efectos secundarios o realizar transferencias adicionales en la misma transacción.

Si no se configura un Hook, el contrato funciona normalmente. La implementación sin Hooks cumple con ERC-8183. Los Hooks son complementarios, no obligatorios. Este diseño mantiene el contrato principal simple y estable. Nuevos casos de uso se soportan mediante nuevos contratos Hook, manteniendo la lógica en cadena, programable y sin confianza, igual que el núcleo.

Ejemplos de aplicaciones comerciales

El núcleo del Job gestiona comercio directo: pagos, entregas, evaluaciones. Pero la economía de los Agentes no es simple. Algunos Jobs implican gestionar capital del cliente, no solo cobrar tarifas. Otros requieren pujas antes de asignar un proveedor. Algunos necesitan consultar datos de reputación externos. Estas son diferentes modelos económicos, y los Hooks permiten que una misma interfaz de Job soporte esta diversidad, haciendo de ERC-8183 una primitive comercial universal.

Jobs basados en servicios: sin Hooks. El cliente paga por generación de contenido, análisis de datos o revisión de código. El proceso de custodia y evaluación funciona completo.

Jobs con transferencia de fondos: más allá de tarifas. El cliente aporta capital (tokens o fondos), el proveedor lo transforma y devuelve el resultado. Los Hooks pueden gestionar estos flujos de capital bidireccionales fuera del núcleo, asegurando que el proveedor deposite los tokens antes de completar el Job. Esto cubre casos como yield farming, intercambios de tokens, reequilibrio de portafolios, o Jobs donde el proveedor maneja fondos del cliente o requiere capital previo.

Jobs con pujas: invierten el modelo de asignación. No es el cliente quien elige proveedor, sino que los proveedores compiten en precio. El Hook verifica la firma criptográfica del puja, demostrando que el proveedor comprometió el precio declarado. Nadie puede falsificar o negar los términos.

Jobs con control de reputación: ejecutan confianza en la capa de protocolo. El Hook consulta ERC-8004 antes de permitir acciones, bloqueando proveedores con baja reputación o agentes no verificados, o exigiendo condiciones más estrictas.

Jobs con privacidad: usan Hooks para negocios sin exposición de datos. Un Hook de privacidad puede requerir que el campo «submit» contenga una prueba ZKP o referencia a un entorno cifrado (como TEE), sin publicar datos sensibles en la cadena. Esto garantiza pagos sin confianza y en público, mientras que la propiedad intelectual o datos personales permanecen en un «refugio» accesible solo a agentes autorizados.

Jobs de evaluación de riesgos / suscripción: mediante Hooks, se puede realizar suscripción en la capa de protocolo. El Hook puede requerir que el proveedor o suscriptor ponga garantías, verifique puntuaciones de reputación ERC-8004, ejecute slashing en garantías en caso de fallo, o consulte oráculos externos de riesgo. Estos procesos antes opacos ahora son transparentes, programables y competitivos.

Cada uno de estos casos puede implementarse como un contrato Hook diferente, manteniendo la lógica central y el estándar del Job. Nuevas variantes de modelos económicos, aplicaciones comerciales o lógica personalizada son nuevos Hooks. Hemos implementado algunos Hooks iniciales como ejemplos, pero solo estamos arañando la superficie. ¿Cómo será el comercio de Agentes en seguros, colaboración creativa o coordinación de cadenas de suministro? No lo sabemos aún, y esa es la parte interesante. La economía de Agentes evolucionará de formas que no podemos prever completamente: nuevos modelos económicos, nuevos mecanismos de confianza, nuevas formas de colaboración entre máquinas. Este estándar está diseñado para crecer con esa evolución, no para limitarla. Debe construirse en apertura, porque las mejores ideas surgirán del ecosistema, y estamos ansiosos por descubrir esas ideas juntos.

Convivencia con ERC-8004

ERC-8183 no existe en aislamiento. Es complementario a ERC-8004 («Trustless Agents»), el estándar de identidad, reputación y verificación de Agentes en Ethereum.

ERC-8004 resuelve descubrimiento y confianza: cómo los Agentes se encuentran y evalúan confiabilidad. Pero su valor depende de los registros de actividad. Sin interacción real, la identidad es solo un archivo vacío. La reputación requiere interacción genuina. La verificación necesita entregables definidos para cotejar.

ERC-8183 alimenta la capa de confianza de ERC-8004 con actividad comercial. Cada Job es una señal de reputación. Cada entrega es un entregable verificable. Cada evaluación es una certificación que otros Agentes pueden citar.

Ambos estándares forman un ciclo que puede permitir a los Agentes autoorganizarse mediante interacciones sin confianza:

Descubrimiento (8004) → Comercio (8183) → Reputación (8004) → Mejor descubrimiento → Más comercio sin confianza

Ambos son indispensables. Juntos constituyen la base para un comercio y una interacción sin confianza entre Agentes.

Más allá de pagos

ERC-8183 no es un protocolo de pago, sino un estándar comercial.

El pago mueve dinero. Pero el comercio requiere mucho más. Requiere acuerdos, verificar que el trabajo esté hecho, quién lo validó, qué pasa si no se cumple. En el mundo tradicional, el comercio funciona gracias a un conjunto de mecanismos: evaluación de riesgos y suscripción antes de aceptar pagos, extensión de crédito para que los compradores puedan comerciar antes de tener fondos, detección en tiempo real de fraude en miles de millones de transacciones, mecanismos de protección y disputa, y sistemas de reputación que construyen confianza mediante interacción repetida. Estas funciones son el valor de los procesadores de pagos, redes de tarjetas y plataformas: no solo mover fondos, sino construir infraestructura de confianza.

Cuando el comercio migra a la cadena, estas funciones no desaparecen. Se reconstruyen en forma sin confianza, programable y abierta. Eso es lo que hace ERC-8183.

El modelo de custodia y evaluación en ERC-8183 es similar a un mecanismo de retención con condiciones programables. La reputación en cadena de ERC-8004 y otros indicadores alimentan ERC-8183 como un proceso de suscripción portátil y verificable. Hooks reemplazan la evaluación de riesgo centralizada con lógica modular, competitiva y auditable, desplegable por cualquier facilitador. El resultado no es solo una forma de transferir fondos en cadena, sino de reconstruir toda la infraestructura de confianza comercial —abierta y sin permisos.

Los protocolos y interfaces de pago existentes, ya sean tradicionales o como x402 para transferencias estables, ofrecen experiencias fluidas y nativas de internet, centradas en mover fondos. ERC-8183 gestiona todo el ciclo de vida del pago sin confianza: especificación, custodia, entrega, evaluación y liquidación determinista en cadena. Los Agentes pueden interactuar mediante interfaces como x402 o HTTP, mientras que la liquidación subyacente fluye en la cadena a través de ERC-8183. Son complementarios.

Inmutabilidad, custodia y reversiones

Otra preocupación en pagos independientes es la irreversibilidad. Cuando una tarjeta de crédito se carga y el servicio no satisface, el consumidor puede disputar y revertir. Una vez transferido el dinero, se pierde. Para pagos y transferencias originales, esto es un problema real y válido.

ERC-8183 mantiene este concepto en su estructura contractual. Los fondos permanecen en custodia hasta que un evaluador verifica que la entrega cumple los términos. La ruta de rechazo reembolsa al cliente. La ruta de expiración recupera automáticamente los fondos. Es una versión programable y sin confianza del modelo de autorización y captura —el que hace que funcione el comercio con tarjetas—, solo que los términos están codificados y ejecutados por código, no por una red con intereses propios.

Para autorizaciones previas de montos variables —como depósitos en hoteles o servicios con alcance variable—, Hooks puede diseñarse para bloquear un monto máximo, y liquidar el monto final verificable al completar. Este esquema soporta modelos de confianza y comportamiento flexibles, manteniendo la liquidación transparente, abierta, sin confianza y en cadena.

Nuevos participantes económicos

La ola de IA está creando en velocidad récord nuevos participantes económicos: compradores y comerciantes. Millones de desarrolladores y no desarrolladores usan asistentes de IA para construir y lanzar microservicios, APIs y herramientas, muchos sin entidad legal, sin sitio web ni historial de transacciones. Agentes de empresas tecnológicas y frameworks de código abierto atraen a millones de usuarios con agentes personales y asistentes.

Los sistemas de pago tradicionales tendrán dificultades para atender a estos comerciantes. No por falta de tecnología, sino porque al aprobar un proveedor, asumen su riesgo: fraude, devoluciones, disputas. Un comerciante sin registros, sin entidad y sin historial es demasiado arriesgado para asegurar.

ERC-8183, por diseño, es sin permisos. Un proveedor es solo una dirección de wallet. No requiere registro, ni aseguramiento, ni guardianes. El primitive Job no solo ofrece un método de cobro, sino toda la ciclo de vida comercial: especificación, custodia de pago, entregables verificables y evaluación, sentando las bases para transacciones confiables.

La incapacidad de asegurar nuevos proveedores puede parecer una brecha temporal. Pero un estándar abierto, por su estructura, acorta esa línea de tiempo. Cualquier facilitador puede desplegar ERC-8183 hoy. La evolución del ecosistema será por experimentación, no por consenso institucional. Pero más allá, ERC-8183 junto con ERC-8004 no solo cierra esa brecha de aseguramiento, sino que aborda la causa raíz: la falta de historia verificable. Cada Job completado queda registrado en la cadena: hashes, evaluaciones, resultados. Esa historia es portátil, verificable y sin pertenencia a nadie.

Lo importante es que estos registros no están atrapados en una sola plataforma. Hoy, la plataforma A conoce tu tasa de devoluciones, la plataforma B tu calificación de vendedor, pero no puedes transferir esas credenciales. En ERC-8183, la reputación es un activo portátil del comerciante, accesible a cualquier facilitador, cadena o interfaz que implemente el estándar. ERC-8183 alimenta las identidades y reputaciones en cadena (ERC-8004) y proporciona datos de aseguramiento.

Construyamos juntos el futuro del comercio de Agentes y la IA descentralizada

ERC-8183 es un estándar abierto para comercio sin confianza entre Agentes. Cómo participar:

Construye con ERC-8183. ¡Sé facilitador! Despliega ERC-8183 en tu cadena. Desarrolla SDKs, wrappers, escáneres y rastreadores. Crea nuevas interfaces y experiencias que permitan liquidación segura y verificable en cadena mediante ERC-8183. Desarrolla frameworks nativos para Agentes que interactúen con este estándar.

Explora, experimenta y desarrolla Hooks. ¿Necesitas pagos por hitos o resolución de disputas? Crea Hooks para ello. Es un espacio para la creatividad y la diversificación de aplicaciones.

Construye y registra evaluadores. Los evaluadores son clave para la seguridad y confianza en el comercio sin confianza, pero actualmente escasean. Desarrolla evaluadores en áreas específicas, especialmente en dominios verificables, y regístralos en ERC-8004. Contribuye a la identidad y reputación de los Agentes de forma significativa.

Contribuye y da retroalimentación. Este es un estándar colectivo. Solo mediante experimentación, uso real, feedback honesto y iteración, podrá evolucionar hacia lo que debe ser. Propón mejoras, desafía errores. La especificación y el código son abiertos, y la discusión también. La evolución será conjunta.

La economía de Agentes se basará en estándares abiertos o en jardines amurallados. Nosotros elegimos estándares abiertos. Un espacio digital compartido.

ERC-8004 para confianza. ERC-8183 para comercio. Y tú, para construir.

Enlaces relacionados:

Especificación ERC-8183:

Especificación ERC-8004: eips.ethereum.org/EIPS/eip-8004

Discusión ERC-8183: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

Comunidad en Telegram: