Há um problema silencioso sentado embaixo de todo esse hype “agente”: continuamos pedindo aos sistemas autônomos para fazer coisas que parecem gastos—reservar um voo, reabastecer o estoque, alugar GPUs, comprar dados, assinar feeds—mas as ferrovias financeiras do mundo ainda assumem que um humano aparecerá para fazer login, aprovar uma cobrança, digitar uma senha ou limpar os recibos depois.
A aposta da Kite é que esse é o verdadeiro gargalo. Não é que os agentes não possam raciocinar. É que eles não podem gastar com segurança em um mundo onde identidade, autoridade e liquidação foram projetadas para humanos que dormem, ficam entediados e notam pop-ups estranhos. Hoje, basicamente, você tem duas escolhas ruins: ou você entrega a um agente credenciais “reais” e aceita um raio de explosão assustador se algo der errado, ou você envolve o agente em tantas aprovações que toda a coisa “autônoma” se transforma em uma performance.
O que torna o Kite interessante é que ele não trata os pagamentos como um recurso adicional. Ele tenta redefinir o que é um “pagador” quando o ator é um software funcionando continuamente em muitos serviços, enquanto o humano deseja resultados—não prompts constantes. Seu whitepaper enquadra isso como um problema de infraestrutura de pilha completa e propõe o que eles chamam de framework SPACE: liquidar em stablecoins, aplicar restrições programáveis, usar autenticação centrada no agente, tornar a auditoria e a conformidade práticas, e suportar micropagamentos sem que tudo colapse sob tráfego de máquina de alta frequência.
Para entender por que eles acham que o modelo de identidade precisa ser reescrito, comece com credenciais. A maioria dos sistemas Web2 e empresariais trata a identidade como “uma conta de usuário”, e a autorização como “um consentimento único mais uma sessão reutilizável.” Isso funciona para pessoas porque as pessoas geralmente se comportam de maneira previsível. Os agentes não. Eles fazem milhares de pequenas chamadas, em explosões, através de múltiplos provedores, e seus modos de falha se parecem mais com violações de servidor ou automação com bugs do que “alguém roubou minha carteira.” O reaproveitamento é o que te mata: uma chave de API ou token OAuth que dura muito tempo se torna uma bomba-relógio se vazar.
A resposta do Kite é dividir a autoridade em três camadas para que nenhuma chave única represente tudo de uma vez: o usuário, o agente e a sessão. A camada do usuário é o proprietário raiz de fundos e permissões. A história do Kite é que essa chave pertence ao armazenamento protegido, como enclaves seguros, e nunca deve ser exposta a agentes, serviços de terceiros ou mesmo à própria plataforma como intermediário. A camada do agente é a autoridade delegada: cada agente recebe sua própria identidade/endereço derivado da carteira do usuário usando derivação hierárquica (eles citam o BIP-32), para que você possa provar “este agente pertence a este usuário” sem dar ao agente a capacidade de voltar à chave do usuário. Então, a camada da sessão é efêmera: chaves de curta duração usadas para uma execução ou tarefa específica, não derivadas das chaves permanentes, então mesmo que algo seja comprometido, o dano é limitado em tempo e escopo.
Isso não é apenas uma boa higiene de chave—é uma filosofia diferente de delegação. Em vez de “confiar que o agente siga a política”, o Kite quer “política aplicada como matemática antes que o valor se mova.” Eles descrevem três primitivos que juntos formam uma cadeia de custódia para cada ação: uma Intenção Permanente (o que um agente é permitido fazer em geral), um Token de Delegação (o agente autorizando uma sessão específica a realizar uma operação específica dentro daquela intenção) e uma Assinatura de Sessão (prova de que a sessão executou esta ação exata agora). A ideia é que cada transação carrega uma prova criptográfica de que o usuário permitiu a categoria de comportamento, o agente delegou uma operação precisa, e a execução aconteceu sob uma chave temporária e limitada.
Eles também enfatizam um ponto prático que as pessoas geralmente perdem: as restrições não são apenas sobre impedir o roubo. Elas são sobre prevenir catástrofes acidentais. Os agentes interpretam mal as instruções. Eles “alucinam”. Eles destroem o contexto. O argumento do Kite é que você precisa de restrições aplicadas no nível do protocolo, então mesmo que um agente tente fazer algo fora dos limites, simplesmente não pode produzir uma cadeia de autorização válida. Eles falam sobre “perda limitada” como um objetivo de design: se você definir limites e prazos, a extração no pior caso se torna quantificável em vez de indefinida.
Uma vez que você aceita que precisa de delegação granular, um segundo problema feio aparece: reconciliação. Se você der a cada agente sua própria carteira e saldo, criou uma hidra contábil—fundos fragmentados, recargas constantes e orçamentos bagunçados. O Kite propõe um modelo de conta unificada: um contrato inteligente on-chain holding fundos compartilhados (eles mencionam USDC ou pyUSD como exemplos), enquanto muitos agentes verificados operam através de chaves de sessão com regras por agente e por sessão. Em termos simples, deve parecer uma tesouraria com um monte de mãos cuidadosamente isoladas, não um monte de tesourarias que você precisa micromanagear.
A economia importa porque a maior parte dos gastos dos agentes não é um único grande checkout. É uma microconsumo em streaming: pague por chamada de API, por inferência, por mil linhas, por minuto de tempo de modelo. Cartões de crédito são uma péssima opção para isso. Taxas e atrasos na liquidação tornam micropagamentos absurdos. A afirmação do Kite é que as stablecoins são o primitivo certo para pagamento por solicitação em escala de máquina, mas mesmo assim, fazer uma transferência on-chain completa para cada mensagem ainda pode ser muito lento ou caro.
Então eles buscam canais de estado: abrem e fecham on-chain, fazem atualizações de alta frequência off-chain, e liquidam o estado final de volta on-chain. Isso não é novo na história do cripto, mas a abordagem do Kite é adaptada para agentes: os agentes frequentemente produzem explosões de interações repetidas com as mesmas contraparte, o que torna os custos de configuração de canal mais fáceis de amortizar, e os serviços que você está pagando são tipicamente online de qualquer forma, o que torna as suposições de permanência menos dolorosas. Eles descrevem diferentes sabores de canais—medição unidirecional, canais bidirecionais para reembolsos/créditos, canais de custódia condicional, canais virtuais para roteamento, e variantes que preservam a privacidade que mantêm fluxos granulares fora da cadeia base.
Eles colocam uma vibração concreta na meta de performance: latência abaixo de 100ms e custo efetivo extremamente baixo quando amortizado, com a piada de que “cada mensagem pode se tornar um pagamento” sem que o sistema se trave. As seções comparativas usam matemática ilustrativa como “um milhão de pagamentos off-chain aproveitando o custo de abertura e fechamento de um canal”, que é basicamente como eles argumentam que o modelo escala para tráfego de máquina.
Sob tudo isso, o Kite se apresenta como uma camada 1 Proof-of-Stake compatível com EVM, construída especificamente para coordenação de agentes em tempo real, além de camadas superiores destinadas a esconder a complexidade da blockchain atrás de APIs amigáveis aos agentes. Eles descrevem uma camada base otimizada para liquidação e canais de stablecoin, uma camada de plataforma que abstrai a mecânica de cripto e liquidação em padrões familiares para desenvolvedores, e uma camada de “confiança programável” que inclui um conceito de Passaporte do Agente e pontes para padrões emergentes de agentes como A2A, MCP e OAuth 2.1.
A interoperabilidade importa porque o mundo dos agentes está se tornando “ilhas de protocolo.” Em paralelo ao plano centrado na cadeia do Kite, a indústria está tentando padronizar como os agentes falam, autorizam e pagam entre plataformas. O Protocolo de Pagamentos de Agentes do Google (AP2) é apresentado como um protocolo aberto para iniciar e transacionar pagamentos liderados por agentes de forma segura, projetado para funcionar junto com A2A e MCP. Depois tem o x402, que tem uma sensação oposta: em vez de uma nova cadeia, tenta fazer os pagamentos parecerem nativos do HTTP, revivendo o aperto de mão HTTP 402 “Pagamento Necessário” para que APIs e conteúdos possam ser monetizados com pagamentos instantâneos em stablecoin, sem contas ou longos fluxos de autenticação. Coinbase e Cloudflare têm promovido o x402 como um padrão aberto por meio do anúncio da Fundação x402, e também há extensões A2A x402 descrevendo como os agentes podem cobrar por serviços e receber pagamentos on-chain usando aquele aperto de mão estilo HTTP. Alguns relatos de terceiros (incluindo a Pesquisa Binance, que deve ser tratada como uma síntese, não como evangelho) descrevem explicitamente o Kite como compatível com x402 e enfatizam a liquidação em stablecoin, além de limites programáveis e custódia.
Se você der um zoom para fora, a pilha começa a parecer estratificada em vez de tudo-ou-nada: AP2 como uma maneira compartilhada de expressar “o que é permitido e quem autorizou”, x402 como um fluxo de solicitação/prova de pagamento HTTP padronizado e, em seguida, camadas de liquidação como Kite como o lugar onde as restrições, a separação de identidade e a finalização são aplicadas em vez de apenas esperadas. Kite se inclina para essa narrativa ao se posicionar como algo que você “adiciona” em vez de algo que você deve “escolher em vez de tudo o mais”, porque os agentes não vão esperar por uma padronização perfeita e os desenvolvedores não vão reescrever sua pilha apenas para suportar uma nova rede de pagamento.
Sobre o design da cadeia, o Kite descreve um L1 PoS compatível com EVM com uma estrutura de ecossistema que inclui “módulos”, que soam como comunidades verticais semi-independentes ou grupos de serviços que ainda se liquefazem de volta à cadeia base. Um documento separado focado no MiCAR torna-se mais concreto, dizendo que a rede é construída usando tecnologia Avalanche Layer-1 e usa um modelo de gás baseado em stablecoin. Também descreve um primitivo de pagamento dedicado com um mempool de faixa rápida e mercado de taxas onde apenas stablecoins autorizadas podem ser usadas tanto para transferência de valor quanto para taxas de transação—basicamente uma tentativa de tornar os custos previsíveis e evitar a volatilidade do token de gás.
Essa escolha de “gás de stablecoin” é mais do que UX. Para os agentes, a volatilidade das taxas pode quebrar a tomada de decisão. Um agente que orça $0,001 por solicitação não pode lidar com um pico de taxas que o transforma em $0,20. A previsibilidade se torna uma propriedade de segurança: se você não pode limitar as taxas, não pode limitar o comportamento. A abordagem do Kite é que as restrições deveriam compilar até a liquidação, incluindo o custo de executar a transação.
Conformidade e auditabilidade se instalam, quer você goste ou não. Assim que o software se torna um gastador, as empresas (e reguladores) querem respostas claras: qual agente fez isso, sob cuja autoridade, dentro de quais limites, e podemos provar que não foi forjado? A cadeia de “três assinaturas” do Kite é basicamente uma maneira de tornar essas respostas criptograficamente recuperáveis em vez de reconstruídas a partir de logs depois do fato. Eles também tentam tornar a identidade legível para humanos descrevendo nomes semelhantes ao ENS e identificadores estilo DID para que os serviços possam verificar a cadeia de autoridade sem precisar de um relacionamento direto com o usuário ou depender de um guardião central.
Sobre o token KITE, seus próprios materiais são incomumente diretos ao afirmar que a utilidade é faseada. Eles descrevem a Fase 1 (em torno da geração do token) como focada nas necessidades de liquidez do módulo (proprietários de módulo bloqueiam KITE em pools de liquidez permanentes pareados com tokens de módulo para ativar módulos), acesso/eligibilidade ao ecossistema (construtores e provedores de serviços de IA que possuem KITE para integrar) e incentivos. A Fase 2 (em torno do mainnet) adiciona coisas como comissões de serviços de IA, staking para funções e votação de governança. Há uma história coerente ali: primeiro, bootstrap os atores do mercado com “pele no jogo”, depois ative segurança e governança mais profundas uma vez que a cadeia esteja ativa. Se você é cético, também pode ler “utilidade da fase 1” como “precisávamos de algo para o token fazer antes que tudo estivesse totalmente pronto”, mas, de qualquer forma, isso reflete a realidade de que mercados de dois lados frequentemente precisam de incentivos antes de precisarem de política.
Eles também explicam a oferta e alocação: um limite de 10 bilhões com distribuição entre ecossistema/comunidade, investidores, módulos e equipe/consultores/contribuintes iniciais, e descrevem um mecanismo de “recompensas contínuas” apelidado de “cofre”, onde você pode reivindicar/vender emissões a qualquer momento, mas fazê-lo encerra permanentemente futuras emissões para aquele endereço. É basicamente uma alavanca comportamental de uma via: liquidez agora custa recompensas contínuas mais tarde, o que tenta amortecer o clássico reflexo de “fazer e despejar”.
O documento MiCAR adiciona mecânicas mais específicas: descreve o KITE como um token utilitário usado para staking, recompensas e pré-requisitos para atividades; delineia papéis como proprietário de módulo, validador e delegador com requisitos de participação explícitos; menciona riscos de penalização ligados não apenas ao comportamento do validador, mas também ao comportamento/performace do módulo escolhido; e descreve rendimentos de staking direcionados e uma mudança pretendida ao longo do tempo de recompensas denominadas em KITE para recompensas mais denominadas em stablecoin. Um ângulo distinto é a ideia de “stake para escolher um módulo”, que empurra a alinhamento para baixo em verticais: validadores e delegadores se associam a módulos específicos, e problemas em nível de módulo podem afetá-los. Se funcionar, os módulos competem não apenas por usuários, mas por segurança e credibilidade alinhadas ao stake. Se não funcionar, pode criar risco correlacionado onde incidentes de módulo cascata em penalidades de validador. De qualquer forma, é um design opinativo, não uma configuração genérica de “cadeia com aplicativos”.
Também vale a pena notar como as stablecoins são tratadas aqui. Neste mundo, as stablecoins não são apenas uma preferência cripto—são uma conveniência para automação. O modelo x402 é explicitamente voltado para stablecoin: um serviço publica um preço via HTTP, o solicitante envia prova de pagamento, e o serviço responde—rápido, scriptável e sem a habitual mecânica de conta e estorno. A pilha do Kite ecoa isso: liquidação nativa de stablecoin, gás de stablecoin para previsibilidade e um plano para capturar valor via mecanismos como a conversão de taxas de stablecoin em KITE antes da distribuição.
Se você quiser um modelo mental mais simples do que “IA encontra cripto”, pense no Kite como um compilador de políticas para gastos. O humano expressa intenção—limites, janelas de tempo, listas brancas, condições. Isso é transformado em restrições criptográficas e contratuais—intenção permanente, tokens de delegação, chaves de sessão, contas unificadas. Então a liquidação acontece de uma maneira que combina com o ritmo do software—pagamentos rápidos, pequenos e repetidos—via canais e execução amigável a stablecoin. Nesse enquadramento, a cadeia não é o produto. O produto é autonomia limitada: autonomia que você pode conceder sem sentir que acabou de entregar a um estranho sua conta bancária inteira.
Ou ainda mais simples: o Kite está tentando fazer com que os humanos deleguem como gerentes, não como apostadores. Gerentes não entregam as chaves da empresa inteira e esperam pelo melhor. Eles estabelecem orçamentos, escopos, caminhos de escalonamento e mecanismos de revisão. No mundo real, esses controles são sociais e legais. O Kite está tentando torná-los criptográficos e aplicáveis em velocidade de máquina.
Ainda há questões abertas reais. As alegações de interoperabilidade são fáceis de dizer e difíceis de realizar—fazer a ponte A2A, MCP, OAuth 2.1, AP2 e x402 significa reconciliar diferentes modelos de ameaça e expectativas de desenvolvedores, e a adoção depende de jogadores fora do controle do Kite. Canais de estado trocam simplicidade on-chain por complexidade operacional e suposições de disputa; o argumento do Kite é que os padrões de tráfego de agentes tornam essa troca válida, mas isso ainda é uma aposta sobre como os agentes se comportam em produção. E as mecânicas do token podem ser engenhosas e ainda assim serem manipuladas; a qualidade do mercado e a demanda real por comércio de agentes importarão tanto quanto a elegância dos incentivos.
Mas a tese central é difícil de descartar: se os agentes vão fazer comércio, eles precisam de trilhos projetados para software, não adaptados de forma desajeitada a partir de fluxos de trabalho humanos. O AP2 sugere que grandes plataformas concordem que padrões abertos para pagamentos liderados por agentes são necessários. O x402 sugere que jogadores de infraestrutura e pagamentos pensam que a própria web deseja uma mão-de-obra de pagamento nativa que máquinas possam executar. A proposta do Kite é que, mesmo com esses padrões, você ainda precisa de um ambiente de execução onde a separação de identidade, restrições programáveis e a economia de micropagamentos são de primeira classe—então “autorização” não é apenas uma promessa em um documento de API, mas algo aplicado quando o dinheiro realmente se move.
Se isso funcionar, a economia de agentes para de ser uma metáfora e começa a parecer um sistema vivo: enxames de agentes especializados negociando, comprando e liquidando em pequenos incrementos, com gastos que são legíveis—quem autorizou, quais limites se aplicaram, o que foi pago, como foi liquidado e como uma contraparte pode verificar a cadeia de permissão sem ter que confiar em uma plataforma centralizada.
Esse é o eixo em que o Kite está tentando girar: não “IA mais cripto”, mas “delegação se torna um protocolo”, para que os agentes possam transacionar sem transformar cada usuário em um gerente de risco em tempo integral.
