Bundlers e UserOperations: Como Funcionam as Transações ERC-4337

Uma UserOperation é o objeto de intenção assinado definido pelo ERC-4337: ela declara o que uma conta de contrato inteligente quer que seja feito e como essa ação deve ser validada e paga. Diferentemente de uma transação Ethereum comum, ela não é um objeto em nível de protocolo assinado por uma conta controlada externamente: sua assinatura é verificada pelo próprio contrato da conta, e ela não precisa pagar o próprio gas nativo. Um bundler é o ator off-chain que coleta UserOperations de um mempool alternativo dedicado, simula cada uma delas, empacota as válidas em uma única transação Ethereum comum e chama o contrato canônico EntryPoint — que valida todas as operações do lote antes de executar qualquer uma. O bundler adianta o gas real a partir de sua própria EOA e é reembolsado on-chain pela conta remetente ou pelo paymaster dessa conta. Um contrato paymaster opcional pode concordar em cobrir uma operação durante essa etapa de validação, e é aí que as taxas passam a ser patrocinadas ou pagáveis em um token ERC-20 em vez do token de gas nativo da cadeia.

Uma rápida recapitulação do ERC-4337

O ERC-4337 é o padrão do Ethereum para abstração de conta — uma forma de dar a contas de contrato inteligente a mesma capacidade de primeira classe de iniciar e pagar por ações que as contas controladas externamente (EOAs) sempre tiveram, sem qualquer mudança no protocolo base. Em vez de modificar a camada de consenso, o ERC-4337 introduz um sistema paralelo de objetos de mais alto nível e infraestrutura off-chain que, no fim, se liquida por meio de transações Ethereum comuns. Se você quiser primeiro a versão do zero, o explicativo sobre o que é abstração de conta aborda a motivação, o que é o ERC-4337 mapeia o padrão completo e contas inteligentes vs EOAs compara diretamente os dois tipos de conta. Este post aprofunda a mecânica: os objetos que percorrem o sistema e os atores que os processam. Note que o ERC-4337 é um padrão da EVM — ele se aplica ao Ethereum e a cadeias compatíveis com EVM, não a cadeias não-EVM como Solana ou TON.

O que uma UserOperation realmente é

O objeto central no ERC-4337 é a UserOperation. Superficialmente parece uma transação, mas é melhor entendida como uma declaração de intenção assinada: "aqui está o que minha conta quer que seja feito, e aqui estão os parâmetros para validá-lo e pagá-lo." Ela é uma struct passada como calldata a um contrato, e não um objeto nativo do protocolo — a camada base nunca ouviu falar dela.

Em essência, uma UserOperation carrega:

• sender — a conta de contrato inteligente em nome da qual a operação age.
• nonce — proteção contra repetição, rastreada pelo EntryPoint como um valor em duas partes (uma chave mais uma sequência), de modo que uma conta possa manter várias faixas de nonce independentes em vez de uma única fila rígida.
• callData — o que a conta deve executar, frequentemente um lote de várias chamadas em uma só operação.
• dados de implantação da conta — opcionais; implantam o contrato da conta em sua primeiríssima operação, e é assim que uma conta inteligente pode ser abastecida em um endereço conhecido, derivado de forma determinística, antes mesmo de existir on-chain.
• limites de gas — orçamentos separados para validação e execução, mais um valor preVerificationGas que compensa o bundler pelo calldata e pela sobrecarga que o EntryPoint não consegue medir sozinho.
• parâmetros de taxa — uma taxa máxima e uma taxa de prioridade máxima, espelhando o EIP-1559.
• dados do paymaster — opcionais; qual contrato patrocinará a operação e qualquer contexto de que ele precise.
• assinatura — verificada pela própria função de validação da conta, não pelo protocolo.

A codificação exata mudou entre as versões do EntryPoint — a v0.7 divide os blobs de implantação e de paymaster em campos explícitos e compacta vários valores de gas juntos, enquanto a v0.6 usava cadeias de bytes únicas initCode e paymasterAndData — mas o conteúdo conceitual é o mesmo. Se você está integrando, verifique qual versão do EntryPoint o seu bundler tem como alvo.

A diferença fundamental em relação a uma transação normal está em quem e o que a assina. Uma transação Ethereum convencional deve ser assinada pela chave privada de uma EOA usando um esquema ECDSA fixo, e essa mesma conta paga o gas. Uma UserOperation é validada pela própria lógica de contrato inteligente da conta remetente — que pode implementar qualquer esquema de assinatura, regra de múltiplas chaves, session key ou política de autorização que a conta definir — e ela não precisa pagar por si mesma em gas nativo. Essa flexibilidade é o ponto principal: a conta, não o protocolo, decide como é uma ação válida.

O mempool alternativo onde elas vivem

As UserOperations não entram no mempool normal de transações do Ethereum, porque ainda não são transações. Em vez disso, elas são transmitidas para um mempool alternativo separado (frequentemente chamado de alt-mempool) — uma rede ponto a ponto dedicada aos objetos ERC-4337. Na prática, uma carteira ou dApp envia uma delas chamando eth_sendUserOperation no endpoint RPC de um bundler; esse bundler pode propagá-la para o alt-mempool compartilhado ou mantê-la em um pool privado próprio. De um jeito ou de outro, a infraestrutura que consome esses objetos escuta aqui, e não no mempool da camada base. Essa separação mantém o tráfego de abstração de conta fora do caminho crítico para o consenso até o momento em que é empacotado em uma transação real.

O papel do bundler

Um bundler é o ator off-chain que transforma intenções em realidade on-chain. Seu trabalho tem quatro partes. Primeiro, ele coleta UserOperations do mempool alternativo. Segundo, ele simula e valida cada uma — executando a lógica de validação da conta em um contexto simulado para confirmar que a assinatura é válida, o nonce está correto e a conta ou seu paymaster pode cobrir o custo. Terceiro, ele empacota uma ou mais UserOperations válidas em uma única transação Ethereum comum. Quarto, ele submete essa transação à rede a partir de sua própria EOA, pagando o gas da camada base antecipadamente e esperando ser reembolsado on-chain.

A simulação sozinha não é proteção suficiente, porque o estado pode mudar entre a simulação e a inclusão. Por isso o ERC-4337 também restringe o que o código de validação tem permissão de fazer: durante a fase de validação, uma conta ou paymaster não pode ler timestamps de bloco nem outros valores de ambiente que lhe permitiriam se comportar on-chain de forma diferente da simulação, e seu acesso a storage fica em grande parte limitado a slots associados à própria conta. Espera-se que contratos que agem em nome de muitos usuários — especialmente factories e paymasters — depositem um stake, para que um único contrato mal-comportado não consiga invalidar barato uma grande fatia do mempool de uma só vez. Essas regras existem por um único motivo: fazer da simulação de um bundler uma previsão confiável do que vai acontecer on-chain.

Como o bundler adianta o gas e ganha taxas pela inclusão, ele se comporta muito como um construtor de blocos especializado para o tráfego de abstração de conta. Sua etapa de simulação e validação é o que o protege: ele não empacota uma operação que deixaria de reembolsá-lo.

O contrato EntryPoint

Tudo converge para um único contrato inteligente canônico chamado EntryPoint. Ele é um singleton, implantado por versão no mesmo endereço em todas as cadeias EVM, e guarda os depósitos que pagam pelas operações. A transação do bundler é uma chamada ao EntryPoint com um array de UserOperations, e o EntryPoint então executa um estrito laço de duas fases.

Na fase de validação, para cada operação ele chama a função de validação da conta remetente (e a do paymaster, se um for especificado) para reverificar on-chain a assinatura, o nonce e o arranjo de pagamento, e reserva o custo máximo possível de quem estiver pagando. Somente após todas as operações do lote terem sido validadas é que ele passa para a fase de execução, na qual despacha o calldata de cada operação para sua conta a fim de realmente realizar a transferência, o swap ou outra ação, e então liquida o custo real e devolve a reserva não utilizada.

Essa divisão importa: validação e execução são separadas para que as garantias de pagamento de um lote sejam estabelecidas antes de qualquer trabalho que altere o estado, e para que o EntryPoint possa contabilizar o gas com precisão em muitas operações de uma vez. Isso também significa que a falha de uma operação durante a execução não contamina as demais do lote.

Onde o paymaster se encaixa

Um paymaster é um contrato opcional que concorda em pagar por uma UserOperation em nome da conta. Quando uma UserOperation inclui dados de paymaster, o EntryPoint pergunta a esse paymaster, durante a fase de validação, se ele patrocinará a operação e em quais termos; o paymaster devolve uma decisão mais um blob de contexto. Depois da execução, o EntryPoint chama o paymaster de volta em uma etapa pós-operação com o gas realmente consumido, e é aí que um paymaster que cobra em token liquida o valor exato. O paymaster pode aceitar incondicionalmente (patrocínio gasless de verdade, no qual um app absorve o custo), ou pode aceitar em troca de valor — mais utilmente, cobrando do usuário em um token ERC-20 em vez de gas nativo. Para uma análise mais aprofundada desse componente, veja o que é um paymaster. O paymaster é o gancho no fluxo que desacopla "com o que o usuário paga" de "em que a rede é paga".

Como o gas e as falhas são tratados

O gas no ERC-4337 é em camadas. O bundler paga ETH real pela transação externa; o EntryPoint mede o gas de validação e execução de cada UserOperation em relação aos limites que ela declarou; e quem estiver responsável — a conta ou seu paymaster — precisa ter depositado o suficiente junto ao EntryPoint para cobrir a conta, que é liquidada ao final do lote. Uma consequência que vale conhecer: uma operação ERC-4337 custa um pouco mais de gas do que a transação simples equivalente, porque, além da ação em si, você paga pela validação em nível de contrato e pela contabilidade do EntryPoint.

As falhas são contidas pelo design de validação primeiro. Se uma operação falha durante a validação on-chain, o lote inteiro reverteria — por isso o bundler a descarta e remonta o pacote em vez de deixar isso acontecer, e é exatamente para isso que serve sua simulação off-chain. Se uma operação passa na validação mas sua execução reverte, os efeitos da execução são desfeitos enquanto o gas já gasto ainda é contabilizado e pago, de modo que o bundler não fica sem compensação por trabalho honesto. Essa assimetria é o motivo de os bundlers simularem com tanto cuidado: sua proteção contra griefing é recusar-se a incluir qualquer coisa que não os reembolse.

O ciclo de vida, em ordem

1. Sua carteira monta uma UserOperation: sender, nonce, calldata, limites de gas, parâmetros de taxa, dados opcionais de paymaster.
2. Um paymaster, se usado, aprova os termos de patrocínio antes de a operação ser transmitida.
3. A lógica de assinatura da sua conta a assina — e ela não precisa ser uma única chave ECDSA.
4. A carteira a submete ao RPC de um bundler, e ela entra no mempool alternativo.
5. O bundler a simula e valida sob as regras do padrão para opcodes restritos e acesso a storage.
6. O bundler a empacota com outras operações em uma transação Ethereum que chama handleOps no EntryPoint, e paga o gas da camada base.
7. O EntryPoint valida todas as operações, executa o calldata de cada uma, liquida os custos contra os depósitos, devolve o excedente e reembolsa o bundler.

O que isso traz para quem usa a carteira

O maquinário é elaborado, mas seu propósito é prosaico e útil: agrupar várias ações em uma única confirmação (approve e swap juntos, por exemplo), taxas patrocinadas ou pagas em token, esquemas de assinatura diferentes de uma única chave secp256k1, políticas de gasto e session keys, e recuperação social ou baseada em dispositivo. Vale notar que o EIP-7702 permite que uma EOA comum execute temporariamente com código de conta inteligente, o que estreita a distância para alguns desses recursos sem substituir a infraestrutura ERC-4337 descrita acima.

Como a WATS usa isso

Em cadeias EVM, a WATS depende de exatamente uma peça desse fluxo: o slot do paymaster. Quando você faz uma transferência, swap ou stake na WATS Hot Wallet, a UserOperation que sua carteira monta nomeia um paymaster, e é esse paymaster que permite que a taxa seja cobrada em ATS em vez do token de gas nativo da cadeia — assim você nunca precisa manter um saldo residual de ETH, BNB ou POL em cada rede só para conseguir movimentar. Não se pede a você que rode um bundler, escolha uma versão do EntryPoint ou mantenha uma chave de RPC de bundler; isso é infraestrutura, e o trabalho da carteira é montar uma UserOperation válida e submetê-la.

Duas ressalvas mantêm isso honesto. Primeiro, pagar em ATS não é um desconto — a rede continua cobrando sua taxa normal e o paymaster a liquida, então o que muda é qual token sai do seu saldo, não o custo subjacente. Segundo, o ERC-4337 é exclusivo da EVM, então em Solana e TON um arranjo equivalente de fee-payer cumpre o papel do paymaster, e não o fluxo do EntryPoint descrito aqui. O ATS é um OFT da LayerZero, e é isso que permite que um único saldo de ATS cubra taxas em Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana e TON; o ATS arrecadado é queimado, levando a oferta de 100.000.000 até um piso de 30.000.000. A WATS é totalmente não custodial em todo o percurso: você guarda suas chaves, e a WATS nunca guarda nenhuma.

Se você quiser ver esse fluxo como um sistema em funcionamento e não como uma especificação, o passo concreto é tentar uma transferência na WATS Hot Wallet em uma cadeia na qual você não tenha nada do token de gas nativo: a UserOperation, o bundler e o EntryPoint fazem seu trabalho fora de vista, e a taxa sai do seu saldo de ATS. Como o modelo de taxa ATS funciona cobre a mecânica de ponta a ponta.