ERC-7779 em Produção

LeeMaimai

/14 de out. de 2025

Principais Resultados

• O ERC-7779 visa aprovações de transação mais seguras e granulares.

• Melhora a experiência do usuário com prompts claros e dados estruturados.

• Adoção do ERC-7779 pode impactar positivamente a segurança e a clareza nas transações no Ethereum.

• Ferramentas como Etherscan Token Approval Checker ajudam na gestão de aprovações.

O ritmo de desenvolvimento de padrões no Ethereum raramente diminui. Com o ERC-7779 agora em produção, usuários, desenvolvedores e provedores de carteiras estão fazendo a mesma pergunta: o que mais um ERC em produção realmente muda para as experiências diárias de cripto e DeFi? Este post detalha por que novos ERCs são importantes, como eles chegam à produção, as implicações práticas para aprovações e a experiência do usuário em transações, e o que os usuários do OneKey podem esperar à medida que os ecossistemas adotam as interfaces mais recentes.

Primeiro, uma rápida recapitulação: o que é um ERC?

Um ERC (Ethereum Request for Comments) é um padrão de nível de aplicativo impulsionado pela comunidade que define como contratos e aplicativos devem se comportar para que possam interoperar de forma confiável (pense em ERC‑20 ou ERC‑721). Os ERCs emergem através do processo EIP, do rascunho à versão final, com discussão aberta e revisão por pares. Se você é novo em como os padrões são feitos, o processo EIP é documentado em detalhes na especificação oficial. Veja o ciclo de vida e a justificativa do EIP na documentação de padrões do Ethereum e no meta‑processo do EIP:

Aprenda como funcionam os padrões do Ethereum no portal oficial do desenvolvedor (veja Padrões do Ethereum)
Mergulhe no ciclo de vida e nas definições de status do EIP (veja EIP‑1)

Para manter carteiras, dapps e Layer 2s alinhados, os ERCs frequentemente se baseiam em EIPs fundamentais, como:

EIP‑712 para assinatura de dados estruturados e legíveis por humanos (veja EIP‑712)
EIP‑165 para detecção de interface e verificações de compatibilidade (veja EIP‑165)
EIP‑2771 para meta‑transações via forwarders confiáveis (veja EIP‑2771)

O que o ERC‑7779 visa melhorar

Embora cada novo ERC seja único, os padrões recentes tendem para dois objetivos:

Aprovações e permissões de transação mais seguras e granulares. Os usuários querem autorizar precisamente o que um dapp pode fazer, por quanto tempo e com prompts claros no dispositivo. Essa direção segue as lições do fluxo approve/transferFrom do ERC‑20 e a evolução para assinaturas no estilo de permissão. Veja o histórico sobre as armadilhas do approve e padrões mais seguros (veja notas do OpenZeppelin sobre approve).
Melhor experiência do usuário da carteira através de contexto mais rico. Os padrões codificam cada vez mais metadados para que as carteiras possam renderizar prompts compreensíveis em vez de bytecode opaco, alinhando-se com convenções de assinatura legíveis por humanos. Leia sobre dados estruturados tipados para prompts mais seguros (veja EIP‑712).

Na prática, o ERC‑7779 "em produção" significa que os primeiros adotantes (dapps, SDKs e carteiras) começaram a integrar uma interface projetada para fornecer aprovações mais seguras, melhor decodificação e menos assinaturas confusas — sem quebrar a compatibilidade com tokens e protocolos existentes.

Por que isso importa agora

O momento é significativo. As atualizações recentes do Ethereum reduziram as taxas de L2 e ampliaram a atividade on-chain, enquanto a abstração de conta e os novos padrões de carteira estão amadurecendo:

O Dencun na mainnet desbloqueou disponibilidade de dados mais barata para rollups e impulsionou a adoção de L2 (veja anúncio do Dencun)
A abstração de conta está passando da teoria para a implementação, permitindo carteiras programáveis (veja EIP‑4337)
Um modelo de transação proposto (EIP‑7702) introduz novas maneiras de autorizar ações com trocas aprimoradas de experiência do usuário e segurança (veja EIP‑7702)
O roteiro de longo prazo do Ethereum continua priorizando escalabilidade e segurança, o que afeta como as carteiras e os padrões evoluem (veja roteiro do Ethereum)

Nesse contexto, qualquer ERC que reforce a segurança de aprovação e melhore a clareza dos prompts pode ter um impacto desproporcional no mundo real.

Para usuários comuns: o que muda na sua carteira

Prompts mais claros, menos assinaturas cegas. Carteiras que implementam metadados no estilo ERC‑7779 podem mostrar o que um contrato está pedindo — e por quê — usando dados estruturados sempre que possível (veja EIP‑712).
Permissões mais granulares. Espere que controles por função ou por valor se tornem mais comuns à medida que os ecossistemas convergem para fluxos semelhantes a permissões e melhores práticas (veja extensão de permissão ERC‑20 EIP‑2612 e padrões Permit2).
Higiene de allowance mais fácil. Continue usando um scanner de allowance para identificar e revogar aprovações arriscadas, especialmente ao migrar para novos padrões (veja Etherscan Token Approval Checker).
Menor carga cognitiva em L2s. À medida que os padrões adotam interfaces consistentes, sua experiência se torna mais uniforme em todas as redes.

Ferramentas e referências úteis:

Etherscan Token Approval Checker para revogações e monitoramento
Fluxos no estilo Permit e padrões de revogação adotados em DEXs modernos (veja visão geral do Permit2)
Orientação do OpenZeppelin sobre aprovações de ERC‑20 e ressalvas de segurança (veja notas do OpenZeppelin sobre approve)

Para desenvolvedores: guia de integração

Compatibilidade retroativa em primeiro lugar. Mantenha a compatibilidade com ERC‑20 enquanto sobrepõe novas interfaces por meio da detecção EIP‑165 para que carteiras antigas não quebrem (veja EIP‑165).
Prefira dados tipados em vez de bytes brutos. Mova as assinaturas voltadas para o usuário para EIP‑712 sempre que viável para permitir assinaturas claras em carteiras de hardware e melhores prompts de risco (veja EIP‑712).
Considere fluxos de permissão. Se o seu caso de uso concede permissões de gastos, adote padrões no estilo de permissão (EIP‑2612) ou bibliotecas comprovadas que reduzem a superfície de ataque de aprovação (veja EIP‑2612 e visão geral do Permit2).
Suporte a meta‑tx onde apropriado. Com o EIP‑2771, permita fluxos com gás patrocinado, mantendo proteções contra replay e separação de domínio intactas (veja EIP‑2771).
Use bibliotecas auditadas. Confie em primitivas e interfaces mantidas em vez de criar as suas próprias (veja OpenZeppelin Contracts).
Modele ameaças para novos caminhos de código. Qualquer novo hook ou superfície de permissão introduz riscos potenciais de reentrância e abuso de aprovação — mapeie-os para categorias SWC conhecidas e teste exaustivamente (veja SWC Registry).

Referências para desenvolvedores:

EIP‑2612 (permissão para ERC‑20)
Visão geral do Permit2 e melhores práticas para aprovações
OpenZeppelin Contracts 5.x para implementações alinhadas com padrões
SWC Registry para classes de vulnerabilidade

Integração de carteira e considerações de hardware

Quando um novo ERC é lançado, a segurança real do usuário depende de como as carteiras o implementam:

Decodificação precisa de métodos: As carteiras devem decodificar interfaces via EIP‑165, quando aplicável, e exibir a intenção legível por humanos em vez de seletores de função.
Assinatura clara no dispositivo: Onde dados estruturados estiverem disponíveis, as carteiras de hardware devem exibir campos legíveis por humanos para que os usuários possam verificar o que estão assinando (veja EIP‑712).
Simulação e indicadores de risco: A simulação pré-assinatura, diferenças de allowance e indicadores de proveniência de contrato ajudam a capturar aprovações maliciosas antes que elas cheguem on-chain.

O que os usuários do OneKey podem esperar:

Assinatura baseada em padrões: O OneKey suporta padrões de Ethereum convencionais, incluindo assinatura de dados estruturados, ajudando você a evitar prompts de bytecode ambíguos (veja EIP‑712).
Revisão transparente de transações: O aplicativo OneKey exibe os detalhes do método, ativo e valor antes de você confirmar no dispositivo.
Ética de código aberto: Com um codebase aberto, revisores independentes e a comunidade podem examinar como novos padrões são integrados — vital quando os ERCs introduzem novos caminhos de permissão.

À medida que a adoção do ERC‑7779 se expande, o OneKey continuará priorizando a assinatura clara e a compatibilidade entre redes L1 e L2, mantendo práticas rigorosas de segurança.

Higiene de segurança: o essencial não muda

Use allowances por dapp e mínimas sempre que possível; evite aprovações ilimitadas a menos que estritamente necessário.
Revogue periodicamente aprovações inativas, especialmente após experimentar novos dapps ou migrar para novos padrões (use Etherscan Token Approval Checker).
Trate novos fluxos como novas superfícies de ataque. Kits de phishing evoluem para imitar novos prompts de carteira — verifique domínios, endereços de contrato e IDs de cadeia.
Prefira contratos e bibliotecas auditados e bem mantidos (veja OpenZeppelin Contracts) e entenda as classes comuns de fraquezas de contratos inteligentes (veja SWC Registry).

Olhando para o futuro

O ERC‑7779 faz parte de um ciclo de atualização mais amplo de carteiras e experiência do usuário, abrangendo abstração de conta (veja EIP‑4337), modelos propostos de autorização de transações (veja EIP‑7702) e a cadência constante de melhorias de rede no roteiro do Ethereum. À medida que os padrões amadurecem e convergem, os usuários devem ver menos prompts confusos, aprovações mais seguras por padrão e uma experiência mais consistente em L2s.

Se você gerencia valor on-chain significativo, considere emparelhar sua carteira de software preferida com uma carteira de hardware. O OneKey enfatiza a assinatura clara para padrões como EIP‑712, transparência de código aberto e compatibilidade multichain — salvaguardas práticas à medida que novos ERCs são lançados e a superfície de transação evolui.

Referências e leituras adicionais: