---
title: "Assinatura da licença ERC-2612: como verificar o Nonce e o prazo"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

<a id="answer"></a>

## 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.

<a id="mechanism"></a>

## 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.

<a id="example"></a>

## 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.

<a id="risks"></a>

## 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.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Tópicos relacionados

- [Assinatura Estruturada EIP-712](/pt-br/crypto/eip712-typed-signature/)
- [Cliente Light do nó Light](/pt-br/crypto/light-client/)
- [Assinatura Permit2](/pt-br/crypto/permit2-signature-risk/)
- [Conflito de armazenamento de contrato do agente: por que o saldo pode ficar confuso após a atualização](/pt-br/crypto/proxy-storage-collision/)
- [Autorização da carteira](/pt-br/crypto/wallet-approval/)

<a id="sources"></a>

## Fontes oficiais

- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (accessed: 2026-07-28)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (accessed: 2026-07-28)

Source: https://wiki.fcontext.com/pt-br/crypto/erc2612-permit-nonce-deadline/index.mdx