A "receita" on-chain de um agente de IA significa normalmente taxas pagas ao contrato inteligente do agente, e não lucro ou clientes pagadores, e os painéis misturam silenciosamente emissões de tokens, transferências de carteiras afiliadas e transações próprias que inflacionam o número. A procura real manifesta-se quando as taxas provenientes de carteiras não relacionadas excedem as emissões do próprio agente; tudo o resto está mais próximo do marketing do que da economia.
Pontos-chave
- A maioria dos painéis de "receita de agentes de IA" contabiliza entradas brutas de contratos, que podem ser dominadas pela própria tesouraria do projeto, carteiras afiliadas ou emissões de tokens recicladas de volta através do agente.
- O wash trading entre bots que partilham um deployer ou tesouraria é uma das maiores fontes de receita falsa e é difícil de detetar sem ferramentas de clustering de carteiras.
- Novos meios de pagamento como o x402 e plataformas de perp como a Hyperliquid tornam possíveis pagamentos legítimos entre agentes, mas a adoção ainda é pequena face aos números de destaque.
- A forma honesta de verificar os ganhos de um agente é subtrair as carteiras da tesouraria e do deployer, comparar as taxas com as emissões e replicar o painel em Dune ou Nansen.
Porque é que a "receita de agentes de IA" parece tão grande nos painéis
Se tem consultado recentemente um painel de cripto, provavelmente viu mosaicos como "receita de agente de IA: 4,2 M$ esta semana" ou gráficos que mostram agentes individuais a ganhar seis dígitos por dia. Os números parecem concretos. Surgem ao lado de tickers de tokens, gráficos de taxas e rácios P/L importados das finanças tradicionais, pelo que a promessa implícita é a de que um agente de IA é uma pequena empresa cujo rendimento pode auditar num explorador de blockchain.
Essa perspetiva é meio certa e meio enganadora. A parte on-chain é genuinamente auditável: cada transação é um evento público, cada contrato tem um endereço e cada taxa tem um pagador e um recetor. O que não é auditável é a definição de "receita" que cada painel escolhe, e é nessa definição que acontece a magia.
A maioria dos painéis extrai dados brutos de entradas para o endereço de recolha de taxas de um agente e chama-lhe receita. Alguns subtraem o gás. Uns poucos subtraem as emissões de tokens. Quase nenhum subtrai pagamentos de carteiras que são obviamente afiliadas ao mesmo projeto, porque isso exige trabalho de clustering que os autores dos painéis preferem evitar. O resultado é que um único agente pode parecer ter um run rate anual de sete dígitos enquanto apenas uma pequena fração desse rendimento vem de clientes independentes.
Os riscos de confiar nos números dos painéis
Tratar a receita não verificada de um agente como facto económico acarreta três riscos concretos, que se manifestam em diferentes partes da stack.
Exposição ao preço do token disfarçada de fundamentos. Quando o pitch deck de um token cita a receita do agente como motivo para comprar, e a receita é sobretudo emissões pagas aos próprios contratos do agente, o "fundamental" é circular. A pressão de venda das emissões está a ser contabilizada como procura do lado da compra por parte dos utilizadores. Se não conseguir distinguir uma da outra, não consegue perceber quando a métrica falha.
Painéis copiados com fontes de dados partilhadas. Muitos dos sites de receita de agentes mais citados usam as mesmas queries Dune ou o mesmo indexador a montante. Quando um erro metodológico inflaciona um agente, inflaciona todo o setor de uma só vez. Os painéis de SocialFi de 2024 tiveram exatamente este problema, e vários agentes no ciclo atual herdam a mesma arquitetura.
Projetos de imitação. Quando uma métrica de receita se torna uma linha de marketing, equipas clonadas lançam agentes estruturalmente idênticos e encaminham silenciosamente pagamentos entre as suas próprias carteiras para reclamar um lugar no top dez. O agente original absorve o dano reputacional quando o volume do clone evapora, e os compradores de retalho não conseguem distinguir facilmente qual é qual.
Nada disto é razão para evitar o setor. É razão para tratar qualquer número isolado de um painel como uma hipótese de partida, e não como uma conclusão.
O que "receita" significa realmente para um agente on-chain
Um agente de AI, no sentido on-chain, é um programa que controla uma ou mais carteiras e assina transações em nome de um modelo, de uma estratégia ou de um utilizador. As estruturas mais comuns hoje são um contrato que recebe taxas, uma multisig de tesouraria detida pela equipa e uma ou mais carteiras de "agente" que a equipa implementa e reforça com fundos.
Dada esta configuração, há quatro definições de receita em uso ativo, e produzem números muito diferentes para o mesmo agente.
Entrada bruta no contrato. Todos os tokens enviados para o endereço do agente que recebe taxas, independentemente de quem os enviou. Este é o valor que a maioria dos dashboards destaca. Inclui os reforços de fundos da própria equipa, emissões encaminhadas através do agente e wash trades entre carteiras afiliadas.
Taxas líquidas do protocolo. Entradas menos saídas, menos tokens devolvidos aos utilizadores, por exemplo, reembolsos ou distribuição de rendimento. É um número mais rigoroso, mas continua vulnerável a autopagamentos se a equipa fizer circular valor pelo agente para fabricar atividade.
Taxas de terceiros. Entradas provenientes de carteiras que não constam de uma lista conhecida de afiliadas, divididas pelo total de entradas. É a definição prática mais limpa e a mais resistente a wash trading, mas exige que o analista construa um grafo de carteiras.
Rendimento de agente tokenizado. Em projetos em que o agente é um cofre que emite um token de recibo, uma estrutura comum nos ecossistemas TAO e VIRTUAL, "receita" por vezes significa o rendimento acumulado pelo token de recibo, e não as taxas ganhas pela estratégia subjacente. Estes rendimentos podem ser subsidiados por emissões e ter muito pouco que ver com clientes pagantes.
Os truques mecânicos que inflacionam o número
Depois de conhecer as definições, os padrões de inflação tornam-se mais fáceis de identificar. Três aparecem repetidamente em dashboards públicos de agentes.
Ciclagem entre carteiras afiliadas. A equipa implementa dez carteiras, cada uma executa o agente contra as outras e paga pequenas taxas a si própria em ciclo. On-chain, isto parece dez utilizadores pagantes. Com agrupamento de carteiras, parece uma única entidade. Algumas equipas vão mais longe e dividem o deployer por várias carteiras de hardware para contornar agrupamentos ingénuos, razão pela qual uma verificação rápida de "quantos pagadores únicos existem?" não é suficiente por si só.
Emissões recicladas como taxas. Um contrato de token emite recompensas para stakers. O staker deposita essas recompensas no agente, o agente implementa capital, e uma fatia do rendimento é encaminhada de volta como uma "taxa" para o contrato do agente. A métrica principal sobe, a tesouraria captura valor, e um investidor de retalho vê um flywheel saudável. Na prática, o agente está a pagar a si próprio com dinheiro que o protocolo acabou de imprimir.
Volume disfarçado de receita. Quando um agente executa uma estratégia de market making ou um bot de futuros perpétuos, a métrica natural é o volume nocional, não as taxas. Alguns dashboards continuam a rotular volume como receita, especialmente quando o volume passa por uma plataforma de perps como a Hyperliquid, onde as taxas são minúsculas em relação ao tamanho. Uma transação com alavancagem de 10x que paga $0,07 em taxas pode aparecer como $70.000 de "atividade", e um eixo de gráfico descuidado permite chamar a isso receita.
Nenhum destes truques exige intenção maliciosa. Muitas equipas acreditam genuinamente que o seu agente tem product-market fit e que os números inflacionados serão substituídos por procura real ao longo do tempo. O problema é que a métrica pública é o que recebe financiamento, é negociado e é classificado, não a previsão interna da equipa.
Os trilhos de pagamento que tornam possíveis agentes legítimos
A infraestrutura para receita honesta de agentes está, finalmente, a melhorar. Duas peças merecem atenção porque alteram o aspeto de um pagamento "real" on-chain.
x402 e pagamentos nativos de máquinas. O padrão x402, assim chamado por causa do código de estado HTTP 402 "payment required", permite que um agente pague programaticamente a outro agente por um serviço, como uma cotação de preço, uma inferência de modelo ou um dado, sem que um humano assine seja o que for. Stablecoins tratam da liquidação. O pagamento é pequeno, denominado em USDC ou USDT, e associado a uma chamada de API específica. Quando vê transações x402 no histórico de taxas de um agente, está a ver uma máquina a pagar literalmente a outra máquina, que é o mais próximo que o setor tem de um sinal limpo de receita.
Hyperliquid e perps on-chain para agentes. A arquitetura de livro de ordens da Hyperliquid permite que agentes coloquem e cancelem ordens em alta frequência com taxas baixas, razão pela qual tantos dashboards de "agentes" em 2024 e 2025 citam volume da Hyperliquid. O risco é que volume não é receita. Uma verificação de bom senso útil é multiplicar o volume da Hyperliquid reportado por um agente pelo escalão médio de taxas da plataforma e ver se essa taxa implícita corresponde aos ganhos reivindicados pelo agente. Se os ganhos reivindicados forem dez vezes maiores do que as taxas implícitas, o resto do número vem de outro lugar.
Ambos os trilhos representam progresso genuíno. Também tornam mais barato falsificar atividade, porque o custo marginal de mais um micropagamento x402 é essencialmente zero. Trate o trilho como uma condição necessária, não suficiente, para receita honesta.
Como verificar por si os ganhos de um agente
Não precisa de ser engenheiro de dados para detetar um dashboard de receita falsa. Um fluxo de trabalho em quatro passos, executável numa tarde, dir-lhe-á se o número em destaque é maioritariamente real.
Passo 1: replique o valor em destaque. Abra o contrato do agente que recebe taxas num explorador de blocos, exporte o histórico de transferências de tokens para CSV e some as entradas no período citado pelo dashboard. Se não conseguir reproduzir o valor em destaque com uma margem de 20%, o dashboard está a usar uma definição pouco óbvia e deve ler cuidadosamente a nota metodológica.
Passo 2: remova a equipa. Retire o endereço do deployer da transação de criação do contrato, depois agrupe-o com a tesouraria, as multisigs públicas da equipa e quaisquer carteiras que tenham recebido fundos desses endereços a poucos saltos de distância. Ferramentas como as etiquetas de carteiras da Nansen, as páginas de entidades da Arkham ou uma pesquisa manual de pistas no Etherscan levam-no quase até ao fim. Calcule as "taxas de terceiros" removendo este agrupamento e veja o que sobra.
Passo 3: compare taxas com emissões. Para qualquer estrutura de agente tokenizado, encontre o calendário de emissões, que normalmente está na documentação do protocolo ou num dashboard público da Dune. Se a receita reivindicada pelo agente for inferior à taxa de emissão anualizada que passa por ele, o protocolo está efetivamente a subsidiar a métrica. Se a receita estiver bem acima das emissões, isso é um sinal muito mais saudável.
Passo 4: crie a sua própria consulta Dune. A Dune permite-lhe escrever SQL sobre eventos de contratos descodificados. Uma consulta inicial razoável junta os eventos de taxas do agente a uma tabela etiquetada de carteiras conhecidas da equipa, soma as entradas líquidas por contraparte e gera uma lista ordenada de pagadores. Se os cinco principais pagadores forem todos afiliados, o número em destaque é maioritariamente circular. Também pode cruzar os dados com as etiquetas de entidades da Nansen para obter uma segunda opinião.
O objetivo não é produzir um número perfeito. O objetivo é delimitar o número real por cima, pelo valor em destaque no dashboard, e por baixo, pelo valor das taxas de terceiros, e decidir se a diferença é plausível.
O que isto significa para o leitor
Se está a avaliar um token de agente de IA como investimento, trate o valor da receita on-chain da mesma forma que trataria o slide de "ARR" de uma startup: útil para ter uma direção, perigoso como resposta final. A diferença é que, neste caso, pode efetivamente auditá-lo.
Há duas heurísticas práticas que vale a pena ter presentes. Primeiro, um agente cujas taxas de terceiros crescem mais rápido do que a sua receita bruta ao longo de um trimestre está genuinamente a conquistar utilizadores pagadores; um agente cuja receita bruta cresce enquanto as taxas de terceiros estagnam está a ser sustentado pela equipa. Segundo, um agente que divulga o seu cluster de carteiras, o seu calendário de emissões e uma metodologia clara para o seu dashboard público é quase sempre mais credível do que um que não o faz, porque o custo da divulgação é baixo quando o número subjacente é real e elevado quando não é.
O setor é jovem, a infraestrutura está a melhorar e há negócios reais a emergir dentro dele. Simplesmente não são aqueles cujos dashboards são mais fáceis de encontrar numa página de pesquisa.
Acompanhe a receita dos agentes de IA com os sinais certos
As métricas dos agentes de IA mudam depressa, e as notícias sobre eles também. Distinguir quais os agentes que efetivamente retêm utilizadores pagadores, em vez daqueles que funcionam à base de emissões e auto-negociações, é um trabalho a tempo inteiro se o fizer manualmente. A Zippfeed destaca notícias sobre agentes de IA com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa ignorar o ruído dos dashboards e focar-se nos agentes cujos números se mantêm firmes sob escrutínio.