Autor: Instituto de Investigación de CoinW
Resumen
Con el desarrollo de aplicaciones como DeFi, abstracción de cuentas y agentes de IA, la autorización en cadena está evolucionando gradualmente desde firmas únicas de confirmación hacia un permiso de ejecución a largo plazo y reutilizable. Al mismo tiempo, también están ocurriendo nuevos cambios: los agentes de IA ya pueden solicitar servicios y realizar pagos de forma automática. Por ejemplo, el protocolo x402 utiliza el código de estado HTTP 402 para permitir que los agentes paguen inmediatamente con monedas estables por recursos y servicios sin intervención humana. Esto hace que los comportamientos en cadena ya no sean transacciones aisladas, sino procesos de colaboración automatizada y continua.
En este contexto, los problemas de autorización se amplían aún más. Los métodos actuales de autorización dentro del ecosistema Web3 siguen teniendo límites ambiguos y expresiones toscas, y suelen resolver solo si se puede o no utilizar un activo, pero con dificultad responden a lo concreto de lo que se permite hacer y hasta qué punto. ERC-8004 se propone precisamente en este contexto. No define nuevos activos ni cambia cómo se ejecutan las transacciones o los pagos, sino que intenta establecer un modelo de permisos que pueda ser comprendido y verificado por el sistema, convirtiendo la autorización misma en un objeto que pueda describirse, restringirse y gestionarse.
Desde una perspectiva de sistema más amplia, ERC-8004 no compite con protocolos de pago automatizados como la abstracción de cuentas y x402, sino que se encuentra en divisiones de trabajo y colaboración en diferentes niveles: x402 resuelve el problema del intercambio de valor después de que ocurra una acción, mientras que ERC-8004 se centra en lo que ocurre antes de la acción, es decir, quién está autorizado para actuar y si los permisos se han excedido. En escenarios como DeFi, agentes de IA y empresas, así como activos financieros reales (RWA), esta estructura en la que los permisos preceden y los pagos siguen, tiene el potencial de impulsar la autorización desde el nivel de activos hasta el nivel de acciones, proporcionando una base controlable para colaboraciones automatizadas más complejas y de largo plazo. Aunque aún enfrenta desafíos reales en términos de costo de aprendizaje, soporte de billeteras y experiencia del usuario, ERC-8004 no es una herramienta narrativa a corto plazo, sino un estándar subyacente que determina si Web3 puede soportar la operación de sistemas complejos.
1. Motivación para la propuesta de ERC-8004
A medida que la infraestructura en cadena continúa evolucionando, las capacidades relacionadas con la subida de activos a la cadena y la ejecución de transacciones se abstraen y refuerzan continuamente. Desde ERC-20, NFT, hasta las billeteras de firma múltiple y la abstracción de cuentas (ERC-4337), el umbral para que los usuarios participen en actividades en cadena se reduce constantemente, y las cuentas en sí mismas también se vuelven cada vez más inteligentes.
Pero en este proceso, una cuestión fundamental nunca ha sido resuelta de manera sistemática: el mecanismo de autorización en sí mismo apenas ha experimentado una evolución sustancial. En el Web3 temprano, la autorización significaba una firma única con la clave privada. Los usuarios expresaban mediante la firma "estoy de acuerdo", ya fuera para transferencias, llamadas a contratos o operaciones de aprobación, y la autorización se consideraba un acto de confirmación único, con los límites de riesgo completamente asumidos por el usuario.
Sin embargo, el entorno en cadena hoy en día ha cambiado. En el escenario de DeFi, la aprobación suele ser de larga duración; bajo sistemas de estrategias automatizadas y claves de sesión, la autorización se utiliza repetidamente; en modelos donde los agentes de IA o bots ejecutan transacciones, los usuarios ni siquiera participan directamente en cada operación. La autorización está evolucionando desde una confirmación única hacia una capacidad de ejecución continua, pareciéndose más a entregar el poder de hacer algo durante un período de tiempo.
El problema radica en que la infraestructura actual de Web3 apenas ofrece una forma clara y uniforme de imponer restricciones a estos estados de autorización a largo plazo. El alcance ambiguo de los permisos, la dificultad para revocar autorizaciones y los riesgos impredecibles se convierten en la fuente de numerosos incidentes de seguridad. Al mismo tiempo, la abstracción de cuentas agrava aún más esta contradicción: cuando una cuenta puede ejecutar transacciones de forma automática y terceros pueden pagar el Gas en su lugar, lo que sí y no puede hacer resulta aún más ambiguo.
Es precisamente en este contexto que se propuso ERC-8004. Intenta completar un eslabón que ha estado faltando durante mucho tiempo en Web3: establecer un modelo de permisos claro, vinculante y comprensible para el sistema, para la autorización en sí misma.
2. Contenido principal del ERC-8004
El punto de partida del ERC-8004 no radica en la forma de los activos ni en la forma de ejecutar las transacciones, sino en si los permisos pueden ser descritos de manera individual, validados de forma independiente y gestionados continuamente a nivel del sistema.
2.1 ¿Qué define el ERC-8004?
Según la definición del sitio web oficial de Ethereum Improvement Proposals (EIP): ERC-8004 es un protocolo estándar para descubrir, seleccionar e interactuar con agentes autónomos confiables en Ethereum. Construye una infraestructura de agentes para interacciones descentralizadas sin necesidad de confianza previa, mediante mecanismos de registro en cadena, reputación y verificación.
Los agentes autónomos aquí no se limitan al Agente de IA, sino que se refieren a cualquier entidad que pueda ser autorizada y actuar de forma independiente, como contratos, scripts automatizados, múltiples firmas o procesos de servicio. ERC-8004 se centra en si la entidad ejecutora tiene la capacidad de poseer autorización y límites de permisos claros, y el Agente de IA es solo una aplicación típica entre ellas.
Desde una perspectiva más general, ERC-8004 no es un nuevo estándar de activos ni un nuevo tipo de cuenta, sino un marco para la expresión y verificación de permisos en cadena, utilizado para describir qué comportamientos se permiten a un sujeto bajo qué condiciones y verificarlos antes de realizar operaciones. Por lo tanto, ERC-8004 no se centra en "qué es el dinero" o "cómo se ejecutan las transacciones", sino en "qué comportamientos están permitidos". No crea nuevos activos ni modifica las propiedades de los activos existentes, sino que simplemente añade una capa de reglas claras y verificables de permisos sobre los activos y cuentas.
Además, ERC-8004 no es un reemplazo para la abstracción de cuentas (ERC-4337). La abstracción de cuentas se centra en cómo se ejecutan las transacciones, mientras que ERC-8004 resuelve la determinación de permisos antes de que ocurra la transacción. Si se dice que la abstracción de cuentas hace que las cuentas sean más flexibles, ERC-8004 establece límites claros para esta flexibilidad.
El núcleo del ERC-8004 radica en transformar la autorización de una acción implícita en la firma, en un objeto de permisos que pueda describirse claramente, validarse de forma independiente y gestionarse de manera continua.
2.2 Marco mecanicista central del ERC-8004
Para comprender el mecanismo central de ERC-8004, se puede dejar de lado la compleja implementación técnica y entenderlo como un "manual de permisos en cadena". En la lógica tradicional de autorización, los usuarios suelen tomar solo una decisión general: "Estoy de acuerdo en que operes con mis activos". En cuanto a lo específico que se puede hacer, cuánto se puede hacer y durante cuánto tiempo, el sistema no hace una distinción más allá. En el marco de ERC-8004, una autorización ya no es un acuerdo vago, sino que se descompone en un conjunto de reglas que se pueden describir claramente y que el sistema ejecuta de manera obligatoria. Este "manual de permisos" generalmente incluye cinco tipos de información clave.
Sujeto autorizado (Who): ¿Quién está autorizado para ejecutar?
Primero, se debe aclarar quién se le otorga el permiso de ejecución. En ERC-8004, el objeto autorizado ya no está limitado a una dirección de billetera fija, sino que también puede ser un contrato, un agente automatizado, o incluso una clave de sesión para operaciones a corto plazo. Esto permite que la autorización se adapte a más escenarios complejos, por ejemplo: permitir que un contrato de estrategia realice operaciones dentro de un ámbito limitado, o que un agente complete tareas específicas sin necesidad de firmas repetidas. Lo importante es que los permisos siempre se otorgan a "un sujeto claramente definido", y no se entregan de manera vaga.
Comportamiento ejecutable (What): ¿Qué operaciones se permiten?
En segundo lugar, se trata de qué comportamientos están permitidos. La autorización tradicional suele ser todo o nada; una vez otorgada, se supone por defecto que el contrato puede llamar libremente dentro del alcance de los permisos. En el diseño de ERC-8004, en cambio, la autorización puede ser precisa en cuanto al tipo de comportamiento, por ejemplo, permitir solo la ejecución de swap, transfer, o una categoría específica de llamadas a funciones, en lugar de abrir por defecto todas las operaciones posibles. ERC-8004 no responde a si se puede usar o no, sino a hasta qué punto se puede usar.
Restricciones (¿Bajo qué condiciones): ¿Bajo qué condiciones se puede ejecutar?
Esta es la parte clave que distingue al ERC-8004 de la autorización tradicional. En los documentos de permisos, la autorización suele ir acompañada de condiciones limitativas explícitas, por ejemplo: límites máximos por transacción o acumulados; restricciones de frecuencia o número de ejecuciones; solo pueden aplicarse a protocolos, piscinas o direcciones de contrato específicos, etc. Estas condiciones no son reglas de monitoreo posteriores, sino condiciones previas que deben cumplirse antes de la ejecución. Tan pronto como las condiciones no se cumplan, la operación en sí misma no podrá ser ejecutada.
Reglas de entrada en vigor y caducidad (When): ¿Cuándo se establece el permiso y cuándo termina?
El ERC-8004 introdujo además conceptos claros de tiempo y ciclo de vida. Los permisos pueden configurarse para: (a) ser válidos solo durante un período de tiempo específico; (b) caducar automáticamente después de un solo uso; (c) revocarse en cualquier momento. Esto hace que los permisos ya no sean una carga a largo plazo que, una vez otorgados, no se puedan recuperar, sino más bien una capacidad temporal que puede gestionarse con precisión.
Método de verificación (How enforced): ¿Cómo se implementan realmente las reglas?
Finalmente, y quizás el punto más fácil de ignorar: cómo se ejecutan estas reglas. La idea central del ERC-8004 es realizar la verificación de permisos antes de que se realice una operación. Si una acción no cumple con las reglas de permisos previamente definidas, el sistema rechazará directamente su ejecución, en lugar de perseguir responsabilidades después de que ocurra el problema. Este es precisamente el punto fundamental de diferencia entre el ERC-8004 y la lógica tradicional de control de riesgos.
2.3 Nuevos tipos de capacidades en ERC-8004: ¿por qué no se podía hacer antes?
A simple vista, ERC-8004 solo permite una autorización más detallada, pero el modelo tradicional de autorización en Ethereum no era capaz de expresar lógicas de autorización complejas. La autorización tradicional solo verifica si una dirección está permitida para operar, y una vez que se aprueba la autorización, lo que se puede hacer, cuánto, y cuándo, no pueden ser reconocidos por el sistema.
La ruptura central del ERC-8004 radica en que eleva la autorización de "juzgar identidades" a "juzgar acciones". El sistema comienza a determinar si una operación cumple con los límites de permisos establecidos por el usuario, y no solo confirma quién la inició. Esto hace que la autorización incluya naturalmente condiciones como monto, frecuencia, alcance y fecha de vencimiento, sin necesidad de depender de la revocación posterior por parte del usuario o de la supervisión manual.
Cuando la lógica de autorización se estructura, adquiere por primera vez la capacidad de ser combinable y reutilizable. Operaciones multietapa y transprotocolo pueden ser claramente restringidas en la fase de autorización, en lugar de dejarse a juicios provisionales en tiempo de ejecución. Por esta razón, ERC-8004 abre realmente espacio para escenarios de Agentes. Los programas automatizados ya no necesitan "autorizaciones ilimitadas", sino que se les restringe a un ámbito de comportamiento claro y verificable, rechazándose la ejecución si se exceden.
Lo que añade el ERC-8004 no es simplemente una "autorización más segura", sino que permite que la lógica de autorización sea entendida y ejecutada por el sistema, lo cual es la diferencia esencial con los mecanismos de autorización tradicionales.
3. Direcciones potenciales de aplicación del ERC-8004
ERC-8004 no es un estándar diseñado para un producto específico, es más bien un lenguaje general para capacidades de autorización. Por lo tanto, su valor de aplicación no se manifiesta en un estallido en un solo escenario, sino en la demanda común de la misma capacidad por parte de múltiples sistemas cuando la autorización se vuelve más compleja.
DeFi: desde la "autonomía a nivel de activos" hacia la "autonomía a nivel de acciones"
En el sistema actual de DeFi, la forma más común de autorización sigue siendo "una sola autorización, monto ilimitado". Por ejemplo, los usuarios, para realizar una operación de intercambio (swap), préstamo o garantía (stake), necesitan primero aprobar (approve) el contrato, lo que en esencia significa entregar el control total de sus activos. Esto es muy eficiente en términos de experiencia, pero también conlleva riesgos evidentes: una vez que el contrato sea actualizado, atacado o utilizado en lógicas no previstas por el usuario, la autorización en sí misma se convertirá en un amplificador de riesgos. El ERC-8004 ya no autoriza activos, sino comportamientos específicos. Por ejemplo, los usuarios podrían exigir: no es que autorizo a este contrato a usar ilimitadamente mis USDC, sino que autorizo que use hasta 1.000 USDC en un plazo de 24 horas para completar una operación de intercambio (swap). Aunque algunos proyectos ya han intentado limitar el alcance y la duración de las autorizaciones, actualmente la mayoría actúa de manera independiente. El valor del ERC-8004 radica en estandarizar la autorización a nivel de comportamiento, logrando un sistema de gestión de permisos reutilizable y combinable, mejorando fundamentalmente la capacidad de control de riesgos.
Agente de IA: proporciona límites de permisos verificables para la ejecución automatizada
Conforme los agentes de IA participan gradualmente en decisiones y ejecuciones en la cadena, el problema de la autorización se amplía a un nuevo nivel. El valor de los agentes radica en su operación continua y ejecución automática, pero esto también significa que deben poseer ciertos permisos operativos a largo plazo. Si no existen límites claros de permisos, lo que se llama agente, en esencia, no es más que un programa automatizado bajo el control completo del usuario, y los riesgos no disminuyen simplemente por ser "inteligente". ERC-8004 proporciona a los agentes un límite de autorización verificable a nivel de sistema. Qué operaciones puede realizar un agente, en qué ámbito actúa, si tiene restricciones temporales, estas reglas pueden ser verificadas antes de la ejecución, en lugar de depender de la supervisión posterior. Solo cuando los permisos mismos son estructurados y verificables, la ejecución automatizada tiene una base de confianza.
Colaboración con el protocolo x402: hacer el comportamiento del Agente "autorizable y facturable"
En escenarios de Agentes, otro problema clave más allá del permiso es: cómo se completa el intercambio de valor cuando se permite una acción. Algunos protocolos de capa de aplicación están intentando resolver este problema. Por ejemplo, el protocolo x402 reactiva el código de estado HTTP 402 (Pago Requerido), permitiendo que los Agentes realicen automáticamente pagos en monedas estables al solicitar recursos o servicios. En esta arquitectura, ERC-8004 y x402 se sitúan en capas diferentes, pero forman una relación complementaria. ERC-8004 se centra en "quién puede hacer qué y si está permitido", estableciendo límites de permisos y confianza para las acciones; x402 resuelve "cómo completar el pago y liquidación cuando ocurre una acción". El primero no depende del segundo para funcionar, y el segundo no requiere ERC-8004 como condición previa. Sin embargo, en la economía de Agentes, ambos asumen respectivamente los roles de capa de permisos y capa de pagos. Esta colaboración en capas permite que los Agentes completen el proceso completo, desde la verificación de permisos hasta el intercambio de valor, sin intervención humana, evitando también la complejidad de mezclar lógica de identidad, autorización y pagos en el mismo sistema. A medida que los Agentes aumentan su actividad en escenarios como adquisición de contenido, llamadas a datos y servicios de cómputo, este tipo de combinaciones tiene potencial para convertirse en una forma arquitectónica escalable.
Escenario empresarial y RWA: los permisos como expresión básica de la conformidad
En aplicaciones empresariales y escenarios de RWA, el valor del ERC-8004 se manifiesta principalmente en la conformidad y la explicabilidad. La gestión de activos en el mundo real requiere a menudo respuestas claras a preguntas como: ¿quién está autorizado para realizar qué acciones bajo qué condiciones? Comparado con si el activo mismo se registra en la cadena, cómo se definen y registran los permisos resulta ser clave para acceder al sistema financiero real. El ERC-8004 no resuelve directamente los problemas de conformidad, pero proporciona soporte subyacente para la expresión estructurada de permisos, lo que permite naturalmente que las autorizaciones sean auditadas, rastreadas y verificadas. Esta capacidad no cambiará inmediatamente la experiencia del usuario, pero reducirá significativamente los costos de integración entre los sistemas Web3 y las organizaciones tradicionales.
Desde estas aplicaciones potenciales se puede ver que ERC-8004 no es un estándar impulsado por escenarios, sino una capacidad fundamental que surge naturalmente a medida que aumenta la complejidad del otorgamiento de permisos. Cuando los comportamientos en cadena evolucionan desde operaciones únicas hacia comportamientos de sistemas en ejecución continuo, una forma clara y verificable de expresar permisos se convierte casi en una elección inevitable.
4. Desafíos y valor a largo plazo del ERC-8004
Desafíos reales
Primero es el costo de aprendizaje. En comparación con autorizar con un solo clic, ERC-8004 introduce una lógica más refinada para describir los permisos. Tanto los desarrolladores como los usuarios necesitarán entender nuevamente el significado de la autorización dentro del sistema. Este costo cognitivo también requerirá cierto tiempo para ser absorbido por el mercado. En segundo lugar, está el soporte de las billeteras e infraestructura. Las capacidades de ERC-8004 solo podrán desempeñarse plenamente si las billeteras, los SDK y los entornos de ejecución las comprenden y colaboran con ellas. En una etapa temprana, se parece más a una capacidad utilizable pero no universal, dificultando formar efectos a gran escala de inmediato. Finalmente, está la experiencia del usuario. Si las autorizaciones complejas se exponen directamente al usuario, solo aumentarán la carga operativa. Cómo convertir un conjunto de reglas estructuradas y verificables por máquinas en una forma de interacción intuitiva y aceptada por usuarios comunes, determinará directamente si ERC-8004 tiene la posibilidad de ser implementado a gran escala.
ERC-4008 no resuelve el presente, sino la próxima etapa
Debido a la existencia de estos umbrales reales, ERC-8004 no es adecuado como una herramienta narrativa a corto plazo. No provocará inmediatamente una explosión en la cantidad de usuarios, ni tampoco dará lugar directamente a nuevos modelos de ingresos. ERC-8004 no intenta hacer que el mundo vaya más rápido, sino que mantiene el sistema controlable, interpretable y verificable incluso después de su complejización. Su valor no radica en la cantidad de funciones, sino en si预留 una base de permisos sostenible para la evolución futura de la automatización, la colaboración de agentes y la participación institucional. En este sentido, ERC-8004 no es un estándar creado para un ciclo específico, sino una de las capacidades fundamentales que determinan si Web3 puede soportar relaciones de colaboración complejas.