Assinatura da licença ERC-2612: como verificar o Nonce e o prazo

A permissão ERC-2612 permite definir autorização de token com uma assinatura. Este artigo explica a inspeção item por item de Proprietário, Gastador, Valor, Nonce e Prazo.

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

ERC-2612 usa uma assinatura EIP-712 para definir o allowance de um token ERC-20 sem uma transação approve separada. Este artigo explica como verificar Owner, Spender, Value, Nonce e Deadline e conferir o estado on-chain.

Quando um permit válido é minerado, o contrato define allowance(owner, spender) como value e incrementa o nonce do proprietário em 1. Um relayer ou terceiro pode enviar a assinatura, portanto o proprietário não precisa enviar a transação nem pagar seu gás. deadline é verificado apenas no envio de permit; ele não faz uma autorização já gravada expirar automaticamente. Enquanto não for zero, o Spender pode chamar transferFrom dentro do limite.

O ID da cadeia e a verificação do contrato correspondem à aplicação pretendidaFunção, gastador, token, valor, nonce e prazo são decodificadosA permissão existente e a semântica de substituição foram verificadasForam simuladas alterações de saldo e aprovaçãoChamadas, delegações ou transferências de valor inesperadas causam rejeição

0 / 5

0 itens revisados; 5 itens ainda não resolvidos

A conclusão desta revisão não prova que um ativo, transação ou sistema seja seguro.

Como funciona

A mensagem vincula owner, spender, value, nonce e deadline; o domínio EIP-712 vincula a assinatura ao contrato do token e à chain ID corretos. O contrato só aceita quando block.timestamp <= deadline; se for bem-sucedido, grava o allowance e incrementa o nonce, mas um prazo posterior não reduz um allowance já gravado. Uma página maliciosa pode trocar o Spender por um contrato de ataque, definir value como 2^256-1 ou deixar o prazo muito distante.

As operações on-chain devem ser divididas em quatro camadas: interface da carteira, transmissão RPC, execução do contrato e finalidade do bloco. O sucesso de qualquer camada não pode substituir a verificação de outras camadas. Os resultados reais são baseados nos recebimentos de transações, eventos, armazenamento de contratos e saldos na cadeia correta.

Exemplo

O usuário quer autorizar apenas 100 USDC, mas o value assinado é 2^256-1 e o deadline fica dez anos à frente. Uma chamada bem-sucedida define esse máximo e incrementa o nonce; mesmo que a primeira transação transfira só 100, o invasor poderá transferir USDC depositado depois enquanto o allowance existir. Após o prazo, um permit não usado não pode mais ser enviado, mas o allowance já gravado não vira 0 automaticamente. Revogue-o com approve(spender, 0) ou outra alteração confiável.

O Gás, a alíquota e o tempo de bloqueio no caso mostram apenas ordens de grandeza. O status atual do contrato, a liquidez do pool e as permissões devem ser lidos antes da operação. Os valores registram simultaneamente valores legíveis por humanos, valores em dólares e números inteiros brutos na cadeia para evitar erros de precisão.

Riscos

Compare os ganhos do protocolo com as perdas de saída no pior caso. Suponha que o gás se expanda cinco vezes, o impacto do preço se expanda duas vezes e a moeda estável receba um desconto de 5%. Se você entrar por mais um dia, não poderá sair. Se os retornos semanais ou mensais não puderem cobrir estas fricções, os chamados retornos elevados não proporcionam uma compensação adequada. Qualquer falha de protocolo único não deve tornar toda a carteira incapaz de pagar gás ou transferir ativos.

Erros comuns

Mito 1: O display frontal é o fato da rede. O front-end pode estar armazenado em cache, indexado tardiamente ou conectado à rede errada e deve ser validado cruzadamente.
Mito 2: Aumentar o gás ou o deslizamento pode resolver qualquer falha. O gás afeta apenas a classificação e a derrapagem apenas relaxa o preço; erros de permissão, Nonce e condição de contrato não serão reparados automaticamente.
Mito 3: Testes bem-sucedidos em pequenas quantidades significam segurança permanente. Atualizações de administradores, parâmetros dinâmicos e alterações de liquidez alterarão os resultados e deverão ser revisados antes de cada expansão de posição.

Tópicos relacionados

Fontes oficiais

ERC-2612: Permit Extension for EIP-20 Signed Approvals - Ethereum Improvement Proposals (accessed: 2026-07-28)
EIP-712: Typed structured data hashing and signing - Ethereum Improvement Proposals (accessed: 2026-07-28)