El estado de los emisores de RWA: Brickken Research está disponible
Informe sobre el estado de los emisores de RWA
Consíguelo ahora
Los agentes de IA autónomos han pasado de las demostraciones de investigación a los sistemas de producción que mantienen el contexto, llaman a herramientas, realizan transacciones y actúan en nombre de entidades reales. Los modelos son potentes, los marcos son maduros y la superficie de integración sigue expandiéndose. Lo que aún falta es la capa institucional subyacente: una forma para que un agente tenga una identidad que un regulador pueda resolver, una reputación en la que los sistemas posteriores puedan confiar sin un agregador, un mandato que limite lo que se le permite hacer y un mecanismo de pago que no dependa de una clave API estática.
Esta es la capa que hemos estado construyendo en Brickken, en parte como trabajo de estándares abiertos junto con otros contribuyentes de Ethereum, en parte como herramientas de producción. Ahora es público como Brickken CLI: una interfaz de línea de comandos para flujos de trabajo de transacciones agénticas pagadas con x402, construida en torno al estándar ERC-8004 para agentes sin confianza y diseñada para componerse con ERC-8226, el estándar de mandato de agente regulado que nuestro equipo está coescribiendo actualmente como un borrador de ERC.
Resumen
Cuando observas cómo los agentes de producción se autentican en los servicios que consumen, casi nada ha cambiado desde la era SaaS: claves API compartidas, facturación opaca, sin identidad en la cadena, sin reputación pública y sin mandato formal que describa lo que el agente tiene permitido hacer en nombre de quién. Los casos de uso legales, sanitarios, financieros y de ingeniería que justifican la IA autónoma son precisamente los dominios donde el comportamiento irresponsable es más costoso, y aquellos donde los reguladores están a punto de empezar a preguntar cómo se autorizó a un sistema autónomo a realizar una acción particular.
Un agente que puede gastar, firmar, negociar e integrar sin una respuesta estructural a esas preguntas no es una herramienta de productividad; es una responsabilidad contingente. Cerrar esa brecha requiere cuatro primitivas, todas nativas de la cadena en lugar de añadidas posteriormente: identidad, reputación, mandato y pago. El panorama de estándares de Ethereum ahora tiene candidatos creíbles para cada uno: ERC-8004 para la identidad y reputación del agente sin confianza, ERC-8226 para la delegación de mandato regulada, ERC-20 para la economía de tokens alineada con el agente y x402 para la liquidación criptográfica por solicitud. Estas cuatro primitivas se componen con el sustrato de activos regulados en sí mismo — ERC-3643 y ERC-7943 (uRWA) para el cumplimiento tokenizado — que es donde los mandatos se aplican en última instancia en el momento de la transferencia. El trabajo interesante en 2026 es componerlos en algo que un equipo de ingeniería pueda realmente implementar
La Brickken CLI es nuestro intento de comprimir esa capa faltante en el área superficial más pequeña posible para desarrolladores y operadores. No es un mercado, un modelo o una billetera, es una interfaz delgada y con opiniones para operaciones que creo que todo operador de agente serio eventualmente necesitará.
El primero es identidad. brickken agent register registra un agente autónomo en la cadena bajo el estándar de agentes sin confianza ERC-8004, adjuntando un punto final de servicio, una referencia de modelo de IA y una billetera de control. El agente deja de ser una fila en la base de datos de un proveedor de SaaS y se convierte en un actor de primera clase en la cadena con un origen verificable.
El segundo es la reputación. brickken agent feedback give, append, and revoke write feedback signals in the ERC-8004 reputation registry. This not of Discord stars or vendor managed scores. Is inmutable, timest-branded, and attribute feedback that downstream systems (ya sean otros agentes, contratos inteligentes o paneles de cumplimiento) can read direct without trust a intermediario aggregater. Trust become a property of the network, not of a private database.
El tercero es la economía. brickken create-token, junto con mint, burn, transfer, transfer-from, and approve, deploy and operation agentic ERC-20 token linked to the agent wallet. Este es el puente entre los servicios del agente y los mercados de capitales: un instrumento a través del cual los titulares pueden financiar el desarrollo, compartir los ingresos por uso o ejercer el control sobre la evolución del agente. Es la diferencia entre subvencionar un servicio de IA a través de capital de riesgo y fijar su precio a través de un mercado.
La identidad te dice quién es un agente. La reputación te dice cómo se ha comportado. Ninguna te dice qué se le permite hacer, en nombre de quién y dentro de qué límites — y esa es precisamente la pregunta que hace un regulador cuando un sistema autónomo ejecuta una transacción de valores. Esta es la brecha que nuestro equipo en Brickken se propuso abordar con ERC-8226, el Estándar de Mandato de Agente Regulado (RAMS), actualmente un borrador de ERC en la vía de estándares de Ethereum.
RAMS define una capa de delegación de cumplimiento para agentes de IA que operan en activos regulados tokenizados. Especifica cómo un principal verificado por KYC puede otorgar a un agente en la cadena una autoridad con alcance, límite de tiempo y límite financiero, efectivamente, un poder notarial en la cadena, y cómo los contratos de tokens regulados verifican ese mandato atómicamente dentro de su gancho de cumplimiento previo a la transferencia. Dos interfaces llevan el diseño: IComplianceProvider, que cualquier operador de KYC o de atestación puede implementar para garantizar la elegibilidad del principal para un alcance determinado; y IAgentMandate, el registro que registra las concesiones de mandatos, extensiones, revocaciones, ejecuciones y congelaciones de nivel regulador. Los mandatos tienen límites de valor por transacción y acumulativos, hashes de jurisdicción y ventanas de validez, y recordExecution hace cumplir esos límites en el momento en que un token regulado intenta liquidar una transferencia.
El objetivo de RAMS no es reemplazar ERC-8004 o los marcos de cumplimiento de tokens como ERC-3643 o ERC-7943; es estar entre ellos. Identity dice que el agente existe. El cumplimiento del token dice que el principal es elegible para mantener este activo específico. RAMS dice que el agente tiene autoridad de este principal, para este alcance, dentro de estos límites, hasta esta fecha — la parte legalmente exigible que históricamente solo ha existido en PDF y hojas de cálculo de back-office. La CLI de Brickken se está construyendo de manera que el registro de un agente de Brickken hoy y la concesión de un mandato de Brickken mañana se lean como el mismo flujo de trabajo coherente, contra las mismas primitivas en la cadena, para la misma audiencia de cumplimiento.
La decisión arquitectónica más importante en la CLI, y la más difícil de explicar en una frase, es que no hay claves API. La autenticación y el pago se unifican a través de x402, un protocolo de pago por solicitud basado en firmas establecido en una stablecoin. Cada solicitud que la CLI hace contra el backend de Brickken se paga con una firma EIP-712 TransferWithAuthorization producida por la billetera del agente. No hay secreto compartido, ni lista de revocación central, ni ritual de rotación de claves trimestral.
Las implicaciones son mayores que la ergonomía del desarrollador. Cada acción del agente se vuelve criptográficamente atribuible a una billetera específica, en un bloque específico, contra una solicitud específica. Los equipos de compras, finanzas y cumplimiento dejan de perseguir archivos de registro y comienzan a leer la liquidación en la cadena. El comercio de agente a agente, el caso de uso hacia el que todos en esta industria se apresuran, finalmente tiene una primitiva de liquidación que no requiere que ambas partes confíen en el mismo procesador de pagos. Para las instituciones, esta es la capa contable que faltaba para el software autónomo.
Hay un patrón en la CLI que hemos conservado deliberadamente contra la tentación de "hacerlo un solo comando". Por defecto, cada comando de transacción prepara una carga útil sin firmar y la imprime. La firma y la difusión solo ocurren cuando el usuario opta explícitamente con --execute, o encadenando tx prepare, tx sign y tx send manualmente.
Esa separación no es fricción. Es la primitiva de cumplimiento. La brecha entre la intención y la difusión es precisamente donde debe ubicarse la revisión institucional: un director financiero aprobando una acción de tesorería, un oficial de cumplimiento firmando la acuñación de un token, un auditor revisando lo que un agente está a punto de hacer antes de que la cadena se entere. También es donde encaja naturalmente una verificación de mandato al estilo RAMS: la misma carga útil preparada que inspecciona un revisor humano puede validarse contra el alcance, los límites de valor y la jurisdicción del mandato activo antes de que se produzca cualquier firma. La mayoría de las CLI eliminan esa brecha porque parece eficiente. La mantuvimos porque todas las instituciones con las que hemos hablado terminan reconstruyéndola desde cero cuando descubren que falta.
La CLI de Brickken es un ejemplo concreto de una pila de infraestructura de agente, no un reemplazo para el contenido verificable ERC-7007, la computación confidencial, el cumplimiento de tokens ERC-3643 o ERC-7943, o los marcos de tokenización más amplios que las instituciones aún necesitan. Se integra con ellos y hace que la capa de agentes de la pila sea legible para los equipos de ingeniería que necesitan lanzar el próximo trimestre, no el próximo año.
Las instituciones que definirán la siguiente etapa de la innovación son las que tratan su IA autónoma como un activo en el balance general en lugar de una partida en la factura de la nube, y eso significa dar a cada agente una identidad verificable, una reputación registrada, un mandato limitado y una primitiva de liquidación que sobreviva a la auditoría. Hoy en día, eso es un registro de agente brickken, un --execute y un hash de transacción que se puede pegar en un explorador de bloques. Mañana, a medida que ERC-8226 madure, será el mismo flujo de trabajo extendido a través de la concesión de mandato brickken. La pregunta es qué instituciones serán las primeras en escribirlo.
