6 posts marcados com "Account Abstraction"

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.