O estado dos emissores de RWA: a Brickken Research está disponível
Relatório sobre o estado dos emissores da RWA
Adquira agora
Agentes autônomos de IA passaram de demonstrações de pesquisa para sistemas de produção que mantêm contexto, chamam ferramentas, realizam transações e agem em nome de entidades reais. Os modelos são poderosos, as estruturas são maduras e a superfície de integração continua a se expandir. O que ainda falta é a camada institucional subjacente: uma maneira de um agente ter uma identidade que um regulador possa resolver, uma reputação na qual os sistemas subsequentes possam confiar sem um agregador, um mandato que limite o que ele pode fazer e um mecanismo de pagamento que não dependa de uma chave de API estática.
Esta é a camada que temos construído na Brickken, em parte como trabalho de padrões abertos ao lado de outros colaboradores do Ethereum, em parte como ferramenta de produção. Agora está disponível publicamente como Brickken CLI: uma interface de linha de comando para fluxos de trabalho de transações agentivas pagas via x402, construída em torno do padrão ERC-8004 para agentes sem confiança e projetada para ser integrada ao ERC-8226, o padrão de mandato de agente regulamentado que nossa equipe está atualmente coescrevendo como um rascunho de ERC.
Resumo
Quando você observa como os agentes de produção se autenticam nos serviços que consomem, quase nada mudou desde a era do SaaS: chaves de API compartilhadas, faturamento opaco, nenhuma identidade on-chain, nenhuma reputação pública e nenhum mandato formal descrevendo o que o agente está autorizado a fazer e em nome de quem. Os casos de uso jurídico, de saúde, financeiro e de engenharia que justificam a IA autônoma são exatamente os domínios onde o comportamento irresponsável é mais custoso — e aqueles em que os reguladores estão prestes a começar a questionar como um sistema autônomo foi autorizado a realizar uma determinada ação. Um agente que pode gastar, assinar, negociar e integrar sem uma resposta estrutural para essas questões não é uma ferramenta de produtividade; é um passivo contingente. Preencher essa lacuna requer quatro elementos básicos, todos nativos da blockchain, em vez de adicionados posteriormente: identidade, reputação, mandato e pagamento. O cenário de padrões do Ethereum agora possui candidatos confiáveis para cada um deles — ERC-8004 para identidade e reputação de agentes sem confiança, ERC-8226 para delegação de mandato regulamentada, ERC-20 para economia de tokens alinhada ao agente e x402 para liquidação criptográfica por solicitação. Esses quatro elementos primitivos se combinam com o próprio substrato de ativos regulamentados — ERC-3643 e ERC-7943 (uRWA) para conformidade tokenizada — que é onde os mandatos são finalmente aplicados no momento da transferência. O trabalho interessante em 2026 é compô-los em algo que uma equipe de engenharia possa realmente implantar.
O Brickken CLI é nossa tentativa de comprimir essa camada ausente na menor área possível para desenvolvedores e operadores. Não é um mercado, um modelo ou uma carteira; é uma interface simples e opinativa para operações que acredito que todo operador de agente sério eventualmente precisará.
O primeiro é a identidade. O comando `brickken agent register` registra um agente autônomo na blockchain sob o padrão de agentes sem confiança ERC-8004, anexando um endpoint de serviço, uma referência de modelo de IA e uma carteira de controle. O agente deixa de ser apenas uma linha no banco de dados de um provedor SaaS e se torna um ator on-chain de primeira classe com origem verificável.
O segundo aspecto é a reputação. Os comandos `brickken agent feedback give`, `append` e `revoke` registram sinais de feedback no registro de reputação ERC-8004. Não se trata de estrelas do Discord ou pontuações gerenciadas por fornecedores. É um feedback imutável, com registro de data e hora, atribuível, que sistemas subsequentes — sejam outros agentes, contratos inteligentes ou painéis de conformidade — podem ler diretamente sem depender de um agregador intermediário. A confiança passa a ser uma propriedade da rede, e não de um banco de dados privado.
O terceiro aspecto é a economia. Os comandos `brickken create-token`, juntamente com `mint`, `burn`, `transfer`, `transfer-from` e `approve`, implantam e operam um token ERC-20 vinculado à carteira do agente. Esta é a ponte entre os serviços do agente e os mercados de capitais: um instrumento através do qual os detentores podem financiar o desenvolvimento, compartilhar a receita de uso ou exercer governança sobre a evolução do agente. É a diferença entre subsidiar um serviço de IA por meio de capital de risco e precificá-lo por meio de um mercado.
A identidade informa quem é um agente. A reputação informa como ele se comportou. Nenhuma delas informa o que ele está autorizado a fazer, em nome de quem e dentro de quais limites — e essa é precisamente a pergunta que um regulador faz quando um sistema autônomo executa uma transação de valores mobiliários. Essa é a lacuna que nossa equipe na Brickken se propôs a preencher com o ERC-8226, o Padrão de Mandato de Agente Regulamentado (RAMS), atualmente um rascunho de ERC no processo de padronização do Ethereum.
O RAMS define uma camada de delegação de conformidade para agentes de IA que operam em ativos regulamentados tokenizados. Ele especifica como um principal verificado por KYC pode conceder a um agente on-chain uma autoridade com escopo, prazo determinado e limite financeiro — efetivamente, uma procuração on-chain — e como os contratos de tokens regulamentados verificam esse mandato atomicamente dentro de seu gancho de conformidade pré-transferência. Duas interfaces sustentam o design: IComplianceProvider, que qualquer operador de KYC ou atestação pode implementar para atestar a elegibilidade do principal para um determinado escopo; e IAgentMandate, o registro que armazena concessões, extensões, revogações, execuções e congelamentos de mandatos por parte dos reguladores. Os mandatos possuem limites de valor por transação e cumulativos, hashes de jurisdição e janelas de validade, e o recordExecution aplica esses limites no momento em que um token regulamentado tenta liquidar uma transferência.
O objetivo do RAMS não é substituir o ERC-8004 ou estruturas de conformidade de tokens como o ERC-3643 ou o ERC-7943; ele é servir de intermediário. A identidade indica que o agente existe. A conformidade do token indica que o principal está qualificado para deter esse ativo específico. O RAMS indica que o agente tem autoridade deste principal, para este escopo, dentro destes limites, até esta data — a parte legalmente vinculativa que historicamente existia apenas em PDFs e planilhas de back-office. A CLI da Brickken está sendo construída de forma que o registro de um agente Brickken hoje e a concessão de um mandato Brickken amanhã sejam interpretados como o mesmo fluxo de trabalho coerente, utilizando as mesmas primitivas on-chain, para o mesmo público-alvo de conformidade.
A decisão arquitetônica mais importante da CLI, e a mais difícil de explicar em uma frase, é a ausência de chaves de API. Autenticação e pagamento são unificados via x402, um protocolo de pagamento por solicitação baseado em assinatura e liquidado em uma stablecoin. Cada solicitação que a CLI faz ao backend da Brickken é paga com uma assinatura EIP-712 TransferWithAuthorization gerada pela carteira do agente. Não há segredo compartilhado, lista de revogação centralizada ou ritual trimestral de rotação de chaves.
As implicações vão além da ergonomia do desenvolvedor. Cada ação do agente torna-se criptograficamente atribuível a uma carteira específica, em um bloco específico, referente a uma solicitação específica. As equipes de compras, finanças e conformidade param de vasculhar arquivos de log e começam a ler a liquidação on-chain. O comércio agente-para-agente — o caso de uso para o qual todos neste setor estão correndo — finalmente tem uma primitiva de liquidação que não exige que ambas as partes confiem no mesmo processador de pagamentos. Para as instituições, esta é a camada contábil que faltava para o software autônomo.
Há um padrão na CLI que preservamos deliberadamente contra a tentação de "torná-la um único comando". Por padrão, cada comando de transação prepara uma carga útil não assinada e a imprime. A assinatura e a transmissão só acontecem quando o usuário opta explicitamente por isso com --execute ou encadeando tx prepare, tx sign e tx send manualmente.
Essa separação não é atrito. É a primitiva de conformidade. A lacuna entre a intenção e a transmissão é exatamente onde a revisão institucional se encaixa — um diretor financeiro aprovando uma ação de tesouraria, um oficial de conformidade aprovando a emissão de um token, um auditor revisando o que um agente está prestes a fazer antes que a blockchain tome conhecimento disso. É também onde uma verificação de mandato no estilo RAMS se encaixa naturalmente: a mesma carga útil preparada que um revisor humano inspeciona pode ser validada em relação ao escopo, limites de valor e jurisdição do mandato ativo antes que qualquer assinatura seja produzida. A maioria das CLIs elimina essa lacuna porque parece eficiente. Nós a mantivemos porque todas as instituições com as quais conversamos acabam reconstruindo-a do zero quando descobrem que ela está faltando.
A CLI Brickken é um exemplo concreto de uma pilha de infraestrutura de agente — não uma substituição para conteúdo verificável ERC-7007, computação confidencial, conformidade com tokens ERC-3643 ou ERC-7943, ou as estruturas de tokenização mais amplas que as instituições ainda precisam. Ela se integra a eles e torna a camada de agentes da pilha legível para as equipes de engenharia que precisam entregar no próximo trimestre, não no próximo ano.
As instituições que definirão o próximo estágio de inovação são aquelas que tratam sua IA autônoma como um ativo no balanço patrimonial, em vez de um item na fatura da nuvem — e isso significa dar a cada agente uma identidade verificável, uma reputação registrada, um mandato delimitado e uma primitiva de liquidação que sobreviva à auditoria. Hoje, isso se resume a um registro de agentes brickken, um --execute e um hash de transação que você pode colar em um explorador de blocos. Amanhã, à medida que o ERC-8226 amadurecer, será o mesmo fluxo de trabalho estendido por meio da concessão de mandato brickken. A questão é quais instituições serão as primeiras a implementá-lo.
