Account abstraction e ERC-4337: como smart contract wallets mudam UX cripto
Deep dive sobre ERC-4337 e EIP-7702 — account abstraction em Ethereum, smart contract wallets, bundlers, paymasters, e adoção em 2026.
14/05/2026 · 5 min de leitura · DeepDive · AccountAbstraction · ERC4337 · EIP7702
O problema: EOAs são limitadas
Em Ethereum tradicional, contas são EOAs (Externally Owned Accounts) — controladas por chave privada única (ECDSA). Limitações: (1) perdeu chave = perdeu fundos; (2) cada transação requer aprovação separada; (3) usuário precisa de ETH para pagar gas; (4) sem recovery social, sem multisig nativo, sem batching.
Smart contract wallets (Safe, Argent) resolvem isso, mas historicamente tinham overhead — usuário precisava de EOA + smart contract wallet, com complexidade. Account abstraction unifica isso: a conta é smart contract por padrão, com features avançadas built-in.
ERC-4337: o padrão de 2023
ERC-4337 (deployed mainnet março de 2023) introduziu account abstraction sem mudar L1 protocol — via mempool alternativo. Componentes: (1) UserOperation — pseudo-transação assinada por smart wallet; (2) Bundler — entidade que agrupa UserOperations e submete em L1 como transação real; (3) Paymaster — opcional, paga gas em nome do usuário.
Em maio de 2026, há ~12 milhões de smart contract wallets ERC-4337 ativos. Adoção foi mais lenta que esperado — overhead de gas extra (2-3x mais caro que EOA) e fragmentação de bundler ecosystem foram fricções.
EIP-7702: account abstraction sem migração
EIP-7702 (incluído em Pectra hard fork, maio 2025) permite que EOAs delegate temporariamente para código de smart contract — sem migrar para endereço novo. Sua wallet MetaMask existente pode rodar lógica de batching, recovery social, paymaster, mantendo mesmo endereço.
Em maio de 2026, EIP-7702 superou ERC-4337 em adoção total — 8+ milhões de endereços delegaram em algum momento. UX é melhor porque usuário não precisa migrar, e overhead de gas é menor (uma única transação L1, não bundler intermediário).
Features que destravam: batching e session keys
Batching: executar múltiplas operações em uma única assinatura. Exemplo: approve USDC + swap em Uniswap + stake em Aave, tudo em uma única transação. Antes precisava 3 transações separadas. Reduz gas total e fricção UX.
Session keys: chaves temporárias com permissões limitadas. Exemplo: gaming app gera session key válida por 1 hora, com permissão de transferir até 100 GAME tokens. Usuário aprova uma vez no setup, e durante a sessão, jogadas não exigem aprovação manual. Game UX como Web2.
Paymasters: pagar gas em outras moedas
Paymaster é contrato que paga gas em nome do usuário. Pode ser sponsored (dApp paga, usuário não vê custo) ou em token (usuário paga gas em USDC, paymaster converte para ETH em backend).
Em maio de 2026, paymasters são comuns em consumer apps (jogos, social tokens), mas adoção em DeFi ainda é limitada — DeFi users tipicamente têm ETH on hand. Onde paymasters brilham é em onboarding — usuário novo pode operar sem ter ETH first.
Riscos: delegation e contratos maliciosos
EIP-7702 introduziu novo vetor de ataque: delegation phishing. Usuário assina mensagem aparentemente inocente, mas que delega execução para contrato malicioso que drena fundos. Em 2025-2026, houve alguns casos públicos (perda de R$ 100k+ por delegação errada).
Mitigação: wallets modernos (Rabby, MetaMask 12+) mostram explicitamente quando delegation é solicitada e o que o contrato delegado pode fazer. Cheque sempre o contrato em Etherscan antes de assinar. Não delegue para contratos não-auditados.
OFFCODE e account abstraction
OFFCODE não usa account abstraction para custódia institucional (usa AWS KMS multisig diretamente). Mas usuários que sacam para self-custody podem usar wallets AA-compatible (Safe, Argent, Rhinestone). Em 2026, recomendamos Rabby + EIP-7702 delegation para usuários intermediários, Safe para users institucionais ou high-value.
Aviso: account abstraction adiciona features mas também complexidade. Para usuários que querem simplicidade, EOA tradicional + hardware wallet (Ledger) continua sendo viable. AA é trade-off — mais features, mais surface attack possível. Avalie seu uso case antes de migrar.