
Se você passou algum tempo perto do Ethereum nos últimos anos, provavelmente já ouviu a frase "account abstraction" por aí — frequentemente acompanhada do codinome ERC-4337. Parece acadêmico, mas a ideia por trás é genuinamente prática: sua wallet de Ethereum deveria se comportar como um pequeno pedaço de software que você pode personalizar, e não como uma única chave privada com uma interface do tipo "pegar ou largar".
Neste artigo vamos explicar o que o ERC-4337 de fato muda, os quatro novos jargões que ele introduz (UserOperation, EntryPoint, bundler, paymaster), o que ele permite na prática, e como ele se relaciona com a abordagem multisig da própria SSP. Não é necessário conhecimento prévio sobre smart contracts — apenas curiosidade sobre como as wallets de cripto funcionam por baixo dos panos.
O problema que o ERC-4337 se propôs a resolver
Antes do account abstraction, toda wallet de Ethereum era o que se chama de externally-owned account — uma EOA. Uma EOA é extremamente simples: uma chave privada controla um endereço, e toda ação que esse endereço toma precisa ser assinada exatamente por essa chave.
Essa simplicidade vem com arestas afiadas:
- Sem recuperação. Perdeu a chave, perdeu os fundos. Não existe link de "esqueci minha senha", nem contato confiável que possa atestar por você, nem desbloqueio com tempo. A chave é a conta.
- Sem batching. Quer aprovar um token e depois trocá-lo? São duas transações separadas, duas assinaturas separadas, dois pagamentos de gas separados. Não há como dizer "faça essas juntas ou nenhuma".
- Sem multisig nativo. Se você quisesse múltiplos assinantes, tinha que implantar um contrato (como o Safe, antigo Gnosis Safe) e então fazer com que uma EOA enviasse transações para esse contrato. O contrato era multisig, mas a conta interagindo com o mundo continuava sendo uma EOA de chave única por baixo. A experiência do usuário era sempre de segunda categoria comparada a uma wallet comum.
- Gas sempre pago em ETH, sempre pago pelo remetente. Nenhuma dApp podia pagar seu gas. Nada de pagar gas em USDC. Sem exceções.
Os desenvolvedores vinham contornando esses limites com padrões de contrato elaborados havia anos. O ERC-4337 finalmente lhes deu uma saída padronizada — sem exigir nenhuma mudança no protocolo base do Ethereum.
O que o ERC-4337 introduz
O ERC-4337 não muda como o Ethereum em si funciona no nível do protocolo — essa é a sua grande sacada. Em vez disso, ele define quatro novos papéis que, juntos, simulam "smart-contract wallets como cidadãos de primeira classe" inteiramente no user-space. Uma vez que você conhece estas quatro palavras, o padrão inteiro faz sentido.
UserOperation. Este é o novo objeto de "intenção assinada" que substitui a transação bruta para uma wallet AA. Onde uma EOA produz uma transação assinada por sua única chave, uma wallet AA produz uma UserOperation — uma solicitação estruturada que diz "esta conta quer fazer X, aqui está a autorização, aqui está como pagar por isso". Uma UserOperation pode dizer "transferir 100 USDC para Alice, autorizado por assinaturas destes dois dispositivos, e a dApp vai cobrir o gas".
Contrato EntryPoint. Um único smart contract canônico e auditado, implantado no Ethereum, que sabe como receber UserOperations, verificá-las contra as regras da wallet AA de onde elas vêm, e executar as ações resultantes. Toda wallet AA conversa com o mesmo EntryPoint, e é isso que faz o padrão ser um padrão.
Bundler. Um ator off-chain (pense nele como um tipo especializado de relayer) que escuta UserOperations em uma mempool pública, agrupa várias delas, e envia o lote para o EntryPoint como uma única transação do Ethereum. O bundler paga o gas real para a rede e é reembolsado pelas UserOperations que ele agrupou.
Paymaster. Um contrato opcional que pode se voluntariar para pagar gas em nome de um usuário. O paymaster é o que torna possível "a dApp paga seu gas" ou "pagar gas em USDC em vez de ETH". Sem um paymaster, a wallet AA do usuário paga seu próprio gas; com um, o paymaster entra em cena.
Esse é todo o vocabulário. Todo o resto é decoração.
O que o account abstraction permite na prática
As quatro peças acima soam abstratas até você ver o que elas destravam:
- Patrocínio de gas. Uma dApp pode pagar gas para novos usuários para que eles não precisem adquirir ETH antes de fazer qualquer coisa. Isso é enorme para o onboarding — novos usuários podem se cadastrar, mintar um NFT, ou fazer sua primeira operação sem antes passar por uma rampa fiat-para-ETH. Argent, Safe e ZeroDev já suportam fluxos de patrocínio hoje.
- Recuperação social. Você pode configurar sua wallet de forma que, se perder sua chave principal, um quórum de "guardiões" (amigos, família, um dispositivo de hardware em um cofre) possa rotacionar a chave em seu nome. A lógica de recuperação vive no contrato da sua wallet — nenhum custodiante centralizado guarda seu dinheiro, mas seu dinheiro não fica permanentemente perdido se um único dispositivo falhar.
- Session keys. Uma dApp pode pedir à sua wallet uma chave de permissão limitada, com escopo para uma aplicação e um conjunto de ações, válida por algumas horas. Você assina uma vez com sua chave principal para conceder a sessão, e depois a dApp pode atuar dentro de seu sandbox sem te perguntar a cada clique. Estúdios de jogos adoram esse padrão.
- Ações em lote. "Aprove este token E troque-o" vira uma assinatura, uma UserOperation, uma execução. Se algum passo falhar, o lote inteiro reverte — chega de transações pela metade presas em estado inconsistente.
- Esquemas de assinatura personalizados. Quer uma wallet que use passkeys, ou um enclave de hardware, ou um esquema de limiar 2-of-3? A lógica de verificação vive no contrato da wallet, então você pode usar qualquer criptografia que quiser, não apenas o ECDSA secp256k1 padrão das EOAs.
Como isso se relaciona com o modelo multisig da SSP
A SSP Wallet toma um caminho diferente para alcançar muitos dos mesmos objetivos. A SSP usa um multisig 2-of-2 BIP48 — duas chaves independentes, em dois dispositivos independentes, ambas necessárias para assinar qualquer transação. ERC-4337 e o multisig BIP48 são mecanismos diferentes atacando um problema compartilhado: nenhum dispositivo único deve ser um ponto único de falha.
Algumas comparações honestas:
- O que eles compartilham. Ambos eliminam o modo de falha de "uma chave, uma chance" de uma wallet clássica de assinatura única. Perdeu um fator, dá para recuperar usando o outro. Comprometeu um fator (malware em um notebook, um celular perdido), e um atacante ainda assim não consegue mover fundos sozinho.
- Onde eles diferem. O BIP48 é um padrão multisig com raízes no Bitcoin que funciona nas blockchains que a SSP suporta — Bitcoin, Ethereum, Litecoin e várias outras — usando as primitivas multisig nativas de cada cadeia. O ERC-4337 é exclusivo do Ethereum e vive na camada de smart contracts, então vem com capacidades que o BIP48 não tem nativamente (patrocínio de gas, session keys), mas ao custo de ficar restrito ao Ethereum e do overhead de execução de contratos.
- Onde a SSP está hoje. A SSP é construída em torno do modelo BIP48. Wallets ERC-4337 e o multisig estilo SSP não são inimigos — são ferramentas complementares — e em princípio uma chave multisig BIP48 poderia ser usada como signatária dentro de uma wallet AA. Esse não é o caminho principal da SSP no momento, e preferimos ser claros sobre o produto de hoje a prometer integrações que ainda não entregamos.
Se você vem ponderando "devo usar uma wallet AA ou um multisig de hardware?", a resposta honesta é que eles resolvem problemas sobrepostos com diferentes trade-offs — e a resposta certa depende de quais blockchains você se importa.
Os trade-offs honestos
O account abstraction é um avanço genuíno, mas não é de graça, e quem te disser o contrário está vendendo alguma coisa.
- Os custos de gas são mais altos. Toda UserOperation executa código de contrato no EntryPoint e no contrato da sua wallet. Isso é estritamente mais computação do que uma transação assinada por uma EOA, o que significa mais gas. Bundling amortiza parte disso, mas por ação você geralmente vai pagar mais do que uma EOA pagaria.
- A recuperação é tão boa quanto o contrato de recuperação. Recuperação social e esquemas de guardiões são recursos poderosos — e também são uma nova superfície de ataque. Um bug na lógica de recuperação, ou um conjunto de guardiões que se revele pequeno demais, pode ser tão catastrófico quanto perder uma chave de EOA. Atenha-se a implementações de wallet auditadas.
- Paymasters criam uma relação de confiança. "A dApp paga o gas" soa ótimo, mas significa que o paymaster vê suas UserOperations e pode, em princípio, recusar-se a patrocinar transações específicas. Esse é um modelo de confiança diferente de "você paga seu próprio gas, ninguém pode te bloquear".
- Menos testado em batalha em escala. EOAs garantiram trilhões de dólares ao longo de mais de uma década. O ERC-4337 entrou no ar em março de 2023 e ainda está amadurecendo. Para armazenamento a frio de alto valor, a resposta conservadora (hardware wallet, multisig, contratos auditados) ainda tem o histórico mais longo.
Indo mais fundo
Para a visão do lado da SSP de como a segurança multi-chave funciona sem smart contracts, leia O que é multisig 2-of-2?.
Para a especificação técnica canônica — incluindo a struct exata da UserOperation, a interface do EntryPoint, e o raciocínio por trás de cada decisão de design — o próprio EIP é a fonte primária: https://eips.ethereum.org/EIPS/eip-4337.