33 postagens marcadas com "Web3"

1. Definição e origem do MCP no contexto Web3​

O ** Model Context Protocol (MCP) ** é um padrão aberto que conecta assistentes de IA (como modelos de idiomas grandes) a fontes, ferramentas e ambientes externos de dados. Freqüentemente descrito como uma "porta USB-C para a IA" devido à sua natureza plug-and-play universal, o MCP foi desenvolvido por antropia e introduzido pela primeira vez no final de novembro de 2024. Emergiu como uma solução para quebrar os modelos de IA de isolamento, com preenchimento com segurança com os bloqueios com segurança.

Originalmente, um projeto lateral experimental na Antrópico, o MCP ganhou tração rapidamente. Em meados de 2024, as implementações de referência de código aberto apareceram e, no início de 2025, tornou-se o padrão ** de fato para a integração da IA ​​Agentic **, com os principais laboratórios de IA (Openai, Google DeepMind, Meta AI) adotando-o nativamente. Essa rápida captação foi especialmente notável na comunidade ** Web3 **. Os desenvolvedores de blockchain consideraram o MCP como uma maneira de infundir recursos de IA em aplicações descentralizadas, levando a uma proliferação de conectores MCP construídos na comunidade para dados e serviços na cadeia. De fato, alguns analistas argumentam que o MCP pode cumprir a visão original do Web3 de uma Internet descentralizada e centrada no usuário de uma maneira mais prática do que apenas a blockchain, usando interfaces de linguagem natural para capacitar os usuários.

Em resumo, o MCP não é ** uma blockchain ou token **, mas um protocolo aberto nascido no mundo da IA ​​que foi rapidamente adotado no ecossistema Web3 como uma ponte entre agentes de IA e fontes de dados descentralizadas. Antrópica de origem aberta O padrão (com uma especificação inicial do GitHub e SDKs) e cultivou uma comunidade aberta em torno dela. Essa abordagem orientada à comunidade preparou o terreno para a integração do MCP no Web3, onde agora é visto como infraestrutura fundamental para aplicativos descentralizados com AI-I-iabled.

2. Arquitetura técnica e protocolos principais​

MCP opera em uma arquitetura leve ** cliente -server ** com três funções principais:

• ** Host MCP: ** O aplicativo ou agente da AI, que orquestra solicitações. Pode ser um chatbot (Claude, ChatGPT) ou um aplicativo movido a IA que precisa de dados externos. O host inicia interações, solicitando ferramentas ou informações via MCP.
• ** Cliente MCP: ** Um componente do conector que o host usa para se comunicar com os servidores. O cliente mantém a conexão, gerencia mensagens de solicitação/resposta e pode lidar com vários servidores em paralelo. Por exemplo, uma ferramenta de desenvolvedor como o Cursor ou o VS Code do modo do Code pode atuar como um cliente MCP que preenche o ambiente local de IA com vários servidores MCP.
• ** Servidor MCP: ** Um serviço que expõe alguns dados ou funcionalidades contextuais à IA. Os servidores fornecem ** ferramentas **, ** Recursos ** ou ** Slots ** que a IA pode usar. Na prática, um servidor MCP pode interagir com um banco de dados, um aplicativo em nuvem ou um nó blockchain e apresentar um conjunto padronizado de operações na IA. Cada par cliente-servidor se comunica em seu próprio canal, para que um agente de IA possa tocar em vários servidores simultaneamente para necessidades diferentes.

** Primitivos principais: ** MCP define um conjunto de tipos de mensagens e primitivos padrão que estruturam a interação da ferramenta da AI. Os três primitivos fundamentais são:

• ** Ferramentas: ** Operações ou funções discretas A IA pode invocar em um servidor. Por exemplo, uma ferramenta "SearchDocuments" ou uma ferramenta "eth_call". As ferramentas encapsulam ações como a consulta de uma API, a execução de um cálculo ou chamando uma função de contrato inteligente. O cliente MCP pode solicitar uma lista de ferramentas disponíveis de um servidor e ligue para as necessárias.
• ** RECURSOS: ** De extremidades de dados que a IA pode ler (ou às vezes gravar para) através do servidor. Estes podem ser arquivos, entradas de banco de dados, estado de blockchain (blocos, transações) ou quaisquer dados contextuais. A IA pode listar os recursos e recuperar seu conteúdo por meio de mensagens MCP padrão (por exemplo, Listresources e` ReadResource ', solicitações).
• ** Prompts: ** Modelos de prompt estruturados ou instruções que os servidores podem fornecer para orientar o raciocínio da IA. Por exemplo, um servidor pode fornecer um modelo de formatação ou um prompt de consulta predefinido. A IA pode solicitar uma lista de modelos de prompt e usá -los para manter a consistência na forma como interage com esse servidor.

Sob o capô, as comunicações do MCP são tipicamente baseadas em JSON e seguem um padrão de resposta-resposta semelhante ao RPC (chamada de procedimento remoto). A especificação do protocolo define mensagens como inicializerequest, listTools, calltool, listresources etc., que garantem que qualquer cliente compatível com MCP possa conversar com qualquer servidor MCP de uma maneira uniforme. Essa padronização é o que permite que um agente de IA * descubra * o que pode fazer: Ao se conectar a um novo servidor, ele pode perguntar "Quais ferramentas e dados você oferece?" E então decida dinamicamente como usá -los.

** Modelo de segurança e execução: ** MCP foi projetado com interações seguras e controladas em mente. O modelo de IA em si não executa o código arbitrário; Ele envia intenções de alto nível (através do cliente) para o servidor, que executa a operação real (por exemplo, buscando dados ou chamando uma API) e retorna resultados. Essa separação significa ações sensíveis (como transações de blockchain ou gravações de banco de dados) podem ser sandboxed ou exigir aprovação explícita do usuário. Por exemplo, existem mensagens como ping (para manter as conexões vivas) e até mesmo um` createMessagerequest ', que permite que um servidor MCP solicite à IA do cliente que gere uma sub-resposta, normalmente bloqueada pela confirmação do usuário. Recursos como autenticação, controle de acesso e registro de auditoria estão sendo desenvolvidos ativamente para garantir que o MCP possa ser usado com segurança em ambientes corporativos e descentralizados (mais sobre isso na seção de roteiro).

Em resumo, a arquitetura do MCP depende de um protocolo de mensagem ** padronizado ** (com chamadas de estilo JSON-RPC) que conecta agentes de IA (hosts) a uma matriz flexível de servidores que fornecem ferramentas, dados e ações. Essa arquitetura aberta é ** modelo-agnóstico ** e ** plataforma-agnóstico **-Qualquer agente de IA pode usar o MCP para conversar com qualquer recurso, e qualquer desenvolvedor pode criar um novo servidor MCP para uma fonte de dados sem precisar modificar o código principal da IA. Essa extensibilidade plug-and-play é o que torna o MCP poderoso no Web3: pode-se criar servidores para nós de blockchain, contratos inteligentes, carteiras ou oráculos e que os agentes de IA integrem perfeitamente esses recursos ao lado das APIs do Web2.

3. Use casos e aplicações do MCP no Web3​

O MCP desbloqueia uma ampla gama de casos de uso **, permitindo que aplicativos acionados por IA acessem dados de blockchain e executem ações na cadeia ou fora da cadeia de uma maneira segura e de alto nível. Aqui estão alguns aplicativos e problemas importantes que isso ajuda a resolver no domínio Web3:

-** Análise e consulta de dados na cadeia: ** Os agentes da IA ​​podem consultar o estado de blockchain ao vivo em tempo real para fornecer informações ou acionar ações. Por exemplo, um servidor MCP conectado a um nó Ethereum permite que um IA busque saldos de conta, leia o armazenamento de contratos inteligentes, rastreia transações ou recupere registros de eventos sob demanda. Isso transforma um chatbot ou assistente de codificação em um explorador de blockchain. Os desenvolvedores podem fazer perguntas de assistente de IA como "Qual é a liquidez atual no Pool X Uniswap X?" ou "simular o custo do gás da transação Ethereum" e a IA usará as ferramentas MCP para chamar um nó RPC e obter a resposta da cadeia ao vivo. Isso é muito mais poderoso do que depender dos dados de treinamento da IA ​​ou dos instantâneos estáticos.

• ** Gerenciamento automatizado de portfólio DEFI: ** Combinando ferramentas de acesso e ação de dados, os agentes da IA ​​podem gerenciar portfólios de criptografia ou posições defi. Por exemplo, um ** "AI Vault Optimizer" ** poderia monitorar as posições de um usuário nas fazendas de rendimento e sugerir ou executar automaticamente estratégias de reequilíbrio com base em condições de mercado em tempo real. Da mesma forma, uma IA poderia atuar como um gerente de portfólio ** **, ajustando as alocações entre protocolos quando o risco ou as taxas mudam. O MCP fornece a interface padrão para a IA ler métricas na cadeia (preços, liquidez, índices colaterais) e, em seguida, invocar ferramentas para executar transações (como mover fundos ou trocar ativos), se permitido. Isso pode ajudar os usuários a maximizar o rendimento ou gerenciar riscos 24 horas por dia, 7 dias por semana, de uma maneira que seria difícil de fazer manualmente.
• ** Agentes de usuários movidos a IA para transações: ** Pense em um assistente pessoal de IA que possa lidar com interações blockchain para um usuário. Com o MCP, esse agente pode se integrar às carteiras e DAPPs para executar tarefas por meio de comandos de linguagem natural. Por exemplo, um usuário poderia dizer: "Ai, enviar 0,5 ETH da minha carteira para Alice" ou "Apoie meus tokens no pool de maior tostura". A IA, através do MCP, usaria um servidor de carteira ** ** (segurando a chave privada do usuário) para criar e assinar a transação e um servidor MCP de blockchain para transmiti -lo. Esse cenário transforma interações complexas de linha de comando ou metamask em uma experiência de conversação. É crucial que os servidores Secure Wallet MCP sejam usados ​​aqui, aplicando permissões e confirmações, mas o resultado final está simplificando as transações na cadeia por meio da assistência da IA. -** Assistentes de desenvolvedores e depuração de contratos inteligentes: ** Os desenvolvedores da Web3 podem aproveitar os assistentes de AI baseados em MCP com muito conhecimento de infraestrutura de blockchain. Por exemplo, ** Servidores MCP do ChainStack para EVM e Solana ** Dê uma visibilidade profunda da codificação da AI no ambiente de blockchain do desenvolvedor. Um engenheiro de contrato inteligente usando um assistente de IA (no código VS ou um IDE) pode fazer com que a IA busque o estado atual de um contrato em um Testnet, execute uma simulação de uma transação ou verifique os logs - tudo via MCP chamadas para nós de blockchain local. Isso ajuda a depurar e testar contratos. A IA não está mais codificando "cegamente"; Na verdade, pode verificar como o código se comporta na cadeia em tempo real. Este caso de uso resolve um importante ponto de dor, permitindo que a IA ingerisse continuamente os documentos atualizados (através de um servidor MCP de documentação) e consulte a blockchain diretamente, reduzindo alucinações e tornando as sugestões muito mais precisas.
• ** Coordenação cruzada de protocolo: ** Como o MCP é uma interface unificada, um único agente de IA pode coordenar em vários protocolos e serviços simultaneamente- algo extremamente poderoso na paisagem interconectada do Web3. Imagine um agente comercial autônomo ** que monitora várias plataformas defi de arbitragem. Através do MCP, um agente poderia fazer interface simultaneamente com os mercados de empréstimos da AAVE, uma ponte de cadeia transversal de camada e um serviço de análise MEV (Miner Extrable Value), em toda a interface coerente. A IA poderia, em um "processo de pensamento", reunir dados de liquidez do Ethereum (por meio de um servidor MCP em um nó Ethereum), obter informações sobre preços ou dados do Oracle (através de outro servidor) e até chamar operações de ponte ou troca. Anteriormente, essa coordenação de várias plataformas exigiria bots complexos com código personalizado, mas o MCP fornece uma maneira generalizável de uma IA navegar em todo o ecossistema Web3 como se fosse um big data/pool de recursos. Isso pode permitir casos de uso avançado, como otimização de rendimento de cadeia cruzada ou proteção de liquidação automatizada, onde uma IA move ativos ou garantias entre as cadeias proativamente.
• ** BOTS ADVISORES E APOIO AI: ** Outra categoria são os consultores voltados para o usuário em aplicativos de criptografia. Por exemplo, um ** defi ajuda chatbot ** integrado a uma plataforma como o Uniswap ou o composto poderia usar o MCP para obter informações em tempo real para o usuário. Se um usuário perguntar: "Qual é a melhor maneira de proteger minha posição?", A IA pode buscar taxas atuais, dados de volatilidade e detalhes do portfólio do usuário via MCP e, em seguida, dê uma resposta com reconhecimento de contexto. As plataformas estão explorando ** Assistentes movidos a IA ** embutidos em carteiras ou DAPPs que podem orientar os usuários por meio de transações complexas, explicar riscos e até executar sequências de etapas com aprovação. Esses agentes de IA estão efetivamente sentados no topo de vários serviços da Web3 (Dexes, Pools de Empréstimos, Protocolos de Seguros), usando o MCP para consultar e comandá -los conforme necessário, simplificando assim a experiência do usuário.
• ** Além do Web3- Fluxos de trabalho com vários domínios: ** Embora nosso foco seja Web3, vale a pena observar os casos de uso do MCP se estendem a qualquer domínio em que a IA precise de dados externos. Ele já está sendo usado para conectar IA a coisas como Google Drive, Slack, Github, Figma e muito mais. Na prática, um único agente de IA pode atravessar o Web3 e o Web2: por exemplo, analisar um modelo financeiro do Excel do Google Drive, sugerindo negociações na cadeia com base nessa análise, tudo em um fluxo de trabalho. A flexibilidade do MCP permite a automação de domínios cruzados (por exemplo, "Programe minha reunião se meu voto da DAO for aprovado e envie um e-mail para os resultados") que combina ações blockchain com as ferramentas do dia a dia.

** Problemas resolvidos: ** O problema abrangente do MCP é a ** falta de uma interface unificada para a IA interagir com dados e serviços ao vivo **. Antes do MCP, se você quisesse uma IA para usar um novo serviço, precisava codificar manualmente um plug-in ou integração para a API desse serviço específico, geralmente de maneira ad-hoc. No Web3, isso era especialmente pesado - todo blockchain ou protocolo possui suas próprias interfaces, e nenhuma IA poderia esperar apoiar todos eles. O MCP resolve isso padronizando como a IA descreve o que deseja (o idioma natural mapeado para as chamadas de ferramentas) e como os serviços descrevem o que eles oferecem. Isso reduz drasticamente o trabalho de integração. Por exemplo, em vez de escrever um plug -in personalizado para cada protocolo DEFI, um desenvolvedor pode escrever um servidor MCP para esse protocolo (anotando essencialmente suas funções no idioma natural). Qualquer IA habilitada para MCP (modelos Claude, ChatGPT ou de código aberto) pode utilizá-lo imediatamente. Isso torna a AI ** extensível ** de maneira plug-and-play, como adicionar um novo dispositivo por meio de uma porta universal é mais fácil do que instalar uma nova placa de interface.

Em suma, o MCP no Web3 permite que ** agentes da IA ​​se tornem cidadãos de primeira classe do mundo da blockchain **-consultando, analisando e até transacionando em sistemas descentralizados, todos através de canais seguros e padronizados. Isso abre a porta para Dapps mais autônomos, agentes de usuários mais inteligentes e integração perfeita da inteligência na cadeia e fora da cadeia.

4. Modelo de tokenômica e governança​

Ao contrário dos protocolos típicos do Web3, ** MCP não possui um token ou criptomoeda nativo. Assim, não há tokenômica interna-não é um modelo de emissão de token, staking ou taxa inerente ao uso do MCP. Aplicativos e servidores de IA se comunicam via MCP sem qualquer criptomoeda envolvida; Por exemplo, uma IA chamando uma blockchain via MCP pode pagar taxas de gás pela transação de blockchain, mas o próprio MCP não adiciona taxa de token extra. Esse design reflete a origem do MCP na comunidade de IA: foi introduzido como um padrão técnico para melhorar as interações da AI-Tool, não como um projeto tokenizado.

** Governança ** do MCP é realizado de maneira aberta e orientada pela comunidade. Depois de liberar o MCP como padrão aberto, o antropia sinalizou um compromisso com o desenvolvimento colaborativo. Um amplo comitê de direção ** e grupos de trabalho se formaram para pastorear a evolução do protocolo. Notavelmente, em meados de 2025, grandes partes interessadas como a Microsoft e o Github ingressaram no comitê de direção do MCP ao lado do Antrópico. Isso foi anunciado na Microsoft Build 2025, indicando uma coalizão de players do setor que orientam as decisões de roteiro e padrões do MCP. O comitê e os mantenedores trabalham por meio de um processo de governança aberta: as propostas para alterar ou estender o MCP são normalmente discutidas publicamente (por exemplo, por meio de questões do GitHub e "Sep" - proposta de aprimoramento padrão - diretrizes). Há também um Grupo de Trabalho de Registro MCP ** (com mantenedores de empresas como Block, PulseMCP, Github e Antrópico) que exemplifica a governança multipartidária. No início de 2025, os colaboradores de pelo menos 9 organizações diferentes colaboraram para criar um registro unificado de servidor MCP para descoberta, demonstrando como o desenvolvimento é descentralizado entre os membros da comunidade, em vez de controlado por uma entidade.

Como não há token, ** Incentivos de governança ** confiam nos interesses comuns das partes interessadas (empresas de IA, fornecedores de nuvem, desenvolvedores de blockchain etc.) para melhorar o protocolo para todos. Isso é um tanto análogo à forma como os padrões W3C ou IETF são governados, mas com um processo mais rápido do Github Centric. Por exemplo, a Microsoft e a Antrópica trabalharam juntos para projetar uma especificação de autorização aprimorada para MCP (integrando coisas como OAuth e Single Sign-On), e o GitHub colaborou no Serviço Oficial de Registro MCP para listar servidores disponíveis. Esses aprimoramentos foram contribuídos de volta para a especificação do MCP para benefício de todos.

Vale a pena notar que, embora o próprio MCP não esteja em Alguns pesquisadores e líderes de pensamento no Web3 prevêem o surgimento de ** “MCP Networks” **-Redes essencialmente descentralizadas de servidores e agentes MCP que usam mecanismos de blockchain para descoberta, confiança e recompensas. Nesse cenário, pode-se imaginar um token sendo usado para recompensar aqueles que executam servidores MCP de alta qualidade (semelhantes aos mineiros ou operadores de nó são incentivados). Recursos como ** Classificações de reputação, computação verificável e descoberta de nós ** podem ser facilitados por contratos inteligentes ou uma blockchain, com um comportamento honesto ao token. Isso ainda é conceitual, mas projetos como o NAMDA do MIT (discutidos mais adiante) estão experimentando mecanismos de incentivo baseados em token para redes de agentes de IA usando MCP. Se essas idéias amadurecem, o MCP poderá se cruzar com a tokenômica na cadeia mais diretamente, mas a partir de 2025 ** o padrão MCP do núcleo permanece sem token **.

Em resumo, o "modelo de governança" do MCP é o de um padrão de tecnologia aberta: mantida colaborativamente por uma comunidade e um comitê diretor de especialistas, sem token de governança na cadeia. As decisões são guiadas por mérito técnico e amplo consenso, em vez de votação ponderada por moedas. Isso distingue o MCP de muitos protocolos Web3 - pretende cumprir os ideais da Web3 (descentralização, interoperabilidade, empoderamento do usuário) por meio de software e padrões abertos, ** não através de uma blockchain ou token proprietário **. Nas palavras de uma análise, *“A promessa do Web3 ... pode finalmente ser realizada não através de blockchain e criptomoeda, mas através da linguagem natural e dos agentes da IA” *, posicionando o MCP como um facilitador chave dessa visão. Dito isto, à medida que as redes do MCP crescem, podemos ver modelos híbridos em que os mecanismos de governança ou incentivo baseados em blockchain aumentam o ecossistema-um espaço para observar atentamente.

5. Comunidade e ecossistema​

O ecossistema MCP cresceu explosivamente em pouco tempo, abrangendo desenvolvedores de IA, colaboradores de código aberto, engenheiros da Web3 e grandes empresas de tecnologia. É um esforço vibrante da comunidade, com os principais colaboradores e parcerias **, incluindo:

• ** Antrópico: ** Como criador, o antropal semeou o ecossistema, de origem aberta da especificação MCP e vários servidores de referência (para o Google Drive, Slack, Github, etc.). O Antrópico continua a liderar o desenvolvimento (por exemplo, funcionários como Theodora Chu servem como gerentes de produto do MCP, e a equipe da Anthropic contribui fortemente para especificar atualizações e suporte da comunidade). A abertura da Anthrópica atraiu outros para construir o MCP, em vez de vê-lo como uma ferramenta única.

• ** Os primeiros adotantes (bloco, Apollo, Zed, Replit, Codeium, SourceGraph): ** Nos primeiros meses após a liberação, uma onda de adotantes iniciais implementou o MCP em seus produtos. ** Bloco (anteriormente Square) ** MCP integrado para explorar os sistemas Agentic AI em Fintech-o CTO do Block elogiou o MCP como uma ponte aberta que conecta a IA a aplicativos do mundo real. ** Apollo ** (provavelmente Apollo GraphQL) também integrou o MCP para permitir o acesso da IA ​​aos dados internos. Empresas de ferramentas de desenvolvedor como ** Zed (editor de código) **, ** Replit (nuvem IDE) **, ** Codeium (AI Coding Assistant) ** e ** SourceGraph (pesquisa de código) ** Cada um trabalhou para adicionar suporte ao MCP. Por exemplo, o SourceGraph usa o MCP para que um assistente de codificação de IA possa recuperar o código relevante de um repositório em resposta a uma pergunta, e os agentes do IDE da Replit podem atrair o contexto específico do projeto. Esses primeiros adotantes deram credibilidade e visibilidade do MCP.

• ** Big Tech endosso - OpenAI, Microsoft, Google: ** Em uma virada notável, empresas que, de outra forma, são concorrentes alinhados no MCP. ** O CEO da Openai, Sam Altman, anunciou publicamente ** em março de 2025, que o OpenAI adicionaria o suporte ao MCP em seus produtos (incluindo o aplicativo de desktop da ChatGPT), dizendo*"As pessoas adoram o MCP e estamos entusiasmados em adicionar suporte em nossos produtos"*. Isso significava que os plug -ins de agente do OpenAI e ChatGPT falavam MCP, garantindo a interoperabilidade. Apenas algumas semanas depois, ** CEO do Google Deepmind, Demis Hassabis **, revelou que os próximos modelos e ferramentas de Gemini do Google suportariam o MCP, chamando -o de um bom protocolo e um padrão aberto para a "Era Agentic AI". ** Microsoft ** Não apenas se juntou ao comitê de direção, mas fez uma parceria com a Anthropic para construir um C# SDK oficial para o MCP servir a comunidade de desenvolvedores corporativos. A Unidade Github da Microsoft integrou o MCP no modo ** Github COOPILOT (modo de "copilot laboratórios/agentes" do vs Código) **, permitindo que o Copilot use servidores MCP para coisas como pesquisas de repositório e execução de casos de teste. Além disso, a Microsoft anunciou que o Windows 11 exporia determinadas funções do sistema operacional (como o acesso ao sistema de arquivos) como servidores MCP para que os agentes da IA ​​possam interagir com o sistema operacional com segurança. A colaboração entre o OpenAi, Microsoft, Google e Antrópica-todos reunidos em torno do MCP-é extraordinária e ressalta o ethos da Comunidade-Over-Competition deste padrão.

• ** Comunidade de desenvolvedores da Web3: ** Vários desenvolvedores e startups blockchain adotaram o MCP. Vários servidores MCP orientados pela comunidade ** foram criados para servir casos de uso de blockchain:

• A equipe da ** Alchemy ** (um provedor de infraestrutura de blockchain líder) construiu um servidor ** de alquimia MCP ** que oferece ferramentas de análise de blockchain sob demanda via MCP. Provavelmente, isso permite que uma IA obtenha estatísticas de blockchain (como transações históricas, atividade de endereçamento) através das APIs da Alquimia usando a linguagem natural.

  • Os colaboradores desenvolveram um servidor MCP ** Bitcoin & Lightning Network ** para interagir com os nós do Bitcoin e a rede de pagamento de raios, permitindo que os agentes da IA ​​leiam dados do Bitcoin Block ou até criem faturas de raios por meio de ferramentas padrão.
  • O grupo de mídia e educação criptográfico ** Bankless ** criou um servidor ** Onchain MCP ** focado nas interações financeiras do Web3, possivelmente fornecendo uma interface aos protocolos de defi (enviando transações, consultando posições de defi, etc.) para assistentes de IA.
  • Projetos como ** rollup.codes ** (uma base de conhecimento para a camada Ethereum 2s) fizeram um servidor ** MCP para informações do ecossistema de rollup **, para que uma IA possa responder a perguntas técnicas sobre rollups, consultando este servidor.
  • ** ChainStack **, um provedor de nós blockchain, lançou um conjunto de servidores MCP (cobertos anteriormente) para documentação, dados da cadeia EVM e Solana, comercializando explicitamente como "colocando sua IA em esteróides de blockchain" para construtores Web3.

Além disso, as comunidades focadas no Web3 surgiram em torno do MCP. Por exemplo, ** PulseMCP ** e ** Goose ** são iniciativas comunitárias referenciadas como ajudando a construir o registro do MCP. Também estamos vendo polinização cruzada com estruturas de agentes de IA: os adaptadores integrados da comunidade de Langchain, para que todos os servidores MCP possam ser usados ​​como ferramentas em agentes movidos a Langchain, e as plataformas de IA de código aberto, como abraçar o TGI FACE (Inferência de Geração de Texto), estão explorando a compatibilidade do MCP. O resultado é um rico ecossistema, onde novos servidores MCP são anunciados quase diariamente, servindo de tudo, desde bancos de dados a dispositivos IoT.

• ** Escala de adoção: ** A tração pode ser quantificada até certo ponto. Até fevereiro de 2025 - apenas três meses após o lançamento - mais de 1.000 servidores/conectores MCP ** haviam sido construídos pela comunidade. Esse número só cresceu, indicando milhares de integrações entre os setores. Mike Krieger (diretor de produtos do Antrópico) observou na primavera de 2025 que o MCP havia se tornado um "padrão aberto prosperando com milhares de integrações e crescimento" **. O registro oficial do MCP (lançado em pré -visualização em setembro de 2025) está catalogando servidores disponíveis ao público, facilitando a descoberta de ferramentas; A API aberta do registro permite que qualquer pessoa pesquise, digamos, "Ethereum" ou "noção" e encontre conectores MCP relevantes. Isso reduz a barreira para novos participantes e ainda mais o crescimento de combustíveis.

• ** Parcerias: ** Tocamos em muitas parcerias implícitas (antropia com a Microsoft, etc.). Para destacar mais alguns:

• ** Anthropic & Slack **: Anthropic fez parceria com o Slack para integrar Claude aos dados do Slack via MCP (o Slack possui um servidor MCP oficial, permitindo que a IA recupere mensagens Slack ou Post Alerts).

  • ** Provedores de nuvem **: Amazon (AWS) e Google Cloud trabalharam com antropia para hospedar Claude, e é provável que eles suportem o MCP nesses ambientes (por exemplo, a AWS Bedrock pode permitir que os conectores MCP para dados corporativos). Embora não estejam explicitamente nas citações, essas parcerias em nuvem são importantes para a adoção da empresa.
  • ** Colaborações acadêmicas **: O projeto de pesquisa do MIT e IBM Namda (discutido a seguir) representa uma parceria entre a academia e a indústria para impulsionar os limites do MCP em ambientes descentralizados.
  • ** Github & vs Code **: Parceria para aprimorar a experiência do desenvolvedor - por exemplo, a equipe do VS Code contribuiu ativamente para o MCP (um dos mantenedores do registro é da equipe do Code).
  • ** Inúmeras startups **: Muitas startups de IA (startups de agentes, startups de automação de fluxo de trabalho) estão construindo no MCP em vez de reinventar a roda. Isso inclui as startups emergentes da AI da Web3 que procuram oferecer "IA como DAO" ou agentes econômicos autônomos.

No geral, a comunidade ** MCP está diversificada e em rápida expansão **. Inclui empresas principais de tecnologia (para padrões e ferramentas básicas), especialistas em Web3 (trazendo conhecimentos de blockchain e casos de uso) e desenvolvedores independentes (que frequentemente contribuem com conectores para seus aplicativos ou protocolos favoritos). O ethos é colaborativo. Por exemplo, as preocupações de segurança sobre os servidores MCP de terceiros levaram a discussões e contribuições da comunidade das melhores práticas (por exemplo, contribuintes do StackLok que trabalham em ferramentas de segurança para servidores MCP). A capacidade da comunidade de iterar rapidamente (o MCP viu várias atualizações de especificações em meses, adicionando recursos como respostas de streaming e melhor autenticação) é um testemunho de amplo envolvimento.

No ecossistema Web3 especificamente, o MCP promoveu um mini-ecossistema de projetos ** "AI + Web3" **. Não é apenas um protocolo para usar; Está catalisando novas idéias, como DAOs orientados a IA, governança na cadeia auxiliada pela análise da IA ​​e automação de domínio cruzado (como vincular eventos na cadeia a ações fora da cadeia através da IA). A presença das principais figuras da Web3 - por exemplo, ** Zhivko Todorov, da Limechain , declarando“MCP representa a inevitável integração de IA e blockchain” - mostra que os veteranos da blockchain estão defendendo ativamente. Parcerias entre as empresas de IA e blockchain (como as entre antropia e bloco, ou o Azure Cloud da Microsoft, tornando o MCP fácil de implantar ao lado de seus serviços de blockchain) sugerem um futuro onde ** agentes da IA ​​e contratos inteligentes trabalham de mãos dadas **.

Pode -se dizer que o MCP acendeu a primeira convergência genuína da comunidade de desenvolvedores de IA com a comunidade de desenvolvedores da Web3. Hackathons e Meetups agora apresentam faixas do MCP. Como uma medida concreta da adoção do ecossistema: em meados de 2025, ** OpenAI, Google e antropia-representando coletivamente a maioria dos modelos avançados de IA-todos suportam MCP ** e, por outro lado, as empresas de bloqueio líder*Blockchain. Esse efeito de rede em dois lados é um bom presságio para o MCP se tornar um padrão duradouro.

6. Roteiro e marcos de desenvolvimento​

O desenvolvimento do MCP tem sido acelerado. Aqui, descrevemos os principais marcos principais até agora e o roteiro à frente ** como obtido de fontes oficiais e atualizações da comunidade:

• ** Tarde de 2024- Lançamento inicial: ** ON ** 25 de novembro de 2024 **, Antrópico anunciou oficialmente o MCP e de origem aberta das especificações e SDKs iniciais. Juntamente com a especificação, eles lançaram um punhado de implementações do MCP Server para ferramentas comuns (Google Drive, Slack, Github etc.) e adicionaram suporte no assistente de Claude AI (Claude Desktop App) para se conectar aos servidores MCP locais. Isso marcou o lançamento 1.0 do MCP. As integrações antecipadas de prova de conceito na Anthropic mostraram como Claude poderia usar o MCP para ler arquivos ou consultar um banco de dados SQL na linguagem natural, validando o conceito.
• ** Q1 2025 - Adoção rápida e iteração: ** Nos primeiros meses de 2025, o MCP viu ** adoção generalizada da indústria **. Em ** março de 2025 **, o OpenAI e outros provedores de IA anunciaram suporte (conforme descrito acima). Esse período também viu ** Evolução de especificações **: MCP atualizado antrópico para incluir ** recursos de streaming ** (permitindo que grandes resultados ou fluxos de dados contínuos sejam enviados de forma incremental). Esta atualização foi observada em abril de 2025 com o C# SDK News, indicando que o MCP agora suportava recursos como respostas em tempo real ou integração de feeds em tempo real. A comunidade também criou implementações de referência ** em vários idiomas (Python, JavaScript, etc.) além do SDK do Anthrópico, garantindo suporte à poliglota.
• ** Q2 2025 - Tooling e governança do ecossistema: ** Em ** maio de 2025 **, com a Microsoft e o Github se unindo ao esforço, houve um esforço para formalizar a governança e aumentar a segurança. Na Build 2025, a Microsoft revelou planos para ** Integração do Windows 11 MCP ** e detalhou uma colaboração para melhorar os fluxos de autorização ** no MCP **. Na mesma época, a idéia de um registro ** MCP ** foi apresentada aos servidores Index Disponível (o brainstorming inicial começou em março de 2025, de acordo com o blog de registro). O processo ** "Standards Track" ** (SEP - propostas de aprimoramento padrão) foi estabelecido no GitHub, semelhante ao EIPS do Ethereum ou ao Python's Peps, para gerenciar contribuições de uma maneira ordenada. As chamadas da comunidade e os grupos de trabalho (para segurança, registro, SDKs) começaram a se reunir.
• ** Mid 2025- Expansão de recursos: ** Até meados de 2025, o roteiro priorizou várias melhorias importantes:
  • ** Suporte de tarefas assíncronas e de longa duração: ** Planeja permitir que o MCP lide com operações longas sem bloquear a conexão. Por exemplo, se uma IA acionar um trabalho em nuvem que leva minutos, o protocolo MCP suportaria respostas assíncronas ou reconexão para obter resultados. -** Autenticação e segurança fina: ** Desenvolvendo ** Autorização de grãos finos ** Mecanismos para ações sensíveis. Isso inclui os fluxos OAuth possivelmente integrando, as chaves da API e o Enterprise SSO nos servidores MCP para que o acesso da IA ​​possa ser gerenciado com segurança. Em meados de 2025, os guias e as melhores práticas para a segurança do MCP estavam em andamento, dados os riscos de segurança de permitir que a IA invocasse ferramentas poderosas. O objetivo é que, por exemplo, se uma IA for acessar o banco de dados privado de um usuário via MCP, ele deve seguir um fluxo de autorização seguro (com consentimento do usuário) em vez de apenas um terminal aberto.
• ** Teste de validação e conformidade: ** Reconhecendo a necessidade de confiabilidade, a comunidade priorizou o edifício ** Suites de teste de conformidade ** e ** implementações de referência **. Ao garantir que todos os clientes/servidores do MCP aderem às especificações (através de testes automatizados), eles visavam impedir a fragmentação. Um servidor de referência (provavelmente um exemplo com as melhores práticas para implantação remota e auth) estava no roteiro, assim como um aplicativo de cliente de referência demonstrando o uso completo do MCP com uma IA.
  • ** Suporte de multimodalidade: ** Estendendo o MCP além do texto para suportar modalidades como ** imagem, áudio, dados de vídeo ** no contexto. Por exemplo, uma IA pode solicitar uma imagem de um servidor MCP (digamos, um ativo de design ou um diagrama) ou produzir uma imagem. A discussão da especificação incluiu a adição de suporte para * transmissão e mensagens fundidas * para lidar com grande conteúdo multimídia interativamente. O trabalho inicial no “MCP Streaming” já estava em andamento (para apoiar coisas como feeds de áudio ao vivo ou dados de sensores contínuos para a IA).
  • ** Registro e descoberta central: ** O plano de implementar um serviço central ** MCP ** para a descoberta do servidor foi executado em meados de 2025. Em ** setembro de 2025 **, o registro oficial do MCP foi lançado em pré -visualização. Este registro fornece uma única fonte de verdade ** para servidores MCP disponíveis ao público, permitindo que os clientes encontrem servidores por nome, categoria ou recursos. É essencialmente como uma loja de aplicativos (mas aberta) para ferramentas de IA. O design permite registros públicos (um índice global) e os privados (específicos da empresa), todos interoperáveis ​​por meio de uma API compartilhada. O registro também introduziu um mecanismo de moderação ** para sinalizar ou excluir servidores maliciosos, com um modelo de moderação da comunidade para manter a qualidade.
• ** Tarde de 2025 e além - em direção a redes MCP descentralizadas: ** Embora ainda não sejam itens de roteiro "oficiais", a trajetória aponta para mais ** descentralização e sinergia Web3 **:
• Os pesquisadores estão explorando ativamente como adicionar ** Descoberta descentralizada, reputação e camadas de incentivo ** ao MCP. O conceito de uma rede ** MCP ** (ou "Marketplace of MCP Endpoints") está sendo incubada. Isso pode envolver registros baseados em contratos inteligentes (portanto, nenhum ponto de falha único para listagens de servidores), sistemas de reputação em que servidores/clientes têm identidades na cadeia e participam de bom comportamento e, possivelmente, ** recompensas de token por executar nós MCP confiáveis ​​**.
  • ** Projeto Namda ** no MIT, iniciado em 2024, é uma etapa concreta nessa direção. Até 2025, a NAMDA havia construído uma estrutura de agente distribuída protótipo nas fundações do MCP, incluindo recursos como descoberta dinâmica de nós, balanceamento de carga entre agrupamentos de agentes e um registro descentralizado usando técnicas de blockchain. Eles até têm incentivos experimentais baseados em token e rastreamento de proveniência para colaborações multi-agentes. Os marcos da NAMDA mostram que é viável ter uma rede de agentes MCP atravessando muitas máquinas com coordenação sem confiança. Se os conceitos da NAMDA forem adotados, podemos ver o MCP evoluir para incorporar algumas dessas idéias (possivelmente por meio de extensões opcionais ou protocolos separados em camadas no topo).
  • ** Enterprise Hardening: ** No lado da empresa, no final de 2025, esperamos que o MCP seja integrado às principais ofertas de software corporativo (a inclusão da Microsoft no Windows e o Azure é um exemplo). O roteiro inclui recursos para empresas, como ** Integração SSO para servidores MCP ** e controles de acesso robustos. A disponibilidade geral do registro e dos kits de ferramentas do MCP para implantar o MCP em escala (por exemplo, dentro de uma rede corporativa) é provável até o final de 2025.

Para recapitular alguns teclas ** Marcos de desenvolvimento até agora ** (formato da linha do tempo para maior clareza):

• ** NOV 2024: ** MCP 1.0 Lançado (antropic).
• ** De dezembro de 2024 - janeiro de 2025: ** Comunidade constrói a primeira onda de servidores MCP; Antrópicos libera o Claude Desktop com suporte ao MCP; Pilotos de pequena escala por bloco, Apollo, etc.
• ** Fev 2025: ** mais de 1000 conectores da comunidade MCP alcançados; Workshops antropia de hosts (por exemplo, em uma cúpula de IA, Educação para dirigir).
• ** Mar 2025: ** OpenAI anuncia suporte (ChatGPT Agents SDK).
• ** abril de 2025: ** Google Deepmind anuncia suporte (Gemini apoiará o MCP); A Microsoft libera visualização do C# SDK.
• ** Maio de 2025: ** Comitê de direção expandido (Microsoft/Github); Construa 2025 demos (integração do Windows MCP).
• ** Jun 2025: ** O ChainStack lança servidores Web3 MCP (EVM/Solana) para uso público.
• ** JUL 2025: ** Atualizações da versão do MCP Spec (streaming, melhorias de autenticação); Roteiro oficial publicado no site do MCP.
• ** Set 2025: ** Registro MCP (visualização) lançado; Provavelmente o MCP atinge a disponibilidade geral em mais produtos (Claude para o trabalho, etc.).
• ** final de 2025 (projetado): ** Registry v1.0 Live; guias de melhor prática de segurança liberados; Possivelmente experimentos iniciais com descoberta descentralizada (resultados da NAMDA).

A visão ** adiante ** é que o MCP se torna tão onipresente e invisível quanto HTTP ou JSON - uma camada comum que muitos aplicativos usam sob o capô. Para o Web3, o roteiro sugere uma fusão mais profunda: onde os agentes de IA não apenas usarão o Web3 (blockchains) como fontes ou sumidouros de informação, mas a infraestrutura do Web3 em si pode começar a incorporar agentes de IA (via MCP) como parte de sua operação (por exemplo, um DAO pode executar um MCP-Compatível AI para gerenciar determinados. A ênfase do roteiro em coisas como verificabilidade e autenticação sugere que as interações MCP minimizadas na linha ** ** podem ser uma realidade-imagine os resultados da IA ​​que acompanham provas criptográficas ou um registro na cadeia de quais ferramentas uma IA invocou para propósitos de auditoria. Essas possibilidades embaçam a linha entre as redes de IA e blockchain, e o MCP está no coração dessa convergência.

Em conclusão, o desenvolvimento do MCP é altamente dinâmico. Ele atingiu grandes marcos iniciais (ampla adoção e padronização dentro de um ano de lançamento) e continua a evoluir rapidamente com um roteiro claro enfatizando ** Segurança, Escalabilidade e Descoberta **. Os marcos alcançados e planejados garantem que o MCP permaneça robusto à medida que escala: abordar desafios como tarefas de longa duração, permissões seguras e a pura descoberta de milhares de ferramentas. Esse momento a termo indica que o MCP não é uma especificação estática, mas um padrão em crescimento, provavelmente incorporar mais recursos com sabor Web3 (governança descentralizada de servidores, alinhamento de incentivo) à medida que essas necessidades surgem. A comunidade está pronta para adaptar o MCP a novos casos de uso (IA multimodal, IoT, etc.), enquanto mantém um olho na promessa central: tornar a AI ** mais conectada, com reconhecimento de contexto e capacitação de usuário ** na era da Web3.

7. Comparação com projetos ou protocolos similares Web3​

A mistura exclusiva de IA e conectividade do MCP significa que não há muitos equivalentes diretos de maçãs para maçãs, mas é esclarecedor compará-lo com outros projetos no cruzamento de Web3 e IA ou com objetivos análogos:

• ** SingularityNet (AGI/X) **-*Marketplace de IA descentralizado:*Singularitynet, lançado em 2017 pelo Dr. Ben Goertzel e outros, é um mercado baseado em blockchain para serviços de IA. Ele permite que os desenvolvedores monetizem os algoritmos de IA como serviços e usuários para consumir esses serviços, todos facilitados por um token (Agix) que é usado para pagamentos e governança. Em essência, a SingularityNet está tentando descentralizar o abastecimento de modelos de IA **, hospedando -os em uma rede onde qualquer pessoa pode chamar um serviço de IA em troca de tokens. Isso difere do MCP fundamentalmente. O MCP não hospeda ou monetiza os modelos de IA; Em vez disso, ele fornece uma interface padrão ** para AI (onde quer que esteja em execução) para acessar dados/ferramentas **. Pode -se imaginar usar o MCP para conectar uma IA aos serviços listados no Singularitynet, mas a própria singularitynet se concentra na camada econômica (que fornece um serviço de IA e como eles são pagos). Outra diferença-chave: ** Governança **-SingularityNet tem governança na cadeia (via ** propostas de aprimoramento de singularitynet (SNEPS) ** e votação do Agix Token) para evoluir sua plataforma. A governança do MCP, por outro lado, é fora da cadeia e colaborativa sem um token. Em resumo, o SingularityNet e o MCP se esforçam para um ecossistema de IA mais aberto, mas o SingularityNet é sobre uma rede tokenizada de algoritmos de AI **, enquanto o MCP é sobre um padrão de protocolo ** para a interoperabilidade da AI-tool **. Eles poderiam complementar: por exemplo, uma IA no Singularitynet poderia usar o MCP para buscar dados externos de que precisa. Mas o SingularityNet não tenta padronizar o uso da ferramenta; Ele usa o Blockchain para coordenar os serviços de IA, enquanto o MCP usa padrões de software para permitir que a IA trabalhe com qualquer serviço.
• ** Fetch.ai (FET) **-Plataforma descentralizada baseada em agente:fetch.ai é outro projeto que mistura a IA e o blockchain. Ele lançou seu próprio blockchain de prova de participação e estrutura para a criação de agentes autônomos ** que executam tarefas e interagem em uma rede descentralizada. Na visão de Fetch, milhões de "agentes de software" (representando pessoas, dispositivos ou organizações) podem negociar e trocar valor, usando tokens FET para transações. O Fetch.ai fornece uma estrutura de agente (UAGENTs) e infraestrutura para descoberta e comunicação entre agentes em seu livro. Por exemplo, um agente de busca pode ajudar a otimizar o tráfego em uma cidade interagindo com outros agentes para estacionamento e transporte ou gerenciar um fluxo de trabalho da cadeia de suprimentos autonomamente. Como isso se compara ao MCP? Ambos lidam com o conceito de agentes, mas os agentes da busca. Os agentes do MCP (hosts de IA) são orientados para o modelo (como um LLM) e não estão vinculados a nenhuma rede única; O MCP está contente em operar pela Internet ou dentro de uma configuração de nuvem, sem exigir uma blockchain. O Fetch.ai tenta construir uma nova economia descentralizada de IA desde o início ** (com seu próprio livro para confiança e transações), enquanto o MCP é ** camada-agnóstico **-ele se levanta em redes existentes (pode ser usado sobre interações HTTPs ou até em cima de um blockchin), se necessário), para inabilizar as interações. Pode-se dizer que buscar mais sobre ** agentes econômicos autônomos ** e MCP sobre ** agentes de uso inteligente de ferramentas **. Curiosamente, eles podem se cruzar: um agente autônomo no busca.ai pode usar o MCP para interagir com recursos fora da cadeia ou outras blockchains. Por outro lado, pode-se usar o MCP para criar sistemas multi-agentes que aproveitam diferentes blockchains (não apenas um). Na prática, o MCP teve uma adoção mais rápida porque não exigia sua própria rede - funciona com o Ethereum, Solana, Web2 APIs etc., fora da caixa. A abordagem do Fetch.ai é mais pesada, criando um ecossistema inteiro que os participantes devem ingressar (e adquirir tokens) para usar. Em suma, ** Fetch.ai vs MCP **: Fetch é uma plataformacom seu próprio token/blockchain para agentes de IA, concentrando -se em interoperabilidade e trocas econômicas entre agentes, enquanto o MCP é um protocoloque os agentes da IA ​​(em qualquer ambiente) podem usar para conectar e ferramentas. Seus objetivos se sobrepõem a permitir a automação orientada pela IA, mas lidam com diferentes camadas da pilha e têm filosofias arquitetônicas muito diferentes (ecossistema fechado vs aberto).
• ** ChainLink e oráculos descentralizados **-Conectando blockchains a dados fora da cadeia:ChainLink não é um projeto de IA, mas é altamente relevante como um protocolo Web3 resolvendo um problema complementar: como conectar ** Blockchains ** com dados e computação externos. O ChainLink é uma rede descentralizada de nós (oráculos) que buscam, verificam e fornecem dados fora da cadeia para contratos inteligentes de maneira minimizada. Por exemplo, o ChainLink Oracles fornece feeds de preços aos protocolos de define ou chamam APIs externas em nome de contratos inteligentes por meio de funções do ChainLink. Comparativamente, o MCP conecta os modelos ** AI ** a dados/ferramentas externas (alguns dos quais podem ser blockchains). Pode -se dizer que ** ChainLink traz dados para blockchains, enquanto o MCP traz dados para ai **. Existe um paralelo conceitual: ambos estabelecem uma ponte entre sistemas isolados. O ChainLink se concentra na confiabilidade, descentralização e segurança dos dados alimentados na cadeia (resolvendo o "problema do Oracle" do ponto único de falha). O MCP se concentra na flexibilidade e padronização de como a IA pode acessar dados (resolvendo o "problema de integração" para os agentes da IA). Eles operam em diferentes domínios (contratos inteligentes versus assistentes de IA), mas pode -se comparar servidores MCP com oracles: um servidor MCP para dados de preços pode chamar a mesma APIs de um nó ChainLink. A diferença é o ** consumidor **-No caso do MCP, o consumidor é um assistente de IA ou usuário, não um contrato inteligente determinístico. Além disso, o MCP não fornece inerentemente a confiança que o ChainLink (MCP Servers pode ser centralizado ou administrado pela comunidade, com a confiança gerenciada no nível do aplicativo). No entanto, como mencionado anteriormente, as idéias para descentralizar redes MCP podem emprestar da Oracle Networks-por exemplo, vários servidores MCP podem ser consultados e os resultados foram verificados para garantir que uma IA não seja alimentada com dados ruins, semelhante a como vários nós do ChainLink agregam um preço. Em resumo, ** ChainLink vs MCP **: ChainLink éMiddleware Web3 para blockchains consumirem dados externos, o MCP éMiddleware AI para os modelos consumirem dados externos (que podem incluir dados de blockchain). Eles atendem às necessidades análogas em diferentes reinos e podem até complementar: uma IA usando o MCP pode buscar um feed de dados fornecido pelo ChainLink como um recurso confiável e, inversamente, uma IA poderia servir como fonte de análise que um Oracle do ChainLink traz na cadeia (embora esse último cenário levantasse questões de verificação).
• ** Funções plugins / openiAI chatgpt vs MCP ** -*ABRIGENÇÕES DE INTEGRAÇÃO DE FERRAMENTAS AI:*Embora não sejam projetos Web3, uma comparação rápida é garantida porque os plugins chatGPT e o recurso de chamada de função do OpenAI também conectam a IA a ferramentas externas. Os plug -ins ChatGPT usam uma especificação OpenAPI fornecida por um serviço, e o modelo pode chamar essas APIs seguindo a especificação. As limitações são que é um ecossistema fechado (plugins aprovados pelo OpenAI, executando os servidores do OpenAI) e cada plug-in é uma integração silenciada. O mais recente * "Agents" * do Openai está mais próximo do MCP no conceito, permitindo que os desenvolvedores defina ferramentas/funções que uma IA pode usar, mas inicialmente era específico para o ecossistema do OpenAI. ** Langchain ** também forneceu uma estrutura para fornecer ferramentas LLMS no código. O MCP difere oferecendo um padrão ** aberto, modelo-agnóstico ** para isso. Como uma análise colocou, Langchain criou um padrão voltado para o desenvolvedor (uma interface Python) para ferramentas, enquanto o MCP cria um * padrão * voltado para o modelo *-um agente de IA pode descobrir e usar qualquer ferramenta definida pelo MCP no tempo de execução sem código personalizado. Em termos práticos, o ecossistema de servidores da MCP se tornou maior e mais diversificado do que a loja de plug -in do ChatGPT dentro de meses. E, em vez de cada modelo ter seu próprio formato de plug -in (o OpenAi tinha o deles, outros tinham diferentes), muitos estão coalescendo em torno do MCP. O próprio OpenAI sinalizou o suporte ao MCP, alinhando essencialmente sua abordagem de função com o padrão mais amplo. Portanto, comparando ** plugins OpenAI com MCP **: Os plugins são uma abordagem centralizada e com curadoria, enquanto o MCP é uma abordagem descentralizada e orientada pela comunidade. Em uma mentalidade do Web3, o MCP é mais "código aberto e sem permissão", enquanto os ecossistemas proprietários de plug -in estão mais fechados. Isso torna o MCP análogo ao ethos do Web3, embora não seja um blockchain - ele permite a interoperabilidade e o controle do usuário (você pode executar seu próprio servidor MCP para obter seus dados, em vez de fornecer tudo a um provedor de IA). Essa comparação mostra por que muitos consideram o MCP como tendo mais potencial de longo prazo: não está bloqueado em um fornecedor ou um modelo.
• ** Projeto NAMDA e estruturas de agentes descentralizadas: ** Namda merece uma nota separada porque combina explicitamente o MCP com os conceitos da Web3. Conforme descrito anteriormente, a NAMDA (arquitetura distribuída modular do agente em rede) é uma iniciativa MIT/IBM iniciada em 2024 para criar uma rede escalável e distribuída de agentes de IA ** usando o MCP como camada de comunicação. Ele trata o MCP como o backbone das mensagens (como o MCP usa mensagens do tipo JSON-RPC padrão, se encaixa bem para comunicações inter-agentes) e, em seguida, adiciona camadas para ** descoberta dinâmica, tolerância a falhas e identidades verificáveis ​​** usando técnicas de bloqueio-inspiração. Os agentes da NAMDA podem estar em qualquer lugar (nuvem, dispositivos de borda, etc.), mas um registro descentralizado (um pouco como um DHT ou blockchain) mantém o controle deles e suas capacidades de uma maneira à prova de adulteração. Eles até exploram os agentes para incentivar a cooperação ou o compartilhamento de recursos. Em essência, o NAMDA é um experimento na aparência de um ** "Web3 do MCP" **. Ainda não é um projeto amplamente implantado, mas é um dos "protocolos semelhantes" mais próximos em espírito. Se visualizarmos Namda vs MCP: Namda usa o MCP (por isso não é padrões concorrentes), mas o estende com um protocolo para redes e coordenar vários agentes de maneira minimizada. Pode-se comparar o NAMDA com estruturas como ** Autonolas ou sistemas multi-agentes (MAS) ** que a comunidade criptográfica viu, mas aqueles geralmente não possuíam um componente de IA poderoso ou um protocolo comum. NAMDA + MCP Juntos mostrar como uma rede de agente descentralizada pode funcionar, com o blockchain fornecendo ** Identidade, reputação e possivelmente incentivos de token ** e MCP fornecendo a comunicação e o uso de ferramentas ** **.

Em resumo, ** MCP se destaca ** da maioria dos projetos anteriores do Web3: ele não começou como um projeto de criptografia, mas rapidamente se cruza com o Web3 porque resolve problemas complementares. Projetos como SingularityNet e Fetch.ai pretendiam * descentralizar a computação ou serviços de IA * usando o blockchain; O MCP *padroniza a integração da IA ​​com os Serviços *, que pode melhorar a descentralização, evitando o bloqueio da plataforma. Redes Oracle como o ChainLink resolveu a entrega de dados no blockchain; O MCP resolve a entrega de dados à IA (incluindo dados de blockchain). Se os principais ideais do Web3 forem descentralização, interoperabilidade e empoderamento do usuário, o MCP está atacando a peça de interoperabilidade no reino da IA. Ele está até influenciando esses projetos mais antigos - por exemplo, não há nada que impeça a SingularityNet de disponibilizar seus serviços de IA via servidores MCP ou buscar agentes de usar o MCP para conversar com sistemas externos. Podemos muito bem ver uma convergência em que as redes de IA controladas por token usam o MCP como sua língua franca *, casando-se com a estrutura de incentivo do Web3 com a flexibilidade do MCP.

Finalmente, se considerarmos ** Percepção do mercado **: O MCP é frequentemente apontado como para a IA, o que o Web3 esperava fazer pela Internet - quebre os silos e capacite os usuários. Isso levou alguns ao apelido do MCP informalmente como "Web3 para IA" (mesmo quando nenhum blockchain está envolvido). No entanto, é importante reconhecer que o MCP é um padrão de protocolo, enquanto a maioria dos projetos da Web3 são plataformas de pilha completa com camadas econômicas. Em comparações, o MCP geralmente é uma solução universal mais leve, enquanto os projetos de blockchain são soluções mais pesadas e especializadas. Dependendo do caso de uso, eles podem complementar, em vez de competir estritamente. À medida que o ecossistema amadurece, podemos ver o MCP integrado a muitos projetos da Web3 como um módulo (como o HTTP ou o JSON são onipresentes), e não como um projeto rival.

8. Percepção pública, tração do mercado e cobertura da mídia​

O sentimento público em relação ao MCP tem sido extremamente positivo nas comunidades de IA e Web3, muitas vezes na fronteira com entusiasmado. Muitos vêem isso como um ** divisor de águas ** que chegou em silêncio, mas depois levou a indústria pela tempestade. Vamos quebrar a percepção, tração e narrativas notáveis ​​da mídia:

** Métricas de tração e adoção do mercado: ** Em meados de 2025, o MCP alcançou um nível de adoção raro para um novo protocolo. É apoiado em praticamente todos os principais provedores de modelos de IA (Antrópico, Openai, Google, Meta) e suportado pela Big Tech Infrastructure (Microsoft, Github, AWS etc.), conforme detalhado anteriormente. Somente isso sinaliza para o mercado que o MCP provavelmente está aqui para ficar (semelhante a como o apoio amplo impulsionou o TCP/IP ou HTTP nos primeiros dias da Internet). No lado Web3, a tração *é evidente no comportamento do desenvolvedor *: Hackathons começou a apresentar projetos MCP, e muitas ferramentas de dev blockchain agora mencionam a integração do MCP como um ponto de venda. A estatística de "mais de 1000 conectores em alguns meses" e a citação de "milhares de integrações" de Mike Krieger são frequentemente citadas para ilustrar a rapidez com que o MCP foi pego. Isso sugere fortes efeitos de rede - quanto mais ferramentas disponíveis via MCP, mais útil é, provocando mais adoção (um ciclo de feedback positivo). VCs e analistas observaram que o MCP alcançou em menos de um ano o que as tentativas anteriores de "interoperabilidade da IA" não fizeram ao longo de vários anos, em grande parte devido ao tempo (montando a onda de interesse em agentes da IA) e de código aberto. Na mídia Web3, a tração às vezes é medida em termos de desenvolvedor Mindshare e integração em projetos, e o MCP pontua agora em ambos.

** Percepção pública nas comunidades de IA e Web3: ** Inicialmente, o MCP voou sob o radar quando anunciado pela primeira vez (final de 2024). Mas no início de 2025, à medida que surgiram histórias de sucesso, a percepção mudou para a emoção. Os profissionais da IA ​​viam o MCP como a "peça de quebra -cabeça ausente" para tornar os agentes de IA verdadeiramente úteis além dos exemplos de brinquedos. Os construtores do Web3, por outro lado, o viram como uma ponte para finalmente incorporar a IA em Dapps sem jogar fora a descentralização-uma IA pode usar dados na cadeia sem precisar de um oráculo centralizado, por exemplo. ** Líderes de pensamento ** estão cantando louvores: por exemplo, Jesus Rodriguez (um importante escritor da AI da Web3) escreveu em Coindesk que o MCP pode ser*“Um dos protocolos mais transformadores da era da IA ​​e um ótimo ajuste para as arquiteturas Web3”*. Rares Crisan em um notável blog de capital argumentou que o MCP poderia cumprir a promessa da Web3, onde apenas o blockchain lutou, tornando a Internet mais centrada no usuário e natural para interagir. Essas narrativas enquadram o MCP como revolucionário, mas prático - não apenas hype.

Para ser justo, ** Nem todos os comentários não são críticos **. Alguns desenvolvedores de IA em fóruns como o Reddit apontaram que o MCP "não faz tudo"-é um protocolo de comunicação, não um agente pronta para uso ou um mecanismo de raciocínio. Por exemplo, uma discussão do Reddit intitulada "MCP é uma armadilha sem saída" argumentou que o MCP por si só não gerencia a cognição do agente ou garante a qualidade; Ainda requer um bom design de agentes e controles de segurança. Essa visão sugere que o MCP pode ser exagerado como uma bala de prata. No entanto, essas críticas são mais sobre as expectativas de temperamento do que rejeitar a utilidade do MCP. Eles enfatizam que o MCP resolve a conectividade da ferramenta, mas ainda é necessário criar lógica robusta do agente (ou seja, o MCP não cria magicamente um agente inteligente, ele equipa um com ferramentas). O consenso **, porém, é que o MCP é um grande passo à frente **, mesmo entre vozes cautelosas. Abraçar o blog da comunidade do rosto observou que, embora o MCP não seja um resolver, é um grande facilitador para a IA integrada e com reconhecimento de contexto, e os desenvolvedores estão se unindo por esse motivo.

** Cobertura da mídia: ** MCP recebeu cobertura significativa em toda a mídia tecnológica e mídia de nicho Blockchain:

• ** TechCrunch ** Runou várias histórias. Eles cobriram o conceito inicial ("Antrópico propõe uma nova maneira de conectar dados aos chatbots da IA") em torno do lançamento em 2024. Em 2025, o TechCrunch destacou cada grande momento de adoção: o suporte do OpenAI, o envolvimento do Google, do Microsoft/Github. Esses artigos geralmente enfatizam a unidade da indústria em torno do MCP. Por exemplo, o TechCrunch citou o endosso de Sam Altman e observou a rápida mudança dos padrões rivais para o MCP. Ao fazer isso, eles retrataram o MCP como o padrão emergente semelhante ao que ninguém queria ficar de fora dos protocolos da Internet nos anos 90. Essa cobertura em uma saída de destaque sinalizou para o mundo da tecnologia mais amplo que o MCP é importante e real, não apenas um projeto de código aberto.
• ** Condesk ** e outras publicações criptográficas agarraram -se ao ângulo ** da Web3 **. O artigo de opinião de Coindesk, de Rodriguez (julho de 2025), é frequentemente citado; Ele pintou uma imagem futurista, onde cada blockchain poderia ser um servidor MCP e novas redes MCP podem ser executadas em blockchains. Ele conectou o MCP a conceitos como identidade descentralizada, autenticação e verificabilidade - falando o idioma do público da blockchain e sugerindo que o MCP poderia ser o protocolo que realmente combina com estruturas descentralizadas. O CointeleGraph, Bankless e outros também discutiram o MCP no contexto de “Agentes e Defi da IA” e tópicos semelhantes, geralmente otimistas sobre as possibilidades (por exemplo, Bankless tinham um artigo sobre o uso do MCP para permitir que uma IA gerencie negociações na cadeia e incluiu um instruções para o seu próprio servidor MCP).
• ** Relatórios notáveis ​​de blogs / analistas de VC: ** A notável postagem no blog de capital (julho de 2025) é um exemplo de análise de risco que atrai paralelos entre o MCP e a evolução dos protocolos da Web. Ele essencialmente argumenta que o MCP poderia fazer pelo Web3 o que o HTTP fez pelo Web1 - fornecendo uma nova camada de interface (interface de linguagem natural) que não substitui a infraestrutura subjacente, mas a torna utilizável. Esse tipo de narrativa é atraente e ecoado em painéis e podcasts. Ele posiciona o MCP não como competindo com o Blockchain, mas como a próxima camada de abstração que finalmente permite que os usuários normais (via IA) aproveitem facilmente o blockchain e os serviços da Web.
• ** Comunidade de desenvolvedores Buzz: ** fora dos artigos formais, a ascensão do MCP pode ser avaliada por sua presença no discurso do desenvolvedor - negociações de conferência, canais do YouTube, boletins informativos. Por exemplo, houve posts populares como "MCP: o link que falta para a AI Agentic?" Em sites como Runtime.News e Newsletters (por exemplo, um do pesquisador da IA ​​Nathan Lambert) discutindo experimentos práticos com o MCP e como ele se compara a outras estruturas de uso de ferramentas. O tom geral é a curiosidade e a emoção: os desenvolvedores compartilham demos de conectar a IA à sua automação residencial ou carteira de criptografia com apenas algumas linhas usando servidores MCP, algo que parecia ficção científica há pouco tempo. Essa emoção de base é importante porque mostra que o MCP tem Mindshare além de apenas endossos corporativos.
• ** Perspectiva corporativa: ** Mídia e analistas focados na IA corporativa também observam o MCP como um desenvolvimento importante. Por exemplo, * a nova pilha * cobriu como o suporte antrópico adicionado para servidores MCP remotos em Claude para uso corporativo. O ângulo aqui é que as empresas podem usar o MCP para conectar suas bases e sistemas de conhecimento interno à IA com segurança. Isso também importa para o Web3, pois muitas empresas de blockchain são as próprias empresas e podem aproveitar o MCP internamente (por exemplo, uma troca de criptografia pode usar o MCP para permitir que um IA analise os registros de transações internas para detecção de fraude).

** Citações e reações notáveis: ** Alguns valem a pena destacar como encapsulando a percepção pública:

• • “Assim como o HTTP revolucionou as comunicações da Web, o MCP fornece uma estrutura universal ... substituindo integrações fragmentadas por um único protocolo.” * - CoinCoindesk. Essa comparação com HTTP é poderosa; Ele enquadra o MCP como inovação em nível de infraestrutura.
• • “O MCP se tornou um padrão aberto próspero, com milhares de integrações e crescimento. Os LLMs são mais úteis ao se conectar aos dados que você já tem ...” * - Mike Krieger (Antrópico). Esta é uma confirmação oficial da tração e da proposta de valor central, que tem sido amplamente compartilhada nas mídias sociais.
• • “A promessa do Web3 ... pode finalmente ser realizada ... através da linguagem natural e dos agentes da IA. ... MCP é a coisa mais próxima que vimos de um Web3 real para as massas.” * - Capital notável. Esta declaração ousada ressoa com aqueles frustrados com as lentas melhorias de UX em criptografia; Ele sugere que a IA pode quebrar o código de adoção convencional, abstraindo a complexidade.

** Desafios e ceticismo: ** Embora o entusiasmo seja alto, a mídia também discutiu desafios:

• ** Preocupações de segurança: ** As tomadas como a nova pilha ou os blogs de segurança levantaram que permitir que a IA execute ferramentas pode ser perigosa se não for uma caixa de areia. E se um servidor MCP malicioso tentasse obter uma IA para executar uma ação prejudicial? O blog Limechain alerta explicitamente de * riscos significativos de segurança " * com servidores MCP desenvolvidos pela comunidade (por exemplo, um servidor que lida com as chaves privados deve ser extremamente seguro). Essas preocupações foram ecoadas nas discussões: essencialmente, o MCP expande as capacidades da IA, mas com o poder vem o risco. A resposta da comunidade (guias, mecanismos de autenticação) também foi abordada, geralmente tranquilizando que as mitigações estão sendo construídas. Ainda assim, qualquer uso indevido de destaque do MCP (digamos que uma IA desencadeou uma transferência de criptografia não intencional) afetaria a percepção, então a mídia está atento a essa frente. -** Desempenho e custo: ** Alguns analistas observam que o uso de agentes de IA com ferramentas pode ser mais lento ou mais caro do que chamar uma API diretamente (porque a IA pode precisar de várias etapas de entrada e saída para obter o que precisa). Em contextos de negociação de alta frequência ou execução na cadeia, essa latência pode ser problemática. Por enquanto, eles são vistos como obstáculos técnicos para otimizar (através de um melhor design ou streaming de agentes), em vez de quebradores de negócios.
• ** Gerenciamento de hype: ** Como em qualquer tecnologia de tendência, há um pouco de hype. Algumas vozes alertam para não declarar MCP a solução para tudo. Por exemplo, o artigo do Hugging Face pergunta: "O MCP é uma bala de prata?" e respostas Não - os desenvolvedores ainda precisam lidar com o gerenciamento de contexto, e o MCP funciona melhor em combinação com boas estratégias de solicitação e memória. Tais tomadas equilibradas são saudáveis ​​no discurso.

** Sentimento geral da mídia: ** A narrativa que emerge é em grande parte esperançosa e prospectiva:

• O MCP é visto como uma ferramenta prática que oferece melhorias reais agora (portanto, não vaporware), qual a mídia ressalta citando exemplos de trabalho: Claude Reading Arquivos, copilot usando o MCP no VSCode, uma IA completando uma transação de solana em uma demonstração, etc ..
• Também é retratado como um ponto de partida estratégico para o futuro da IA ​​e da Web3. A mídia geralmente conclui que o MCP ou coisas como será essencial para "IA descentralizada" ou "Web4" ou qualquer termo que se use para a Web da próxima geração. Há uma sensação de que o MCP abriu uma porta e agora a inovação está fluindo - seja os agentes descentralizados ou empresas descentralizados da NAMDA que conectam sistemas herdados à IA, muitas histórias futuras remontam à introdução do MCP.

No mercado, pode -se avaliar a tração pela formação de startups e financiamento em torno do ecossistema MCP. De fato, existem rumores/relatórios de startups com foco em "mercados MCP" ou plataformas MCP gerenciadas recebendo financiamento (escrita notável de capital sobre isso sugere juros de VC). Podemos esperar que a mídia comece a cobri -las tangencialmente - por exemplo, “O startup X usa o MCP para permitir que sua IA gerencie seu portfólio de criptografia - eleva US $ y milhões”.

** Conclusão da percepção: ** No final de 2025, o MCP desfruta de uma reputação como uma tecnologia que habilita a tecnologia. Tem forte defesa de figuras influentes na IA e na criptografia. A narrativa pública evoluiu de *"Aqui está uma ferramenta interessante" *para *"Isso pode ser fundamental para a próxima web" *. Enquanto isso, a cobertura prática confirma que está funcionando e sendo adotada, emprestando credibilidade. Desde que a comunidade continue enfrentando desafios (segurança, governança em escala) e nenhum desastre importante ocorre, é provável que a imagem pública do MCP permaneça positiva ou até se torne icônica como "o protocolo que fez a IA e a Web3 serem agradáveis ​​juntos".

A mídia provavelmente ficará de olho em:

• Histórias de sucesso (por exemplo, se um grande DAO implementa um tesoureiro de IA via MCP ou um governo usa o MCP para sistemas de IA de dados abertos).
• Quaisquer incidentes de segurança (para avaliar o risco).
• A evolução das redes MCP e se algum componente de token ou blockchain entra oficialmente em cena (que seria uma grande notícia em ponte a IA e a criptografia com mais força).

A partir de agora, no entanto, a cobertura pode ser resumida por uma linha de Coindesk: * “A combinação de Web3 e MCP pode ser apenas uma nova base para a IA descentralizada”.

** Referências: **

• Notícias antrópicas: * "Introdução ao protocolo de contexto do modelo", * novembro de 2024
• Blog Limechain: * "O que é MCP e como ele se aplica a blockchains?" * Maio de 2025
• Blog do ChainStack: * "MCP for Web3 Builders: Solana, EVM e Documentação" * Junho de 2025
• Condesk Op-ed: * "O Protocolo dos Agentes: Potencial do MCP da Web3", * Jul 2025
• Capital notável: * "Por que o MCP representa a oportunidade real da Web3", * julho de 2025
• TechCrunch: * "OpenAI adota o padrão de Anthropic ...", * 26 de março de 2025
• TechCrunch: * "Google para abraçar o padrão de Anthropic ...", * 9 de abril de 2025
• TechCrunch: * "Github, Microsoft abraça… (Comitê de Direção MCP)", * 19 de maio de 2025
• Microsoft Dev Blog: * "Official C# SDK for MCP", * abril de 2025
• Blog de rosto abraçando: * "#14: O que é MCP e por que todo mundo está falando sobre isso?" * Mar 2025
• Pesquisa Mescari: * "Fetch.ai Perfil", * 2023
• Média (Nu Fintimes): * "Unveing ​​SingularityNet", * março de 2024

O Protocolo de Pagamentos por Agente (AP2) do Google é um padrão aberto recém-anunciado, projetado para permitir transações seguras e confiáveis iniciadas por agentes de IA em nome dos usuários. Desenvolvido em colaboração com mais de 60 organizações de pagamentos e tecnologia (incluindo grandes redes de pagamento, bancos, fintechs e empresas Web3), o AP2 estabelece uma linguagem comum para pagamentos “agênticos” – ou seja, compras e transações financeiras que um agente autônomo (como um assistente de IA ou um agente baseado em LLM) pode realizar para um usuário. A criação do AP2 é impulsionada por uma mudança fundamental: tradicionalmente, os sistemas de pagamento online assumiam que um humano estava clicando diretamente em “comprar”, mas o surgimento de agentes de IA agindo sob as instruções do usuário quebra essa suposição. O AP2 aborda os desafios resultantes de autorização, autenticidade e responsabilidade no comércio impulsionado por IA, mantendo-se compatível com a infraestrutura de pagamento existente. Este relatório examina a arquitetura técnica do AP2, seu propósito e casos de uso, integrações com agentes de IA e provedores de pagamento, considerações de segurança e conformidade, comparações com protocolos existentes, implicações para sistemas Web3/descentralizados e a adoção/roteiro da indústria.

Arquitetura Técnica: Como o AP2 Funciona​

Em sua essência, o AP2 introduz uma estrutura de transação criptograficamente segura construída sobre credenciais digitais verificáveis (VDCs) – essencialmente objetos de dados assinados e à prova de adulteração que servem como “contratos” digitais do que o usuário autorizou. Na terminologia do AP2, esses contratos são chamados de Mandatos, e eles formam uma cadeia de evidências auditável para cada transação. Existem três tipos principais de mandatos na arquitetura do AP2:

• Mandato de Intenção: Captura as instruções ou condições iniciais do usuário para uma compra, especialmente para cenários “humano-ausente” (onde o agente agirá mais tarde sem o usuário online). Ele define o escopo de autoridade que o usuário concede ao agente – por exemplo, “Comprar ingressos para o show se o preço cair abaixo de $200, até 2 ingressos”. Este mandato é assinado criptograficamente antecipadamente pelo usuário e serve como prova verificável de consentimento dentro de limites específicos.
• Mandato de Carrinho: Representa os detalhes finais da transação que o usuário aprovou, usado em cenários “humano-presente” ou no momento do checkout. Inclui os itens ou serviços exatos, seu preço e outras particularidades da compra. Quando o agente está pronto para concluir a transação (por exemplo, após preencher um carrinho de compras), o comerciante primeiro assina criptograficamente o conteúdo do carrinho (garantindo os detalhes do pedido e o preço), e então o usuário (através de seu dispositivo ou interface do agente) assina para criar um Mandato de Carrinho. Isso garante o que você vê é o que você paga, fixando o pedido final exatamente como apresentado ao usuário.
• Mandato de Pagamento: Uma credencial separada que é enviada à rede de pagamento (por exemplo, rede de cartão ou banco) para sinalizar que um agente de IA está envolvido na transação. O Mandato de Pagamento inclui metadados como se o usuário estava presente ou não durante a autorização e serve como um sinalizador para sistemas de gerenciamento de risco. Ao fornecer aos bancos adquirentes e emissores evidências criptograficamente verificáveis da intenção do usuário, este mandato os ajuda a avaliar o contexto (por exemplo, distinguindo uma compra iniciada por agente de uma fraude típica) e a gerenciar a conformidade ou responsabilidade de acordo.

Todos os mandatos são implementados como credenciais verificáveis assinadas pelas chaves da parte relevante (usuário, comerciante, etc.), gerando uma trilha de auditoria não-repudiável para cada transação liderada por agente. Na prática, o AP2 usa uma arquitetura baseada em funções para proteger informações sensíveis – por exemplo, um agente pode lidar com um Mandato de Intenção sem nunca ver os detalhes brutos de pagamento, que são revelados de forma controlada apenas quando necessário, preservando a privacidade. A cadeia criptográfica de intenção do usuário → compromisso do comerciante → autorização de pagamento estabelece confiança entre todas as partes de que a transação reflete as verdadeiras instruções do usuário e que tanto o agente quanto o comerciante aderiram a essas instruções.

Fluxo de Transação: Para ilustrar como o AP2 funciona de ponta a ponta, considere um cenário de compra simples com um humano no circuito:

1. Solicitação do Usuário: O usuário pede ao seu agente de IA para comprar um item ou serviço específico (por exemplo, “Pedir este par de sapatos no meu tamanho”).
2. Construção do Carrinho: O agente se comunica com os sistemas do comerciante (usando APIs padrão ou através de uma interação agente-para-agente) para montar um carrinho de compras para o item especificado a um determinado preço.
3. Garantia do Comerciante: Antes de apresentar o carrinho ao usuário, o lado do comerciante assina criptograficamente os detalhes do carrinho (item, quantidade, preço, etc.). Esta etapa cria uma oferta assinada pelo comerciante que garante os termos exatos (evitando quaisquer alterações ocultas ou manipulação de preços).
4. Aprovação do Usuário: O agente mostra ao usuário o carrinho finalizado. O usuário confirma a compra, e esta aprovação aciona duas assinaturas criptográficas do lado do usuário: uma no Mandato de Carrinho (para aceitar o carrinho do comerciante como está) e uma no Mandato de Pagamento (para autorizar o pagamento através do provedor de pagamento escolhido). Esses mandatos assinados são então compartilhados com o comerciante e a rede de pagamento, respectivamente.
5. Execução: Munidos do Mandato de Carrinho e do Mandato de Pagamento, o comerciante e o provedor de pagamento prosseguem para executar a transação com segurança. Por exemplo, o comerciante envia a solicitação de pagamento juntamente com a prova de aprovação do usuário para a rede de pagamento (rede de cartão, banco, etc.), que pode verificar o Mandato de Pagamento. O resultado é uma transação de compra concluída com uma trilha de auditoria criptográfica que vincula a intenção do usuário ao pagamento final.

Este fluxo demonstra como o AP2 constrói confiança em cada etapa de uma compra impulsionada por IA. O comerciante tem prova criptográfica do que exatamente o usuário concordou em comprar e a que preço, e o emissor/banco tem prova de que o usuário autorizou esse pagamento, mesmo que um agente de IA tenha facilitado o processo. Em caso de disputas ou erros, os mandatos assinados atuam como evidência clara, ajudando a determinar a responsabilidade (por exemplo, se o agente se desviou das instruções ou se uma cobrança não foi o que o usuário aprovou). Em essência, a arquitetura do AP2 garante que a intenção verificável do usuário – em vez da confiança no comportamento do agente – seja a base da transação, reduzindo grandemente a ambiguidade.

Propósito e Casos de Uso para o AP2​

Por que o AP2 é Necessário: O propósito principal do AP2 é resolver problemas emergentes de confiança e segurança que surgem quando agentes de IA podem gastar dinheiro em nome dos usuários. O Google e seus parceiros identificaram várias questões-chave que a infraestrutura de pagamento atual não consegue responder adequadamente quando um agente autônomo está no circuito:

• Autorização: Como provar que um usuário realmente deu permissão ao agente para fazer uma compra específica? (Em outras palavras, garantir que o agente não está comprando coisas sem o consentimento informado do usuário.)
• Autenticidade: Como um comerciante pode saber que uma solicitação de compra de um agente é genuína e reflete a verdadeira intenção do usuário, em vez de um erro ou alucinação da IA?
• Responsabilidade: Se uma transação fraudulenta ou incorreta ocorrer via um agente, quem é o responsável – o usuário, o comerciante, o provedor de pagamento ou o criador do agente de IA?

Sem uma solução, essas incertezas criam uma “crise de confiança” em torno do comércio liderado por agentes. A missão do AP2 é fornecer essa solução, estabelecendo um protocolo uniforme para transações seguras de agentes. Ao introduzir mandatos padronizados e provas de intenção, o AP2 previne um ecossistema fragmentado, onde cada empresa inventa seus próprios métodos ad-hoc de pagamento por agente. Em vez disso, qualquer agente de IA compatível pode interagir com qualquer comerciante/provedor de pagamento compatível sob um conjunto comum de regras e verificações. Essa consistência não apenas evita a confusão do usuário e do comerciante, mas também oferece às instituições financeiras uma maneira clara de gerenciar o risco para pagamentos iniciados por agentes, em vez de lidar com uma colcha de retalhos de abordagens proprietárias. Em suma, o propósito do AP2 é ser uma camada fundamental de confiança que permite que a “economia de agentes” cresça sem quebrar o ecossistema de pagamentos.

Casos de Uso Pretendidos: Ao resolver os problemas acima, o AP2 abre as portas para novas experiências de comércio e casos de uso que vão além do que é possível com um humano clicando manualmente nas compras. Alguns exemplos de comércio habilitado por agente que o AP2 suporta incluem:

• Compras Mais Inteligentes: Um cliente pode instruir seu agente: “Quero esta jaqueta de inverno em verde, e estou disposto a pagar até 20% acima do preço atual por ela”. Munido de um Mandato de Intenção que codifica essas condições, o agente monitorará continuamente sites de varejistas ou bancos de dados. No momento em que a jaqueta estiver disponível em verde (e dentro do limite de preço), o agente executa automaticamente uma compra com uma transação segura e assinada – capturando uma venda que de outra forma teria sido perdida. Toda a interação, desde a solicitação inicial do usuário até o checkout automatizado, é governada pelos mandatos do AP2, garantindo que o agente compre exatamente o que foi autorizado.
• Ofertas Personalizadas: Um usuário diz ao seu agente que está procurando um produto específico (digamos, uma nova bicicleta) de um determinado comerciante para uma próxima viagem. O agente pode compartilhar esse interesse (dentro dos limites de um Mandato de Intenção) com o agente de IA do próprio comerciante, incluindo contexto relevante como a data da viagem. O agente do comerciante, conhecendo a intenção e o contexto do usuário, poderia responder com um pacote personalizado ou desconto – por exemplo, “bicicleta + capacete + bagageiro com 15% de desconto, disponível pelas próximas 48 horas”. Usando o AP2, o agente do usuário pode aceitar e concluir esta oferta personalizada com segurança, transformando uma simples consulta em uma venda mais valiosa para o comerciante.
• Tarefas Coordenadas: Um usuário planejando uma tarefa complexa (por exemplo, uma viagem de fim de semana) a delega inteiramente: “Reserve-me um voo e hotel para estas datas com um orçamento total de $700”. O agente pode interagir com agentes de vários provedores de serviços – companhias aéreas, hotéis, plataformas de viagem – para encontrar uma combinação que se ajuste ao orçamento. Uma vez identificado um pacote de voo-hotel adequado, o agente usa o AP2 para executar múltiplas reservas de uma só vez, cada uma criptograficamente assinada (por exemplo, emitindo Mandatos de Carrinho separados para a companhia aérea e o hotel, ambos autorizados sob o Mandato de Intenção do usuário). O AP2 garante que todas as partes desta transação coordenada ocorram conforme aprovado, e até permite a execução simultânea para que passagens e reservas sejam feitas juntas sem risco de uma parte falhar no meio do caminho.

Esses cenários ilustram apenas alguns dos casos de uso pretendidos do AP2. De forma mais ampla, o design flexível do AP2 suporta tanto fluxos de e-commerce convencionais quanto modelos de comércio totalmente novos. Por exemplo, o AP2 pode facilitar serviços semelhantes a assinaturas (um agente mantém você abastecido com itens essenciais comprando quando as condições são atendidas), compras orientadas por eventos (comprar ingressos ou itens no instante em que um evento acionador ocorre), negociações de agentes em grupo (agentes de múltiplos usuários agrupando mandatos para negociar um acordo em grupo) e muitos outros padrões emergentes. Em todos os casos, o fio condutor é que o AP2 fornece a estrutura de confiança – autorização clara do usuário e auditabilidade criptográfica – que permite que essas transações impulsionadas por agentes ocorram com segurança. Ao lidar com a camada de confiança e verificação, o AP2 permite que desenvolvedores e empresas se concentrem em inovar novas experiências de comércio de IA sem reinventar a segurança de pagamentos do zero.

Integração com Agentes, LLMs e Provedores de Pagamento​

O AP2 é explicitamente projetado para se integrar perfeitamente com frameworks de agentes de IA e com sistemas de pagamento existentes, atuando como uma ponte entre os dois. O Google posicionou o AP2 como uma extensão de seus padrões de protocolo Agent2Agent (A2A) e Model Context Protocol (MCP). Em outras palavras, se o A2A fornece uma linguagem genérica para agentes se comunicarem tarefas e o MCP padroniza como os modelos de IA incorporam contexto/ferramentas, então o AP2 adiciona uma camada de transações por cima para o comércio. Os protocolos são complementares: o A2A lida com a comunicação agente-para-agente (permitindo, por exemplo, que um agente de compras converse com o agente de um comerciante), enquanto o AP2 lida com a autorização de pagamento agente-para-comerciante dentro dessas interações. Como o AP2 é aberto e não proprietário, ele é destinado a ser agnóstico em relação a frameworks: os desenvolvedores podem usá-lo com o próprio Agent Development Kit (ADK) do Google ou qualquer biblioteca de agentes de IA, e da mesma forma, pode funcionar com vários modelos de IA, incluindo LLMs. Um agente baseado em LLM, por exemplo, poderia usar o AP2 gerando e trocando os payloads de mandato necessários (guiado pela especificação AP2) em vez de apenas texto livre. Ao impor um protocolo estruturado, o AP2 ajuda a transformar a intenção de alto nível de um agente de IA (que pode vir do raciocínio de um LLM) em transações concretas e seguras.

No lado dos pagamentos, o AP2 foi construído em conjunto com provedores de pagamento e padrões tradicionais, em vez de ser um sistema de substituição total. O protocolo é agnóstico em relação ao método de pagamento, o que significa que pode suportar uma variedade de trilhos de pagamento – desde redes de cartão de crédito/débito até transferências bancárias e carteiras digitais – como o método subjacente para movimentar fundos. Em sua versão inicial, o AP2 enfatiza a compatibilidade com pagamentos por cartão, já que são os mais comuns no comércio online. O Mandato de Pagamento do AP2 é projetado para se encaixar no fluxo de processamento de cartão existente: ele fornece dados adicionais à rede de pagamento (por exemplo, Visa, Mastercard, Amex) e ao banco emissor de que um agente de IA está envolvido e se o usuário estava presente, complementando assim as verificações existentes de detecção de fraude e autorização. Essencialmente, o AP2 não processa o pagamento em si; ele aumenta a solicitação de pagamento com prova criptográfica da intenção do usuário. Isso permite que os provedores de pagamento tratem as transações iniciadas por agentes com a cautela ou velocidade apropriadas (por exemplo, um emissor pode aprovar uma compra de aparência incomum se vir um mandato AP2 válido provando que o usuário a pré-aprovou). Notavelmente, o Google e seus parceiros planejam evoluir o AP2 para suportar também métodos de pagamento “push” – como transferências bancárias em tempo real (como os sistemas UPI da Índia ou PIX do Brasil) – e outros tipos emergentes de pagamento digital. Isso indica que a integração do AP2 se expandirá além dos cartões, alinhando-se às tendências de pagamento modernas em todo o mundo.

Para comerciantes e processadores de pagamento, integrar o AP2 significaria suportar as mensagens de protocolo adicionais (mandatos) e verificar assinaturas. Muitas grandes plataformas de pagamento já estão envolvidas na formação do AP2, então podemos esperar que elas construam suporte para ele. Por exemplo, empresas como Adyen, Worldpay, Paypal, Stripe (não explicitamente nomeadas no blog, mas provavelmente interessadas) e outras poderiam incorporar o AP2 em suas APIs de checkout ou SDKs, permitindo que um agente inicie um pagamento de forma padronizada. Como o AP2 é uma especificação aberta no GitHub com implementações de referência, provedores de pagamento e plataformas de tecnologia podem começar a experimentá-lo imediatamente. O Google também mencionou um AI Agent Marketplace onde agentes de terceiros podem ser listados – espera-se que esses agentes suportem o AP2 para quaisquer capacidades transacionais. Na prática, uma empresa que constrói um assistente de vendas de IA ou um agente de compras pode listá-lo neste marketplace, e graças ao AP2, esse agente pode realizar compras ou pedidos de forma confiável.

Finalmente, a história de integração do AP2 se beneficia de seu amplo apoio da indústria. Ao co-desenvolver o protocolo com grandes instituições financeiras e empresas de tecnologia, o Google garantiu que o AP2 se alinha com as regras e requisitos de conformidade existentes na indústria. A colaboração com redes de pagamento (por exemplo, Mastercard, UnionPay), emissores (por exemplo, American Express), fintechs (por exemplo, Revolut, Paypal), players de e-commerce (por exemplo, Etsy) e até provedores de identidade/segurança (por exemplo, Okta, Cloudflare) sugere que o AP2 está sendo projetado para se encaixar em sistemas do mundo real com atrito mínimo. Esses stakeholders trazem experiência em áreas como KYC (regulamentações Conheça Seu Cliente), prevenção de fraude e privacidade de dados, ajudando o AP2 a atender a essas necessidades desde o início. Em resumo, o AP2 é construído para ser amigo do agente e amigo do provedor de pagamento: ele estende os protocolos existentes de agentes de IA para lidar com transações, e se sobrepõe às redes de pagamento existentes para utilizar sua infraestrutura, adicionando as garantias de confiança necessárias.

Considerações de Segurança, Conformidade e Interoperabilidade​

Segurança e confiança estão no cerne do design do AP2. O uso de criptografia pelo protocolo (assinaturas digitais em mandatos) garante que cada ação crítica em uma transação agêntica seja verificável e rastreável. Essa não-repudiação é crucial: nem o usuário nem o comerciante podem negar posteriormente o que foi autorizado e acordado, já que os mandatos servem como registros seguros. Um benefício direto é na prevenção de fraudes e resolução de disputas – com o AP2, se um agente malicioso ou com bugs tentar uma compra não autorizada, a falta de um mandato válido assinado pelo usuário seria evidente, e a transação pode ser recusada ou revertida. Inversamente, se um usuário alegar “Eu nunca aprovei esta compra”, mas um Mandato de Carrinho existir com sua assinatura criptográfica, o comerciante e o emissor têm fortes evidências para apoiar a cobrança. Essa clareza de responsabilidade responde a uma grande preocupação de conformidade para a indústria de pagamentos.

Autorização e Privacidade: O AP2 impõe uma etapa (ou etapas) de autorização explícita do usuário para transações lideradas por agentes, o que se alinha às tendências regulatórias como a autenticação forte do cliente. O princípio de Controle do Usuário incorporado ao AP2 significa que um agente não pode gastar fundos a menos que o usuário (ou alguém delegado pelo usuário) tenha fornecido uma instrução verificável para fazê-lo. Mesmo em cenários totalmente autônomos, o usuário predefine as regras por meio de um Mandato de Intenção. Essa abordagem pode ser vista como análoga a conceder uma procuração ao agente para transações específicas, mas de forma digitalmente assinada e granular. Do ponto de vista da privacidade, o AP2 é cuidadoso com o compartilhamento de dados: o protocolo usa uma arquitetura de dados baseada em funções para garantir que informações sensíveis (como credenciais de pagamento ou detalhes pessoais) sejam compartilhadas apenas com as partes que absolutamente precisam delas. Por exemplo, um agente pode enviar um Mandato de Carrinho a um comerciante contendo informações de item e preço, mas o número real do cartão do usuário pode ser compartilhado apenas através do Mandato de Pagamento com o processador de pagamento, não com o agente ou comerciante. Isso minimiza a exposição desnecessária de dados, auxiliando na conformidade com as leis de privacidade e as regras PCI-DSS para o tratamento de dados de pagamento.

Conformidade e Padrões: Como o AP2 foi desenvolvido com a contribuição de entidades financeiras estabelecidas, ele foi projetado para atender ou complementar os padrões de conformidade existentes em pagamentos. O protocolo não ignora os fluxos usuais de autorização de pagamento – em vez disso, ele os aumenta com evidências e sinalizadores adicionais. Isso significa que as transações AP2 ainda podem aproveitar sistemas de detecção de fraude, verificações 3-D Secure ou quaisquer verificações regulatórias exigidas, com os mandatos do AP2 atuando como fatores de autenticação extras ou pistas de contexto. Por exemplo, um banco poderia tratar um Mandato de Pagamento como a assinatura digital de um cliente em uma transação, potencialmente simplificando a conformidade com os requisitos de consentimento do usuário. Além disso, os designers do AP2 mencionam explicitamente o trabalho “em conjunto com as regras e padrões da indústria”. Podemos inferir que, à medida que o AP2 evolui, ele pode ser levado a órgãos de padronização formais (como W3C, EMVCo ou ISO) para garantir que se alinhe aos padrões financeiros globais. O Google declarou compromisso com uma evolução aberta e colaborativa do AP2, possivelmente através de organizações de padronização. Esse processo aberto ajudará a resolver quaisquer preocupações regulatórias e a alcançar ampla aceitação, semelhante a como os padrões de pagamento anteriores (cartões com chip EMV, 3-D Secure, etc.) passaram por colaboração em toda a indústria.

Interoperabilidade: Evitar a fragmentação é um objetivo chave do AP2. Para isso, o protocolo é publicado abertamente e disponibilizado para qualquer pessoa implementar ou integrar. Não está vinculado aos serviços do Google Cloud – na verdade, o AP2 é código aberto (licença Apache-2) e a especificação, além do código de referência, está em um repositório público do GitHub. Isso incentiva a interoperabilidade porque vários fornecedores podem adotar o AP2 e ainda ter seus sistemas funcionando juntos. Já, o princípio da interoperabilidade é destacado: o AP2 é uma extensão de protocolos abertos existentes (A2A, MCP) e não é proprietário, o que significa que ele promove um ecossistema competitivo de implementações, em vez de uma solução de um único fornecedor. Em termos práticos, um agente de IA construído pela Empresa A poderia iniciar uma transação com um sistema de comerciante da Empresa B se ambos seguirem o AP2 – nenhum dos lados está preso a uma única plataforma.

Uma possível preocupação é garantir a adoção consistente: se alguns grandes players escolhessem um protocolo diferente ou uma abordagem fechada, a fragmentação ainda poderia ocorrer. No entanto, dada a ampla coalizão por trás do AP2, ele parece pronto para se tornar um padrão de fato. A inclusão de muitas empresas focadas em identidade e segurança (por exemplo, Okta, Cloudflare, Ping Identity) no ecossistema do AP2 Figura: Mais de 60 empresas de finanças, tecnologia e cripto estão colaborando no AP2 (lista parcial de parceiros). sugere que a interoperabilidade e a segurança estão sendo abordadas em conjunto. Esses parceiros podem ajudar a integrar o AP2 em fluxos de trabalho de verificação de identidade e ferramentas de prevenção de fraude, garantindo que uma transação AP2 possa ser confiável em todos os sistemas.

Do ponto de vista tecnológico, o uso de técnicas criptográficas amplamente aceitas pelo AP2 (provavelmente credenciais verificáveis baseadas em JSON-LD ou JWT, assinaturas de chave pública, etc.) o torna compatível com a infraestrutura de segurança existente. As organizações podem usar sua PKI (Infraestrutura de Chave Pública) existente para gerenciar chaves para assinar mandatos. O AP2 também parece antecipar a integração com sistemas de identidade descentralizada: o Google menciona que o AP2 cria oportunidades para inovar em áreas como identidade descentralizada para autorização de agentes. Isso significa que, no futuro, o AP2 poderia alavancar padrões DID (Identificador Descentralizado) ou verificação de identificador descentralizado para identificar agentes e usuários de forma confiável. Tal abordagem aprimoraria ainda mais a interoperabilidade, não dependendo de nenhum provedor de identidade único. Em resumo, o AP2 enfatiza a segurança através da criptografia e da responsabilidade clara, visa estar pronto para a conformidade por design e promove a interoperabilidade através de sua natureza de padrão aberto e amplo suporte da indústria.

Comparação com Protocolos Existentes​

O AP2 é um protocolo inovador que aborda uma lacuna que os frameworks de pagamento e agentes existentes não cobriram: permitir que agentes autônomos realizem pagamentos de maneira segura e padronizada. Em termos de protocolos de comunicação de agentes, o AP2 se baseia em trabalhos anteriores como o protocolo Agent2Agent (A2A). O A2A (código aberto no início de 2025) permite que diferentes agentes de IA conversem entre si, independentemente de seus frameworks subjacentes. No entanto, o A2A por si só não define como os agentes devem conduzir transações ou pagamentos – é mais sobre negociação de tarefas e troca de dados. O AP2 estende esse cenário adicionando uma camada de transação que qualquer agente pode usar quando uma conversa leva a uma compra. Em essência, o AP2 pode ser visto como complementar ao A2A e ao MCP, em vez de sobreposto: o A2A cobre os aspectos de comunicação e colaboração, o MCP cobre o uso de ferramentas/APIs externas, e o AP2 cobre pagamentos e comércio. Juntos, eles formam uma pilha de padrões para uma futura “economia de agentes”. Essa abordagem modular é um tanto análoga aos protocolos de internet: por exemplo, HTTP para comunicação de dados e SSL/TLS para segurança – aqui o A2A pode ser como o HTTP dos agentes, e o AP2 a camada transacional segura por cima para o comércio.

Ao comparar o AP2 com protocolos e padrões de pagamento tradicionais, existem paralelos e diferenças. Pagamentos online tradicionais (checkouts de cartão de crédito, transações PayPal, etc.) tipicamente envolvem protocolos como HTTPS para transmissão segura, e padrões como PCI DSS para lidar com dados de cartão, além de possivelmente 3-D Secure para autenticação adicional do usuário. Estes assumem um fluxo impulsionado pelo usuário (o usuário clica e talvez insere um código único). O AP2, por outro lado, introduz uma maneira para um terceiro (o agente) participar do fluxo sem comprometer a segurança. Poderíamos comparar o conceito de mandato do AP2 a uma extensão da autoridade delegada no estilo OAuth, mas aplicada a pagamentos. No OAuth, um usuário pode conceder a um aplicativo acesso limitado a uma conta via tokens; similarmente no AP2, um usuário concede a um agente autoridade para gastar sob certas condições via mandatos. A principal diferença é que os “tokens” do AP2 (mandatos) são instruções específicas e assinadas para transações financeiras, o que é mais granular do que as autorizações de pagamento existentes.

Outro ponto de comparação é como o AP2 se relaciona com os fluxos de checkout de e-commerce existentes. Por exemplo, muitos sites de e-commerce usam protocolos como a API Payment Request do W3C ou SDKs específicos de plataforma para agilizar pagamentos. Estes padronizam principalmente como navegadores ou aplicativos coletam informações de pagamento de um usuário, enquanto o AP2 padroniza como um agente provaria a intenção do usuário a um comerciante e processador de pagamento. O foco do AP2 na intenção verificável e na não-repudiação o diferencia de APIs de pagamento mais simples. Ele está adicionando uma camada adicional de confiança sobre as redes de pagamento. Poderíamos dizer que o AP2 não está substituindo as redes de pagamento (Visa, ACH, blockchain, etc.), mas sim as aumentando. O protocolo suporta explicitamente todos os tipos de métodos de pagamento (até cripto), então trata-se mais de padronizar a interação do agente com esses sistemas, não de criar um novo trilho de pagamento do zero.

No domínio dos protocolos de segurança e autenticação, o AP2 compartilha algum espírito com coisas como assinaturas digitais em cartões com chip EMV ou a notarização em contratos digitais. Por exemplo, transações com cartão com chip EMV geram criptogramas para provar que o cartão estava presente; o AP2 gera prova criptográfica de que o agente do usuário foi autorizado. Ambos visam prevenir fraudes, mas o escopo do AP2 é o relacionamento agente-usuário e a comunicação agente-comerciante, o que nenhum padrão de pagamento existente aborda. Outra comparação emergente é com a abstração de contas em cripto (por exemplo, ERC-4337) onde os usuários podem autorizar ações de carteira pré-programadas. Carteiras de cripto podem ser configuradas para permitir certas transações automatizadas (como pagar automaticamente uma assinatura via um contrato inteligente), mas essas são tipicamente confinadas a um ambiente de blockchain. O AP2, por outro lado, visa ser multiplataforma – ele pode alavancar blockchain para alguns pagamentos (através de suas extensões), mas também funciona com bancos tradicionais.

Não há um protocolo “concorrente” direto ao AP2 na indústria de pagamentos mainstream ainda – parece ser o primeiro esforço concertado em um padrão aberto para pagamentos por agentes de IA. Tentativas proprietárias podem surgir (ou já podem estar em andamento dentro de empresas individuais), mas o amplo suporte do AP2 lhe dá uma vantagem para se tornar o padrão. Vale a pena notar que a IBM e outros têm um Protocolo de Comunicação de Agentes (ACP) e iniciativas semelhantes para interoperabilidade de agentes, mas estas não abrangem o aspecto de pagamento de forma tão abrangente quanto o AP2. Se houver, o AP2 pode se integrar ou alavancar esses esforços (por exemplo, os frameworks de agentes da IBM poderiam implementar o AP2 para quaisquer tarefas de comércio).

Em resumo, o AP2 se distingue por visar a intersecção única de IA e pagamentos: onde protocolos de pagamento mais antigos assumiam um usuário humano, o AP2 assume um intermediário de IA e preenche a lacuna de confiança resultante. Ele estende, em vez de conflitar, os processos de pagamento existentes e complementa os protocolos de agentes existentes como o A2A. No futuro, pode-se ver o AP2 sendo usado juntamente com padrões estabelecidos – por exemplo, um Mandato de Carrinho AP2 pode funcionar em conjunto com uma chamada de API de gateway de pagamento tradicional, ou um Mandato de Pagamento AP2 pode ser anexado a uma mensagem ISO 8583 em bancos. A natureza aberta do AP2 também significa que, se surgirem abordagens alternativas, o AP2 poderia potencialmente absorvê-las ou se alinhar a elas através da colaboração da comunidade. Nesta fase, o AP2 está estabelecendo uma base que não existia antes, efetivamente pioneirando uma nova camada de protocolo na pilha de IA e pagamentos.

Implicações para Web3 e Sistemas Descentralizados​

Desde o início, o AP2 foi projetado para ser inclusivo de pagamentos baseados em Web3 e criptomoedas. O protocolo reconhece que o comércio futuro abrangerá tanto os canais fiduciários tradicionais quanto as redes blockchain descentralizadas. Como observado anteriormente, o AP2 suporta tipos de pagamento que vão desde cartões de crédito e transferências bancárias até stablecoins e criptomoedas. Na verdade, juntamente com o lançamento do AP2, o Google anunciou uma extensão específica para pagamentos cripto chamada A2A x402. Esta extensão, desenvolvida em colaboração com players da indústria cripto como Coinbase, Ethereum Foundation e MetaMask, é uma “solução pronta para produção para pagamentos cripto baseados em agentes”. O nome “x402” é uma homenagem ao código de status HTTP 402 “Payment Required”, que nunca foi amplamente utilizado na Web – a extensão cripto do AP2 efetivamente revive o espírito do HTTP 402 para agentes descentralizados que desejam cobrar ou pagar uns aos outros on-chain. Em termos práticos, a extensão x402 adapta o conceito de mandato do AP2 para transações blockchain. Por exemplo, um agente poderia manter um Mandato de Intenção assinado de um usuário e então executar um pagamento on-chain (digamos, enviar uma stablecoin) uma vez que as condições sejam atendidas, anexando a prova do mandato a essa transação on-chain. Isso une a estrutura de confiança off-chain do AP2 com a natureza sem confiança da blockchain, oferecendo o melhor dos dois mundos: um pagamento on-chain que partes off-chain (usuários, comerciantes) podem confiar que foi autorizado pelo usuário.

A sinergia entre AP2 e Web3 é evidente na lista de colaboradores. Exchanges de cripto (Coinbase), fundações blockchain (Ethereum Foundation), carteiras cripto (MetaMask) e startups Web3 (por exemplo, Mysten Labs da Sui, Lightspark para Lightning Network) estão envolvidas no desenvolvimento do AP2. Sua participação sugere que o AP2 é visto como complementar às finanças descentralizadas, em vez de competitivo. Ao criar uma maneira padrão para agentes de IA interagirem com pagamentos cripto, o AP2 pode impulsionar mais o uso de cripto em aplicações impulsionadas por IA. Por exemplo, um agente de IA pode usar o AP2 para alternar perfeitamente entre pagar com cartão de crédito ou pagar com uma stablecoin, dependendo da preferência do usuário ou da aceitação do comerciante. A extensão A2A x402 permite especificamente que os agentes monetizem ou paguem por serviços por meios on-chain, o que pode ser crucial em mercados descentralizados do futuro. Isso sugere que agentes possivelmente operando como atores econômicos autônomos em blockchain (um conceito que alguns se referem como DACs ou DAOs) serão capazes de lidar com pagamentos necessários para serviços (como pagar uma pequena taxa a outro agente por informações). O AP2 poderia fornecer a língua franca para tais transações, garantindo que, mesmo em uma rede descentralizada, o agente tenha um mandato comprovável para o que está fazendo.

Em termos de concorrência, poderíamos perguntar: soluções puramente descentralizadas tornam o AP2 desnecessário, ou vice-versa? É provável que o AP2 coexistirá com soluções Web3 em uma abordagem em camadas. As finanças descentralizadas oferecem execução sem confiança (contratos inteligentes, etc.), mas não resolvem inerentemente o problema de “Um IA teve permissão de um humano para fazer isso?”. O AP2 aborda exatamente esse elo de confiança humano-para-IA, que continua sendo importante mesmo que o pagamento em si seja on-chain. Em vez de competir com protocolos blockchain, o AP2 pode ser visto como uma ponte entre eles e o mundo off-chain. Por exemplo, um contrato inteligente pode aceitar uma determinada transação apenas se ela incluir uma referência a uma assinatura de mandato AP2 válida – algo que poderia ser implementado para combinar a prova de intenção off-chain com a execução on-chain. Inversamente, se houver frameworks de agentes cripto-nativos (alguns projetos blockchain exploram agentes autônomos que operam com fundos cripto), eles podem desenvolver seus próprios métodos de autorização. O amplo suporte da indústria ao AP2, no entanto, pode levar até mesmo esses projetos a adotar ou integrar-se ao AP2 para consistência.

Outro ângulo é a identidade e credenciais descentralizadas. O uso de credenciais verificáveis pelo AP2 está muito alinhado com a abordagem da Web3 para a identidade (por exemplo, DIDs e VCs padronizados pelo W3C). Isso significa que o AP2 poderia se conectar a sistemas de identidade descentralizada – por exemplo, o DID de um usuário poderia ser usado para assinar um mandato AP2, que um comerciante poderia verificar contra uma blockchain ou um hub de identidade. A menção de explorar a identidade descentralizada para autorização de agentes reforça que o AP2 pode alavancar inovações de identidade Web3 para verificar identidades de agentes e usuários de forma descentralizada, em vez de depender apenas de autoridades centralizadas. Este é um ponto de sinergia, pois tanto o AP2 quanto a Web3 visam dar aos usuários mais controle e prova criptográfica de suas ações.

Potenciais conflitos podem surgir apenas se alguém imaginar um ecossistema de comércio totalmente descentralizado sem papel para grandes intermediários – nesse cenário, o AP2 (inicialmente impulsionado pelo Google e parceiros) poderia ser muito centralizado ou governado por players tradicionais? É importante notar que o AP2 é de código aberto e destinado a ser padronizável, portanto, não é proprietário do Google. Isso o torna mais palatável para a comunidade Web3, que valoriza protocolos abertos. Se o AP2 for amplamente adotado, ele pode reduzir a necessidade de protocolos de pagamento específicos da Web3 separados para agentes, unificando assim os esforços. Por outro lado, alguns projetos blockchain podem preferir mecanismos de autorização puramente on-chain (como carteiras multi-assinatura ou lógica de custódia on-chain) para transações de agentes, especialmente em ambientes sem confiança e sem autoridades centralizadas. Essas poderiam ser vistas como abordagens alternativas, mas provavelmente permaneceriam nichadas, a menos que possam interagir com sistemas off-chain. O AP2, ao cobrir ambos os mundos, pode realmente acelerar a adoção da Web3 ao tornar a cripto apenas mais um método de pagamento que um agente de IA pode usar perfeitamente. De fato, um parceiro observou que “stablecoins fornecem uma solução óbvia para desafios de escalabilidade [para] sistemas agênticos com infraestrutura legada”, destacando que a cripto pode complementar o AP2 no tratamento de escala ou cenários transfronteiriços. Enquanto isso, o líder de engenharia da Coinbase observou que trazer a extensão cripto x402 para o AP2 “fez sentido – é um playground natural para agentes... emocionante ver agentes pagando uns aos outros ressoar com a comunidade de IA”. Isso implica uma visão onde agentes de IA transacionando via redes cripto não é apenas uma ideia teórica, mas um resultado esperado, com o AP2 atuando como um catalisador.

Em resumo, o AP2 é altamente relevante para a Web3: ele incorpora pagamentos cripto como um cidadão de primeira classe e está se alinhando com padrões de identidade e credenciais descentralizadas. Em vez de competir diretamente com protocolos de pagamento descentralizados, o AP2 provavelmente interoperará com eles – fornecendo a camada de autorização enquanto os sistemas descentralizados lidam com a transferência de valor. À medida que a linha entre finanças tradicionais e cripto se confunde (com stablecoins, CBDCs, etc.), um protocolo unificado como o AP2 poderia servir como um adaptador universal entre agentes de IA e qualquer forma de dinheiro, centralizada ou descentralizada.

Adoção da Indústria, Parcerias e Roteiro​

Uma das maiores forças do AP2 é o extenso apoio da indústria por trás dele, mesmo nesta fase inicial. O Google Cloud anunciou que está “colaborando com um grupo diversificado de mais de 60 organizações” no AP2. Isso inclui grandes redes de cartão de crédito (por exemplo, Mastercard, American Express, JCB, UnionPay), líderes em fintech e processadores de pagamento (PayPal, Worldpay, Adyen, Checkout.com, concorrentes da Stripe), e-commerce e mercados online (Etsy, Shopify (via parceiros como Stripe ou outros), Lazada, Zalora), empresas de tecnologia empresarial (Salesforce, ServiceNow, Oracle possivelmente via parceiros, Dell, Red Hat), empresas de identidade e segurança (Okta, Ping Identity, Cloudflare), empresas de consultoria (Deloitte, Accenture), e organizações de cripto/Web3 (Coinbase, Ethereum Foundation, MetaMask, Mysten Labs, Lightspark), entre outras. Uma gama tão ampla de participantes é um forte indicador do interesse da indústria e da provável adoção. Muitos desses parceiros expressaram publicamente seu apoio. Por exemplo, o Co-CEO da Adyen destacou a necessidade de um “livro de regras comum” para o comércio agêntico e vê o AP2 como uma extensão natural de sua missão de apoiar os comerciantes com novos blocos de construção de pagamento. O EVP da American Express afirmou que o AP2 é importante para “a próxima geração de pagamentos digitais” onde a confiança e a responsabilidade são primordiais. A equipe da Coinbase, como observado, está animada com a integração de pagamentos cripto no AP2. Esse coro de apoio mostra que muitos na indústria veem o AP2 como o provável padrão para pagamentos impulsionados por IA, e estão ansiosos para moldá-lo para garantir que atenda aos seus requisitos.

Do ponto de vista da adoção, o AP2 está atualmente na fase de especificação e implementação inicial (anunciado em setembro de 2025). A especificação técnica completa, a documentação e algumas implementações de referência (em linguagens como Python) estão disponíveis no GitHub do projeto para os desenvolvedores experimentarem. O Google também indicou que o AP2 será incorporado em seus produtos e serviços para agentes. Um exemplo notável é o AI Agent Marketplace mencionado anteriormente: esta é uma plataforma onde agentes de IA de terceiros podem ser oferecidos aos usuários (provavelmente parte do ecossistema de IA generativa do Google). O Google diz que muitos parceiros que constroem agentes os disponibilizarão no marketplace com “novas experiências transacionáveis habilitadas pelo AP2”. Isso implica que, à medida que o marketplace for lançado ou crescer, o AP2 será a espinha dorsal para qualquer agente que precise realizar uma transação, seja comprando software do Google Cloud Marketplace autonomamente ou um agente comprando bens/serviços para um usuário. Casos de uso empresariais como aquisição autônoma (um agente comprando de outro em nome de uma empresa) e escalonamento automático de licenças foram especificamente mencionados como áreas que o AP2 poderia facilitar em breve.

Em termos de roteiro, a documentação do AP2 e o anúncio do Google fornecem algumas indicações claras:

• Curto prazo: Continuar o desenvolvimento aberto do protocolo com a contribuição da comunidade. O repositório do GitHub será atualizado com implementações de referência adicionais e melhorias à medida que os testes no mundo real ocorrerem. Podemos esperar o surgimento de bibliotecas/SDKs, tornando mais fácil integrar o AP2 em aplicações de agentes. Além disso, programas piloto iniciais ou provas de conceito podem ser conduzidos pelas empresas parceiras. Dado que muitas grandes empresas de pagamento estão envolvidas, elas podem testar o AP2 em ambientes controlados (por exemplo, uma opção de checkout habilitada para AP2 em uma pequena versão beta para usuários).
• Padrões e Governança: O Google expressou o compromisso de mover o AP2 para um modelo de governança aberta, possivelmente através de órgãos de padronização. Isso pode significar submeter o AP2 a organizações como a Linux Foundation (como foi feito com o protocolo A2A) ou formar um consórcio para mantê-lo. A Linux Foundation, W3C ou até mesmo órgãos como ISO/TC68 (serviços financeiros) podem estar nos planos para formalizar o AP2. Uma governança aberta tranquilizaria a indústria de que o AP2 não está sob o controle de uma única empresa e permanecerá neutro e inclusivo.
• Expansão de Recursos: Tecnicamente, o roteiro inclui a expansão do suporte para mais tipos de pagamento e casos de uso. Como observado na especificação, após os cartões, o foco mudará para pagamentos “push” como transferências bancárias e esquemas de pagamento locais em tempo real, e moedas digitais. Isso significa que o AP2 delineará como um Mandato de Intenção/Carrinho/Pagamento funciona para, digamos, uma transferência bancária direta ou uma transferência de carteira cripto, onde o fluxo é um pouco diferente das retiradas de cartão. A extensão A2A x402 é uma dessas expansões para cripto; da mesma forma, podemos ver uma extensão para APIs de open banking ou uma para cenários de faturamento B2B.
• Aprimoramentos de Segurança e Conformidade: À medida que as transações reais começarem a fluir através do AP2, haverá escrutínio de reguladores e pesquisadores de segurança. O processo aberto provavelmente iterará para tornar os mandatos ainda mais robustos (por exemplo, garantindo que os formatos de mandato sejam padronizados, possivelmente usando o formato W3C Verifiable Credentials, etc.). A integração com soluções de identidade (talvez alavancando biometria para a assinatura de mandatos pelo usuário, ou vinculando mandatos a carteiras de identidade digital) pode fazer parte do roteiro para aumentar a confiança.
• Ferramentas do Ecossistema: Um ecossistema emergente é provável. Já, startups estão percebendo lacunas – por exemplo, a análise da Vellum.ai menciona uma startup chamada Autumn construindo “infraestrutura de faturamento para IA”, essencialmente ferramentas sobre o Stripe para lidar com preços complexos para serviços de IA. À medida que o AP2 ganhar tração, podemos esperar mais ferramentas como gateways de pagamento focados em agentes, painéis de gerenciamento de mandatos, serviços de verificação de identidade de agentes, etc., aparecerem. O envolvimento do Google significa que o AP2 também pode ser integrado em seus produtos Cloud – imagine o suporte AP2 em ferramentas Dialogflow ou Vertex AI Agents, tornando-o um clique para permitir que um agente lide com transações (com todas as chaves e certificados necessários gerenciados no Google Cloud).

No geral, a trajetória do AP2 lembra outros grandes padrões da indústria: um lançamento inicial com um forte patrocinador (Google), ampla coalizão da indústria, código de referência de código aberto, seguido por melhorias iterativas e adoção gradual em produtos reais. O fato de o AP2 convidar todos os players “a construir este futuro conosco” ressalta que o roteiro é sobre colaboração. Se o impulso continuar, o AP2 poderá se tornar tão comum em alguns anos quanto protocolos como OAuth ou OpenID Connect são hoje em seus domínios – uma camada invisível, mas crítica, que permite a funcionalidade entre serviços.

Conclusão​

O AP2 (Protocolo de Pagamentos por Agente) representa um passo significativo em direção a um futuro onde agentes de IA podem transacionar de forma tão confiável e segura quanto os humanos. Tecnicamente, ele introduz um mecanismo inteligente de mandatos e credenciais verificáveis que instilam confiança em transações lideradas por agentes, garantindo que a intenção do usuário seja explícita e aplicável. Sua arquitetura aberta e extensível permite que ele se integre tanto aos crescentes frameworks de agentes de IA quanto à infraestrutura financeira estabelecida. Ao abordar as principais preocupações de autorização, autenticidade e responsabilidade, o AP2 estabelece as bases para que o comércio impulsionado por IA floresça sem sacrificar a segurança ou o controle do usuário.

A introdução do AP2 pode ser vista como o estabelecimento de uma nova fundação – muito parecido com os primeiros protocolos da internet que habilitaram a web – para o que alguns chamam de “economia de agentes”. Ele abre caminho para inúmeras inovações: agentes de compras pessoais, bots de busca automática de ofertas, agentes autônomos de cadeia de suprimentos e muito mais, todos operando sob uma estrutura de confiança comum. Importante, o design inclusivo do AP2 (abrangendo tudo, desde cartões de crédito até cripto) o posiciona na interseção das finanças tradicionais e da Web3, potencialmente unindo esses mundos através de um protocolo comum mediado por agentes.

A resposta da indústria até agora tem sido muito positiva, com uma ampla coalizão sinalizando que o AP2 provavelmente se tornará um padrão amplamente adotado. O sucesso do AP2 dependerá da colaboração contínua e de testes no mundo real, mas suas perspectivas são fortes dada a clara necessidade que ele aborda. Em um sentido mais amplo, o AP2 exemplifica como a tecnologia evolui: uma nova capacidade (agentes de IA) surgiu que quebrou velhas suposições, e a solução foi desenvolver um novo padrão aberto para acomodar essa capacidade. Ao investir em um protocolo aberto e com segurança em primeiro lugar agora, o Google e seus parceiros estão efetivamente construindo a arquitetura de confiança necessária para a próxima era do comércio. Como diz o ditado, “a melhor maneira de prever o futuro é construí-lo” – o AP2 é uma aposta em um futuro onde agentes de IA lidam perfeitamente com transações para nós, e está ativamente construindo a confiança e as regras necessárias para tornar esse futuro viável.

Fontes:

• Blog do Google Cloud – “Impulsionando o comércio de IA com o novo Protocolo de Pagamentos por Agente (AP2)” (16 de setembro de 2025)
• Documentação do AP2 no GitHub – “Especificação e Visão Geral do Protocolo de Pagamentos por Agente”
• Blog da Vellum AI – “AP2 do Google: Um novo protocolo para pagamentos de agentes de IA” (Análise)
• Artigo do Medium – “Protocolo de Pagamentos por Agente (AP2) do Google” (Resumo por Tahir, setembro de 2025)
• Citações de Parceiros sobre o AP2 (Blog do Google Cloud)
• Extensão A2A x402 (extensão de pagamentos cripto do AP2) – README do GitHub

A privacidade está se tornando infraestrutura pública. Em 2025, desenvolvedores precisam de ferramentas que tornem a criptografia tão fácil quanto armazenar dados. O Seal da Mysten Labs oferece exatamente isso—gerenciamento descentralizado de segredos com controle de acesso onchain. Este tutorial te ensinará como construir aplicações Web3 seguras usando criptografia baseada em identidade, segurança threshold e políticas de acesso programáveis.

Introdução: Por que o Seal Importa para Web3​

Aplicações cloud tradicionais dependem de sistemas centralizados de gerenciamento de chaves onde um único provedor controla o acesso aos dados criptografados. Embora conveniente, isso cria pontos únicos perigosos de falha. Se o provedor for comprometido, ficar offline ou decidir restringir o acesso, seus dados se tornam inacessíveis ou vulneráveis.

Seal muda completamente esse paradigma. Construído pela Mysten Labs para a blockchain Sui, Seal é um serviço de gerenciamento descentralizado de segredos (DSM) que possibilita:

• Criptografia baseada em identidade onde o conteúdo é protegido antes de deixar seu ambiente
• Criptografia threshold que distribui acesso às chaves entre múltiplos nós independentes
• Controle de acesso onchain com time locks, token-gating e lógica de autorização customizada
• Design agnóstico de armazenamento que funciona com Walrus, IPFS ou qualquer solução de armazenamento

Seja construindo aplicações de mensagens seguras, plataformas de conteúdo restrito por tokens ou transferências de ativos com time lock, Seal fornece as primitivas criptográficas e infraestrutura de controle de acesso que você precisa.

Primeiros Passos​

Pré-requisitos​

Antes de mergulhar, certifique-se de ter:

• Node.js 18+ instalado
• Familiaridade básica com TypeScript/JavaScript
• Uma carteira Sui para testes (como Sui Wallet)
• Entendimento de conceitos blockchain

Instalação​

Instale o SDK Seal via npm:

npm install @mysten/seal

Você também vai querer o SDK Sui para interações blockchain:

npm install @mysten/sui

Configuração do Projeto​

Crie um novo projeto e inicialize-o:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

Crie uma configuração TypeScript simples:

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

Conceitos Fundamentais: Como o Seal Funciona​

Antes de escrever código, vamos entender a arquitetura do Seal:

1. Criptografia Baseada em Identidade (IBE)​

Diferente da criptografia tradicional onde você criptografa para uma chave pública, IBE permite criptografar para uma identidade (como um endereço de email ou endereço Sui). O destinatário só pode descriptografar se conseguir provar que controla essa identidade.

2. Criptografia Threshold​

Em vez de confiar em um único servidor de chaves, Seal usa esquemas t-of-n threshold. Você pode configurar 3-de-5 servidores de chaves, significando que qualquer 3 servidores podem cooperar para fornecer chaves de descriptografia, mas 2 ou menos não conseguem.

3. Controle de Acesso Onchain​

Políticas de acesso são aplicadas por smart contracts da Sui. Antes que um servidor de chaves forneça chaves de descriptografia, ele verifica se o solicitante atende aos requisitos da política onchain (propriedade de tokens, restrições de tempo, etc.).

4. Rede de Servidores de Chaves​

Servidores de chaves distribuídos validam políticas de acesso e geram chaves de descriptografia. Esses servidores são operados por diferentes partes para garantir que não haja um único ponto de controle.

Implementação Básica: Sua Primeira Aplicação Seal​

Vamos construir uma aplicação simples que criptografa dados sensíveis e controla o acesso através de políticas blockchain da Sui.

Passo 1: Inicializar o Cliente Seal​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // Inicializar cliente Sui para testnet
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // Configurar cliente Seal com servidores de chaves da testnet
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // threshold 2-de-3
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

Passo 2: Criptografia/Descriptografia Simples​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // Dados para criptografar
  const sensitiveData = "Esta é minha mensagem secreta!";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // Criptografar dados para um endereço Sui específico
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // Opcional: adicionar metadados
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('Dados criptografados:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // Depois, descriptografar os dados (requer autorização adequada)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('Dados descriptografados:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('Falha na criptografia/descriptografia:', error);
  }
}

basicExample();

Controle de Acesso com Smart Contracts da Sui​

O verdadeiro poder do Seal vem do controle de acesso programável. Vamos criar um exemplo de criptografia com time lock onde os dados só podem ser descriptografados após um tempo específico.

Passo 1: Implementar Contrato de Controle de Acesso​

Primeiro, precisamos de um smart contract Move que define nossa política de acesso:

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

Passo 2: Integrar com Seal​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Criar política de acesso na Sui
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // Desbloquear em 1 minuto
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // Executar transação para criar política
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // Seu keypair Sui
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // Agora criptografar com esta política
  const sensitiveData = "Isso será desbloqueado em 1 minuto!";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('Dados com time lock criados. Tente descriptografar após 1 minuto.');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

Exemplos Práticos​

Exemplo 1: Aplicação de Mensagens Seguras​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // Armazenar mensagem criptografada em armazenamento descentralizado (Walrus)
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // Recuperar do armazenamento
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Descriptografar com Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // Integração com armazenamento Walrus
    // Isso faria upload dos dados criptografados para Walrus
    // e retornaria o blob ID para recuperação
  }

  private async retrieveFromWalrus(blobId: string) {
    // Recuperar dados criptografados do Walrus usando blob ID
  }
}

Exemplo 2: Plataforma de Conteúdo com Token-Gating​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // Criar política de propriedade de NFT
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // Criptografar conteúdo com requisito de acesso por NFT
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // Destinatário especial para portadores de NFT
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // Verificar propriedade de NFT primeiro
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('Acesso negado: NFT necessário não encontrado');
    }

    // Descriptografar conteúdo
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // Criar contrato Move que verifica propriedade de NFT
    // Retorna ID do objeto de política
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // Verificar se usuário possui NFT necessário
    // Consultar Sui para propriedade de NFT
  }
}

Exemplo 3: Transferência de Ativos com Time Lock​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // Criar política de time lock na Sui
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // Criptografar dados de transferência de ativo
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`Ativo bloqueado até ${new Date(unlockTimestamp)}`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // Processar a transferência de ativo
    console.log('Transferência de ativo desbloqueada:', transferData);

    return transferData;
  } catch (error) {
    console.error('Transferência ainda não desbloqueada ou acesso negado:', error);
    throw error;
  }
}

Integração com Armazenamento Descentralizado Walrus​

Seal funciona perfeitamente com Walrus, a solução de armazenamento descentralizado da Sui. Veja como integrar ambos:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // Criptografar com Seal
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // Armazenar dados criptografados no Walrus
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // Retornar referência que inclui informações tanto do Seal quanto do Walrus
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // Recuperar do Walrus
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Descriptografar com Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// Exemplo de uso
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('Conteúdo de documento importante');
  const recipientAddress = '0x...';

  // Armazenar criptografado
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Armazenado com Blob ID:', result.blobId);

  // Depois, recuperar e descriptografar
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('Dados recuperados:', decrypted.toString());
}

Configuração Avançada de Criptografia Threshold​

Para aplicações de produção, você vai querer configurar criptografia threshold customizada com múltiplos servidores de chaves:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // Configurar com múltiplos servidores de chaves independentes
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // threshold 3-de-5
    network: 'mainnet',
    // Opções avançadas
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "Dados criptografados de missão crítica";

  // Criptografar com altas garantias de segurança
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // Exigir todos os 5 servidores para máxima segurança
    customThreshold: 5,
    // Adicionar redundância
    redundancy: 2,
    accessPolicy: {
      // Requisitos multifator
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

Melhores Práticas de Segurança​

1. Gerenciamento de Chaves​

// src/security-practices.ts

// BOM: Usar derivação segura de chaves
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// BOM: Armazenar chaves de forma segura (exemplo com variáveis de ambiente)
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// RUIM: Nunca hardcodar chaves
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // Não faça isso!
);

2. Validação de Política de Acesso​

// Sempre validar políticas de acesso antes da criptografia
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // Validar endereço do destinatário
  if (!isValidSuiAddress(recipient)) {
    throw new Error('Endereço de destinatário inválido');
  }

  // Verificar se política existe e é válida
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('Política de acesso inválida');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. Tratamento de Erros e Fallbacks​

// Tratamento robusto de erros
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('Acesso negado: Verifique suas permissões');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // Tentar com configuração de backup
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('Servidores de chaves insuficientes disponíveis');
    } else {
      throw new Error(`Falha na descriptografia: ${error.message}`);
    }
  }
}

4. Validação de Dados​

// Validar dados antes da criptografia
function validateDataForEncryption(data: Buffer): boolean {
  // Verificar limites de tamanho
  if (data.length > 1024 * 1024) { // Limite de 1MB
    throw new Error('Dados muito grandes para criptografia');
  }

  // Verificar padrões sensíveis (opcional)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('Aviso: Dados contêm padrões potencialmente sensíveis');
  }

  return true;
}

Otimização de Performance​

1. Operações em Lote​

// Agrupar múltiplas criptografias para eficiência
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. Cache de Respostas de Servidores de Chaves​

// Cache de sessões de servidores de chaves para reduzir latência
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Testando Sua Integração Seal​

Testes Unitários​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Integração Seal', () => {
  it('deve criptografar e descriptografar dados com sucesso', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('mensagem de teste');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('mensagem de teste');
  });

  it('deve aplicar políticas de controle de acesso', async () => {
    // Testar que usuários não autorizados não podem descriptografar
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('segredo'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('Acesso negado');
  });
});

Deploy para Produção​

Configuração de Ambiente​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // Configurações de segurança
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1 hora
  retryAttempts: 3
};

Monitoramento e Logging​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] Dados criptografados ${encryptionId} para ${recipient}`);
    // Enviar para seu serviço de monitoramento
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] Descriptografia ${encryptionId}: ${success ? 'SUCESSO' : 'FALHA'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] Servidor de chaves ${serverUrl}: ${status}`);
  }
}

Recursos e Próximos Passos​

Documentação Oficial​

• Documentação Seal: https://seal-docs.wal.app/
• Repositório GitHub: https://github.com/MystenLabs/seal
• Documentação Sui: https://docs.sui.io/
• Documentação Walrus: https://docs.wal.app/

Comunidade e Suporte​

• Discord Sui: Junte-se ao canal #seal para suporte da comunidade
• GitHub Issues: Reporte bugs e solicite funcionalidades
• Fóruns de Desenvolvedores: Fóruns da comunidade Sui para discussões

Tópicos Avançados para Explorar​

1. Políticas de Acesso Customizadas: Construa lógica de autorização complexa com contratos Move
2. Integração Cross-Chain: Use Seal com outras redes blockchain
3. Gerenciamento de Chaves Empresarial: Configure sua própria infraestrutura de servidores de chaves
4. Auditoria e Compliance: Implemente logging e monitoramento para ambientes regulamentados

Aplicações de Exemplo​

• App de Chat Seguro: Mensagens criptografadas de ponta a ponta com Seal
• Gerenciamento de Documentos: Compartilhamento de documentos empresariais com controles de acesso
• Gerenciamento de Direitos Digitais: Distribuição de conteúdo com políticas de uso
• Analytics Preservando Privacidade: Workflows de processamento de dados criptografados

Conclusão​

Seal representa uma mudança fundamental em direção a tornar privacidade e criptografia preocupações de nível de infraestrutura em Web3. Ao combinar criptografia baseada em identidade, segurança threshold e controle de acesso programável, ele fornece aos desenvolvedores ferramentas poderosas para construir aplicações verdadeiramente seguras e descentralizadas.

As principais vantagens de construir com Seal incluem:

• Sem Ponto Único de Falha: Servidores de chaves distribuídos eliminam autoridades centrais
• Segurança Programável: Políticas de acesso baseadas em smart contracts fornecem autorização flexível
• Amigável ao Desenvolvedor: SDK TypeScript integra-se perfeitamente com ferramentas Web3 existentes
• Agnóstico de Armazenamento: Funciona com Walrus, IPFS ou qualquer solução de armazenamento
• Pronto para Produção: Construído pela Mysten Labs com padrões de segurança empresariais

Seja protegendo dados de usuários, implementando modelos de assinatura ou construindo aplicações complexas multipartidárias, Seal fornece as primitivas criptográficas e infraestrutura de controle de acesso que você precisa para construir com confiança.

Comece a construir hoje, e junte-se ao crescente ecossistema de desenvolvedores tornando a privacidade uma parte fundamental da infraestrutura pública.

Pronto para começar a construir? Instale @mysten/seal e comece a experimentar com os exemplos deste tutorial. A web descentralizada está esperando por aplicações que colocam privacidade e segurança em primeiro lugar.

Lançar um protocolo ou escalar um produto on-chain deixou de ser apenas uma tarefa técnica. Os reguladores analisam desde o lançamento de tokens até a privacidade das carteiras, enquanto os usuários exigem proteções de nível consumidor. Para continuar construindo com confiança, cada equipe fundadora precisa de um método estruturado para transformar memorandos jurídicos complexos em decisões de produto. Inspirado em 50 das dúvidas mais comuns entre advogados web3, este guia traduz a conversa em ações prontas para builders.

1. Constituição e governança: separe a devco, a fundação e a comunidade​

• Escolha o veículo adequado. C-corps ou LLCs tradicionais continuam sendo as melhores para folha de pagamento, propriedade intelectual e diligência de investidores. Se você vai administrar um protocolo ou programa de grants, uma fundação ou entidade sem fins lucrativos separada mantém os incentivos limpos e a governança transparente.
• Formalize todos os relacionamentos. Utilize cessões de IP, acordos de confidencialidade e planos de vesting com cliffs, lockups e cláusulas de clawback para condutas inadequadas. Registre as aprovações do conselho e trate a tabela de tokens com o mesmo rigor do cap table de equity.
• Defina limites claros entre as entidades. A empresa de desenvolvimento pode construir sob licença, mas orçamento, política de tesouraria e direitos de decisão devem estar em uma fundação ou DAO com estatuto e constituição próprios. Se a DAO precisar de personalidade jurídica, use uma LLC ou equivalente.

2. Tokens e valores mobiliários: projete para a utilidade e registre a justificativa​

• Pressuponha que os reguladores ignoram os rótulos. Chamá-los de “governança” ou “utilidade” só ajuda se os usuários interagem com uma rede funcional, compram para consumo e não recebem promessas de lucro. Lockups reduzem especulação, mas documente a lógica como estabilidade ou defesa anti-sybil.
• Diferencie acesso de investimento. Tokens de acesso devem soar como passes de produto: preço, documentação e marketing precisam reforçar o direito ao serviço, não lucros futuros. Stablecoins podem disparar regras de pagamentos ou moeda eletrônica conforme reservas e direitos de resgate.
• Trate staking e rendimento como produtos financeiros. Promessas de APR, pool compartilhado ou dependência do esforço da equipe elevam o risco de serem considerados valores mobiliários. Mantenha o marketing simples, divulgue fatores de risco e planeje uma trajetória em conformidade do SAFT até o mainnet se levantar capital com tokens futuros.
• Lembre-se de que NFTs podem ser valores mobiliários. Frações, pools ou mensagens sobre lucros os aproximam de investimentos. NFTs de uso claro, com licenças explícitas, são mais seguros.

3. Captação e vendas: divulgue a rede, não promessas de foguete à lua​

• Faça divulgações maduras. Propósito, funcionalidade, vesting, alocação, restrições de transferência, dependências e uso dos recursos devem constar de todo memorando de venda. Garanta que o marketing siga os mesmos termos—nada de tweets com “rentabilidade garantida”.
• Respeite as fronteiras regulatórias. Se não consegue cumprir as regras dos EUA ou de outros mercados complexos, combine geofencing com checagens de elegibilidade, restrições contratuais e monitoramento pós-venda. KYC/AML é obrigatório em vendas e, cada vez mais, em airdrops.
• Gerencie o risco promocional. Campanhas com influenciadores precisam de divulgação explícita de patrocínio e roteiros em conformidade. Listagens em exchanges ou acordos de market making exigem contratos escritos, gestão de conflitos e comunicação transparente com as plataformas.

4. AML, impostos e propriedade intelectual: embuta controles no produto​

• Conheça seu papel regulatório. Softwares não custodiais enfrentam obrigações AML menores, mas ao tocar rampas fiat, custódia ou intermediação de câmbio, regras de transmissores de dinheiro ou VASP passam a valer. Prepare triagem de sanções, fluxos de escalonamento e prontidão para Travel Rule quando necessário.
• Trate tokens como caixa na contabilidade. Receitas em tokens costumam ser reconhecidas a valor de mercado e a venda posterior gera ganhos ou perdas. Concessões a colaboradores tendem a ser tributadas no vesting: tenha acordos escritos, registre o custo e prepare-se para a volatilidade.
• Respeite os limites de PI. Vincule NFTs e conteúdo on-chain a licenças claras, cumpra os termos de código open source de terceiros e registre marcas. Se for treinar modelos de IA, confirme os direitos sobre os dados e remova informações sensíveis.

5. Privacidade e dados: minimize a coleta, prepare-se para deletar​

• Considere carteiras como dados pessoais. Endereços de wallet combinados com IP, IDs de dispositivos ou e-mails configuram informações identificáveis. Coleta apenas o essencial, mantenha dados off-chain sempre que possível e use hashing ou tokenização.
• Programe-se para exclusões. A imutabilidade da blockchain não isenta do cumprimento de leis de privacidade: mantenha PII fora da cadeia, remova referências quando o usuário solicitar e elimine vínculos que possam reidentificar dados hasheados.
• Seja transparente com telemetria. Banners de cookies, avisos sobre analytics e opções de opt-out são obrigatórios. Documente um plano de resposta a incidentes com níveis de severidade, prazos de notificação e responsáveis.

6. Operações e riscos: audite cedo, comunique sempre​

• Audite e publique. Auditorias independentes de smart contracts, verificação formal quando fizer sentido e bug bounty contínuo demonstram maturidade. Divulgue relatórios e explique os riscos residuais.
• Estabeleça Termos de Uso claros. Descreva a situação de custódia, critérios de elegibilidade, usos proibidos, resolução de disputas e política para forks. Alinhe Termos, Política de Privacidade e o comportamento real do produto.
• Planeje forks, seguros e expansão internacional. Garanta o direito de escolher redes suportadas, datas de snapshot e caminhos de migração. Avalie seguros cibernéticos, contra crimes, D&O e E&O tecnológico. Ao operar globalmente, localize termos, verifique controles de exportação e utilize parceiros EOR/PEO para evitar problemas trabalhistas.
• Prepare-se para disputas. Decida antecipadamente se arbitragem ou cláusulas anti-class action combinam com sua base de usuários. Registre pedidos de autoridades, valide a base legal e explique limitações técnicas como a ausência de custódia de chaves.

7. Checklist de ação para builders​

• Mapeie seu papel operacional: fornecedor de software, custodiante, serviço similar a corretora ou intermediário de pagamentos.
• Mantenha o marketing factual e focado na funcionalidade; evite linguagem que sugira retorno especulativo.
• Minimize custódia e coleta de dados pessoais; documente pontos de contato inevitáveis.
• Mantenha vivos os documentos de alocação de tokens, desenho de governança, status de auditoria e decisões de risco.
• Reserve orçamento desde o início para assessoria jurídica, ferramentas de conformidade, auditorias, bug bounties e especialistas fiscais.

8. Transforme aconselhamento jurídico em velocidade de produto​

A regulação não vai diminuir o ritmo para os builders. O que muda os resultados é incorporar considerações legais na priorização do backlog, na gestão da tesouraria e na comunicação com usuários. Traga o jurídico para as revisões de sprint, treine respostas a incidentes e itere as divulgações da mesma forma que a UX. Assim, as 50 FAQs deixam de ser bloqueio e passam a ser vantagem competitiva para o seu protocolo.

A maioria dos aplicativos ainda ancora a identidade a nomes de usuário, senhas e bancos de dados centralizados. Esse modelo é frágil (vazamentos), vazante (revenda de dados) e engessado (repetição infinita de KYC). A nova pilha que surge em torno de identificadores descentralizados (DIDs), credenciais verificáveis (VCs) e atestações aponta para um futuro diferente: os usuários carregam provas criptográficas de fatos sobre si mesmos e revelam apenas o que for necessário — nem mais, nem menos.

Este post destila o cenário e oferece um plano prático que você pode colocar em produção hoje.

A Mudança: De Contas para Credenciais​

O núcleo dessa nova pilha de identidade é construído sobre duas normas fundamentais da W3C que mudam radicalmente como lidamos com os dados dos usuários.

• Identificadores Descentralizados (DIDs): São identificadores controlados pelo usuário que não exigem um registro central como um sistema de nomes de domínio. Pense em um DID como um endereço permanente e auto‑propriedade para identidade. Um DID resolve para um “documento DID” assinado contendo chaves públicas e pontos de serviço, permitindo autenticação segura e descentralizada. A norma v1.0 tornou‑se uma Recomendação oficial da W3C em 19 de julho de 2022, marcando um marco importante para o ecossistema.
• Credenciais Verificáveis (VCs): Formato digital à prova de violação para expressar declarações, como “idade acima de 18”, “possui diploma da Universidade X” ou “passou por verificação KYC”. O Modelo de Dados VC 2.0 tornou‑se Recomendação da W3C em 15 de maio de 2025, consolidando uma base moderna para emissão e verificação dessas credenciais.

O que muda para os desenvolvedores? A mudança é profunda. Em vez de armazenar informações pessoais sensíveis (PII) no seu banco de dados, você verifica provas criptográficas fornecidas pela carteira do usuário. Você pode solicitar apenas a informação específica que precisa (por exemplo, residência em determinado país) sem ver o documento subjacente, graças a primitivas poderosas como divulgação seletiva.

Onde Isso Encontra os Logins que Você Já Usa​

Esse novo mundo não exige abandonar experiências de login familiares. Pelo contrário, ele as complementa.

• Passkeys / WebAuthn: Sua solução para autenticação resistente a phishing. Passkeys são credenciais FIDO vinculadas a um dispositivo ou biometria (Face ID, impressão digital) e agora são amplamente suportadas nos principais navegadores e sistemas operacionais. Elas oferecem uma experiência de login sem senha, fluida, para seu app ou carteira.
• Sign‑In with Ethereum (SIWE / EIP‑4361): Padrão que permite ao usuário provar o controle de um endereço de blockchain e vinculá‑lo a uma sessão de aplicação. Funciona via mensagem simples assinada, baseada em nonce, criando uma ponte limpa entre sessões Web2 tradicionais e controle Web3.

A melhor prática é usá‑las juntas: implemente passkeys para login cotidiano e ofereça SIWE para fluxos vinculados à carteira onde o usuário precisa autorizar uma ação nativa de cripto.

Os Trilhos para Emitir e Verificar Credenciais​

Para que as credenciais sejam úteis, precisamos de maneiras padronizadas de emiti‑las aos usuários e de os usuários as apresentarem às apps. A OpenID Foundation fornece os dois protocolos chave para isso.

• Emissão: OpenID for Verifiable Credential Issuance (OID4VCI) define uma API protegida por OAuth para obter credenciais de emissores (governo, provedor KYC) para a carteira digital do usuário. É flexível, suportando múltiplos formatos de credencial.
• Apresentação: OpenID for Verifiable Presentations (OID4VP) padroniza como sua aplicação faz um “pedido de prova” e como a carteira do usuário responde. Isso pode acontecer via redirecionamentos OAuth clássicos ou por APIs modernas de navegador.

Ao construir, você encontrará alguns formatos de credencial projetados para diferentes ecossistemas e casos de uso:

• W3C VC com Suites de Integridade de Dados (JSON‑LD): Frequentemente combinados com criptografia BBS+ para habilitar divulgação seletiva poderosa.
• VC‑JOSE‑COSE e SD‑JWT VC (IETF): Formatos construídos para ecossistemas JWT e CBOR, também com fortes capacidades de divulgação seletiva.

Felizmente, a interoperabilidade está melhorando rapidamente. Perfis como OpenID4VC High Assurance ajudam a reduzir as opções técnicas, tornando as integrações entre fornecedores muito mais sensatas para desenvolvedores.

Métodos DID: Escolhendo o Esquema de Endereço Correto​

Um DID é apenas um identificador; um “método DID” especifica como ele é ancorado a uma raiz de confiança. Você desejará suportar alguns dos mais comuns.

• did:web: Este método amarra um DID a um domínio que você controla. É incrivelmente fácil de implantar e uma escolha fantástica para empresas, emissores e organizações que querem usar sua infraestrutura web existente como âncora de confiança.
• did:pkh: Deriva um DID diretamente de um endereço de blockchain (por exemplo, um endereço Ethereum). Muito útil quando sua base de usuários já possui carteiras cripto e você quer ligar a identidade aos ativos on‑chain.

Regra prática: Suporte ao menos dois métodos — did:web para organizações e did:pkh para usuários individuais. Use uma biblioteca padrão de resolvedor DID para lidar com a busca e consulte os registros oficiais para avaliar segurança, persistência e governança de qualquer novo método que considere adicionar.

Blocos de Construção Úteis que Você Pode Plug‑ar​

Além dos padrões centrais, várias ferramentas podem melhorar sua pilha de identidade.

• ENS (Ethereum Name Service): Fornece nomes legíveis por humanos (seunome.eth) que podem mapear para endereços de blockchain e DIDs. Ferramenta valiosa para melhorar a experiência do usuário, reduzir erros e oferecer uma camada de perfil simples.
• Atestações: “Facts” verificáveis e flexíveis que podem ser registrados on‑chain ou off‑chain. O Ethereum Attestation Service (EAS), por exemplo, oferece um substrato robusto para construir grafos de reputação e confiança sem jamais armazenar PII em um ledger público.

Ventos de Conformidade que Você Deve Acompanhar​

Regulação costuma ser vista como obstáculo, mas neste espaço é um acelerador massivo. O Quadro de Identidade Digital da UE (eIDAS 2.0), adotado oficialmente como Regulamento UE 2024/1183 em 20 de maio de 2024, é o desenvolvimento mais significativo. Ele obriga todos os Estados‑Membros da UE a oferecer aos cidadãos uma Carteira Digital de Identidade da UE (EUDI) gratuita. Com regulamentos de implementação publicados em 7 de maio de 2025, isso sinaliza fortemente a adoção de credenciais baseadas em carteira tanto em serviços públicos quanto privados na Europa.

Mesmo que você não opere na UE, espere que a Carteira EUDI e seus protocolos subjacentes moldem as expectativas dos usuários e impulsionem a adoção de carteiras globalmente.

Padrões de Design que Funcionam na Produção (2025)​

• Primeiro Sem Senha, Carteiras Opcionais: Use passkeys como padrão de login. É seguro, simples e familiar. Só introduza SIWE quando o usuário precisar executar uma ação vinculada a cripto, como mintar um NFT ou receber um pagamento.
• Peça Provas, Não Documentos: Substitua uploads engessados por um pedido de prova VC usando OID4VP. Em vez de solicitar a carteira de motorista, peça prova de “idade acima de 18” ou “residência no país X”. Aceite credenciais que suportem divulgação seletiva, como as que usam BBS+ ou SD‑JWT.
• Mantenha PII Fora dos Seus Servidores: Quando um usuário prova algo, registre uma atestado ou um resultado de verificação de curta duração, não a credencial bruta. Atestados on‑chain são poderosos para criar registros auditáveis — “Usuário Y passou KYC com Emissor Z em data D” — sem armazenar dados pessoais.
• Deixe Organizações Serem Emissores com did:web: Empresas, universidades e outras organizações já controlam seus domínios. Permita que assinem credenciais como emissores usando did:web, gerenciando chaves criptográficas sob seus modelos de governança web existentes.
• Use ENS para Nomes, Não para Identidade: Trate ENS como um apelido amigável e ponte de perfil. É ótimo para UX, mas mantenha as reivindicações de identidade autoritativas dentro de credenciais e atestações.

Uma Arquitetura Inicial​

Aqui está um plano para um sistema de identidade moderno baseado em credenciais:

• Autenticação
  • Login Padrão: Passkeys (FIDO/WebAuthn).
  • Sessões Ligadas a Cripto: Sign‑In with Ethereum (SIWE) para ações baseadas em carteira.
• Credenciais
  • Emissão: Integre com endpoints OID4VCI dos emissores escolhidos (provedor KYC, universidade, etc.).
  • Apresentação: Dispare pedidos de prova OID4VP a partir do seu app web ou nativo. Esteja preparado para aceitar tanto W3C VCs (com BBS+) quanto VCs SD‑JWT.
• Resolução & Confiança
  • Resolvedor DID: Use uma biblioteca que suporte ao menos did:web e did:pkh. Mantenha uma lista de permissões de DIDs emissores confiáveis para evitar spoofing.
• Atestações & Reputação
  • Registros Duráveis: Quando precisar de um sinal auditável de verificação, crie uma atestado contendo hash, DID do emissor e timestamp, ao invés de armazenar a reivindicação em si.
• Armazenamento & Privacidade
  • Minimalismo: Reduza drasticamente o PII armazenado no servidor. Criptografe tudo em repouso e defina políticas estritas de tempo de vida (TTL). Prefira provas efêmeras e aproveite zero‑knowledge ou divulgação seletiva.

Lições de UX Aprendidas​

• Comece Invisível: Para a maioria dos usuários, a melhor carteira é a que eles não precisam pensar. Use passkeys para login fluido e só exponha interações de carteira quando absolutamente necessário.
• Divulgação Progressiva: Não peça tudo de uma vez. Solicite a menor prova possível que desbloqueie o objetivo imediato do usuário. Com divulgação seletiva, você não precisa do documento completo para validar um fato.
• Recuperação de Chave Importa: Uma credencial vinculada a uma única chave de dispositivo é um risco. Planeje re‑emissão e portabilidade entre dispositivos desde o início. Esse é um motivo chave para adoção de formatos como SD‑JWT VC e vinculação baseada em reivindicações.
• Apelidos Legíveis Ajudam: Um nome ENS é muito menos intimidador que um endereço hexadecimal longo. Reduz erros e adiciona contexto reconhecível, mesmo que a autoridade real esteja nas credenciais subjacentes.

O Que Entregar no Próximo Trimestre: Roteiro Pragmatico​

• Semanas 1–2:
  • Adicionar passkeys ao fluxo principal de login.
  • Proteger todas as ações nativas de cripto atrás de verificação SIWE.
• Semanas 3–6:
  • Pilotar um simples gate de idade ou região usando um pedido OID4VP.
  • Aceitar credenciais VC 2.0 com divulgação seletiva (BBS+ ou SD‑JWT VC).
  • Começar a criar atestações para eventos “verificação concluída” ao invés de registrar PII.
• Semanas 7–10:
  • Integrar um emissor parceiro (ex.: seu provedor KYC) usando did:web e implementar lista de permissões de DIDs.
  • Oferecer vínculo de nome ENS nos perfis de usuário para melhorar a UX de endereços.
• Semanas 11–12:
  • Modelar ameaças nos fluxos de apresentação e revogação. Adicionar telemetria para modos de falha comuns (credencial expirada, emissor não confiável).
  • Publicar uma postura de privacidade clara explicando exatamente o que você solicita, por quê, por quanto tempo retém e como os usuários podem auditar.

O Que Está Mudando Rápido (Fique de Olho)​

• Rollouts da Carteira EUDI da UE: Implementação e testes de conformidade dessas carteiras moldarão massivamente capacidades e UX de verificação globalmente.
• Perfis OpenID4VC: Interoperabilidade entre emissores, carteiras e verificadores está em constante aprimoramento graças a novos perfis e suítes de teste.
• Criptossuites de Divulgação Seletiva: Bibliotecas e guias para BBS+ e SD‑JWT VC amadurecem rapidamente, facilitando a implementação.

Princípios para Construir​

• Prove, Não Armazene: Priorize verificação de reivindicações ao invés de armazenar PII bruto.
• Interoperabilidade por Padrão: Suporte múltiplos formatos de credencial e métodos DID desde o início para tornar sua pilha à prova de futuro.
• Minimize & Divulgue: Peça a menor reivindicação possível. Seja transparente com os usuários sobre o que está sendo verificado e por quê.
• Recuperação Sem Drama: Planeje perda de dispositivo e rotação de emissores. Evite vinculação frágil de chaves que possa deixar usuários presos.

Se você está construindo fintech, redes sociais ou plataformas para criadores, identidade primeiro‑credencial não é mais uma aposta futura — é o caminho mais curto para risco reduzido, onboarding mais suave e interoperabilidade global.

Blockchains públicas oferecem um livro-razão sincronizado e auditável, mas expõem todos os dados por padrão. Lançado na Sui Mainnet em 3 de setembro de 2025, o Seal resolve esse dilema ao combinar lógica de políticas on-chain com gerenciamento descentralizado de chaves, permitindo que builders decidam exatamente quem pode descriptografar cada payload.

Resumo​

• O que é: Seal é uma rede de gestão de segredos que permite aos contratos inteligentes da Sui aplicar políticas de descriptografia on-chain enquanto os clientes criptografam dados com criptografia baseada em identidade (IBE) e dependem de servidores de chaves com limiar para derivar as chaves.
• Por que importa: Em vez de backends personalizados ou scripts opacos fora da cadeia, privacidade e controle de acesso tornam-se primitivas de Move de primeira classe. Os desenvolvedores podem armazenar os cifrados em qualquer lugar—Walrus é o complemento natural—e ainda controlar quem pode ler.
• Quem se beneficia: Equipes que entregam conteúdo tokenizado, revelações com bloqueio temporal, mensagens privadas ou agentes de IA guiados por políticas podem integrar o SDK do Seal e focar na lógica do produto, não na infraestrutura criptográfica.

A lógica de políticas vive em Move​

Os pacotes do Seal incluem funções Move seal_approve* que definem quem pode solicitar chaves para um determinado identificador e em quais condições. As políticas podem combinar propriedade de NFT, listas de permissão, bloqueios temporais ou sistemas de papéis personalizados. Quando um usuário ou agente solicita descriptografia, os servidores de chaves avaliam essas políticas consultando o estado de um full node da Sui e só aprovam se a cadeia concordar.

Como as regras de acesso fazem parte do seu pacote on-chain, elas são transparentes, auditáveis e versionadas junto com o restante do código do contrato inteligente. Atualizações de governança podem ser implementadas como qualquer upgrade de Move, com revisão da comunidade e histórico on-chain.

Criptografia de limiar gerencia as chaves​

O Seal criptografa dados para identidades definidas pela aplicação. Um comitê de servidores de chaves independentes—escolhido pelo desenvolvedor—compartilha o segredo mestre de IBE. Quando a verificação de política é aprovada, cada servidor deriva uma fração de chave para a identidade solicitada. Quando o quórum de t servidores responde, o cliente combina as frações para obter uma chave de descriptografia utilizável.

Você controla o equilíbrio entre disponibilidade e confidencialidade ao escolher os membros do comitê (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One ou o serviço Enoki da Mysten) e definir o limiar. Precisa de mais disponibilidade? Selecione um comitê maior com limiar menor. Quer garantias de privacidade mais fortes? Endureça o quórum e privilegie provedores permissionados.

Experiência do desenvolvedor: SDK e chaves de sessão​

O Seal oferece um SDK TypeScript (npm i @mysten/seal) que cuida dos fluxos de criptografia/descriptografia, formatação de identidades e batching. Ele também emite chaves de sessão para evitar que carteiras recebam prompts constantes quando o app precisa de acesso repetido. Para fluxos avançados, contratos Move podem solicitar descriptografia on-chain em modos especiais, permitindo que lógicas como revelações em escrow ou leilões resistentes a MEV sejam executadas diretamente no código do contrato.

Como o Seal é agnóstico quanto ao armazenamento, as equipes podem combiná-lo com Walrus para blobs verificáveis, com IPFS ou até com repositórios centralizados quando o cenário operacional exigir. O limite de criptografia—e a aplicação das políticas—acompanha os dados independentemente de onde o cifrado esteja armazenado.

Boas práticas ao projetar com Seal​

• Modele o risco de disponibilidade: Limiares como 2-de-3 ou 3-de-5 se traduzem diretamente em garantias de uptime. Implantações em produção devem misturar provedores, monitorar telemetria e estabelecer SLA antes de delegar fluxos críticos.
• Atenção à variação de estado: A avaliação de políticas depende de chamadas dry_run em full nodes. Evite regras que dependam de contadores que mudam rapidamente ou da ordenação dentro do checkpoint para prevenir aprovações inconsistentes entre servidores.
• Planeje a higiene das chaves: As chaves derivadas residem no cliente. Implemente logs, gire chaves de sessão e considere criptografia envelope—use o Seal para proteger uma chave simétrica que cifra o payload maior—para limitar o impacto caso um dispositivo seja comprometido.
• Projete para rotação: O comitê usado em um cifrado fica fixo no momento da criptografia. Crie caminhos de upgrade que recriptografem os dados com novos comitês quando for necessário trocar provedores ou ajustar as hipóteses de confiança.

Próximos passos​

O roadmap do Seal aponta para servidores MPC operados por validadores, ferramentas de cliente no estilo DRM e opções de KEM pós-quântico. Para builders que exploram agentes de IA, conteúdo premium ou fluxos de dados regulados, a versão atual já oferece um plano claro: codifique sua política em Move, componha um comitê de chaves diversificado e entregue experiências criptografadas que respeitem a privacidade do usuário sem sair da zona de confiança da Sui.

Se estiver avaliando o Seal para seu próximo lançamento, comece prototipando uma política simples com NFT e um comitê aberto 2-de-3, depois evolua para a combinação de provedores e controles operacionais que correspondam ao perfil de risco do seu aplicativo.

TL;DR​

A abstração cross‑chain transforma um labirinto de cadeias, pontes e carteiras em uma experiência de plataforma única e coerente para desenvolvedores e usuários finais. O ecossistema amadureceu silenciosamente: padrões de intenção, abstração de conta, mobilidade nativa de stablecoins e iniciativas de nível de rede como OP Superchain e AggLayer da Polygon tornam realista um futuro de “muitas cadeias, uma experiência” em 2025. Para as empresas, o ganho é pragmático: integrações mais simples, controles de risco executáveis, operações determinísticas e auditoria pronta para conformidade — sem apostar tudo em uma única cadeia.

O Problema Real das Empresas (e Por Que as Pontes Sozinhas Não Resolveram)​

A maioria das equipes empresariais não quer “escolher uma cadeia”. Elas querem resultados: liquidar um pagamento, emitir um ativo, compensar uma negociação ou atualizar um registro — de forma confiável, auditável e a um custo previsível. O problema é que o Web3 de produção hoje é irrevogavelmente multichain. Centenas de rollups, appchains e L2s foram lançados nos últimos 18 meses, cada um com suas próprias taxas, tempos de finalização, ferramentas e suposições de confiança.

Abordagens tradicionais de cross‑chain resolveram o transporte — mover tokens ou mensagens de A para B — mas não a experiência. As equipes ainda precisam gerenciar carteiras por rede, provisionar gás por cadeia, escolher uma ponte por rota e lidar com diferenças de segurança que não podem quantificar facilmente. Esse atrito é o verdadeiro imposto à adoção.

A abstração cross‑chain elimina esse imposto ao ocultar a seleção de cadeia e o transporte por trás de APIs declarativas, experiências orientadas por intenção e identidade e gás unificados. Em outras palavras, usuários e aplicações expressam o que desejam; a plataforma determina como e onde isso acontece, de forma segura. A abstração de cadeia torna a tecnologia blockchain invisível ao usuário final, preservando seus benefícios centrais.

Por Que 2025 é Diferente: Os Blocos de Construção Finalmente Se Encaixaram​

A visão de um mundo multichain perfeito não é nova, mas a tecnologia fundamental está finalmente pronta para produção. Vários componentes-chave amadureceram e convergiram, tornando a abstração robusta de cadeias possível.

• Unificação em Nível de Rede: Projetos agora constroem frameworks para que cadeias separadas pareçam uma única rede unificada. O OP Superchain visa padronizar L2s OP‑Stack com ferramentas e camadas de comunicação compartilhadas. O AggLayer da Polygon agrega muitas cadeias seguras por ZK com “provas pessimistas” para contabilidade em nível de cadeia, impedindo que problemas de uma cadeia contaminem outras. Enquanto isso, o IBC v2 expande a interoperabilidade padronizada além do ecossistema Cosmos, avançando para “IBC em todo lugar”.

• Trilhos de Interoperabilidade Maduros: O middleware para comunicação cross‑chain agora está testado em batalha e amplamente disponível. O Chainlink CCIP oferece transferência de tokens e dados de nível empresarial em um número crescente de cadeias. O LayerZero v2 fornece mensagens omnichain e tokens OFT padronizados com suprimento unificado. O Axelar entrega General Message Passing (GMP) para chamadas de contrato complexas entre ecossistemas, conectando cadeias EVM e Cosmos. Plataformas como Hyperlane permitem implantações permissionless, permitindo que novas cadeias se juntem à rede sem gatekeepers, enquanto o Wormhole oferece uma camada de mensagens generalizada usada em mais de 40 cadeias.

• Intenção & Abstração de Conta: A experiência do usuário foi transformada por dois padrões críticos. O ERC‑7683 padroniza intenções cross‑chain, permitindo que apps declarem metas e deixem uma rede de solucionadores compartilhada executá‑las eficientemente entre cadeias. Simultaneamente, as contas inteligentes EIP‑4337, combinadas com Paymasters, habilitam abstração de gás. Isso permite que uma aplicação patrocine taxas de transação ou que usuários paguem em stablecoins, essencial para fluxos que tocam múltiplas redes.

• Mobilidade Nativa de Stablecoins: O Cross‑Chain Transfer Protocol (CCTP) da Circle move USDC nativo entre cadeias via um processo seguro de queima‑e‑mint, reduzindo risco de ativos encapsulados e unificando liquidez. A versão mais recente, CCTP v2, corta ainda mais a latência e simplifica fluxos de trabalho de desenvolvedores, tornando a liquidação em stablecoin parte fluida da experiência abstraída.

Como a “Abstração Cross‑Chain” Se Apresenta em uma Pilha Empresarial​

Pense nisso como uma capacidade em camadas que pode ser adicionada a sistemas existentes. O objetivo é ter um único endpoint para expressar uma intenção e um plano de políticas único para governar sua execução em qualquer número de cadeias.

1. Identidade & Política Unificadas: No nível superior estão contas inteligentes (EIP‑4337) com controle de acesso baseado em funções, recuperação social e opções modernas de custódia como passkeys ou MPC. Isso é governado por um motor de políticas central que define quem pode fazer o quê, onde, usando listas de permissão e negação para cadeias, ativos e pontes específicos.

2. Abstração de Gás & Taxas: Paymasters removem a dor de “preciso de gás nativo na cadeia X”. Usuários ou serviços podem pagar taxas em stablecoins, ou a aplicação pode patrociná‑las integralmente, sujeito a políticas e orçamentos pré‑definidos.

3. Execução Orientada por Intenção: Usuários expressam resultados, não transações. Por exemplo, “trocar USDC por wETH e entregar ao wallet do fornecedor na cadeia Y antes das 17h”. O padrão ERC‑7683 define o formato desses pedidos, permitindo que redes de solucionadores compartilhem competição para executá‑los de forma segura e econômica.

4. Liquidação & Mensageria Programáveis: Nos bastidores, o sistema usa uma API consistente para selecionar o trilho correto para cada rota. Pode usar CCIP para transferência de token onde o suporte empresarial é crucial, Axelar GMP para chamada de contrato cross‑ecosistema, ou IBC onde a segurança de light‑client nativo se encaixa no modelo de risco.

5. Observabilidade & Conformidade por Defeito: Todo o fluxo é rastreável, da intenção inicial à liquidação final. Isso gera trilhas de auditoria claras e permite exportar dados para SIEMs existentes. Estruturas de risco podem ser programadas para aplicar allowlists ou acionar freios de emergência, por exemplo, pausando rotas se a postura de segurança de uma ponte se deteriorar.

Arquitetura de Referência​

De cima para baixo, um sistema com abstração de cadeia é composto por camadas claras:

• Camada de Experiência: Superfícies de aplicação que coletam intenções do usuário e ocultam completamente detalhes de cadeia, emparelhadas com fluxos de carteira tipo SSO usando contas inteligentes.
• Plano de Controle: Motor de políticas para gerenciar permissões, cotas e orçamentos. Essa camada integra‑se a KMS/HSM e mantém allowlists para cadeias, ativos e pontes. Também ingere feeds de risco para cortar rotas vulneráveis automaticamente.
• Camada de Execução: Roteador de intenções que seleciona o melhor trilho de interoperabilidade (CCIP, LayerZero, Axelar, etc.) baseado em política, preço e requisitos de latência. Um Paymaster trata das taxas, extraindo de um tesouro de gás agrupado e orçamentos em stablecoins.
• Liquidação & Estado: Contratos on‑chain canônicos para funções centrais como custódia e emissão. Um indexador unificado rastreia eventos cross‑chain e provas, exportando dados para um data‑warehouse ou SIEM para análise e conformidade.

Construir vs. Comprar: Como Avaliar Provedores de Abstração de Cadeia​

Ao selecionar um parceiro para fornecer capacidades de abstração de cadeia, as empresas devem fazer várias perguntas-chave:

• Segurança & Modelo de Confiança: Quais são as suposições de verificação subjacentes? O sistema depende de oráculos, conjuntos de guardiões, light clients ou redes de validadores? O que pode ser slashado ou vetado?
• Cobertura & Neutralidade: Quais cadeias e ativos são suportados hoje? Quão rápido novas podem ser adicionadas? O processo é permissionless ou controlado pelo provedor?
• Alinhamento com Padrões: A plataforma suporta padrões críticos como ERC‑7683, EIP‑4337, OFT, IBC e CCIP?
• Operações: Quais são os SLAs do provedor? Quão transparentes são sobre incidentes? Oferecem provas reproduzíveis, tentativas determinísticas e logs de auditoria estruturados?
• Governança & Portabilidade: Você pode trocar trilhos de interoperabilidade por rota sem reescrever sua aplicação? Abstrações neutras ao fornecedor são críticas para flexibilidade a longo prazo.
• Conformidade: Quais controles estão disponíveis para retenção e residência de dados? Qual é a postura SOC2/ISO? Você pode trazer seu próprio KMS/HSM?

Rollout Empresarial Pragmatico de 90 Dias​

• Dias 0–15: Baseline & Política: Inventariar todas as cadeias, ativos, pontes e carteiras em uso. Definir uma allowlist inicial e estabelecer regras de circuit‑breaker baseadas em um framework de risco claro.
• Dias 16–45: Prototipar: Converter uma jornada de usuário única, como um pagamento cross‑chain, para usar fluxo baseado em intenção com abstração de conta e paymaster. Medir impacto em abandono, latência e carga de suporte.
• Dias 46–75: Expandir Trilhos: Adicionar um segundo trilho de interoperabilidade ao sistema e rotear transações dinamicamente conforme política. Integrar CCTP para mobilidade nativa de USDC se stablecoins fizerem parte do fluxo.
• Dias 76–90: Endurecer: Conectar dados de observabilidade da plataforma ao seu SIEM, executar testes de caos em falhas de rota e documentar todos os procedimentos operacionais, incluindo protocolos de pausa de emergência.

Armadilhas Comuns (e Como Evitá‑las)​

• Roteamento Apenas por “Preço do Gás”: Latência, finalização e suposições de segurança importam tanto quanto taxas. Preço sozinho não é um modelo de risco completo.
• Ignorar o Gás: Se sua experiência toca múltiplas cadeias, abstração de gás não é opcional — é requisito básico para um produto utilizável.
• Tratar Pontes como Intercambiáveis: Elas não são. Suas suposições de segurança diferem significativamente. Codifique allowlists e implemente circuit‑breakers para gerenciar esse risco.
• Espalhamento de Ativos Encapsulados: Sempre que possível, prefira mobilidade nativa de ativos (como USDC via CCTP) para minimizar fragmentação de liquidez e reduzir risco de contraparte.

O Benefício Empresarial​

Quando a abstração de cadeia é bem feita, a blockchain deixa de ser uma coleção de redes idiossincráticas e se torna um tecido de execução que suas equipes podem programar. Ela oferece políticas, SLAs e trilhas de auditoria que correspondem aos padrões sob os quais você já opera. Graças a padrões de intenção maduros, abstração de conta, trilhos de interoperabilidade robustos e transporte nativo de stablecoins, você finalmente pode entregar resultados Web3 sem forçar usuários — ou seus próprios desenvolvedores — a se preocupar com qual cadeia fez o trabalho.

Alchemy é uma força dominante no espaço de infraestrutura Web3, servindo como ponto de entrada para milhares de desenvolvedores e projetos importantes como OpenSea. Ao analisar feedback público de usuários em plataformas como G2, Reddit e GitHub, podemos obter uma visão clara do que os desenvolvedores valorizam, onde eles têm dificuldades e como pode ser o futuro da experiência de desenvolvimento Web3. Isso não se trata apenas de um provedor; é um reflexo das necessidades amadurecidas de todo o ecossistema.

O que os Usuários Consistentemente Gostam​

Em sites de avaliação e fóruns, os usuários elogiam consistentemente a Alchemy por várias forças chave que consolidaram sua posição no mercado.

• “On‑ramp” sem Esforço & Facilidade de Uso: Iniciantes e pequenas equipes celebram a rapidez com que podem começar. Avaliações no G2 frequentemente destacam como uma “ótima plataforma para construir Web3”, elogiando sua configuração fácil e documentação abrangente. Ela abstrai com sucesso a complexidade de operar um nó.
• Painel Centralizado & Ferramentas: Desenvolvedores valorizam ter um único “centro de comando” para observabilidade. A capacidade de monitorar logs de requisições, visualizar análises, configurar alertas e rotacionar chaves de API em um único painel é um ganho significativo de experiência do usuário.
• Padrões Inteligentes do SDK: O Alchemy SDK lida com tentativas de requisição e back‑off exponencial por padrão. Esse recurso pequeno, porém crucial, salva desenvolvedores de escrever lógica boilerplate e reduz o atrito ao construir aplicações resilientes.
• Reputação de Suporte Forte: No mundo frequentemente complexo do desenvolvimento de blockchain, suporte responsivo é um grande diferencial. Sites de avaliação agregados como TrustRadius frequentemente citam a equipe de suporte útil da Alchemy como um benefício chave.
• Prova Social e Confiança: Ao apresentar estudos de caso com gigantes como OpenSea e garantir fortes endossos de parceiros, a Alchemy oferece segurança a equipes que estão escolhendo um provedor de RPC gerenciado.

Principais Pontos de Dor​

Apesar dos aspectos positivos, desenvolvedores encontram desafios recorrentes, especialmente à medida que suas aplicações começam a escalar. Esses pontos de dor revelam oportunidades críticas de melhoria.

• A “Parede Invisível” dos Limites de Throughput: A frustração mais comum é encontrar erros 429 Too Many Requests. Desenvolvedores se deparam com isso ao forkar a mainnet para testes, implantar em picos ou servir alguns usuários simultâneos. Isso gera confusão, especialmente em planos pagos, pois os usuários sentem que são limitados durante picos críticos. O impacto são pipelines CI/CD quebrados e testes instáveis, forçando desenvolvedores a implementar manualmente comandos sleep ou lógica de back‑off.
• Percepção de Baixa Concorrência: Em fóruns como Reddit, um relato comum é que planos de nível inferior só conseguem lidar com poucos usuários simultâneos antes que a limitação de taxa entre em vigor. Seja isso estritamente preciso ou dependente da carga de trabalho, a percepção leva equipes a considerar configurações multi‑provedor mais complexas ou a fazer upgrade antes do esperado.
• Timeouts em Consultas Pesadas: Chamadas JSON‑RPC intensas, particularmente eth_getLogs, podem gerar timeouts ou erros 500. Isso não só interrompe a experiência do cliente como pode travar ferramentas locais de desenvolvimento como Foundry e Anvil, resultando em perda de produtividade.
• Confusão entre SDK e Provedor: Novatos frequentemente enfrentam uma curva de aprendizado sobre o escopo de um provedor de nó. Por exemplo, perguntas no Stack Overflow mostram confusão quando eth_sendTransaction falha, sem perceber que provedores como Alchemy não armazenam chaves privadas. Erros opacos de chaves ou URLs de API mal configuradas também são obstáculos para quem está começando no ecossistema.
• Privacidade de Dados e Preocupações com Centralização: Um subconjunto vocal de desenvolvedores prefere RPCs auto‑hospedados ou focados em privacidade. Eles citam preocupações sobre grandes provedores centralizados registrarem endereços IP e potencialmente censurarem transações, destacando que confiança e transparência são fundamentais.
• Amplitude de Produto e Roteiro: Avaliações comparativas no G2 às vezes sugerem que concorrentes estão expandindo mais rápido para novos ecossistemas ou que a Alchemy está “ocupada focada em algumas cadeias”. Isso pode criar um descompasso de expectativas para equipes que constroem em cadeias não‑EVM.

Onde as Expectativas dos Desenvolvedores Quebram​

Esses pontos de dor costumam surgir em momentos previsíveis do ciclo de vida de desenvolvimento:

1. Protótipo para Testnet: Um projeto que funciona perfeitamente na máquina do desenvolvedor falha repentinamente em um ambiente CI/CD quando testes rodam em paralelo, atingindo limites de throughput.
2. Fork Local: Desenvolvedores usando Hardhat ou Foundry para forkar a mainnet para testes realistas são frequentemente os primeiros a relatar erros 429 e timeouts de consultas massivas de dados.
3. APIs de NFT/Dados em Escala: Eventos de mint ou carregamento de dados para grandes coleções de NFT podem facilmente sobrecarregar limites de taxa padrão, forçando desenvolvedores a buscar boas práticas de cache e batch.

Descobrindo o Núcleo dos “Jobs‑to‑be‑Done”​

Ao destilar esse feedback, revelam‑se três necessidades fundamentais dos desenvolvedores Web3:

• “Me dê uma única visão para observar e depurar.” Esse job é bem atendido pelo painel da Alchemy.
• “Torne minhas cargas de trabalho bursty previsíveis e gerenciáveis.” Desenvolvedores aceitam limites, mas precisam de manejo mais suave de picos, padrões melhores e scaffolds de código que funcionem out‑of‑the‑box.
• “Ajude‑me a ficar desbloqueado durante incidentes.” Quando algo dá errado, desenvolvedores precisam de atualizações claras de status, post‑mortems acionáveis e padrões de failover fáceis de implementar.

Oportunidades Acionáveis para um DX Melhor​

Com base nesta análise, qualquer provedor de infraestrutura poderia melhorar sua oferta ao abordar estas oportunidades:

• “Coach de Throughput” Proativo: Uma ferramenta no painel ou CLI que simula a carga planejada, prevê quando limites de CU/s (Unidades de Computação por segundo) podem ser atingidos e gera snippets de retry/back‑off configurados corretamente para bibliotecas populares como ethers.js, viem, Hardhat e Foundry.
• Templates de Caminho Dourado: Fornecer templates prontos, de produção, para pontos de dor comuns, como uma configuração de rede Hardhat para forkar a mainnet com concorrência conservadora, ou código de exemplo para batch de chamadas eth_getLogs com paginação eficiente.
• Capacidade de Burst Adaptativa: Oferecer “créditos de burst” ou um modelo de capacidade elástica em planos pagos para lidar melhor com picos de tráfego de curta duração. Isso atenderia diretamente a sensação de estar desnecessariamente limitado.
• Guias Oficiais de Failover Multi‑Provider: Reconhecer que dApps resilientes usam múltiplos RPCs. Fornecer receitas opinativas e código de exemplo para failover para um provedor de backup construiria confiança e alinharia com as melhores práticas do mundo real.
• Transparência Radical: Abordar diretamente preocupações de privacidade e censura com documentação clara e acessível sobre políticas de retenção de dados, o que é registrado e qualquer filtragem que ocorra.
• Relatórios de Incidente Acionáveis: Ir além de uma simples página de status. Quando um incidente ocorre (como a latência na região da UE em 5‑6 de agosto de 2025), acompanhá‑lo com uma breve Análise de Causa Raiz (RCA) e conselhos concretos, como “o que você pode fazer agora para mitigar”.

Conclusão: Um Roteiro para Infraestrutura Web3​

O feedback de usuários sobre a Alchemy fornece um roteiro valioso para todo o espaço de infraestrutura Web3. Enquanto a plataforma se destaca ao simplificar a experiência de onboarding, os desafios enfrentados pelos usuários ao escalar, prever e buscar transparência apontam para a próxima fronteira da experiência do desenvolvedor.

À medida que a indústria amadurece, as plataformas vencedoras serão aquelas que não apenas fornecem acesso confiável, mas também capacitam desenvolvedores com ferramentas e orientações para construir aplicações resilientes, escaláveis e confiáveis desde o primeiro dia.

A QuickNode se destaca como um pilar no cenário de infraestrutura Web3, elogiada por sua velocidade e amplo suporte multi‑chain. Para entender o que a torna a escolha preferida de tantos desenvolvedores — e onde a experiência pode ser aprimorada — sintetizamos uma ampla variedade de feedback público de usuários de plataformas como G2, Reddit, Product Hunt e Trustpilot.

Esta análise revela uma história clara: embora os desenvolvedores amem o produto principal, a jornada do usuário não está isenta de obstáculos, particularmente em relação ao custo.

Os Pontos Altos: O que os Usuários Amam na QuickNode​

De modo geral, os usuários celebram a QuickNode por oferecer uma experiência de desenvolvedor premium e sem atritos, construída sobre três pontos fortes principais.

🚀 Desempenho Ultrarrápido & Confiabilidade Inabalável​

Esta é a funcionalidade mais elogiada da QuickNode. Os usuários descrevem consistentemente o serviço como "ultrarrápido" e "o provedor RPC mais performático e confiável disponível". Respostas de baixa latência, frequentemente abaixo de 100 ms, e um tempo de atividade alegado de 99,99 % dão aos desenvolvedores a confiança para construir e escalar dApps responsivos.

Como observou um cliente corporativo da Nansen, a QuickNode fornece "nós robustos, de baixa latência e alto desempenho" capazes de lidar com bilhões de solicitações. Esse desempenho não é apenas um número; é uma funcionalidade crítica que garante uma experiência fluida ao usuário final.

✅ Integração Sem Esforço & Interface Intuitiva​

Os desenvolvedores costumam estar "prontos e funcionando em minutos". A plataforma é frequentemente elogiada por seu painel limpo e fluxos de trabalho intuitivos que abstraem as complexidades de operar um nó.

Um desenvolvedor no Reddit chamou a interface de "óbvia", enquanto um desenvolvedor full‑stack destacou que "criar uma conta e provisionar um nó leva minutos, sem nenhum trabalho complexo de DevOps". Essa facilidade de uso torna a QuickNode uma ferramenta indispensável para prototipagem e testes rápidos.

🤝 Suporte ao Cliente de Alto Nível & Documentação​

Suporte e documentação excepcionais são temas recorrentes. A equipe de suporte é descrita como "rápida ao responder e genuinamente prestativa", um recurso crucial ao solucionar problemas sensíveis ao tempo.

A documentação da API recebe elogios universais por ser clara, completa e amigável para iniciantes, com um usuário chamando os tutoriais de "bem elaborados". Esse investimento em recursos para desenvolvedores reduz significativamente a barreira de entrada e diminui o atrito na integração.

Os Obstáculos: Onde os Usuários Encontram Desafios​

Apesar do desempenho excepcional e da experiência do usuário, duas áreas‑chave de atrito surgem do feedback, principalmente relacionadas ao custo e às limitações de recursos.

💸 O Dilema dos Preços​

O preço é, de longe, o ponto de crítica mais comum e carregado emocionalmente. O feedback revela uma história de duas bases de usuários:

• Para Empresas, o custo costuma ser visto como um investimento justo pela performance premium e confiabilidade.
• Para Startups e Desenvolvedores Independentes, o modelo pode ser proibitivo.

As questões principais são:

1. Saltos Abruptos Entre Camadas: Usuários observam um "salto significativo do plano ‘Build’ de US$49 para o plano ‘Accelerate’ de US$ 249", desejando uma camada intermediária que suporte melhor projetos em crescimento.
2. Taxas de Excesso Punitivas: Este é o ponto de dor mais significativo. A política da QuickNode de cobrar automaticamente por outro bloco completo de solicitações após exceder a cota — sem opção de limitar o uso — é uma fonte de grande frustração. Um usuário descreveu como um "excesso inadvertido de apenas 1 milhão de solicitações pode gerar US$ 50 adicionais". Essa imprevisibilidade levou um cliente de longa data no Trustpilot a chamar o serviço de "o maior golpe…fique longe" após acumular altas taxas.

Como resumiu perfeitamente um revisor do G2, "a estrutura de preços poderia ser mais amigável para startups".

🧩 Lacunas de Recursos de Nicho​

Embora o conjunto de recursos da QuickNode seja robusto, usuários avançados apontaram algumas lacunas. Solicitações comuns incluem:

• Suporte a Protocolos Mais Amplos: Usuários manifestaram desejo por cadeias como Bitcoin e L2s mais recentes como Starknet.
• Ferramentas Mais Poderosas: Alguns desenvolvedores compararam a QuickNode com concorrentes, observando que faltam "recursos como suporte a webhooks mais avançado".
• Autenticação Moderna: Um usuário de longo prazo desejava suporte a OAuth para melhor gerenciamento de chaves de API em ambientes corporativos.

Essas lacunas não diminuem a oferta central para a maioria dos usuários, mas destacam áreas onde os concorrentes podem ter vantagem para casos de uso específicos.

Principais Lições para o Espaço de Infraestrutura Web3​

O feedback sobre a QuickNode oferece lições valiosas para qualquer empresa que construa ferramentas para desenvolvedores.

• Desempenho é o Básico: Velocidade e confiabilidade são a base. Sem elas, nada mais importa. A QuickNode estabelece um padrão elevado aqui.
• Experiência do Desenvolvedor é o Diferencial: Uma UI limpa, integração rápida, documentação excelente e suporte responsivo constroem uma base fiel e criam um produto que os desenvolvedores realmente gostam de usar.
• Previsibilidade de Preços Constrói Confiança: Esta é a lição mais crítica. Modelos de preço ambíguos ou punitivos, especialmente aqueles com excessos sem limite, geram ansiedade e destroem a confiança. Um desenvolvedor que recebe uma fatura surpresa dificilmente permanecerá um cliente feliz a longo prazo. Preços previsíveis, transparentes e amigáveis para startups são uma enorme vantagem competitiva.

Conclusão​

A QuickNode conquistou, com razão, sua reputação como provedor de infraestrutura de alto nível. Ela cumpre sua promessa de alto desempenho, confiabilidade excepcional e uma experiência de desenvolvedor exemplar. Contudo, seu modelo de preços cria atritos significativos, particularmente para startups e desenvolvedores independentes que são a força vital da inovação Web3.

Este feedback dos usuários serve como um lembrete poderoso de que construir uma plataforma de sucesso não se trata apenas de excelência técnica; trata‑se de alinhar seu modelo de negócios com as necessidades e a confiança de seus usuários. O provedor de infraestrutura que conseguir equiparar o desempenho da QuickNode oferecendo uma estrutura de preços mais transparente e previsível estará extremamente bem posicionado para o futuro.