---
title: "Risco de assinatura Permit2"
description: "Permit2 separa allowances reutilizáveis de transferências por assinatura de uso único; assinar com segurança exige verificar deployment, domínio, spender, destinatário, valor, nonce, prazo, witness e calldata de execução."
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.
# Risco de assinatura Permit2
> Apenas para fins educacionais; não constitui aconselhamento nem recomendação de investimento. Investimentos podem resultar em perdas.
## Resposta direta
Permit2 combina dois sistemas de autorização distintos. `AllowanceTransfer` armazena allowance reutilizável owner-token-spender com valor, expiração e nonce ordenado. `SignatureTransfer` consome máximo assinado de uso único com nonce bitmap não ordenado e não cria allowance persistente para spender. Ambos ainda dependem da allowance ERC-20 do owner para Permit2.
Uma assinatura sem gas pode mover ativos quando spender ou relayer paga a execução. Verifique cadeia, código Permit2 implantado, domínio EIP-712, módulo, token, spender, máximo assinado, calldata do destinatário, nonce e relógios. Contrato Permit2 legítimo não torna seguros spender, destinatário, router ou witness maliciosos.
## Como funciona
1. Fixe `chainId`, rede, `verifyingContract` Permit2, código runtime implantado, endereço e decimais do token, tipo de wallet owner e aplicação pretendida. Use registro oficial; endereço ou rótulo conhecido não basta.
2. Leia saldo e allowance ERC-20 upstream do owner para Permit2. Identifique aprovação finita ou ilimitada e comportamento do token; esse registro sobrevive à expiração da assinatura Permit2 ou allowance downstream.
3. Identifique caminho e primary type assinado: `PermitSingle` ou `PermitBatch` de AllowanceTransfer, ou `PermitTransferFrom` e variantes batch/witness de SignatureTransfer. Não trate `transferFrom` como tipo assinado.
4. Decodifique domínio EIP-712 e cada entrada. Em AllowanceTransfer, verifique token, `uint160 amount`, `expiration`, nonce ordenado, spender e `sigDeadline`. Em SignatureTransfer, verifique token e valor permitidos, nonce não ordenado, deadline e spender vinculado pelo contexto do caller.
5. Decodifique calldata separadamente. No SignatureTransfer básico, `SignatureTransferDetails.to` e `requestedAmount` são parâmetros de execução, não campos do permit básico assinado; o valor solicitado apenas precisa ficar dentro do máximo. Verifique cada índice batch e hash/type string witness exatos.
6. Consulte nonce atual da allowance ordenada ou palavra/bit do bitmap e simule caller, calldata, cadeia e estado exatos. Concilie destinatário, ações do router, particularidades do token, saldo e ambos os registros; simulação pode mudar com estado, ordenação ou reorganização.
7. Minimize valores e prazos. Se houver suspeita, preserve typed data e envie por caminho confiável revogação upstream, downstream ou invalidação de nonce correta, tratando como corrida de mempool; aguarde confirmação e concilie transferências, saldos, allowances e bits.
O `sigDeadline` de AllowanceTransfer limita quando o permit assinado pode criar ou atualizar autoridade armazenada; `expiration` limita por quanto tempo ela pode ser gasta. O deadline de SignatureTransfer limita sua execução única. EIP-712 fornece hash tipado e separação de domínio, não proteção contra replay ou segurança da intenção; nonce e prazo do Permit2 estabelecem esses limites.
Para wallet de contrato, validade ERC-1271 depende de política `isValidSignature`, módulos, limiares e código atuais. Rótulos, telas truncadas e simulações bem-sucedidas são evidências, não garantias. Desconectar frontend não revoga aprovação nem assinatura.
## Exemplos
- **Dois registros de allowance.** A allowance finita do token para Permit2 começa em `1,000 USDC`; um `PermitSingle` armazena `600 USDC` para spender S. Depois de S transferir `225 USDC`, o valor armazenado é `600 - 225 = 375 USDC`, enquanto allowance upstream padrão fica `1,000 - 225 = 775 USDC`. Expirar ou revogar 375 não elimina 775; tokens não padrão podem diferir.
- **Destinatário e valor de uso único.** SignatureTransfer assina máximo de `250 USDC`; calldata solicita `180 USDC` para comerciante. Com saldo e allowance upstream suficientes, transfere 180. O nonce é consumido e os `70 USDC` não são reutilizáveis. Se calldata indicar atacante, o permit básico não impede redirecionamento pelo spender vinculado.
- **Bitmap de nonce não ordenado.** Para nonce `513`, `wordPos = 513 >> 8 = 2`, `bitPos = 513 & 255 = 1` e `mask = 1 << 1 = 2`. Executar marca bit 1 da palavra 2; repetir 513 falha, enquanto nonce `512` no bit 0 segue independente.
- **Corrida de revogação.** Uma allowance armazenada é `400 USDC`. O owner transmite revogação a zero, mas transferência de `300 USDC` executa primeiro, deixando `100 USDC`; a revogação posterior deixa `0`. Allowance final zero não desfaz perda de `300 USDC`; ordem e saldos devem ser conciliados.
## Riscos
- Chain ID, deployment ou código runtime incorretos.
- Verifying contract falso ou inesperado.
- Confusão entre AllowanceTransfer e SignatureTransfer.
- Spender ou caller malicioso ou incorreto.
- Destinatário escolhido pela calldata de execução.
- Valor solicitado próximo do máximo assinado.
- Endereço, símbolo, decimais ou unidades raw do token incorretos.
- Aprovação ERC-20 upstream persistente ou ilimitada.
- Valor downstream ou expiração excessivos.
- Confusão entre deadline, signature deadline e expiration.
- Nonce ordenado obsoleto ou em corrida.
- Bit bitmap reutilizado ou máscara de invalidação ampla.
- Hash witness ou type string exato divergente.
- Entrada batch oculta, duplicada ou mal indexada.
- Exibição do frontend ou calldata diverge da intenção.
- Revogação perde corrida de mempool ou MEV.
- Mudança de módulo, signer, limiar ou upgrade ERC-1271.
- Token fee-on-transfer, rebasing, pausado, bloqueado ou com callback.
- Deriva de estado, falha ou reorganização após simulação.
- Confundir confirmação em hardware wallet ou desconexão com segurança.
## Equívocos comuns
- **Assinatura sem prompt de gas não move tokens.** Outra parte pode pagar o gas da execução.
- **Endereço oficial Permit2 prova que spender e destinatário são seguros.** Permit2 pode executar fielmente autoridade maliciosa.
- **SignatureTransfer e AllowanceTransfer criam a mesma permissão persistente.** Uma é de uso único; a outra armazena allowance reutilizável.
- **Desconectar ou revogar uma camada cancela todos os caminhos e assinaturas pendentes.** Estados upstream, downstream e nonce são separados e corridas permanecem.
- **EIP-712, hardware wallet ou simulação bem-sucedida prova intenção e finalidade.** Melhoram visibilidade ou teste, mas não substituem verificar campos, calldata e estado confirmado.
## Tópicos relacionados
- [Assinatura tipada EIP-712](/pt-br/crypto/eip712-typed-signature/)
- [Aprovação de wallet](/pt-br/crypto/wallet-approval/)
- [Assinatura de wallet](/pt-br/crypto/wallet-signature/)
## Fontes
- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers (acessado em 2026-08-13)
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers (acessado em 2026-08-13)
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers (acessado em 2026-08-13)
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers (acessado em 2026-08-13)
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2 (acessado em 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (acessado em 2026-08-13)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (acessado em 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (acessado em 2026-08-13)
Source: https://wiki.fcontext.com/pt-br/crypto/permit2-signature-risk/index.mdx