ERC-4337: o que é e como funciona o padrão [2026]

Uma transação comum no Ethereum é rígida: ela sai de uma conta controlada por uma chave privada, paga o gás em ETH e segue um formato fixo definido no núcleo do protocolo. Por anos, mudar essa rigidez parecia exigir alterar o próprio coração da rede, algo lento, arriscado e politicamente difícil.

O ERC-4337 é o padrão que trouxe account abstraction ao Ethereum sem mexer no protocolo base. Em vez de uma transação, o usuário assina uma "intenção" chamada UserOperation, e um conjunto de contratos e nós especializados cuida do resto. Nenhum hard fork foi necessário.

Abaixo, em profundidade técnica: por que padrões anteriores falharam, quais são as cinco peças do ERC-4337, como uma operação percorre o sistema do começo ao fim, como os bundlers evitam ataques de negação de serviço, o que mudou entre as versões do EntryPoint e onde tudo isso já está rodando, incluindo o caso do Picnic.

O que é o ERC-4337?

O ERC-4337 é o padrão que implementa account abstraction em uma camada acima do protocolo Ethereum, usando uma mempool alternativa em vez de exigir mudanças na camada de consenso. Em outras palavras: ele entrega contas programáveis (login por biometria, recuperação sem seed phrase, gás pago em outro token, transações em lote) sem que a rede precise de um hard fork.

A ideia central é simples de enunciar e engenhosa de implementar. O protocolo continua processando transações tradicionais normalmente. Por cima dele, o ERC-4337 cria um segundo trilho: usuários assinam objetos chamados UserOperation, que vivem em uma fila própria e são processados por contratos inteligentes auditados. Para a rede base, tudo isso parece apenas uma transação comum chegando de um nó qualquer.

Segundo a ethereum.org, o padrão já viabilizou a criação de mais de 26 milhões de smart accounts e o processamento de mais de 170 milhões de UserOperations (dados verificados em junho de 2026). Deixou de ser proposta e virou infraestrutura.

Por que o ERC-4337 precisou existir

Account abstraction não é uma ideia nova. As primeiras tentativas de trazê-la ao Ethereum esbarraram no mesmo obstáculo: exigiam mexer na camada de consenso.

• EIP-2938 propunha um novo tipo de transação nativo para contas-contrato. Exigia mudanças profundas no protocolo.
• EIP-3074 introduzia dois novos opcodes (AUTH e AUTHCALL) para permitir que EOAs delegassem controle a contratos. Por adicionar opcodes na camada de consenso, dependia de um hard fork e de ampla coordenação da rede.

Ambas acabaram pausadas justamente pela extensão das mudanças que pediam. A grande sacada do ERC-4337 foi abandonar a abordagem "mudar o protocolo" e adotar a abordagem "construir por cima dele". Ao definir uma mempool alternativa e processar operações através de contratos, o padrão entregou os mesmos benefícios sem tocar no consenso. Esse é o motivo do subtítulo oficial da especificação: Account Abstraction Using Alt Mempool.

A diferença prática: uma proposta que precisa de hard fork depende de toda a rede concordar e atualizar ao mesmo tempo. O ERC-4337 pôde ser implantado como um contrato e adotado por quem quisesse, sem pedir permissão ao restante do ecossistema.

As cinco peças do ERC-4337

O ERC-4337 funciona pela cooperação de cinco componentes. Vale entender o papel de cada um, porque o ciclo de vida de uma operação passa por todos eles.

A divisão de trabalho é o que torna o sistema seguro e flexível: a smart account define as regras, o EntryPoint impõe a disciplina, o bundler faz o transporte e o paymaster resolve quem paga.

O ciclo de vida de uma UserOperation

Acompanhar uma operação do início ao fim deixa o desenho concreto. O fluxo, passo a passo:

1. Assinatura off-chain. O usuário (ou o app) monta uma UserOperation e a assina. Com uma passkey, por exemplo, a assinatura nasce da biometria do celular, sem seed phrase.
2. Entrada na mempool alternativa. A operação é transmitida para uma mempool dedicada a UserOperations, separada da mempool de transações comuns.
3. Validação pelo bundler. Antes de aceitar a operação, o bundler simula sua fase de validação para confirmar que ela vai mesmo pagar o gás. Se a simulação falhar ou desrespeitar as regras (mais sobre isso abaixo), o bundler descarta a operação.
4. Empacotamento. O bundler junta várias UserOperations válidas em uma única transação on-chain endereçada ao EntryPoint.
5. Validação on-chain. O EntryPoint chama a função de validação de cada smart account (e do paymaster, se houver), conferindo assinatura e fundos. Essa é a primeira das duas fases.
6. Execução. Aprovada a validação, o EntryPoint chama a função de execução da smart account, que realiza a ação pretendida. É a segunda fase.
7. Contabilidade e reembolso. O EntryPoint calcula o gás gasto, paga o bundler e devolve o que sobrou conforme as regras do paymaster ou do depósito da conta.

Para quem usa, nada disso aparece. A pessoa confirma uma ação com a digital e vê o resultado. Toda a coreografia entre mempool, bundler e EntryPoint acontece nos bastidores. Esse é exatamente o ponto da abstração.

Validação em duas fases e as regras do ERC-7562

Aqui está o detalhe mais sutil, e mais importante, do desenho. Um sistema de contas baseado em contratos tem um problema de segurança difícil: como o bundler pode ter certeza de que uma operação vai pagar o gás sem executá-la inteira primeiro?

Se o bundler precisasse rodar a operação completa para descobrir se ela paga, um atacante poderia inundar a rede com operações que fingem pagar e revertem no último instante, depois de consumir processamento. Seria um vetor barato de negação de serviço (DoS).

A solução tem duas partes:

• Separação validação/execução. O EntryPoint sempre roda primeiro a fase de validação (a conta confirma "esta assinatura é válida e há fundos") e só depois a fase de execução. Isso permite decidir se a operação paga antes de gastar com a execução.
• Regras de escopo do ERC-7562. Durante a validação, a operação opera sob restrições rígidas, formalizadas no padrão ERC-7562 (Account Abstraction Validation Scope Rules). A validação não pode depender de valores não-determinísticos nem ler estado de qualquer endereço. Na prática, ficam proibidos opcodes como TIMESTAMP e SELFBALANCE, e a operação não pode acessar o estado de contratos fora do próprio sender.

Por que isso importa: como a fase de validação é determinística e isolada, o bundler consegue simular a operação off-chain e confiar que o resultado on-chain será o mesmo. Se a simulação diz que paga, paga. Essas regras são impostas pelos bundlers fora da cadeia e são o que mantém a mempool alternativa protegida contra DoS. Sem o ERC-7562, a mempool de UserOperations seria fácil de entupir.

Quanto custa: o overhead de gás do EntryPoint

Toda essa flexibilidade tem um preço, e ser honesto sobre ele faz parte de entender o padrão.

Uma transação de uma EOA simples é barata porque o protocolo a processa nativamente. Uma UserOperation, por passar pelo EntryPoint, pela validação do contrato e por uma camada extra de contabilidade, consome mais gás do que a transação equivalente de uma EOA. Há também o custo único de implantar a smart account na rede, que uma EOA não tem.

O ecossistema ataca esse custo por vários lados:

• Bundling. Agrupar várias operações em uma transação dilui o custo fixo entre elas.
• Paymasters. Patrocinam o gás ou cobram em outro token, tirando o peso de cima do usuário final.
• Otimizações de versão. O EntryPoint v0.7 reempacotou campos da UserOperation (juntando limites de gás e taxas em campos compactos) justamente para reduzir o custo de calldata. O v0.8 trouxe novas otimizações, como deixar de aplicar a penalidade de gás não usado quando ela fica abaixo de 40.000 de gás.
• L2s. A maior parte da atividade de ERC-4337 acontece em redes de camada 2, onde o gás é uma fração do custo da mainnet.

Na prática, em uma boa implementação esse overhead fica nos bastidores, absorvido ou diluído por quem constrói o produto.

EntryPoint v0.6, v0.7 e v0.8: o que mudou

O EntryPoint é versionado, e cada versão vive em um endereço próprio (é um singleton imutável por versão). Conhecer a linha do tempo ajuda a ler integrações e documentações.

A direção é clara: cada versão deixou as operações mais baratas e ampliou o alcance do padrão, culminando na integração com o EIP-7702.

ERC-4337 vs EIP-7702: concorrentes ou complementares?

Essa é a confusão mais comum em 2026, então vale separar bem. O EIP-7702 entrou em vigor com a atualização Pectra do Ethereum, em 7 de maio de 2025. Ele permite que uma EOA já existente delegue temporariamente seu comportamento a um contrato inteligente, ganhando recursos de smart account sem precisar migrar saldo para uma conta nova.

A diferença de abordagem:

O ponto-chave: os dois não competem, eles se encaixam. A partir do EntryPoint v0.8, uma EOA que usa EIP-7702 pode aproveitar toda a infraestrutura de bundlers e paymasters do ERC-4337. Um caminho moderniza contas novas; o outro moderniza as antigas. Juntos, empurram o ecossistema inteiro na mesma direção.

Segurança e trade-offs honestos

O ERC-4337 resolve problemas reais, mas não é mágica sem custo. Os pontos de atenção mais relevantes:

• Superfície de código maior. Mais lógica programável significa mais espaço para possíveis bugs. Uma EOA é segura pela simplicidade; uma smart account depende da qualidade e da auditoria do contrato que a define. Por isso o EntryPoint passou por auditorias antes de cada versão ir para a mainnet.
• Validação em duas fases é uma defesa, não uma garantia absoluta. As regras do ERC-7562 reduzem drasticamente a superfície de DoS, mas exigem que bundlers as implementem corretamente.
• Centralização em amadurecimento. Bundlers e paymasters são peças novas. A descentralização e a robustez dessa camada ainda estão evoluindo, e em alguns produtos há dependência de provedores específicos.
• Interoperabilidade incompleta. Mover uma smart account entre carteiras diferentes nem sempre é simples, e a padronização de recursos avançados (como autorizações temporárias) segue em evolução.
• Custo de gás. Como visto, operar via contrato custa mais gás que uma EOA pura. Mitigável, mas real.

A boa notícia é que a maior parte desses custos vive nos bastidores, sob responsabilidade de quem constrói o produto, não de quem o usa.

Onde o ERC-4337 já está rodando

O padrão deixou de ser teoria. O EntryPoint está implantado nas principais redes compatíveis com Ethereum, com forte concentração de atividade em L2s como Base, Arbitrum, Optimism e Polygon. No lado das ferramentas, há um ecossistema maduro de implementações de smart account: Safe AA, Kernel (ZeroDev), Biconomy, o Account Kit da Alchemy e a Coinbase Smart Wallet, entre outras.

O Picnic, plataforma de tecnologia que oferece conta internacional com cartão Visa e dólar digital, usa o ERC-4337 como base do produto. A conta do usuário é uma smart account no padrão Safe, com passkey como signer (a mesma tecnologia do Face ID e da digital) e recuperação sem seed phrase. É essa engenharia que permite oferecer autocustódia de verdade, em que você mantém o controle dos seus ativos, com a experiência de um app financeiro comum: abrir o app, entrar com a biometria e o saldo já está sob o seu controle.

Por baixo, a infraestrutura de account abstraction do ERC-4337. Na frente, uma conta internacional com cartão Visa sem anuidade, dólar digital, sem IOF e sem taxa Picnic, aceito em mais de 180 países. Conheça a conta internacional do Picnic.

Conclusão

O ERC-4337 é o padrão que trouxe account abstraction ao Ethereum pela porta de cima: sem hard fork, usando uma mempool alternativa e um conjunto de contratos auditados. As cinco peças (UserOperation, EntryPoint, bundler, paymaster e smart account) trabalham juntas para transformar uma "intenção" assinada off-chain em uma ação executada on-chain, com a validação em duas fases e as regras do ERC-7562 garantindo que tudo isso seja seguro contra DoS.

Para o desenvolvedor, o resultado é uma base sólida e versionada (v0.6 em 2023, v0.7 em 2024, v0.8 em 2025) que hoje conversa com o EIP-7702 e roda em escala nas principais L2s. Para o usuário final, o resultado é invisível e por isso mesmo poderoso: login por biometria, recuperação possível e autocustódia que cabe no dia a dia. Os trade-offs (mais gás, mais código, infraestrutura ainda amadurecendo) são reais, mas em grande parte resolvidos por quem constrói o produto.

É nessa ponte que o Picnic se posiciona: o ERC-4337 nos bastidores e, na frente, uma conta internacional com cartão Visa, dólar digital e autocustódia desde o primeiro acesso. Abra sua conta no Picnic e tenha o controle dos seus ativos sem precisar entender nada do que acontece embaixo do capô.

---

A Picnic é uma plataforma de tecnologia que permite ao usuário interagir de forma autônoma com USDC, stablecoin emitida pela Circle, pareada ao dólar americano, em redes blockchain públicas. O USDC não é moeda de curso legal no Brasil.

A cotação exibida varia conforme condições de mercado e o valor final válido é o apresentado na tela de confirmação da transação. Criptoativos envolvem riscos, incluindo volatilidade e perda de paridade.

A Picnic não custodia ativos do usuário e não é instituição financeira ou PSAV. O envio e recebimento de valores em dólares para conta americana é realizado por meio de parceria com a Noah Savings Inc. Termos e condições se aplicam.

Dados verificados em junho de 2026.