9 posts marcados com "Account Abstraction"

Por cinco anos, "insuficiente SOL para transação" tem sido a mensagem de erro mais cara da Solana. Cada aplicativo de consumo que tentou atrair um usuário não familiarizado com cripto perdeu uma porcentagem deles ali mesmo — na etapa de checkout, onde um estranho precisa adquirir um segundo token apenas para gastar o primeiro. Em abril de 2026, a Solana Foundation finalmente lançou a resposta: Kora, um relayer de taxas e nó de assinatura que permite que dApps patrocinem transações nativamente, paguem taxas em qualquer token SPL e terceirizem a assinatura para TEEs ou cofres baseados em KMS. Não é um lançamento chamativo. É uma atualização de infraestrutura básica. E atualizações de infraestrutura são como a Base e a Abstract capturaram silenciosamente os últimos doze meses de integração de usuários.

A questão não é mais se a Solana pode igualar a UX sem gás das cadeias de consumo EVM. O Kora torna essa parte trivial. A questão é se fechar essa lacuna de "última milha" é o suficiente para reconquistar os desenvolvedores que já construíram em outro lugar.

O que o Kora Realmente Entrega​

Remova o marketing e o Kora é composto por três coisas unidas: um relayer de transação, um assinante remoto e um mecanismo de política. Um dApp constrói uma transação, define um nó Kora como o pagador da taxa, o usuário assina o payload a partir de uma carteira incorporada e o operador do Kora assina em conjunto e faz o broadcast. Os validadores ainda são pagos em SOL. O usuário nunca detém nenhum.

O que o torna interessante é a camada de validação. Um nó Kora não repassa cegamente qualquer coisa que os usuários lhe entreguem. Ele realiza três verificações antes de assinar:

• Validação de instruções em relação aos programas Solana associados, para que instruções malformadas ou maliciosas sejam rejeitadas antes de atingirem um líder.
• Adequação de taxas apoiada por oráculos, comparando a quantidade de token SPL oferecida com o preço atual do SOL mais a margem do operador, para que o relayer nunca opere com prejuízo.
• Aplicação de listas de permissão e listas de bloqueio no nível do programa e do token, para que um operador que execute um nó Kora para um único dApp nunca patrocine acidentalmente uma transação visando algum contrato aleatório não auditado.

O caminho de assinatura é onde a arquitetura se torna ambiciosa. O Kora suporta assinatura remota através do Turnkey e AWS KMS nativamente, o que significa que a chave privada que paga as taxas nunca reside no disco do relayer. Para uma fintech construindo na Solana, essa é a diferença entre "nós criamos nosso próprio paymaster e cruzamos os dedos" e "nossa história de custódia de chaves passa por uma auditoria SOC 2".

Tudo foi auditado e testado por fuzzing diferencial pela Runtime Verification, que é o tipo de detalhe que você menciona apenas quando espera que instituições leiam os pormenores.

Por que o "Nativo" Vence o "Contrato Inteligente" Aqui​

A tentação é comparar o Kora ao ERC-4337 e assumir que a Solana está se recuperando. As arquiteturas estão fazendo coisas diferentes, e a diferença importa.

O ERC-4337 é a abstração de conta implementada como um sistema paralelo no topo do Ethereum. Ele introduz uma mempool separada, um objeto UserOperation, uma função de bundler e um contrato EntryPoint — nada disso o protocolo base entende nativamente. Os bundlers agrupam as operações do usuário, os paymasters patrocinam as taxas e um contrato on-chain impõe a validação. Ele funciona, e foi implantado na rede principal do Ethereum e em grandes L2s, mas é um projeto de construção de seis anos para adaptar um recurso de UX que o protocolo nunca previu.

O design da Solana absorveu essa complexidade na camada de protocolo anos atrás. Cada transação já possui um campo feePayer. Assinaturas parciais são nativas. Programas podem validar instruções arbitrárias. O Kora não é uma construção de bundler e paymaster; é um operador de nó que preenche o slot feePayer e assina com uma das assinaturas parciais que o protocolo já aceita.

A consequência prática é a latência e a área de superfície do desenvolvedor. As transações ERC-4337 passam por uma mempool separada com suas próprias regras de ordenação e atrasos de propagação. As transações Kora passam pelo mesmo caminho que qualquer outra transação Solana, com a mesma finalidade inferior a 400 ms. Não há mercado de arbitragem de bundlers para se preocupar, nenhuma versão de contrato EntryPoint para rastrear, nenhuma estimativa de gás de UserOperation para depurar.

O que isso oferece aos desenvolvedores da Solana é algo próximo a "defina o campo do pagador de taxas, lance o dApp". O que se perde é parte da opcionalidade que as contas inteligentes EVM obtêm gratuitamente — autenticação de múltiplas chaves, chamadas em lote, políticas de sessão on-chain — embora muito disso esteja sendo construído separadamente na Solana através de PDAs e contas controladas por programas.

A Lacuna de "Última Milha" que a Solana Realmente Tinha​

Apesar de toda a conversa sobre o ímpeto dos desenvolvedores da Solana em 2025 e 2026, a camada de carteira de consumo foi a parte que ficou para trás. A pilha de infraestrutura amadureceu rápido: o volume DEX da Pump.fun ultrapassou US$ 2 bilhões no primeiro trimestre de 2026, Jito e Marinade dominam o staking líquido, a Tensor transformou a negociação de NFTs em um terminal profissional. Mas cada um desses produtos teve que lançar sua própria resposta para "o usuário não tem SOL".

As soluções improvisadas tornaram-se criativas. A Pump.fun roteou as aquisições iniciais de tokens através de onramps integrados. A Jito pré-financiou contas de usuários com pequenas quantias (dust). A Tensor apoiou-se na Phantom e na Backpack para lidar com a etapa de aquisição de SOL antes que os usuários chegassem ao livro de ofertas. Cada uma delas funcionou individualmente e nenhuma delas era composta. Um usuário que fizesse o onboarding através do fluxo da Pump.fun não chegava à Tensor com um saldo para pagamento de taxas.

Enquanto isso, a Base lançou o fluxo de passkey da Coinbase Smart Wallet, patrocínio de gás gratuito através da Coinbase Developer Platform e um SDK para desenvolvedores que esconde todo o conceito de uma chave privada por trás do login por e-mail. A Abstract levou a mesma ideia adiante com carteiras incorporadas que parecem aplicativos Web2. A proposta combinada para um desenvolvedor de aplicativos de consumo em 2025 era: construa na Base, seus usuários não saberão que estão on-chain e nós pagaremos as taxas enquanto você escala.

O Kora não replica essa proposta linha por linha. O que ele faz é remover a razão arquitetônica pela qual um dApp Solana não poderia fazer a mesma proposta. Com o Kora, uma equipe Solana pode agora oferecer:

• Cadastro por e-mail ou passkey através de Privy, Turnkey ou Coinbase Embedded Wallets.
• Saldo zero de SOL necessário para transacionar.
• Taxas pagas em USDC, BONK ou no token nativo do dApp, se houver.
• Finalidade abaixo de um segundo sem nenhum bundler no caminho.

As peças já existiam antes. O Octane foi o ancestral de código aberto. Circle's Gas Station, Openfort, Portal, Gelato, Biconomy e meia dúzia de outros fornecedores ofereciam o repasse de taxas como um serviço. O que o Kora muda é que a própria Solana Foundation está agora lançando a implementação de referência padrão, auditada e compatível com KMS. Isso remove a pergunta "em qual paymaster de terceiros confiamos" da árvore de decisão de cada equipe que anteriormente estava criando o seu próprio ou pagando a um fornecedor.

A Camada de Fornecedores Acima da Kora​

O ponto onde as coisas ficam interessantes é o que acontece com os fornecedores de carteiras incorporadas (embedded wallets) que já construíram soluções em torno da lacuna que a Kora acaba de fechar.

A Privy, adquirida pela Stripe em junho de 2025, tem sido a carteira de escolha para apps de consumo em dApps da Solana que desejam login por e-mail. A Solana é oficialmente uma rede secundária para a Privy — a profundidade está na EVM — mas o fluxo de carteira incorporada se estende à Solana, e a Privy já suporta a configuração de uma carteira pagadora de taxas (fee payer) que o app gerencia. A Kora não substitui a Privy; ela fornece à Privy um backend padronizado para se conectar, em vez de cada cliente rodar seu próprio serviço de paymaster.

A Turnkey é o signatário incorporado focado em segurança que se combina naturalmente com a API de assinatura remota da Kora. A Turnkey explicitamente não inclui infraestrutura de paymaster, portanto, as equipes da Solana que desejam chaves isoladas por hardware combinadas com uma UX gasless (sem taxas) foram forçadas a unir dois fornecedores. A Kora simplifica essa integração.

A Dynamic, adquirida pela Fireblocks em 2025, traz autenticação multi-chain para equipes institucionais. O posicionamento apoiado pela Fireblocks torna a Dynamic a escolha natural para fintechs que precisam de cobertura tanto para Solana quanto para EVM com conformidade empresarial. A Kora oferece à Dynamic uma narrativa limpa de abstração de taxas na Solana que não exige que a Fireblocks lance um paymaster concorrente.

A Coinbase Developer Platform está em uma posição desconfortável. A Coinbase investiu pesadamente em tornar a Base a rede de consumo padrão por meio da Coinbase Smart Wallet, taxas gratuitas na Base e o SDK de carteira incorporada. A Kora reduz a diferenciação que a Base vem vendendo, especialmente para apps que desejam fluxos nativos de USDC, onde a Solana já possui vantagens de escala.

O resultado provável é que a Kora se torne o backend padrão da Solana para todos os fornecedores de carteiras incorporadas que não quiseram operar um serviço de paymaster por conta própria. Os fornecedores competem na UX de autenticação, gerenciamento de chaves e controles de política. A Kora cuida do relay de taxas por baixo. Isso é mais saudável para o ecossistema do que o estado anterior, onde cada dApp de consumo na Solana tomava uma decisão de fornecedor independente e tinha que avaliar a segurança do relayer próprio de cada candidato.

O Que Isso Resolve e O Que Não Resolve​

A Kora fecha uma lacuna definitivamente e deixa várias outras abertas. Vale a pena ser preciso sobre o que é o quê.

O que a Kora resolve:

• O abismo de UX de que o "usuário deve possuir SOL" para qualquer dApp disposto a subsidiar taxas em outro token.
• A decisão de "construir vs comprar um paymaster" para equipes que anteriormente tinham que escolher entre carga operacional e dependência de fornecedor (vendor lock-in).
• A lacuna de aceitabilidade institucional, já que a auditoria e o suporte a KMS permitem que entidades regulamentadas operem nós da Kora sem criar os seus próprios.

O que a Kora não resolve:

• A aquisição de carteira em si — os usuários ainda precisam de uma carteira incorporada de algum lugar, seja Phantom, Privy, Turnkey ou Coinbase.
• Primitivas de abstração de conta, como chamadas em lote (batched calls) e chaves de sessão, que ainda estão sendo montadas separadamente na Solana através de PDAs e outros padrões de nível de programa.
• A questão econômica de quem paga pelo SOL que os operadores da Kora adiantam. Para um dApp com receita de token ou uma reserva de stablecoin, isso é aceitável; para um produto gratuito, o patrocínio de taxas é apenas um custo de aquisição de cliente.
• A UX cross-chain, que ainda exige que o usuário interaja com uma ponte ou uma camada de abstração de rede como LayerZero, Wormhole ou Across.

A tese da "infraestrutura gasless como primitiva de protocolo" corta para os dois lados. A Solana agora tem a história de abstração de taxas nativa mais limpa de qualquer grande rede. Isso também significa que a diferenciação sobe na pilha para a UX da carteira, fluxos de recuperação e recursos de abstração de conta, onde a EVM tem uma vantagem de vários anos.

A Leitura Estratégica para Construtores​

Para uma equipe escolhendo uma rede em meados de 2026, o cálculo mudou. Doze meses atrás, a resposta para o onboarding de consumidores era Base, Abstract ou uma das novas redes de consumo EVM, ponto final. A Solana tinha a atenção dos desenvolvedores e ímpeto de infraestrutura, mas perdia usuários de varejo para a etapa de aquisição de SOL. Isso não é mais verdade.

Um dApp de consumo lançado hoje na Solana com Privy ou Turnkey no front-end e Kora no back-end tem funcionalmente a mesma superfície de UX que o stack equivalente na Base. Login por e-mail, transações sem taxas, pagamento de taxas em USDC, finalidade abaixo de um segundo. As diferenças restantes são o modelo de runtime, o ecossistema de ferramentas e a liquidez disponível. Para um app que deseja o throughput da Solana e a profundidade das DEXs, o argumento de UX para escolher EVM tornou-se substancialmente mais fraco.

Para equipes que já estão operando na Base, a Kora não muda a decisão imediata. Ela muda a pressão competitiva de longo prazo. Se os dApps de consumo com a UX mais limpa começarem a aparecer na Solana porque a nova infraestrutura é uma integração a menos com que se preocupar, a gravidade em torno do fosso de onboarding de consumidores da Base começa a mudar.

A leitura honesta é que a Kora é necessária, mas não suficiente. Ela remove um motivo específico pelo qual os desenvolvedores não estavam escolhendo a Solana para apps de consumo. Ela não cria, por si só, um novo motivo para escolher a Solana. Os próximos dois trimestres mostrarão se os fornecedores de carteiras incorporadas realmente adotarão a Kora por padrão, se novos dApps de consumo a citarão como um motivo para sua escolha de rede e se as redes de consumo EVM existentes responderão melhorando suas próprias histórias de infraestrutura.

De qualquer forma, "o usuário deve adquirir SOL antes de transacionar" é finalmente um problema do passado, não um problema atual. Só isso já vale o lançamento.

BlockEden.xyz opera infraestrutura RPC da Solana de nível de produção para equipes que constroem dApps de consumo, trilhos de pagamento e sistemas de negociação. Se você está integrando fluxos sem taxas ou escalando um produto na Solana, explore nosso marketplace de APIs para endpoints de baixa latência projetados para a próxima geração de cripto para consumidores.

Fontes​

• GitHub: solana-foundation/kora
• Kora — Nunca mais perca um usuário por 'SOL insuficiente'
• Como Habilitar Transações Sem Gas na Solana com Kora — QuickNode
• Solana Foundation Introduz Kora — Metaverse Post
• Relayer de Taxas Kora Permite Onboarding e Taxas em Aplicativos Solana — Cryptonomist
• Patrocínio de Taxas — Solana Cookbook
• O que é ERC-4337 na Solana? — Solana Developers
• Abstração de Conta: Ethereum vs Solana Explicado — Squads
• Como o Gas Station da Circle usa Pagadores de Taxas na Solana
• Patrocinando transações na Solana — Privy Docs
• Melhores Carteiras Solana para Desenvolvedores em 2026 — Openfort
• Coinbase Smart Wallet — Estado das Carteiras Parte 2
• Anza descreve os principais desenvolvimentos para a Solana em 2026 — Phemex

E se o seu grafo social, o mapa invisível de cada pessoa que você segue, cada post que você curtiu, cada criador para quem você enviou uma gorjeta, não estivesse trancado dentro de um banco de dados corporativo? E se a migração de 650.000 perfis, 28 milhões de conexões sociais e 12 milhões de posts para uma blockchain novinha em folha pudesse acontecer em um único fim de semana, sem que nenhum desses usuários precisasse mover um dedo?

É exatamente isso que o Lens realizou quando lançou a Lens Chain e o Lens V3. E ao fazer isso, o projeto fez uma das maiores apostas na Web3 até o momento: que o SocialFi, a mídia social descentralizada com monetização integrada, precisa de sua própria Camada 2 construída para esse fim, e não de uma rede de propósito geral compartilhada com bots de DeFi e negociadores de NFTs. A pilha de tecnologia escolhida? A ZK Stack da ZKsync para execução, Avail para disponibilidade de dados e a stablecoin GHO da Aave como o token de gás.

É uma aposta opinativa. Mas também pode ser a aposta correta.

Imagine dizer a um bot DeFi: "troque todo o meu WETH por USDC, forneça-o ao Aave, mas somente se meu saldo final permanecer acima de $5.000." Hoje, essa instrução exige que um desenvolvedor codifique cada parâmetro antes da assinatura — o saldo exato de WETH, a saída esperada de USDC, o valor do depósito no Aave — criando uma transação frágil que falha no momento em que as condições de mercado mudam entre o bloco em que foi assinada e o bloco em que é incluída on-chain. O ERC-8211, publicado em 6 de abril de 2026, pela Biconomy e pela Ethereum Foundation, elimina essa fragilidade por completo. É o primeiro padrão Ethereum que permite a agentes de IA ler o estado da blockchain em tempo real, validar condições e executar estratégias de múltiplas etapas em uma única transação atômica — transformando chamadas em lote estáticas em fluxos de trabalho inteligentes e auto-ajustáveis.

O momento não é coincidência. Mais de 17.000 agentes de IA estão ativos somente no Virtuals Protocol. O AgentKit da Coinbase alimenta carteiras autônomas em múltiplos provedores de LLM. O cofundador da NEAR declarou que "os usuários da blockchain serão agentes de IA." Mas até agora, esses agentes foram forçados a interagir com DeFi por meio dos mesmos formatos rígidos de transação projetados para humanos clicando botões em uma interface. O ERC-8211 oferece algo fundamentalmente diferente: a capacidade de compor decisões on-chain, no momento da execução, com mecanismos de segurança integrados.

O Problema: Batching Estático Nunca Foi Construído para Agentes Autônomos​

Contratos multi-call como Multicall3 e bundlers ERC-4337 já permitem que carteiras agrupem múltiplas transações em uma só. Mas cada parâmetro deve ser travado no momento da assinatura. Se um agente de IA assina um lote para trocar 2,5 WETH por USDC e fornecer os rendimentos ao Aave, o valor de 2,5 WETH fica congelado — mesmo que o saldo real do agente tenha mudado entre a assinatura e a execução devido a uma transferência pendente ou dedução de taxa.

Isso cria três problemas em cascata para agentes autônomos:

• Estado obsoleto: No momento em que uma transação em lote é incluída em um bloco, o estado on-chain que ela pressupunha pode não ser mais válido. Uma variação de preço de 0,3% pode fazer um swap reverter, desperdiçando gas e deixando a estratégia parcialmente executada.
• Superespecificação: Os agentes devem pré-calcular cada valor intermediário (valores exatos de saída, limites de slippage, quantidades de depósito) antes de assinar. Para um loop de alavancagem de cinco etapas, isso significa prever cinco saídas sequenciais — qualquer uma delas pode invalidar o restante.
• Sem lógica condicional: Lotes estáticos são tudo ou nada. Não há como dizer "prossiga com a etapa três somente se o resultado da etapa dois exceder um limite." Um agente não consegue expressar restrições de segurança dentro do próprio lote.

O resultado é que os agentes de IA de hoje executam estratégias DeFi com a flexibilidade de um cartão de embarque impresso — cada detalhe deve estar correto antes da partida, e qualquer mudança exige começar tudo de novo.

Como o ERC-8211 Funciona: Fetchers, Constraints e Predicates​

O ERC-8211 introduz o que a Biconomy chama de "smart batching" — um padrão de codificação em nível de contrato onde cada parâmetro em um lote declara como obter seu valor e quais condições esse valor deve satisfazer. O padrão é construído sobre três primitivas:

Fetchers​

Cada parâmetro de entrada carrega um tipo de fetcher que determina como seu valor é obtido no momento da execução, não no momento da assinatura. Três tipos de fetcher estão disponíveis:

• RAW_BYTES: O valor é codificado diretamente, idêntico ao batching tradicional.
• STATIC_CALL: O valor é lido a partir de uma chamada de contrato on-chain em tempo real — verificando um saldo, consultando o preço de um oráculo ou lendo as reservas de um pool.
• BALANCE: O valor é o saldo de token nativo ou ERC-20 da conta executora no momento da execução.

Um destino de roteamento então determina para onde o valor resolvido vai: no endereço de destino da chamada, no campo de valor ou no calldata.

Constraints​

Cada valor resolvido pode carregar constraints inline — verificações lógicas validadas on-chain antes que a chamada prossiga. Os tipos de constraint suportados incluem EQ (igual), GTE (maior ou igual), LTE (menor ou igual) e IN (pertencimento a um conjunto). Se qualquer constraint falhar, o lote inteiro reverte atomicamente.

Na prática, isso significa que um agente pode dizer: "Obtenha meu saldo de WETH (fetcher BALANCE), confirme que é GTE 1.0 WETH (constraint), então passe o valor resolvido para o calldata do swap (roteamento)."

Predicates​

Entradas com target = address(0) atuam como pontos de verificação de asserção pura. Elas codificam uma condição booleana sobre o estado da blockchain — por exemplo, verificando que o saldo de USDC de uma carteira permanece acima de um piso de segurança após um loop de alavancagem — sem executar nenhuma chamada externa. Se o predicate falhar, o lote reverte.

Juntas, essas três primitivas transformam um lote de um script estático em um programa reativo: "Troque meu saldo completo de WETH por USDC, então forneça exatamente o que chegou ao Aave, mas somente se meu saldo final exceder meu piso de segurança." Tudo em uma transação, tudo resolvido no momento da execução.

A Pilha Emergente de Protocolos para Agentes​

O ERC-8211 não existe isoladamente. Ele se encaixa em uma pilha de protocolos cada vez mais coerente que a Ethereum Foundation vem montando especificamente para agentes autônomos:

A analogia não é acidental: o ERC-8004 identifica quem está transacionando, o ERC-8183 governa qual trabalho está sendo trocado, o ERC-8211 lida com como o trabalho é executado on-chain, e o x402 gerencia como os pagamentos fluem entre agentes. Juntos, eles formam o que observadores da indústria começaram a chamar de "momento TCP/IP para IA on-chain" — uma pilha em camadas onde cada protocolo trata de uma preocupação de forma limpa.

O ERC-8183 é particularmente complementar. Sua primitiva Job — onde um agente cliente contrata um agente provedor, fundos em custódia são mantidos e um avaliador atesta a entrega — gera exatamente o tipo de ações on-chain de múltiplas etapas e condicionais que o ERC-8211 foi projetado para executar. Um agente de IA aceitando um trabalho através do ERC-8183 pode precisar realizar uma série de operações DeFi (swap, fornecimento, empréstimo) como parte do cumprimento do trabalho. O ERC-8211 garante que essas operações sejam executadas corretamente mesmo que as condições de mercado mudem entre a aceitação do trabalho e a execução.

Abordagens Concorrentes: AgentKit, NEAR Chain Signatures e o Risco de Fragmentação​

O smart batching do ERC-8211 não é o único framework disputando para se tornar a camada de execução padrão para agentes de IA:

Coinbase AgentKit fornece infraestrutura de carteira e primitivas de ação on-chain para agentes de IA, com suporte nativo para modelos OpenAI, Anthropic e Llama. Em março de 2026, a World (projeto de identidade de Sam Altman) lançou uma integração do AgentKit com pagamentos x402 e verificação World ID, permitindo que agentes carreguem prova criptográfica de respaldo humano. O AgentKit se destaca em gerenciamento de carteiras e transações simples, mas atualmente não oferece a execução condicional e ciente de estado que o ERC-8211 proporciona.

NEAR Chain Signatures adota uma abordagem arquitetural diferente: os agentes obtêm suas próprias contas NEAR com chaves privadas armazenadas em Ambientes de Execução Confiável (TEEs), e por meio da tecnologia Chain Signatures, podem assinar transações em qualquer blockchain — Ethereum, Bitcoin, Solana — a partir de uma única identidade baseada na NEAR. Isso resolve o problema multi-chain de forma elegante, mas opera na camada de infraestrutura e não na camada de semântica de execução.

O Trusted Agent Protocol da Visa e o AP2 (Agent Payment Protocol 2.0) do Google abordam o lado de pagamento e verificação de comerciantes, ajudando o comércio tradicional a reconhecer e processar transações de agentes de IA. Eles complementam, em vez de competir com, o foco de execução on-chain do ERC-8211.

O risco de fragmentação é real. Se o AgentKit construir suas próprias primitivas de execução condicional, ou se a NEAR desenvolver um padrão concorrente de execução em lote, os agentes poderão enfrentar os mesmos desafios de interoperabilidade que prejudicaram o DeFi nos seus primórdios — múltiplos padrões resolvendo o mesmo problema, nenhum alcançando massa crítica. A vantagem do ERC-8211 é sua compatibilidade com a infraestrutura existente de account abstraction (ERC-4337, ERC-7683) e sua pegada mínima: não requer fork de protocolo, nenhum novo opcode, e funciona com qualquer implementação de smart account.

Por Que Isso Importa: A Economia de 400.000 Agentes Precisa de Composabilidade On-Chain​

Os números pintam um quadro claro de urgência. Mais de 400.000 agentes de IA estão operando em redes blockchain, de acordo com estimativas da Chainalysis. Somente o Virtuals Protocol ultrapassou $39,5 milhões em receita acumulada com seus mais de 17.000 agentes. O AgentKit da Coinbase suporta carteiras autônomas em todos os principais LLMs. A economia de agentes não é especulativa — está gerando receita real e executando transações reais hoje.

Mas esses agentes estão limitados por uma infraestrutura projetada para usuários humanos. Um humano assinando um swap no Uniswap pode verificar o preço, ajustar o slippage e confirmar — tudo em segundos. Um agente autônomo operando em escala não pode se dar ao luxo desse ciclo de feedback manual. Ele precisa expressar estratégias complexas como pacotes de transações autocontidos e auto-validados que executam corretamente independentemente do que aconteça entre a assinatura e a inclusão.

O impacto do ERC-8211 vai além da automação DeFi. Considere estes cenários:

• Gestão autônoma de tesouraria: Um agente de tesouraria de DAO que rebalanceia entre protocolos de rendimento, com verificações de predicate garantindo que nenhum protocolo individual detenha mais de 30% dos fundos — tudo em uma única transação atômica.
• Execução resistente a MEV: Ao resolver valores no momento da execução em vez do momento da assinatura, os smart batches reduzem a informação disponível para buscadores de MEV que exploram parâmetros obsoletos em transações pendentes.
• Arbitragem entre protocolos: Um agente que detecta uma discrepância de preço entre Uniswap e Curve pode executar a arbitragem atomicamente com constraints garantindo limites mínimos de lucro, eliminando o risco de executar uma ponta e falhar na outra.

O Caminho Adiante: De Padrão a Infraestrutura​

O ERC-8211 ainda é uma proposta ERC, não um padrão finalizado. Sua implementação de referência é open-source e está disponível em forma de demonstração, mas a adoção depende de provedores de carteira, operadores de bundler e protocolos DeFi integrarem a interface de smart batching. O design agnóstico de conta do padrão — funciona com smart accounts ERC-4337, intents cross-chain ERC-7683 e EOAs tradicionais através de contratos executores — remove a maior barreira de adoção, mas a integração ainda requer desenvolvimento ativo.

A pilha de quatro padrões para agentes (ERC-8004 + ERC-8183 + ERC-8211 + x402) representa uma visão coerente, mas visões coerentes em cripto historicamente se fragmentaram sob pressão competitiva. Se a pilha se consolida em um padrão de facto ou se divide em implementações concorrentes dependerá de quais protocolos entregarão integrações em produção primeiro.

O que não está em dúvida é a direção. Os principais usuários da blockchain estão mudando de humanos clicando em interfaces para agentes autônomos executando estratégias programáticas. O ERC-8211 é a primeira tentativa séria de dar a esses agentes um formato de transação que corresponda às suas capacidades — um que pensa antes de transacionar.

Construindo agentes de IA que interagem com protocolos DeFi em múltiplas blockchains? BlockEden.xyz oferece endpoints RPC de alto desempenho e APIs de dados para Ethereum, Sui, Aptos e mais de 20 redes — a camada de infraestrutura que seus agentes precisam para leituras e execuções on-chain confiáveis. Explore nosso marketplace de APIs para começar.

Durante quinze anos, a experiência de onboarding das criptomoedas esteve imperdoavelmente quebrada. Novos usuários baixam uma carteira, são bombardeados com doze palavras aleatórias que não entendem, descobrem que precisam de ETH para fazer qualquer coisa ( mas não podem comprar ETH sem antes ter ETH para o gás ) e abandonam frustrados antes de completar uma única transação. A indústria chamou isso de "descentralização". Os usuários chamaram de design hostil.

A abstração de conta — especificamente o ERC-4337 combinado com a atualização EIP-7702 do Ethereum em maio de 2025 — está finalmente corrigindo o que nunca deveria ter sido quebrado. Mais de 40 milhões de contas inteligentes foram implantadas no Ethereum e em redes de Camada 2, com quase 20 milhões criadas apenas em 2024. O padrão permitiu mais de 100 milhões de UserOperations, marcando um aumento de 10 x em relação a 2023. E com 87 % dessas transações com gás patrocinado por paymasters, estamos testemunhando a morte do paradoxo "você precisa de ETH para usar o Ethereum".

Isso não é um melhoria incremental — é o ponto de inflexão onde a criptografia para de punir os usuários por não serem criptógrafos.

O Marco de 40 Milhões de Contas Inteligentes: O Que Mudou​

A abstração de conta não é nova — os desenvolvedores a discutem desde os primórdios do Ethereum. O que mudou em 2024 - 2025 foi a infraestrutura de implantação, o suporte de carteiras e o escalonamento da Camada 2 que tornou as contas inteligentes economicamente viáveis.

O ERC-4337, finalizado em março de 2023, introduziu uma forma padronizada de implementar carteiras de contratos inteligentes sem alterar o protocolo principal do Ethereum. Ele funciona por meio de UserOperations — pseudo - transações agrupadas e enviadas por nós especializados chamados bundlers — que permitem recursos impossíveis com as contas tradicionais de propriedade externa ( EOAs ):

• Transações sem gás: Paymasters patrocinam as taxas de gás, removendo o problema de inicialização de ETH
• Transações em lote: Agrupe várias operações em uma só, reduzindo custos e cliques
• Recuperação social: Recupere contas por meio de contatos de confiança em vez de frases semente
• Chaves de sessão: Conceda permissões temporárias a aplicativos sem expor as chaves mestras
• Segurança programável: Lógica de validação personalizada, limites de gastos, detecção de fraude

O marco de 40 milhões de implantações representa um crescimento de 7 x em relação ao ano anterior. Quase metade dessas contas foram criadas em 2024, acelerando ao longo de 2025 à medida que as principais carteiras e Camadas 2 adotaram a infraestrutura ERC-4337.

Base, Polygon e Optimism lideram a adoção. A integração da Base com a Coinbase Wallet permitiu um onboarding sem gás para milhões de usuários. O forte ecossistema de jogos da Polygon utiliza contas inteligentes para economias dentro do jogo sem exigir que os jogadores gerenciem chaves privadas. A padronização do OP Stack da Optimism ajudou L2s menores a adotar a abstração de conta sem implementações personalizadas.

Mas o verdadeiro catalisador foi o EIP-7702, que foi ativado com a atualização Pectra do Ethereum em 7 de maio de 2025.

EIP-7702: Como Atualizar 300 Milhões de Carteiras Existentes​

As contas inteligentes ERC-4337 são poderosas, mas são contas novas. Se você usa o Ethereum desde 2015, seus ativos estão em uma EOA — um simples par de chave - valor onde a chave privada controla tudo. Migrar esses ativos para uma conta inteligente exige transações, taxas de gás e risco de erros. Para a maioria dos usuários, esse atrito era muito alto.

O EIP-7702 resolveu isso permitindo que as EOAs existentes executem temporariamente o código de contrato inteligente durante as transações. Ele introduz um novo tipo de transação ( 0x04 ) onde uma EOA pode anexar bytecode executável sem se tornar permanentemente um contrato.

Funciona assim: O proprietário de uma EOA assina um "designador de delegação" — um endereço contendo código executável que sua conta adota temporariamente. Durante essa transação, a EOA ganha capacidades de contrato inteligente: operações em lote, patrocínio de gás, lógica de validação personalizada. Após a conclusão da transação, a EOA retorna ao seu estado original, mas a infraestrutura agora a reconhece como compatível com a abstração de conta.

Isso significa que mais de 300 + milhões de endereços Ethereum existentes podem ganhar recursos de conta inteligente sem migrar ativos ou implantar novos contratos. Carteiras como MetaMask, Trust Wallet e Ambire podem atualizar as contas dos usuários de forma transparente, permitindo:

• Onboarding sem gás: Aplicativos patrocinam o gás para novos usuários, removendo o paradoxo do ETH
• Agrupamento de transações: Aprove e troque tokens com um clique em vez de duas transações
• Delegação para esquemas de chaves alternativos: Use Face ID, passkeys ou carteiras de hardware como autenticação primária

As principais carteiras implementaram o suporte ao EIP-7702 poucas semanas após a atualização Pectra. Ambire e Trust Wallet lançaram o suporte imediatamente, deixando as EOAs de seus usuários prontas para a abstração de conta sem migração manual. Isso não foi apenas uma atualização de recurso — foi a modernização de toda a base instalada de usuários do Ethereum com uma UX moderna.

A combinação do ERC-4337 ( novas contas inteligentes ) e do EIP-7702 ( contas existentes atualizadas ) cria um caminho para mais de 200 milhões + de contas inteligentes até o final de 2025, conforme estimam as projeções da indústria. Isso não é propaganda — é o resultado natural da remoção do atrito de onboarding que a criptografia impôs a si mesma sem um bom motivo.

100 Milhões de UserOperations: A Verdadeira Métrica de Adoção​

Implementações de contas inteligentes são uma métrica de vaidade se ninguém as usa. UserOperations — os pacotes semelhantes a transações que as contas inteligentes ERC-4337 enviam — contam a história real.

O padrão ERC-4337 permitiu mais de 100 milhões de UserOperations, um aumento em relação aos 8,3 milhões em 2023. Isso representa um aumento de 12 vezes em apenas um ano, impulsionado principalmente por jogos, DeFi e fluxos de onboarding sem gas.

87 % dessas UserOperations foram patrocinadas por gas via paymasters — contratos inteligentes que pagam taxas de transação em nome dos usuários. Esta é a funcionalidade matadora. Em vez de forçar os usuários a adquirir ETH antes de interagir com seu app, os desenvolvedores podem patrocinar o gas e integrar usuários instantaneamente. O custo? Alguns centavos por transação. O benefício? Eliminar o principal ponto de fricção no onboarding cripto.

Paymasters funcionam em três modos:

1. Patrocínio total: O aplicativo paga todas as taxas de gas. Usado para onboarding, referências ou campanhas promocionais.
2. Pagamento em ERC-20: Os usuários suprem o gas em USDC, DAI ou tokens nativos do aplicativo em vez de ETH. Comum em jogos onde os jogadores ganham tokens, mas não possuem ETH.
3. Patrocínio condicional: Taxas de gas patrocinadas se certas condições forem atendidas (ex: primeira transação, valor da transação excede um limite, usuário indicado por um membro existente).

O impacto prático: um novo usuário pode passar do registro à primeira transação em menos de 60 segundos sem tocar em uma exchange centralizada, sem baixar múltiplas carteiras e sem entender sobre taxas de gas. Eles se cadastram com e-mail e senha (ou autenticação social), e o aplicativo patrocina suas primeiras transações. No momento em que precisarem entender sobre carteiras e chaves, eles já estarão usando o app e percebendo valor.

É assim que os aplicativos Web2 funcionam. É assim que a cripto sempre deveria ter funcionado.

Transações Sem Gas: O Fim do Problema de Bootstrapping do ETH​

O problema "você precisa de ETH para usar a Ethereum" tem sido a falha de UX mais embaraçosa da cripto. Imagine dizer aos usuários de um novo aplicativo: "Antes de poder experimentar isso, você precisa ir a um serviço separado, verificar sua identidade, comprar a moeda da rede e, em seguida, transferi-la para este aplicativo. Além disso, se você ficar sem essa moeda, nenhum dos seus outros fundos funcionará".

Os paymasters acabaram com esse absurdo. Os desenvolvedores agora podem integrar usuários que têm zero ETH, patrocinar suas primeiras transações e permitir que interajam com DeFi, jogos ou aplicativos sociais imediatamente. Uma vez que os usuários ganham familiaridade, eles podem transitar para a autocustódia e gerenciar o gas por conta própria, mas a experiência inicial não pune os recém-chegados por não entenderem os detalhes internos da blockchain.

O Paymaster da Circle é um exemplo clássico. Ele permite que aplicativos patrocinem taxas de gas para usuários que pagam em USDC. Um usuário com USDC em sua carteira pode transacionar na Ethereum ou em Layer 2s sem nunca adquirir ETH. O paymaster converte USDC para cobrir o gas em segundo plano, de forma invisível para o usuário. Para aplicativos focados em stablecoins (remessas, pagamentos, poupança), isso remove a carga mental de gerenciar um token de gas volátil.

A infraestrutura de paymaster da Base permitiu que a Coinbase integrasse milhões de usuários ao DeFi sem a complexidade cripto. A Coinbase Wallet define a Base como padrão, patrocina transações iniciais e permite que os usuários interajam com aplicativos como Uniswap ou Aave antes de entenderem o que é gas. No momento em que os usuários precisam comprar ETH, eles já estão experimentando valor e têm contexto sobre o porquê de o sistema funcionar daquela maneira.

Plataformas de jogos como Immutable X e Treasure DAO usam paymasters para subsidiar as transações dos jogadores. Ações no jogo — cunhagem (minting) de itens, negociação em marketplaces, resgate de recompensas — acontecem instantaneamente sem interromper a jogabilidade para aprovar transações de gas. Os jogadores ganham tokens através do jogo, que podem usar posteriormente para gas ou negociação, mas a experiência inicial é sem fricção.

O resultado: dezenas de milhões de dólares em taxas de gas patrocinadas por aplicativos em 2024-2025. Isso não é caridade — é custo de aquisição de clientes. Os apps decidiram que pagar $ 0,02 - 0,10 por transação para integrar usuários é mais barato e eficaz do que forçar os usuários a navegar em exchanges centralizadas primeiro.

Transações em Lote: Um Clique, Múltiplas Ações​

Um dos aspectos mais frustrantes da UX tradicional da Ethereum é a necessidade de aprovar cada ação separadamente. Quer trocar USDC por ETH na Uniswap? São duas transações: uma para aprovar que a Uniswap gaste seu USDC, outra para executar a troca. Cada transação requer um pop-up da carteira, confirmação da taxa de gas e tempo de confirmação do bloco. Para novos usuários, isso parece que o aplicativo está quebrado. Para usuários experientes, é apenas irritante.

O ERC-4337 e o EIP-7702 permitem o agrupamento (batching) de transações, onde múltiplas operações são reunidas em uma única UserOperation. Essa mesma troca na Uniswap torna-se um clique, uma confirmação, uma taxa de gas. A conta inteligente executa internamente a aprovação e a troca sequencialmente, mas o usuário vê apenas uma única transação.

Os casos de uso estendem-se muito além do DeFi:

• Cunhagem de NFT: Aprovar USDC, cunhar NFT e listar no marketplace em uma única transação
• Jogos: Resgatar recompensas, atualizar itens e fazer staking de tokens simultaneamente
• Governança de DAO: Votar em múltiplas propostas em uma única transação em vez de pagar gas por cada uma
• Aplicativos sociais: Postar conteúdo, dar gorjetas a criadores e seguir contas sem confirmações por ação

Isso não é apenas um polimento de UX — muda fundamentalmente a forma como os usuários interagem com aplicativos on-chain. Fluxos complexos de várias etapas que antes pareciam desajeitados e caros agora parecem instantâneos e coesos. A diferença entre "este aplicativo é complicado" e "este aplicativo simplesmente funciona" muitas vezes se resume ao agrupamento (batching).

Recuperação Social : O Fim da Ansiedade com a Frase de Recuperação​

Pergunte a qualquer usuário não nativo de cripto o que ele mais teme sobre a autocustódia, e a resposta é invariavelmente : "E se eu perder minha frase de recuperação ( seed phrase ) ?" As frases de recuperação são seguras na teoria, mas catastróficas na prática. Os usuários as escrevem em papel ( facilmente perdido ou danificado ), as armazenam em gerenciadores de senhas ( ponto único de falha ) ou simplesmente não fazem backup ( perda garantida em caso de falha do dispositivo ).

A recuperação social inverte esse modelo. Em vez de um mnemônico de 12 palavras como o único método de recuperação, as contas inteligentes permitem que os usuários designem "guardiões" de confiança — amigos, familiares ou até mesmo dispositivos de hardware — que podem, coletivamente, restaurar o acesso se a chave primária for perdida.

Aqui está como funciona : um usuário configura sua conta inteligente e designa três guardiões ( pode ser qualquer número e limite, por exemplo, 2 de 3, 3 de 5 ). Cada guardião possui um fragmento de recuperação — uma chave parcial que, sozinha, não pode acessar a conta. Se o usuário perder sua chave primária, ele entra em contato com os guardiões e solicita a recuperação. Assim que o limite for atingido ( por exemplo, 2 de 3 guardiões aprovam ), o acesso da conta inteligente é transferido para uma nova chave controlada pelo usuário.

A Argent foi pioneira neste modelo em 2019. Em 2025, a Argent viabilizou a recuperação social para centenas de milhares de usuários, com taxas de sucesso de recuperação superiores a 95 % para usuários que perderam seus dispositivos. A mudança mental é significativa : em vez de "preciso proteger esta frase de recuperação para sempre ou perderei tudo", torna-se "preciso manter relacionamentos com pessoas em quem confio, o que já faço naturalmente".

A Ambire Wallet adotou uma abordagem híbrida, combinando autenticação por e-mail / senha com recuperação social opcional para contas de alto valor. Usuários que preferem simplicidade podem contar com a recuperação baseada em e-mail ( com fragmentos de chave criptografados armazenados em servidores ). Usuários avançados podem adicionar uma camada de recuperação social para segurança adicional.

A crítica : a recuperação social não é puramente livre de confiança ( trustless ) — ela exige confiar que os guardiões não irão conspirar entre si. É um ponto válido. Mas, para a maioria dos usuários, confiar em três amigos é muito mais prático do que confiar em si mesmos para nunca perder um pedaço de papel. A postura maximalista da cripto sobre a "autocustódia pura" tornou o ecossistema inutilizável para 99 % da humanidade. A recuperação social é um compromisso pragmático que permite a adoção ( onboarding ) sem sacrificar a segurança em modelos de ameaça realistas.

Chaves de Sessão : Permissões Delegadas Sem Exposição​

As EOAs ( Externally Owned Accounts ) tradicionais funcionam no estilo "tudo ou nada" : se um aplicativo tem sua chave privada, ele pode esvaziar toda a sua carteira. Isso cria um dilema para aplicativos interativos ( jogos, aplicativos sociais, bots de negociação automatizados ) que precisam de assinaturas de transações frequentes sem a intervenção constante do usuário.

As chaves de sessão resolvem isso ao conceder permissões temporárias e limitadas aos aplicativos. O proprietário de uma conta inteligente pode criar uma chave de sessão que seja válida por uma duração específica ( por exemplo, 24 horas ) e apenas para ações específicas ( por exemplo, negociar na Uniswap, cunhar NFTs, postar em um aplicativo social ). O aplicativo mantém a chave de sessão, podendo executar transações dentro dessas restrições, mas não pode acessar o saldo total da conta nem realizar ações não autorizadas.

Casos de uso em expansão em 2025 - 2026 :

• Jogos : Os jogadores concedem chaves de sessão aos clientes dos jogos, permitindo transações instantâneas dentro do jogo ( coletar saques, trocar itens, evoluir personagens ) sem janelas pop-up da carteira a cada 30 segundos. A chave de sessão é restrita aos contratos relacionados ao jogo e expira após o término da sessão.

• Bots de negociação : Usuários de DeFi criam chaves de sessão para estratégias de negociação automatizadas. O bot pode executar negociações, rebalancear portfólios e reivindicar rendimentos ( yields ), mas não pode sacar fundos ou interagir com contratos fora da lista de permissões ( whitelist ).

• Aplicativos sociais : Alternativas descentralizadas ao Twitter / Reddit usam chaves de sessão para permitir que os usuários postem, comentem e deem gorjetas sem precisar aprovar cada ação. A chave de sessão é limitada a interações de contratos sociais e possui um limite de gastos para gorjetas.

O modelo de segurança baseia-se em permissões com limite de tempo e escopo definido — exatamente como o OAuth funciona para aplicativos Web2. Em vez de dar a um aplicativo acesso total à conta, você concede permissões específicas por um tempo limitado. Se o aplicativo for comprometido ou se comportar de forma maliciosa, o dano no pior cenário possível está contido ao escopo e à duração da chave de sessão.

Esta é a expectativa de experiência do usuário ( UX ) que os usuários trazem da Web2. O fato de a cripto não ter tido isso por 15 anos é inaceitável, e a abstração de conta está finalmente corrigindo isso.

Base, Polygon, Optimism : Onde 40 Milhões de Contas Inteligentes Realmente Vivem​

As 40 milhões de implantações de contas inteligentes não estão distribuídas uniformemente — elas se concentram em Camadas 2 ( Layer 2s ) onde as taxas de gas são baixas o suficiente para tornar a abstração de conta economicamente viável.

A Base lidera a adoção, aproveitando a distribuição da Coinbase para integrar usuários de varejo em larga escala. A Coinbase Wallet define a Base como padrão para novos usuários, com contas inteligentes criadas de forma transparente. A maioria dos usuários nem percebe que está usando uma conta inteligente — eles se cadastram com e-mail, começam a transacionar e experimentam um onboarding sem taxas de gas sem entender a tecnologia subjacente. Esse é o objetivo. A cripto não deve exigir que os usuários entendam árvores de Merkle e curvas elípticas antes de poderem testar um aplicativo.

O ecossistema de jogos da Base se beneficia fortemente da abstração de conta. Jogos construídos na Base usam chaves de sessão para permitir uma jogabilidade sem atritos, agrupam transações ( batch transactions ) para reduzir a latência das ações no jogo e utilizam paymasters para subsidiar a entrada de jogadores. O resultado : jogadores com zero experiência em cripto podem começar a jogar jogos Web3 sem notar que estão em uma blockchain.

A Polygon teve um impulso inicial com plataformas de jogos e NFTs adotando o ERC-4337. As baixas taxas da Polygon ( muitas vezes < $ 0,01 por transação ) tornam o gas patrocinado por paymasters economicamente sustentável. Projetos como Aavegotchi, Decentraland e The Sandbox usam contas inteligentes para remover o atrito para usuários que desejam interagir com mundos virtuais, e não gerenciar carteiras.

A Polygon também fez parcerias com grandes marcas ( Starbucks Odyssey, Reddit Collectible Avatars, Nike .SWOOSH ) para integrar milhões de usuários não nativos de cripto. Esses usuários não veem carteiras, frases de recuperação ou taxas de gas — eles veem programas de fidelidade gamificados e colecionáveis digitais. Nos bastidores, eles estão usando contas inteligentes habilitadas por abstração de conta.

A padronização da OP Stack da Optimism tornou a abstração de conta portável entre rollups. Qualquer rede OP Stack pode herdar a infraestrutura ERC-4337 da Optimism sem uma implementação personalizada. Isso criou um efeito de rede : desenvolvedores criam aplicativos habilitados para abstração de conta uma única vez e os implantam na Base, Optimism e outras redes OP Stack com modificações mínimas.

O foco da Optimism no financiamento de bens públicos também incentivou desenvolvedores de carteiras a adotar a abstração de conta. Rodadas de Financiamento Retroativo de Bens Públicos ( RPGF ) recompensaram explicitamente projetos que melhoram a UX do Ethereum, com carteiras de abstração de conta recebendo alocações significativas.

O padrão é claro : taxas baixas + canais de distribuição + ferramentas para desenvolvedores = adoção. As contas inteligentes não decolaram na rede principal ( mainnet ) do Ethereum porque taxas de gas de $ 5 - 50 tornam o patrocínio via paymaster proibitivamente caro. Elas decolaram nas L2s, onde os custos por transação caíram para centavos, tornando o onboarding sem gas economicamente viável.

O Endgame de 200 Milhões de Smart Accounts​

Projeções do setor estimam mais de 200 milhões de smart accounts até o final de 2025, impulsionadas pela adoção do ERC-4337 e pela adaptação do EIP-7702 às EOAs existentes. Isso não é uma especulação exagerada — é o resultado natural da remoção da fricção artificial.

O caminho para os 200 milhões:

1. Adoção de carteiras móveis. Ambire Mobile, Trust Wallet e MetaMask Mobile agora suportam abstração de conta (account abstraction), trazendo recursos de smart accounts para bilhões de usuários de smartphones. O mobile é onde ocorre a próxima onda de adoção de cripto, e a UX móvel não tolera o gerenciamento de frases de recuperação (seed phrases) ou confirmações de gás por transação.

2. Onboarding em jogos. Os jogos Web3 são o caso de uso de maior volume para a abstração de conta. Jogos free-to-play com mecânicas play-to-earn podem integrar milhões de jogadores, patrocinar transações iniciais e permitir uma jogabilidade sem interrupções. Se 10 a 20 grandes jogos adotarem a abstração de conta em 2025-2026, teremos de 50 a 100 milhões de usuários.

3. Aplicações empresariais. Empresas como Circle, Stripe e PayPal estão integrando pagamentos em blockchain, mas não submeterão os clientes ao gerenciamento de frases de recuperação. A abstração de conta permite que apps empresariais ofereçam serviços baseados em blockchain com uma UX de nível Web2.

4. Apps sociais. Plataformas sociais descentralizadas (Farcaster, Lens, Friend.tech) precisam de um onboarding sem fricção para competir com o Twitter e o Instagram. Ninguém usará um Twitter descentralizado se cada postagem exigir a aprovação de uma carteira. Chaves de sessão (session keys) e paymasters tornam os apps sociais descentralizados viáveis.

5. Adaptação do EIP-7702. Mais de 300 milhões de EOAs existentes na Ethereum podem ganhar recursos de smart accounts sem migração. Se apenas 20-30% dessas contas adotarem os recursos do EIP-7702, serão de 60 a 90 milhões de contas atualizadas.

O ponto de inflexão: quando as smart accounts se tornarem o padrão, e não a exceção. Assim que as principais carteiras (MetaMask, Trust Wallet, Coinbase Wallet) criarem smart accounts por padrão para novos usuários, a base instalada mudará rapidamente. As EOAs tornam-se infraestrutura legada, mantidas por compatibilidade, mas não sendo mais a experiência principal do usuário.

Por que os Desenvolvedores da BlockEden.xyz Devem se Importar​

Se você está construindo na Ethereum ou Layer 2, a abstração de conta não é uma infraestrutura opcional — é o requisito básico para uma UX competitiva. Os usuários esperam onboarding sem gás, transações em lote (batch transactions) e recuperação social porque é assim que os apps Web2 funcionam e como os apps de cripto modernos devem funcionar.

Para desenvolvedores, implementar a abstração de conta significa:

Escolher a infraestrutura certa: Use bundlers ERC-4337 e serviços de paymaster (Alchemy, Pimlico, Stackup, Biconomy) em vez de construir do zero. O protocolo é padronizado, o ferramental está maduro e reinventar a roda desperdiça tempo.

Projetar fluxos de onboarding que escondam a complexidade: Não mostre frases de recuperação aos usuários no cadastro. Não peça aprovações de taxas de gás antes que eles experimentem o valor do produto. Patrocine transações iniciais, use chaves de sessão para interações repetitivas e introduza recursos avançados gradualmente.

Suportar recuperação social: Ofereça recuperação baseada em e-mail para usuários casuais, recuperação social para quem desejar e backup de frase de recuperação para usuários avançados que exigem controle total. Diferentes usuários possuem diferentes modelos de ameaça — sua carteira deve acomodar todos eles.

A abstração de conta é a infraestrutura que torna seu app acessível para o próximo bilhão de usuários. Se o seu fluxo de onboarding ainda exige que os usuários comprem ETH antes de testar seu produto, você está competindo com uma mão amarrada nas costas.

Para desenvolvedores que criam aplicações com abstração de conta, a BlockEden.xyz fornece a infraestrutura RPC para suportar smart accounts em escala. Esteja você implementando UserOperations do ERC-4337, integrando serviços de paymaster ou fazendo o deploy na Base, Polygon ou Optimism, nossas APIs lidam com as demandas de taxa de transferência e confiabilidade da abstração de conta em produção. Explore nosso marketplace de APIs para construir a próxima geração da UX cripto.

Fontes​

• Documentação do ERC-4337
• O que é ERC-4337? | Alchemy
• Guia de Implementação do EIP-7702 | QuickNode
• Visão Geral da Atualização Ethereum Pectra | Alchemy
• Atualização Pectra & EIP-7702 dão Superpoderes de Smart Wallet para EOAs | Circle
• O que são Paymasters? (ERC-4337) | Alchemy
• Transações sem gás com paymaster | Documentação da Base
• O que é Abstração de Conta? | Blog da Ambire
• Por que a Abstração de Conta resolverá o maior problema da cripto | Medium

AllScale.io é uma plataforma de pagamento de stablecoin legítima e com financiamento de risco — não um projeto de token — que visa freelancers e pequenas empresas em mercados emergentes. Fundada em fevereiro de 2025 e apoiada por $6.5M de VCs de cripto renomados, incluindo YZi Labs, Draper Dragon e KuCoin Ventures, a empresa mostra sinais positivos: uma equipe publicamente identificada com experiência verificável na Kraken, Capital One e Block, além de apoio institucional da incubadora Cyberport de Hong Kong. No entanto, a ausência de auditorias de segurança públicas e a extrema juventude da plataforma (menos de um ano de idade) exigem uma diligência prévia cuidadosa antes de um envolvimento significativo.

O que a AllScale faz e o problema que resolve​

A AllScale se posiciona como o "primeiro neobanco de stablecoin de autocustódia do mundo", projetado especificamente para as mais de 600 milhões de microempresas globais — freelancers, criadores de conteúdo, PMEs e contratados remotos — que enfrentam dificuldades com pagamentos transfronteiriços tradicionais. O problema central: freelancers internacionais enfrentam barreiras de contas bancárias, altas taxas de transferência, perdas na conversão de moeda e atrasos na liquidação que frequentemente excedem 5 dias úteis.

A plataforma permite que as empresas criem faturas, recebam pagamentos em USDT ou USDC, independentemente de como os clientes pagam (cartão de crédito, transferência bancária ou cripto), e acessem os fundos instantaneamente por meio de uma carteira não-custodial. Os principais produtos incluem AllScale Invoice (ativo desde setembro de 2025), AllScale Pay (comércio social via Telegram, WhatsApp, Line) e AllScale Payroll (pagamentos transfronteiriços para contratados). A empresa enfatiza o "cripto invisível" — os clientes podem não saber que estão usando trilhos de blockchain enquanto os comerciantes recebem stablecoins.

Estágio atual de desenvolvimento: A plataforma está em beta público com um produto funcional ativo na mainnet da BNB Chain. Os usuários podem acessar o painel em dashboard.allscale.io, embora uma lista de espera possa ser aplicada.

A arquitetura técnica depende da BNB Chain e da abstração de conta​

A AllScale se baseia na infraestrutura de blockchain existente em vez de operar sua própria cadeia. A pilha de tecnologia primária inclui:

A abordagem baseada em chave de acesso elimina o notório atrito de UX do gerenciamento de frases semente, diminuindo a barreira para a adoção mainstream. A arquitetura de patrocínio de paymaster multi-chain lida com os custos de transação nos bastidores.

O que falta: A AllScale não mantém repositórios públicos no GitHub — a infraestrutura é proprietária e de código fechado. Nenhum endereço de contrato inteligente foi publicado, nenhuma API ou SDK pública está disponível, e a documentação técnica em docs.allscale.io foca em guias de usuário em vez de especificações de arquitetura. Essa opacidade impede a verificação técnica independente de suas alegações.

Sem token nativo — a plataforma usa USDT e USDC​

A AllScale não possui um token de criptomoeda nativo. Esta é uma distinção crítica de muitos projetos Web3: não há ICO, IDO, venda de token ou ativo especulativo envolvido. A empresa opera como uma C-corp tradicional de Delaware levantando financiamento de capital.

A plataforma usa stablecoins de terceiros — principalmente USDT e USDC — como meio de pagamento. Os usuários recebem pagamentos em stablecoins, com conversão automática de pagamentos fiduciários ou por cartão. A integração com a BNB Chain também fornece acesso ao USD1 (a stablecoin afiliada à Binance).

Modelo de receita (estimado, não divulgado publicamente):

• Taxas de transação no processamento de faturas/pagamentos
• Spreads de conversão de moeda em trocas de fiat para stablecoin
• Serviços de gerenciamento de folha de pagamento B2B
• Taxas de integração de on/off-ramp

A ausência de um token elimina certos riscos (volatilidade especulativa, manipulação de tokenomics, preocupações regulatórias de valores mobiliários), mas também significa que não há exposição baseada em token para investidores além da participação acionária.

Quatro fundadores publicamente identificados com históricos verificáveis​

A equipe da AllScale demonstra forte transparência — todos os fundadores são publicamente identificados com históricos profissionais verificáveis:

Shawn Pang (CEO e Co-Fundador): Ciência da Computação e Negócios pela Western University. Ex-Gerente de Produto para fraude de pagamentos na Capital One; primeiro PM no Canadá no TikTok; co-fundou a HashMatrix, uma agência de marketing de crescimento para produtos de IA.

Ruoyang "Leo" Wang (COO e Co-Fundador): Engenharia da Computação pela University of Toronto. Experiência na PingCAP (bancos de dados distribuídos), IBM, AMD e Scotiabank. Experiência anterior em startup com a CP Clickme.

Jun Li e Khalil Lin (Co-Fundadores): Co-fundadores adicionais com experiência jurídica/compliance, supostamente incluindo histórico na OKX. Perfis do LinkedIn disponíveis.

Avrilyn Li (Gerente de Produto Fundadora): Empreendedora de IA para Web3 da Ivey Business School, liderando o produto de folha de pagamento.

A equipe afirma experiência coletiva na Binance, OKX, Kraken, Block (Square), Amazon, Dell e HP. O tamanho total da equipe é de aproximadamente 7-11 funcionários.

Financiamento e investidores​

Investidores participantes notáveis incluem KuCoin Ventures, Oak Grove Ventures, BlockBooster, Aptos, GSR Ventures e V3V Ventures. Os investidores anjo incluem Gracy Chen e Jedi Lu. A empresa é membro do Programa de Incubação Cyberport de Hong Kong, um acelerador de tecnologia apoiado pelo governo.

Grande preocupação de segurança: sem auditorias públicas ou programa de bug bounty​

Este é o sinal de alerta mais significativo na pesquisa. Apesar de lidar com fundos de usuários por meio de carteiras de contrato inteligente:

• Nenhuma auditoria pública de contrato inteligente de empresas reconhecidas (CertiK, Hacken, Trail of Bits, OpenZeppelin, SlowMist)
• Não listado no CertiK Skynet ou bancos de dados de segurança semelhantes
• Nenhum programa de bug bounty no Immunefi, HackerOne ou Bugcrowd
• Nenhum mecanismo de seguro ou cobertura divulgado
• Nenhuma política de divulgação de segurança publicamente visível

A AllScale afirma ter recursos de segurança, incluindo arquitetura de autocustódia, conformidade automatizada com KYC/KYB/KYT, integração de módulo de segurança de hardware (HSM) para chaves de acesso e suporte a 2FA. O modelo de autocustódia reduz o risco de contraparte da plataforma — se a AllScale fosse comprometida, os fundos dos usuários em suas próprias carteiras estariam teoricamente mais seguros do que em um serviço custodial.

Pelo lado positivo: Nenhum incidente de segurança, hack ou exploração foi relatado para a AllScale. No entanto, dada a juventude da plataforma, essa ausência de incidentes pode simplesmente refletir uma exposição limitada, em vez de uma segurança robusta.

Cenário competitivo e posicionamento de mercado​

A AllScale compete no espaço de pagamentos com stablecoins em rápida evolução:

Fatores de diferenciação da AllScale:

• Modelo de autocustódia (usuários controlam os fundos)
• Autenticação por chave de acesso eliminando o atrito de UX da frase semente
• Taxas de gás zero via abstração de conta
• Foco em mercados emergentes (África, América Latina, Sudeste Asiático)
• Segmentação de PMEs de "última milha" vs. foco em empresas

Desvantagens: Extrema juventude, equipe pequena, histórico limitado, concorrência contra empresas estabelecidas e bem financiadas com canais de distribuição consolidados.

A presença na comunidade está em estágio inicial e focada em B2B​

A AllScale mantém canais sociais Web3 padrão:

• X (Twitter): @allscaleio (ativo desde abril de 2025)
• Telegram: Grupo da comunidade AllScaleHQ
• Discord: Servidor ativo com ID da comunidade visível
• LinkedIn: Página da empresa AllScale Inc
• Newsletter: "The Stablecoin Scoop" no Substack

A comunidade está em estágio inicial, com engajamento principalmente por meio de sessões de AMA, X Spaces e anúncios de parcerias. A AllScale sediou o Scale Stablecoin Summit em Hong Kong (junho de 2025) com o HashKey Group e o Amber Group.

Nenhuma métrica DeFi tradicional se aplica: A AllScale é uma plataforma de pagamentos, não um protocolo DeFi, portanto, as métricas de TVL (Total Value Locked) não são aplicáveis. A plataforma não está listada no DeFiLlama ou Dune Analytics. A contagem de usuários e as métricas de retenção são mencionadas por investidores, mas não são divulgadas publicamente.

Parcerias notáveis incluem BNB Chain (parceiro oficial do ecossistema), Skill Afrika (comunidades de freelancers africanos), Ethscriptions (permanência L1) e Asseto (tokenização de RWA para produtos de rendimento).

A avaliação de risco revela um empreendimento de estágio inicial de risco moderado​

Sinais positivos de legitimidade​

• Equipe publicamente identificada com históricos profissionais verificáveis
• VCs de cripto renomados (YZi Labs, Draper Dragon, Amber Group, KuCoin Ventures)
• Apoio institucional do Cyberport de Hong Kong
• Estrutura legal de C-corp de Delaware
• Produto funcional ativo na mainnet da BNB Chain
• Nenhuma alegação de golpe, reclamações no BBB ou avisos da comunidade encontrados
• Nenhuma preocupação com equipe anônima
• Nenhuma promessa de rendimento irrealista ou especulação de token
• Posicionamento focado em conformidade (GENIUS Act, Hong Kong Stablecoin Ordinance)

Áreas que exigem cautela​

• Extrema juventude: Fundada em fevereiro de 2025, com menos de um ano de idade
• Nenhuma auditoria de segurança pública apesar de lidar com fundos
• Nenhum programa de bug bounty
• Nenhuma avaliação independente de usuários ou feedback da comunidade disponível
• Infraestrutura de código fechado — não é possível verificar as alegações de forma independente
• Cobertura da imprensa principalmente por sindicação de comunicados de imprensa, não por jornalismo independente
• Riscos de centralização: Plataforma operada pela empresa, dependência da BNB Chain
• Equipe pequena (~7-11 pessoas) executando um escopo global ambicioso

Não encontrado (potenciais sinais de alerta pela ausência)​

• Nenhuma métrica de usuário divulgada publicamente
• Nenhum dado de receita
• Nenhum conselho consultivo formal
• Nenhuma licença regulatória específica (estrutura de Hong Kong ainda não efetiva)

Desenvolvimentos recentes e roteiro​

Marcos recentes (2025):

• 8 de dezembro: Rodada seed de $5M anunciada (liderada pela YZi Labs)
• Novembro: AllScale Pay ativo na BNB Chain; parceria com Skill Afrika
• Outubro: Parceria com Ethscriptions para permanência L1
• Setembro: Lançamento do produto AllScale Invoice
• Agosto: Integração da BNB Chain com suporte a USD1
• Junho: Scale Stablecoin Summit em Hong Kong; financiamento pré-seed de $1.5M

Próximos passos:

• Q1 2026: Expansão para o mercado da América Latina
• Futuro: Opções de rendimento DeFi, capacidades cross-chain expandidas, soluções empresariais B2B

Conclusão​

A AllScale.io surge como uma startup legítima em estágio inicial, em vez de uma preocupação com golpes, apoiada por investidores credíveis e uma equipe transparente e verificável. O projeto aborda um problema de mercado real — o atrito nos pagamentos transfronteiriços para freelancers de mercados emergentes — com uma abordagem técnica bem pensada, alavancando a abstração de conta e as stablecoins.

No entanto, duas lacunas significativas exigem atenção antes de um envolvimento significativo: a completa ausência de auditorias de segurança públicas e a infraestrutura de código fechado que impede a verificação independente. Para uma plataforma que lida com fundos de usuários, essas omissões são preocupações materiais, independentemente das credenciais da equipe.

Classificação de risco geral: Moderado. O empreendimento mostra fortes sinais de legitimidade, mas carrega riscos inerentes ao estágio inicial. Usuários em potencial devem começar com pequenas quantias até que as auditorias de segurança sejam publicadas. Parceiros em potencial devem solicitar acesso direto às especificações técnicas e relatórios de auditoria. O projeto vale a pena ser monitorado à medida que amadurece, particularmente para quaisquer anúncios de auditoria de segurança no Q1 de 2026.

Imagine um mundo onde os usuários podem interagir com seu dApp de forma contínua, sem a necessidade de possuir tokens nativos (SUI). Isso não é mais um sonho distante. Com a Gas Station da Sui (também conhecida como Paymaster), os desenvolvedores podem cobrir as taxas de gás em nome de seus usuários, removendo completamente uma das maiores barreiras para novos participantes da Web3 e permitindo uma experiência on-chain verdadeiramente sem atritos.

Este artigo fornece um guia completo para atualizar seu dApp para ser sem gás. Vamos nos aprofundar nos conceitos centrais do Sui Paymaster, sua arquitetura, padrões de implementação e melhores práticas.

1. Contexto e Conceitos Centrais: O que é uma Transação Patrocinada?​

No mundo da blockchain, toda transação requer uma taxa de rede, ou "gás". Para usuários acostumados às experiências contínuas da Web2, isso é um obstáculo cognitivo e operacional significativo. A Sui aborda esse desafio no nível do protocolo com Transações Patrocinadas.

A ideia central é simples: permitir que uma parte (o Patrocinador) pague as taxas de gás SUI para a transação de outra parte (o Usuário). Dessa forma, mesmo que um usuário tenha zero SUI em sua carteira, ele ainda pode iniciar ações on-chain com sucesso.

Paymaster ≈ Gas Station​

No ecossistema Sui, a lógica para patrocinar transações é tipicamente tratada por um serviço off-chain ou on-chain chamado Gas Station ou Paymaster. Suas responsabilidades primárias incluem:

1. Avaliar a Transação: Ele recebe os dados da transação sem gás de um usuário (GasLessTransactionData).
2. Fornecer Gás: Ele bloqueia e aloca a taxa de gás necessária para a transação. Isso geralmente é gerenciado por meio de um pool de gás composto por muitos objetos SUI Coin.
3. Gerar uma Assinatura do Patrocinador: Após aprovar o patrocínio, a Gas Station assina a transação com sua chave privada (SponsorSig), certificando sua disposição em pagar a taxa.
4. Retornar a Transação Assinada: Ele envia de volta os TransactionData, que agora incluem os dados de gás e a assinatura do patrocinador, para aguardar a assinatura final do usuário.

Em suma, uma Gas Station atua como um serviço de reabastecimento para os usuários do seu dApp, garantindo que seus "veículos" (transações) possam viajar sem problemas na rede Sui.

2. Arquitetura de Alto Nível e Fluxo de Interação​

Uma transação típica sem gás envolve a coordenação entre o usuário, o frontend do dApp, a Gas Station e um Sui Full Node. A sequência de interação é a seguinte:

Detalhes do Fluxo:

1. O Usuário realiza uma ação na UI do dApp, que constrói um pacote de dados de transação sem nenhuma informação de gás.
2. O dApp envia esses dados para sua Gas Station designada para solicitar patrocínio.
3. A Gas Station verifica a validade da solicitação (por exemplo, verifica se o usuário é elegível para patrocínio), então preenche a transação com uma Gas Coin e sua assinatura, retornando a transação semi-completa para o dApp.
4. O Usuário vê os detalhes completos da transação em sua carteira (por exemplo, "Comprar um NFT") e fornece a assinatura final. Este é um passo crucial que garante que o usuário mantenha o consentimento e o controle sobre suas ações.
5. O dApp transmite a transação completa, contendo as assinaturas do usuário e do patrocinador, para um Sui Full Node.
6. Após a transação ser finalizada on-chain, a Gas Station pode confirmar isso ouvindo eventos ou recibos on-chain, e então notificar o backend do dApp via um webhook para fechar o ciclo do processo de negócio.

3. Três Modelos de Interação Principais​

Você pode usar os três modelos de interação a seguir individualmente ou em combinação para atender às suas necessidades de negócio.

Modelo 1: Iniciado pelo Usuário → Aprovado pelo Patrocinador (Mais Comum)​

Este é o modelo padrão, adequado para a grande maioria das interações dentro do dApp.

1. Usuário constrói GasLessTransactionData: O usuário realiza uma ação dentro do dApp.
2. Patrocinador adiciona GasData e assina: O backend do dApp envia a transação para a Gas Station, que a aprova, anexa uma Gas Coin e adiciona sua assinatura.
3. Usuário revisa e dá a assinatura final: O usuário confirma os detalhes finais da transação em sua carteira e a assina. O dApp então a submete à rede.

Este modelo atinge um excelente equilíbrio entre segurança e experiência do usuário.

Modelo 2: Airdrops/Incentivos Iniciados pelo Patrocinador​

Este modelo é perfeito para airdrops, incentivos a usuários ou distribuições em lote de ativos.

1. Patrocinador pré-preenche TransactionData + assina: O Patrocinador (tipicamente a equipe do projeto) pré-constrói a maior parte da transação (por exemplo, enviando um NFT por airdrop para um endereço específico) e anexa sua assinatura de patrocínio.
2. A segunda assinatura do usuário a torna efetiva: O usuário só precisa assinar esta transação "pré-aprovada" uma vez para que ela seja executada.

Isso cria uma experiência de usuário extremamente fluida. Com apenas um clique para confirmar, os usuários podem reivindicar recompensas ou completar tarefas, aumentando drasticamente as taxas de conversão de campanhas de marketing.

Modelo 3: GasData Curinga (Modelo de Linha de Crédito)​

Este é um modelo mais flexível e baseado em permissões.

1. Patrocinador transfere um objeto GasData: O Patrocinador primeiro cria um ou mais objetos Gas Coin com um orçamento específico e transfere a propriedade diretamente para o usuário.
2. Usuário gasta livremente dentro do orçamento: O usuário pode então usar livremente essas Gas Coins para pagar por quaisquer transações que ele inicie dentro dos limites e período de validade do orçamento.
3. Gas Coin é devolvida: Uma vez esgotado ou expirado, o objeto Gas Coin pode ser projetado para ser automaticamente destruído ou devolvido ao Patrocinador.

Este modelo é equivalente a dar ao usuário um "cartão de crédito de taxa de gás" com tempo e orçamento limitados, adequado para cenários que exigem um alto grau de autonomia do usuário, como oferecer uma experiência free-to-play durante uma temporada de jogo.

4. Cenários de Aplicação Típicos​

O poder do Sui Paymaster reside não apenas em resolver o problema da taxa de gás, mas também em sua capacidade de se integrar profundamente com a lógica de negócio para criar novas possibilidades.

Cenário 1: Paywalls​

Muitas plataformas de conteúdo ou serviços de dApp exigem que os usuários atendam a certos critérios (por exemplo, possuir um NFT VIP, atingir um certo nível de associação) para acessar recursos. O Paymaster pode implementar essa lógica perfeitamente.

• Fluxo: Um usuário solicita uma ação → o backend do dApp verifica as qualificações do usuário (por exemplo, posse de NFT) → se elegível, ele chama o Paymaster para patrocinar a taxa de gás; se não, ele simplesmente nega a solicitação de assinatura.
• Vantagem: Este modelo é inerentemente resistente a bots e abusos. Como a decisão de patrocínio é tomada no backend, usuários maliciosos não podem ignorar a verificação de qualificação para esgotar os fundos de gás.

Cenário 2: Checkout com Um Clique​

Em cenários de e-commerce ou compras dentro do jogo, simplificar o processo de pagamento é crítico.

• Fluxo: O usuário clica em "Comprar Agora" em uma página de checkout. O dApp constrói uma transação que inclui a lógica de negócio (por exemplo, transfer_nft_to_user). O usuário só precisa assinar para aprovar a transação de negócio em sua carteira, sem se preocupar com o gás. A taxa de gás é coberta pelo Patrocinador do dApp.
• Vantagem: Você pode codificar parâmetros de negócio como um order_id diretamente no ProgrammableTransactionBlock, permitindo uma atribuição on-chain precisa para pedidos de backend.

Cenário 3: Atribuição de Dados​

O rastreamento preciso de dados é fundamental para a otimização de negócios.

• Fluxo: Ao construir a transação, escreva um identificador único (como um order_hash) nos parâmetros da transação ou em um evento que será emitido após a execução.
• Vantagem: Quando a Gas Station recebe o recibo on-chain para uma transação bem-sucedida, ela pode facilmente extrair este order_hash analisando os dados do evento ou da transação. Isso permite um mapeamento preciso entre as mudanças de estado on-chain e pedidos de backend específicos ou ações do usuário.

5. Esqueleto de Código (Baseado no SDK Rust)​

Aqui está um trecho de código simplificado demonstrando os passos centrais de interação.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Para uma implementação completa, consulte o Tutorial da Gas Station da documentação oficial da Sui, que oferece exemplos de código prontos para uso.

6. Riscos e Proteção​

Embora poderosa, a implantação de uma Gas Station em um ambiente de produção requer consideração cuidadosa dos seguintes riscos:

• Equivocação (Gasto Duplo): Um usuário malicioso pode tentar usar a mesma Gas Coin para múltiplas transações em paralelo, o que faria com que a Gas Coin fosse bloqueada pela rede Sui. Isso pode ser efetivamente mitigado atribuindo uma Gas Coin única por usuário ou transação, mantendo uma lista negra e limitando a taxa de solicitações de assinatura.
• Gerenciamento de Pool de Gás: Em cenários de alta concorrência, uma única Gas Coin de grande valor pode se tornar um gargalo de desempenho. O serviço da Gas Station deve ser capaz de dividir automaticamente grandes SUI Coins em muitas Gas Coins de menor valor e recuperá-las eficientemente após o uso. Provedores profissionais de Gas Station como a Shinami oferecem soluções maduras e gerenciadas para isso.
• Autorização e Limitação de Taxa: Você deve estabelecer políticas rigorosas de autorização e limitação de taxa. Por exemplo, gerenciar limites e frequências de patrocínio com base no IP do usuário, endereço da carteira ou tokens de API para evitar que o serviço seja esgotado por atores maliciosos.

7. Ferramentas do Ecossistema​

O ecossistema Sui já oferece um rico conjunto de ferramentas para simplificar o desenvolvimento e a implantação do Paymaster:

• SDKs Oficiais (Rust/TypeScript): Incluem APIs de alto nível como sponsor_transaction_block(), reduzindo significativamente a complexidade da integração.
• Shinami Gas Station: Fornece um serviço gerenciado completo, incluindo divisão/recuperação automatizada de Gas Coin, monitoramento detalhado de métricas e notificações por webhook, permitindo que os desenvolvedores se concentrem na lógica de negócio.
• Enoki / Mysten Demos: A comunidade e a Mysten Labs também fornecem implementações de Paymaster de código aberto que podem ser usadas como referência para construir seu próprio serviço.

8. Lista de Verificação de Implementação​

Pronto para atualizar seu dApp para a era sem gás? Revise esta lista de verificação antes de começar:

• Planeje Seu Fluxo de Financiamento: Defina a fonte de financiamento do Patrocinador, orçamento e estratégia de reabastecimento. Configure monitoramento e alertas para métricas chave (por exemplo, saldo do pool de gás, taxa de consumo).
• Reserve Campos de Atribuição: Ao projetar seus parâmetros de transação, certifique-se de reservar campos para identificadores de negócio como order_id ou user_id.
• Implante Políticas Anti-Abuso: Você deve implementar mecanismos rigorosos de autorização, limitação de taxa e registro antes de entrar em produção.
• Ensaie na Testnet: Seja construindo seu próprio serviço ou integrando uma Gas Station de terceiros, sempre conduza testes exaustivos de concorrência e estresse em uma testnet ou devnet primeiro.
• Otimize Continuamente: Após o lançamento, acompanhe continuamente as taxas de sucesso das transações, razões de falha e custos de gás. Ajuste seu orçamento e estratégias com base nos dados.

Conclusão​

O Sui Paymaster (Gas Station) é mais do que apenas uma ferramenta para cobrir as taxas de gás do usuário. É um paradigma poderoso que combina elegantemente uma experiência de usuário "zero SUI on-chain" com a necessidade de negócio de "atribuição on-chain em nível de pedido" dentro de uma única transação atômica. Ele abre o caminho para que usuários da Web2 entrem na Web3 e oferece aos desenvolvedores uma flexibilidade sem precedentes para personalização de negócios.

Com um ecossistema de ferramentas cada vez mais maduro e os atuais baixos custos de gás na rede Sui, nunca houve um momento melhor para atualizar os fluxos de pagamento e interação do seu dApp para a era sem gás.

Como eliminar o atrito da carteira, manter o fluxo de usuários e prever o potencial de crescimento

E se o seu aplicativo Web3 tivesse o mesmo fluxo de inscrição simplificado de um serviço Web2 moderno? Essa é a promessa central do zkLogin na blockchain Sui. Ele funciona como um OAuth para Sui, permitindo que os usuários façam login com contas familiares do Google, Apple, X e outras. Uma prova de conhecimento zero (zero-knowledge proof) vincula de forma segura essa identidade Web2 a um endereço Sui on-chain — sem pop-ups de carteira, sem frases de recuperação (seed phrases), sem rotatividade de usuários (churn).

O impacto é real e imediato. Com centenas de milhares de contas zkLogin já ativas, estudos de caso relatam ganhos massivos na conversão de usuários, saltando de meros 17 % para saudáveis 42 % após a remoção das barreiras tradicionais de carteira. Vamos detalhar como isso funciona e o que pode fazer pelo seu projeto.

Por que as Carteiras Matam a Conversão de Novos Usuários​

Você construiu um dApp inovador, mas seu funil de aquisição de usuários está com vazamentos. O culpado é quase sempre o mesmo: o botão "Conectar Carteira" (Connect Wallet). O onboarding padrão da Web3 é um labirinto de instalações de extensões, avisos de frases de recuperação e questionários de jargão cripto.

É uma barreira massiva para os recém-chegados. Pesquisadores de UX observaram uma queda impressionante de 87 % no momento em que um aviso de carteira aparecia. Em um experimento revelador, simplesmente redirecionar esse aviso para um estágio posterior no processo de checkout aumentou a taxa de conclusão para 94 %. Mesmo para usuários curiosos sobre cripto, o medo principal é: "Posso perder meus fundos se clicar no botão errado." Remover esse único passo intimidador é a chave para desbloquear um crescimento exponencial.

Como o zkLogin Funciona (em Linguagem Simples)​

O zkLogin contorna elegantemente o problema da carteira usando tecnologias em que todos os usuários da Internet já confiam. A mágica acontece nos bastidores em alguns passos rápidos:

1. Par de Chaves Efêmeras: Quando um usuário deseja fazer login, um par de chaves temporário de sessão única é gerado localmente em seu navegador. Pense nisso como uma chave de acesso temporária, válida apenas para esta sessão.
2. Dança do OAuth: O usuário faz login com sua conta do Google, Apple ou outra conta social. Seu aplicativo incorpora de forma inteligente um valor exclusivo (nonce) nesta solicitação de login.
3. Serviço ZKP: Após um login bem-sucedido, um serviço ZKP (Zero-Knowledge Proof) gera uma prova criptográfica. Esta prova confirma: "Este token OAuth autoriza o proprietário da chave de acesso temporária", sem nunca revelar a identidade pessoal do usuário on-chain.
4. Derivar Endereço: O JWT (JSON Web Token) do usuário, fornecido pelo provedor OAuth, é combinado com um salt exclusivo para gerar deterministicamente seu endereço Sui permanente. O salt é mantido privado, seja no lado do cliente ou em um backend seguro.
5. Enviar Transação: Seu aplicativo assina transações with a chave temporária e anexa a prova ZK. Os validadores da Sui verificam a prova on-chain, confirmando a legitimidade da transação sem que o usuário precise de uma carteira tradicional.

Guia de Integração Passo a Passo​

Pronto para implementar isso? Aqui está um guia rápido usando o SDK do TypeScript. Os princípios são idênticos para Rust ou Python.

1. Instalar o SDK​

O pacote @mysten/sui inclui todos os utilitários de zklogin que você precisará.

pnpm add @mysten/sui

2. Gerar Chaves e Nonce​

Primeiro, crie um par de chaves efêmero e um nonce vinculado à época (epoch) atual na rede Sui.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. Redirecionar para o OAuth​

Construa a URL de login OAuth apropriada para o provedor que você está usando (ex: Google, Facebook, Apple) e redirecione o usuário.

4. Decodificar JWT e Buscar Salt do Usuário​

Após o login e o redirecionamento de volta, obtenha o id_token da URL. Use-o para buscar o salt específico do usuário em seu backend e, em seguida, derive o endereço Sui dele.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. Solicitar Prova ZK​

Envie o JWT para um serviço de prova (prover service) para obter a prova ZK. Para desenvolvimento, você pode usar o provador público da Mysten. Em produção, você deve hospedar o seu próprio ou usar um serviço como o Enoki.

const proof = await fetch('/api/prove', {
  method: 'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Assinar e Enviar​

Agora, construa sua transação, defina o remetente como o endereço zkLogin do usuário e execute-a. O SDK cuida de anexar os zkLoginInputs (a prova) automaticamente. ✨

const tx = new TransactionBlock();
tx.moveCall({ target: '0x2::example::touch_grass' }); // Qualquer chamada Move
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // A mágica acontece aqui
});

7. Persistir Sessão​

Para uma experiência de usuário mais fluida, criptografe e armazene o par de chaves e o salt no IndexedDB ou no armazenamento local (local storage). Lembre-se de rotacioná-los a cada poucas épocas para maior segurança.

Modelo de Projeção de KPI​

A diferença que o zkLogin faz não é apenas qualitativa; é quantificável. Compare um funil de integração típico com um potencializado pelo zkLogin:

👉 O que isso significa: Para uma campanha que atrai 10.000 visitantes únicos, essa é a diferença entre 300 ações on-chain no primeiro dia e mais de 2.500.

Melhores Práticas e Pontos de Atenção​

Para criar uma experiência ainda mais fluida, mantenha estas dicas profissionais em mente:

• Use Transações Patrocinadas: Pague pelas taxas das primeiras transações dos seus usuários. Isso remove todo o atrito e proporciona um momento "aha" incrível.
• Manipule os Salts com Cuidado: Alterar o salt de um usuário gerará um novo endereço. Só faça isso se você controlar um caminho de recuperação confiável para eles.
• Exponha o Endereço Sui: Após o cadastro, mostre aos usuários o endereço on-chain deles. Isso permite que usuários avançados o importem para uma carteira tradicional mais tarde, se desejarem.
• Evite Loops de Atualização: Armazene em cache o JWT e o par de chaves efêmeras até que expirem para evitar pedir ao usuário que faça login repetidamente.
• Monitore a Latência do Provador: Fique de olho no tempo de ida e volta da geração da prova. Se exceder 2 segundos, considere hospedar um provador regional para manter as coisas rápidas.

Onde o BlockEden.xyz Agrega Valor​

Embora o zkLogin aperfeiçoe o fluxo voltado para o usuário, escalá-lo introduz novos desafios de backend. É aí que o BlockEden.xyz entra.

• Camada de API: Nossos nós RPC de alto rendimento e roteamento geográfico garantem que suas transações zkLogin sejam processadas com latência mínima, independentemente da localização do usuário.
• Observabilidade: Obtenha painéis prontos para uso para acompanhar métricas importantes como latência de prova, taxas de sucesso/falha e a integridade do seu funil de conversão.
• Conformidade: Para aplicativos que fazem a ponte para moedas fiduciárias, nosso módulo opcional de KYC fornece um on-ramp em conformidade diretamente da identidade verificada do usuário.

Pronto para Lançar?​

A era dos fluxos de carteira desajeitados e intimidadores acabou. Ative um sandbox zkLogin, conecte o endpoint de full-node da BlockEden e veja seu gráfico de cadastros subir — enquanto seus usuários nem precisam ouvir a palavra “carteira”. 😉

Por anos, o mundo cripto tem sido atrapalhado por um problema crítico de usabilidade: a carteira. Carteiras tradicionais, conhecidas como Contas Externamente Possuídas (EOAs), são implacáveis. Uma única frase‑semente perdida significa que seus fundos desaparecem para sempre. Cada ação requer uma assinatura, e as taxas de gás devem ser pagas no token nativo da cadeia. Essa experiência pesada e de alto risco é uma barreira importante para a adoção em massa.

Surge então a Abstração de Conta (AA), uma mudança de paradigma que promete redefinir como interagimos com a blockchain. No seu cerne, a AA transforma a conta do usuário em um contrato inteligente programável, desbloqueando recursos como recuperação social, transações de um clique e pagamentos de gás flexíveis.

A jornada rumo a esse futuro mais inteligente está se desenrolando por três caminhos distintos: o ERC‑4337, já testado em batalha; a AA Nativa, eficiente; e o tão aguardado EIP‑7702. Vamos analisar o que cada abordagem significa para desenvolvedores e usuários.

💡 Caminho 1: O Pioneiro — ERC‑4337​

O ERC‑4337 foi a ruptura que trouxe a abstração de conta para Ethereum e cadeias EVM sem alterar o protocolo central. Pense nele como uma camada inteligente adicionada ao sistema existente.

Ele introduz um novo fluxo de transação envolvendo:

• UserOperations: um novo objeto que representa a intenção do usuário (ex.: “trocar 100 USDC por ETH”).
• Bundlers: atores off‑chain que coletam UserOperations, as agrupam e as enviam à rede.
• EntryPoint: um contrato inteligente global que valida e executa as operações agrupadas.

O Positivo:

• Compatibilidade Universal: pode ser implantado em qualquer cadeia EVM.
• Flexibilidade: permite recursos avançados como chaves de sessão para jogos, segurança multi‑assinatura e patrocínio de gás via Paymasters.

O Trade‑off:

• Complexidade & Custo: introduz uma sobrecarga de infraestrutura significativa (execução de Bundlers) e tem os maiores custos de gás dos três métodos, já que cada operação passa pela lógica extra do EntryPoint. Por isso, sua adoção floresceu principalmente em L2s econômicas como Base e Polygon.

O ERC‑4337 abriu caminho para que outras soluções de AA pudessem existir. Ele provou a demanda e lançou as bases para uma experiência Web3 mais intuitiva.

🚀 Caminho 2: O Ideal Integrado — Abstração de Conta Nativa​

Se o ERC‑4337 é um add‑on, a AA Nativa incorpora recursos inteligentes diretamente na fundação da blockchain. Cadeias como zkSync Era e Starknet foram projetadas desde o início com a AA como princípio central. Nessas redes, toda conta é um contrato inteligente.

O Positivo:

• Eficiência: ao integrar a lógica de AA ao protocolo, elimina‑se as camadas extras, resultando em custos de gás significativamente menores comparados ao ERC‑4337.
• Simplicidade para Devs: desenvolvedores não precisam gerenciar Bundlers nem um mempool separado. O fluxo de transação se assemelha muito ao padrão.

O Trade‑off:

• Fragmentação do Ecossistema: a AA Nativa é específica de cada cadeia. Uma conta no zkSync é diferente de uma conta no Starknet, e nenhuma delas é nativa da mainnet Ethereum. Isso cria uma experiência fragmentada para usuários e desenvolvedores que trabalham em múltiplas cadeias.

A AA Nativa nos mostra o “fim de jogo” em termos de eficiência, mas sua adoção está atrelada ao crescimento dos ecossistemas que a hospedam.

🌉 Caminho 3: A Ponte Pragmática — EIP‑7702​

Previsto para ser incluído na atualização “Pectra” de 2025 da Ethereum, o EIP‑7702 é um divisor de águas projetado para levar recursos de AA às massas de usuários de EOAs existentes. Ele adota uma abordagem híbrida: permite que um EOA delegue temporariamente sua autoridade a um contrato inteligente para uma única transação.

Pense nisso como conceder superpoderes temporários ao seu EOA. Você não precisa migrar fundos nem mudar de endereço. Sua carteira pode simplesmente adicionar uma autorização a uma transação, permitindo executar operações agrupadas (ex.: aprovação + troca em um clique) ou ter seu gás patrocinado.

O Positivo:

• Compatibilidade Retroativa: funciona com os bilhões de dólares protegidos por EOAs atuais. Nenhuma migração necessária.
• Baixa Complexidade: usa o pool de transações padrão, eliminando a necessidade de Bundlers e simplificando drasticamente a infraestrutura.
• Catalisador de Adoção em Massa: ao tornar recursos inteligentes acessíveis a todo usuário Ethereum da noite para o dia, pode acelerar rapidamente a adoção de padrões de UX melhores.

O Trade‑off:

• Não é “AA Completa”: o EIP‑7702 não resolve a gestão de chaves para o próprio EOA. Se você perder sua chave privada, ainda estará sem acesso. Ele foca mais em aprimorar as capacidades de transação do que em reformular a segurança da conta.

Comparação Lado a Lado​

O Futuro é Convergente e Centrado no Usuário​

Esses três caminhos não são mutuamente exclusivos; eles convergem para um futuro onde a carteira deixa de ser ponto de atrito.

1. Recuperação Social Torna‑se Padrão 🛡️: A era de “chaves perdidas, fundos perdidos” está terminando. A AA permite recuperação baseada em guardiões, tornando a autocustódia tão segura e indulgente quanto uma conta bancária tradicional.
2. UX de Jogos Reimaginada 🎮: Chaves de sessão permitirão jogabilidade fluida sem pop‑ups constantes de “aprovar transação”, finalmente fazendo os jogos Web3 se sentirem como jogos Web2.
3. Carteiras como Plataformas Programáveis: As carteiras se tornarão modulares. Usuários poderão adicionar um “módulo DeFi” para farming automatizado ou um “módulo de segurança” que exija 2FA para transferências grandes.

Para desenvolvedores e provedores de infraestrutura como Blockeden.xyz, essa evolução é extremamente empolgante. A complexidade de Bundlers, Paymasters e os diversos padrões de AA cria uma oportunidade enorme para oferecer infraestrutura robusta, confiável e abstraída. O objetivo é uma experiência unificada onde o desenvolvedor possa integrar recursos de AA facilmente, e a carteira escolha inteligentemente entre ERC‑4337, AA Nativa ou EIP‑7702 conforme a cadeia suporte.

A carteira finalmente recebe a atualização que merece. A transição de EOAs estáticas para contas inteligentes dinâmicas não é apenas uma melhoria — é a revolução que tornará o Web3 acessível e seguro para o próximo bilhão de usuários.

Olá e bem‑vindo de volta ao nosso blog de blockchain! Hoje, vamos mergulhar em uma proposta empolgante chamada ERC-4337, que introduz a abstração de conta ao Ethereum sem exigir mudanças no protocolo da camada de consenso. Em vez disso, essa proposta depende de infraestrutura de camada superior para alcançar seus objetivos. Vamos explorar o que o ERC-4337 tem a oferecer e como ele resolve as limitações do ecossistema Ethereum atual.

O que é ERC-4337?​

ERC-4337 é uma proposta que introduz a abstração de conta ao Ethereum por meio do uso de um mempool separado e de um novo tipo de objeto pseudo‑transação chamado UserOperation. Usuários enviam objetos UserOperation para o mempool alternativo, onde uma classe especial de atores chamada bundlers os empacota em uma transação que faz uma chamada handleOps a um contrato dedicado. Essas transações são então incluídas em um bloco.

A proposta visa alcançar vários objetivos:

1. Permitir que os usuários utilizem carteiras de contrato inteligente com lógica de verificação arbitrária como suas contas principais.
2. Eliminar completamente a necessidade de contas externamente possuídas (EOAs).
3. Garantir descentralização ao permitir que qualquer bundler participe do processo de inclusão de operações de usuário abstraídas.
4. Permitir que toda a atividade ocorra em um mempool público, eliminando a necessidade de os usuários conhecerem endereços de comunicação direta de atores específicos.
5. Evitar suposições de confiança nos bundlers.
6. Evitar a necessidade de alterações no consenso do Ethereum para uma adoção mais rápida.
7. Suportar outros casos de uso, como aplicações que preservam privacidade, operações atômicas múltiplas, pagamento de taxas de transação com tokens ERC‑20 e transações patrocinadas por desenvolvedores.

Compatibilidade Retroativa​

Como o ERC-4337 não altera a camada de consenso, não há problemas diretos de compatibilidade retroativa para o Ethereum. Contudo, contas pré‑ERC‑4337 não são facilmente compatíveis com o novo sistema porque carecem da função validateUserOp necessária. Isso pode ser resolvido criando uma conta compatível com ERC‑4337 que re‑implementa a lógica de verificação como um wrapper e definindo‑a como o remetente de operação confiável da conta original.

Implementação de Referência​

Para quem deseja aprofundar nos detalhes técnicos do ERC‑4337, uma implementação de referência está disponível em https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Considerações de Segurança​

O contrato de ponto de entrada para o ERC‑4337 deve ser amplamente auditado e formalmente verificado, pois serve como ponto central de confiança para todo o sistema. Embora essa abordagem reduza a carga de auditoria e verificação formal para contas individuais, ela concentra o risco de segurança no contrato de ponto de entrada, que deve ser robustamente verificado.

A verificação deve cobrir duas reivindicações principais:

1. Segurança contra sequestro arbitrário: o ponto de entrada só chama uma conta genericamente se validateUserOp para essa conta específica tiver sido aprovado.
2. Segurança contra drenagem de taxas: se o ponto de entrada chamar validateUserOp e passar, ele também deve fazer a chamada genérica com calldata igual a op.calldata.

Conclusão​

ERC‑4337 é uma proposta empolgante que visa introduzir a abstração de conta ao Ethereum sem exigir mudanças no protocolo da camada de consenso. Ao usar infraestrutura de camada superior, abre novas possibilidades para descentralização, flexibilidade e diversos casos de uso. Embora existam considerações de segurança a serem abordadas, essa proposta tem o potencial de melhorar significativamente o ecossistema Ethereum e a experiência do usuário.