
Patrocínio de gas e paymasters, explicados
Toda transação na Ethereum custa gas, e em uma conta tradicional quem envia a transação é quem paga por ela, na moeda nativa da rede. É justamente essa regra única que faz com que um usuário novo que tem uma stablecoin, mas nenhum ETH, possa se ver incapaz de mover os próprios fundos. A account abstraction rompe esse vínculo, e a engrenagem que faz esse rompimento é o paymaster. Este artigo explica o que é um paymaster no ERC-4337, onde ele se encaixa no fluxo e — o mais importante — o que o patrocínio de gas realmente significa para alguém que mantém a custódia das próprias chaves.
Este é o quarto artigo da nossa série sobre account abstraction. Se os termos abaixo parecerem desconhecidos, comece por A account abstraction a partir de primeiros princípios; para o modelo de taxas subjacente sobre o qual o patrocínio de gas se apoia, leia As taxas de gas na Ethereum explicadas para usuários de autocustódia.
O que é, de fato, um paymaster
Um paymaster é um smart contract. Sua única função é concordar em cobrir o gas da operação de outra pessoa. Sob o ERC-4337, quando um smart account expressa o que quer fazer como uma UserOperation, essa operação pode nomear um paymaster. Se o paymaster concordar, é ele — e não a conta — que acerta o custo do gas com a rede.
Há duas variações disso, e elas respondem a dois problemas distintos do usuário:
- Patrocinar o gas diretamente. O paymaster paga a taxa em nome do usuário, e o usuário não paga nada de gas. É isso que as pessoas querem dizer com "sem gas".
- Aceitar o pagamento em um token ERC-20. O paymaster paga à rede o gas em moeda nativa e depois cobra do usuário em um token ERC-20 — uma stablecoin, por exemplo. O usuário nunca precisa ter ETH; ele acerta as contas no token que já possui.
Em ambos os casos a rede continua sendo paga na moeda nativa. O gas não passa a ser gratuito; a única pergunta é quem o financia e em qual denominação o usuário sente o custo.
Onde o paymaster se encaixa no fluxo
Para entender por que se pode confiar que um paymaster pague, ajuda relembrar como uma operação ERC-4337 trafega. Um smart account não envia uma transação normal. Ele emite uma UserOperation para uma mempool separada. Um bundler as coleta, empacota e as submete on-chain através do contrato auditado EntryPoint, que invoca cada conta para executar sua lógica de validação antes de processar.
O paymaster entra durante a etapa de validação. Quando o EntryPoint processa uma UserOperation que nomeia um paymaster, ele chama a própria função de validação do paymaster. O paymaster inspeciona a operação e decide, ali mesmo, se está disposto a cobrir o gas. Se concordar, ele efetivamente garante o pagamento ao EntryPoint, e a operação prossegue. Se recusar, a operação não é patrocinada — ou recai sobre a conta pagar, ou não passa naqueles termos.
O modelo mental importante é este: o patrocínio é uma decisão tomada no momento da validação, por um contrato, sobre uma operação específica. Não é uma promessa genérica. Um paymaster olha para esta operação e diz sim ou não.
Para que serve o patrocínio de gas
Desacoplar o pagador da taxa de quem envia desbloqueia um punhado de padrões concretos:
- Onboarding patrocinado. Um usuário novo pode concluir sua primeira ação — um swap, um mint, um resgate — sem antes adquirir o token de gas nativo em uma exchange. Eliminar esse passo de "você precisa comprar ETH antes de fazer qualquer coisa" é uma das maiores reduções de atrito que a account abstraction oferece.
- Taxas patrocinadas pela dApp. Um aplicativo pode optar por pagar o gas de seus usuários como decisão de produto, do mesmo modo que um app web absorve custos de servidor. O usuário clica; o paymaster do app cobre a operação.
- Pagar taxas em uma stablecoin. Em vez de manter um saldo de ETH à parte só para o gas, o usuário pode pagar a taxa no token que já está transacionando. O paymaster recebe o token e adianta a moeda nativa à rede.
Cada um desses casos é uma instância da mesma primitiva — um contrato disposto a pagar gas nas condições que ele define — aplicada a um problema diferente.
"Patrocinado" não é "grátis"
Vale ser franco sobre a economia, porque a palavra "sem gas" convida a um mal-entendido. A rede sempre cobra o gas na moeda nativa. Quando uma transação é "patrocinada", esse custo não desapareceu; alguém concordou em absorvê-lo. Um paymaster precisa estar financiado, e quem o financia — um aplicativo, um protocolo, um serviço — está pagando dinheiro real pelo privilégio de remover o atrito.
Isso tem duas consequências que um usuário de autocustódia deve ter em mente:
- Um paymaster pode recusar. Como o patrocínio é uma decisão por operação, não há garantia de que uma operação qualquer será coberta. Programas de patrocínio podem ter regras de elegibilidade, tetos de gasto, ou simplesmente ficar sem fundos. "Sem gas" é uma característica de um fluxo específico, não uma propriedade da rede.
- Você deveria saber qual paymaster está envolvido. Um paymaster é um contrato que participa da sua transação. Como com qualquer contrato com o qual você interage, vale entender de quem é o paymaster e o que ele faz — patrocinar uma taxa é benigno, mas a confiança ainda importa. Quando você paga taxas em um token, você também está aceitando qualquer taxa de câmbio que o paymaster aplique entre esse token e a moeda nativa.
Nada disso é motivo para evitar paymasters. É motivo para entendê-los: uma transação patrocinada é um serviço que alguém está prestando, não um almoço grátis que o protocolo distribui.
O que isso significa para a autocustódia
Aqui está a parte que mais importa para alguém que mantém as próprias chaves, e é fácil entender ao contrário. O patrocínio de gas muda quem paga a taxa. Ele não muda quem controla os fundos.
Quando um paymaster cobre seu gas, você ainda assina a operação com suas próprias chaves. O paymaster não pode mover seus ativos, redirecionar sua transação nem autorizar nada em seu nome — ele só pode concordar em pagar a taxa da operação que você autorizou. A custódia permanece intacta. Você continua sendo a única parte que pode aprovar uma transferência dos seus fundos; o paymaster apenas se ofereceu para pagar o pedágio de uma viagem que você decidiu fazer.
Para a SSP especificamente, isso se encaixa naturalmente no modelo de segurança. A SSP é uma carteira de autocustódia construída em torno de multisig 2-of-2: uma chave na extensão de navegador SSP Wallet, a segunda no app móvel SSP Key, ambas necessárias para aprovar cada transação. Em redes EVM, a SSP é um smart account ERC-4337 que verifica uma assinatura Schnorr-agregada 2-of-2, auditada pela Halborn em 2025. Por ser uma conta ERC-4337, a mecânica de gas do padrão — incluindo a possibilidade de uma UserOperation ser paga por um paymaster — se aplica a ela do mesmo modo que se aplica a qualquer conta ERC-4337. O design completo é abordado em a arquitetura de account abstraction da SSP.
Para ser preciso sobre o que isso promete e o que não promete: o ERC-4337 possibilita o patrocínio de gas e os fluxos de pagamento em token, e as contas da SSP vivem dentro desse padrão. Se uma transação específica que você faz é patrocinada, ou pagável em um token, depende do aplicativo ou do fluxo de carteira que você está usando e de haver ou não um paymaster em jogo para aquela operação. A garantia de custódia com duas chaves, por outro lado, está sempre em vigor, independentemente de quem paga o gas.
A conclusão
Um paymaster é um contrato que pode pagar o gas de uma UserOperation em nome do usuário, ou permitir que esse gas seja pago em um token ERC-20 em vez da moeda nativa. Ele concorda com isso durante a validação, por operação, e pode recusar. Ele possibilita onboarding sem gas, taxas patrocinadas pela dApp e gas em stablecoin — conveniências reais que baixam a barreira para transacionar. Mas "patrocinado" significa "financiado por alguém", não "grátis", e o paymaster nunca ganha qualquer controle sobre seus ativos. Para um usuário de autocustódia, esse é o resumo limpo: paymasters podem mudar quem paga a viagem, mas você ainda segura as chaves do carro.
O resto desta série
- A account abstraction a partir de primeiros princípios — por que as EOAs são limitantes e o que significa a account abstraction.
- EOA versus smart account: as diferenças que importam — uma comparação direta dos dois modelos de conta.
- A arquitetura de account abstraction da SSP — como a SSP integra o ERC-4337 em uma carteira 2-of-2.
- Patrocínio de gas e paymasters, explicados — este artigo: como os paymasters desacoplam quem paga de quem envia.
- A account abstraction em redes não Ethereum — como a mesma ideia viaja para além da Ethereum.
Para o padrão em si, a referência autorizada é o EIP-4337, e o roteiro de account abstraction da Ethereum acompanha para onde o esforço mais amplo está indo. Se você prefere o padrão isoladamente primeiro, leia O que é account abstraction (ERC-4337)?.


