Saltar al contenido
Financial Context Wiki

Riesgo de firma Permit2

Permit2 separa allowances reutilizables de transferencias por firma de un solo uso; firmar con seguridad exige verificar despliegue, dominio, spender, destinatario, importe, nonce, plazo, witness y calldata de ejecución.

Actualizado

Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

Respuesta directa

Permit2 combina dos sistemas de autorización distintos. AllowanceTransfer almacena una allowance reutilizable owner-token-spender con importe, vencimiento y nonce ordenado. SignatureTransfer consume un máximo firmado de un solo uso con nonce bitmap no ordenado y no crea una allowance persistente para el spender. Ambos dependen aún de la allowance ERC-20 del owner a Permit2.

Una firma sin gas puede mover activos cuando un spender o relayer paga la ejecución. Verifique cadena, código Permit2 desplegado, dominio EIP-712, módulo, token, spender, máximo firmado, calldata del destinatario, nonce y relojes. El contrato Permit2 legítimo no vuelve seguros a spender, destinatario, router o witness maliciosos.

Riesgo de firma Permit2
0 / 5
0 elementos revisados; 5 elementos pendientes

Completar esta revisión no demuestra que un activo, una transacción o un sistema sean seguros.

Cómo funciona

  1. Fije chainId, red, verifyingContract de Permit2, código runtime desplegado, dirección y decimales del token, tipo de wallet owner y aplicación prevista. Use un registro oficial; dirección o etiqueta conocida no basta.
  2. Lea saldo y allowance ERC-20 upstream del owner a Permit2. Identifique aprobación finita o ilimitada y comportamiento del token; este registro sobrevive al vencimiento de una firma Permit2 o allowance downstream.
  3. Identifique vía y primary type firmada: PermitSingle o PermitBatch de AllowanceTransfer, o PermitTransferFrom y variantes batch/witness de SignatureTransfer. No trate transferFrom como tipo firmado.
  4. Decodifique dominio EIP-712 y cada entrada. En AllowanceTransfer revise token, uint160 amount, expiration, nonce ordenado, spender y sigDeadline. En SignatureTransfer revise token e importe permitidos, nonce no ordenado, deadline y spender vinculado por el contexto del caller.
  5. Decodifique por separado la calldata. En SignatureTransfer básico, SignatureTransferDetails.to y requestedAmount son parámetros de ejecución, no campos del permit básico firmado; basta que el importe solicitado no exceda el máximo firmado. Verifique cada índice batch y hash/type string witness exactos.
  6. Consulte nonce actual de allowance ordenada o palabra/bit del bitmap no ordenado y simule caller, calldata, cadena y estado exactos. Concilie destinatario, acciones del router, particularidades del token, saldo y ambos registros; la simulación puede cambiar por estado, orden o reorganización.
  7. Minimice importes y vigencias. Ante sospecha, conserve typed data y envíe por vía fiable la revocación upstream, downstream o invalidación de nonce correcta, tratándola como carrera de mempool; espere confirmación y concilie transferencias, saldos, allowances y bits.

El sigDeadline de AllowanceTransfer limita cuándo el permit firmado puede crear o actualizar autoridad almacenada; expiration limita cuánto tiempo puede gastarse. El deadline de SignatureTransfer limita su ejecución única. EIP-712 aporta hash tipado y separación de dominio, no protección contra replay ni seguridad de intención; nonce y plazo de Permit2 establecen esos límites.

Para una wallet contractual, la validez ERC-1271 depende de política isValidSignature, módulos, umbrales y código actuales. Etiquetas, pantallas truncadas y simulaciones satisfactorias son evidencias, no garantías. Desconectar un frontend no revoca aprobación ni firma.

Ejemplos

  • Dos registros de allowance. La allowance finita del token a Permit2 parte de 1,000 USDC; un PermitSingle almacena 600 USDC para spender S. Tras transferir S 225 USDC, queda 600 - 225 = 375 USDC, mientras una allowance upstream estándar queda 1,000 - 225 = 775 USDC. Vencer o revocar 375 no elimina 775; tokens no estándar pueden diferir.
  • Destinatario e importe de un solo uso. SignatureTransfer firma máximo 250 USDC; la calldata pide 180 USDC para un comercio. Con saldo y allowance upstream suficientes, transfiere 180. El nonce se consume y los 70 USDC no son reutilizables. Si calldata designa al atacante, el permit básico no impide esa redirección por el spender vinculado.
  • Bitmap de nonce no ordenado. Para nonce 513, wordPos = 513 >> 8 = 2, bitPos = 513 & 255 = 1 y mask = 1 << 1 = 2. Ejecutar marca bit 1 de palabra 2; repetir 513 falla y nonce 512 en bit 0 sigue independiente.
  • Carrera de revocación. Una allowance almacenada es 400 USDC. El owner difunde revocación a cero, pero primero se ejecuta transferencia de 300 USDC, dejando 100 USDC; después la revocación deja 0. Allowance final cero no revierte pérdida de 300 USDC; deben conciliarse orden y saldos.

Riesgos

  • Chain ID, deployment o código runtime equivocados.
  • Verifying contract falso o inesperado.
  • Confusión entre AllowanceTransfer y SignatureTransfer.
  • Spender o caller malicioso o erróneo.
  • Destinatario elegido mediante calldata de ejecución.
  • Importe solicitado próximo al máximo firmado.
  • Dirección, símbolo, decimales o unidades raw del token erróneos.
  • Aprobación ERC-20 upstream persistente o ilimitada.
  • Importe downstream o vencimiento excesivo.
  • Confusión entre deadline, signature deadline y expiration.
  • Nonce ordenado obsoleto o sujeto a carrera.
  • Bit bitmap reutilizado o máscara de invalidación excesiva.
  • Hash witness o type string exacto incorrectos.
  • Entrada batch oculta, duplicada o mal indexada.
  • Pantalla del frontend o calldata distinta de la intención.
  • Revocación pierde carrera de mempool o MEV.
  • Cambio de módulo, firmante, umbral o upgrade ERC-1271.
  • Token fee-on-transfer, rebasing, pausado, bloqueado o con callback.
  • Deriva de estado, fallo o reorganización tras simulación.
  • Confundir confirmación de hardware wallet o desconexión con seguridad.

Errores comunes

  • Una firma sin solicitud de gas no puede mover tokens. Otra parte puede pagar el gas.
  • La dirección oficial de Permit2 demuestra que spender y destinatario son seguros. Permit2 puede ejecutar fielmente autoridad maliciosa.
  • SignatureTransfer y AllowanceTransfer crean el mismo permiso persistente. Uno es de uso único; el otro almacena allowance reutilizable.
  • Desconectar o revocar una capa cancela todas las vías y firmas pendientes. Estado upstream, downstream y nonce son distintos y quedan carreras.
  • EIP-712, hardware wallet o simulación exitosa prueba intención y finalidad. Mejoran visibilidad o pruebas, pero no sustituyen verificar campos, calldata y estado confirmado.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...