Ir para o conteúdo
Financial Context Wiki

Risco de assinatura Permit2

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.

Atualizado

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.

Risco de assinatura Permit2
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

  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

Fontes

Navegação

Pesquisar na wiki...