
O EIP-8141 representa uma proposta de atualização para o Ethereum que apresenta as Frame Transactions, um novo tipo de transação que permite programar a validação de contas, a execução e o pagamento de Gas. Em vez de exigir que um único remetente convencional autentique e assuma todos os custos, uma transação pode incluir várias frames com funções distintas. Para utilizadores de Carteiras e programadores, isto aproxima funcionalidades como o patrocínio de Gas, agrupamento atómico, autenticação flexível e segurança de contas avançada da camada de protocolo do Ethereum.
A proposta destina-se à atualização Hegotá do Ethereum. Em setembro de 2026, a Ethereum Foundation descreveu o EIP-8141 como a principal novidade da camada de execução dessa atualização, embora as especificações possam ainda ser ajustadas antes da implementação.
O EIP-8141 introduz o formato Frame Transaction, que pode conter múltiplas frames independentes.
Permite separar autorização, execução e pagamento de Gas, viabilizando a abstração nativa de contas.
Um patrocinador pode assumir o custo do Gas na rede Ethereum, enquanto o utilizador compensa esse patrocinador com um Token ERC-20.
O agrupamento atómico garante que ações relacionadas sejam tudo ou nada, reduzindo problemas como aprovações de tokens remanescentes.
A verificação programável abre caminho à rotação de chaves, recuperação social, esquemas de assinatura alternativos e autenticação pós-quântica.
A especificação oficial do EIP-8141 define um novo tipo de transação com validade e pagamento de Gas definidos de forma abstrata. Uma Frame Transaction divide-se em várias frames, cada uma com o seu modo de execução, destino, dados, valor e limites de Gas. Uma transação pode incluir até 64 frames.
De forma resumida, uma frame pode verificar o remetente, outra autoriza um patrocinador a pagar o Gas, e as frames seguintes executam as operações pretendidas.
Esta abordagem prolonga a direção traçada pelo Ethereum com o EIP-7702 e a abstração de contas. O roadmap de abstração de contas do Ethereum apresenta as contas programáveis como forma de suportar regras de segurança flexíveis, taxas patrocinadas, mecanismos de recuperação e agrupamento de transações.
A abstração de frames separa funções tradicionalmente unificadas nas transações convencionais.
Uma frame VERIFY pode executar a lógica de verificação e autorizar a execução ou pagamento. Uma frame SENDER atua usando o contexto do remetente. Outras frames podem tratar da implementação da conta, lógica do patrocinador ou processamento após a execução.
O elemento central é o opcode APPROVE. Um contrato de verificação utiliza APPROVE com um âmbito definido para autorizar execução, pagamento de Gas ou ambos. Apenas após a aprovação adequada as frames de remetente podem ser executadas.
O EIP inclui ainda seis instruções de introspeção—TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM, SIGPARAM e SIGDATACOPY—além do APPROVE, totalizando sete novos opcodes relacionados com frames. Estes permitem à lógica de verificação inspecionar parâmetros da transação, dados das frames, estado da execução, informações de Gas e metadados das assinaturas.
O patrocínio de Gas é das funcionalidades mais práticas do EIP-8141. Um contrato patrocinador ou outra conta elegível pode autorizar o pagamento, dispensando o remetente da necessidade de ETH disponível na conta de origem.
Por exemplo, um utilizador detentor apenas de stablecoins pode transferir um Token ERC-20 para o patrocinador na mesma Frame Transaction. O patrocinador torna-se o pagador de Gas ao nível do protocolo. O Ethereum liquida a taxa de rede através do pagador designado; a transferência ERC-20 serve para compensar esse pagador, não sendo aceite diretamente como Gas pela rede.
Cada frame define o seu orçamento de execução e Gas de estado. A capacidade não utilizada não é acumulada nas frames seguintes. O acerto final calcula o custo efetivo para o pagador e devolve a parte não utilizada do valor máximo reservado.
O EIP-8141 permite combinar várias operações numa única transação e identificar frames relacionadas como agrupamento atómico.
Por exemplo, num swap ERC-20, normalmente o utilizador aprova o Token e depois realiza o swap numa transação separada. Com o EIP, a frame de aprovação e a frame de swap podem ser agrupadas. Se a frame de swap for revertida, a aprovação inicial é também revertida.
Esta abordagem evita aprovações órfãs e simplifica interações de múltiplos passos em Carteiras.
O EIP-8141 define ainda código por defeito para contas sem smart-contract code ou código delegado. Isto permite a contas EOA existentes usar funções como transações patrocinadas e agrupamento atómico sem migração prévia dos ativos para uma smart account separada.
Uma frame de implementação pode instalar código de conta antes da verificação, quando for necessário criar uma nova smart account.
A abstração nativa de contas permite que contas implementem lógica de verificação para além do modelo clássico de Chave privada única. Isso possibilita rotação de chaves, políticas de recuperação, regras de Assinatura múltipla e agregação futura de assinaturas. A Ethereum Foundation identifica as Frame Transactions como caminho para esquemas de assinatura pós-quântica sem exigir fork do protocolo para cada novo esquema.
Distingue-se da abstração de contas ERC-4337, que utiliza UserOperations, bundlers e um mempool alternativo, sem alterar o formato base das transações Ethereum.
A flexibilidade traz complexidade acrescida. Lógica de verificação arbitrária pode criar riscos de denial-of-service no mempool público, pelo que o EIP-8141 impõe regras estritas de prefixo de validação e acesso ao estado. Os nodos devem limitar a exposição ao mempool público, mantendo em geral apenas uma Frame Transaction pendente por remetente.
O patrocínio de Gas também apresenta riscos. O EIP alerta que patrocinadores ERC-20 podem ser vítimas de frontrunning caso um utilizador remova o saldo de tokens antes da inclusão da transação.
Acima de tudo, o EIP-8141 ainda faz parte de uma atualização futura do Ethereum e não deve ser considerado ativo na mainnet atualmente.
Os utilizadores de Ethereum podem acompanhar os desenvolvimentos do protocolo através da cobertura de notícias da Gate sobre o EIP-8141 e Hegotá, bem como utilizar materiais educativos sobre abstração de contas para compreender possíveis alterações no comportamento das Carteiras.
Para análise de mercado, quem quiser estudar o impacto das grandes atualizações do Ethereum no ETH pode consultar o mercado de ETH e condições de negociação na Gate. As melhorias de protocolo podem afetar a usabilidade do Ethereum, mas não determinam isoladamente o preço de mercado do ETH.
O EIP-8141 revoluciona a transação no Ethereum ao centrá-la em frames programáveis, deixando de tratar validação, execução e pagamento de Gas como um único processo rígido. Se implementado com a atualização Hegotá, pode tornar a abstração nativa de contas uma funcionalidade de protocolo, suportando taxas patrocinadas, agrupamento atómico, implementação de contas, políticas de segurança flexíveis e sistemas de autenticação futuros.
A principal alteração é estrutural: uma conta Ethereum pode passar a funcionar essencialmente como código programável, e não apenas como um endereço gerido por uma única Chave privada.
Este conteúdo tem fins exclusivamente educativos e não constitui aconselhamento financeiro ou de investimento. Criptoativos e protocolos de Blockchain apresentam riscos técnicos e de mercado.
Não. O EIP-8141 está previsto para a atualização Hegotá e depende ainda de trabalhos de implementação e especificação antes de ser ativado.
Sim, através de patrocínio. Um patrocinador paga o custo de Gas à rede, enquanto a transação pode compensar esse patrocinador com um Token ERC-20, como uma stablecoin.
APPROVE permite que a lógica de verificação autorize a execução da transação, o pagamento de Gas ou ambos, no âmbito de uma Frame Transaction.
Não. O EIP-8141 baseia-se no trabalho contínuo de abstração de contas do Ethereum. A especificação depende do EIP-7702 e estende o modelo com a nova estrutura de Frame Transaction ao nível do protocolo.
Ao tornar a autenticação programável, as contas deixam de estar dependentes de um único esquema de chave ECDSA. Futuros designs de Carteiras podem rodar chaves ou adotar métodos de verificação pós-quântica sem que o Ethereum tenha de codificar cada esquema de autenticação separadamente.











