---
title: "Riesgo de firma Permit2"
description: "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."
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.
# Riesgo de firma Permit2
> 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.
## 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
- [Firma tipada EIP-712](/es/crypto/eip712-typed-signature/)
- [Aprobación de wallet](/es/crypto/wallet-approval/)
- [Firma de wallet](/es/crypto/wallet-signature/)
## Fuentes
- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers (consultado: 2026-08-13)
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers (consultado: 2026-08-13)
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers (consultado: 2026-08-13)
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers (consultado: 2026-08-13)
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2 (consultado: 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consultado: 2026-08-13)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (consultado: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultado: 2026-08-13)
Source: https://wiki.fcontext.com/es/crypto/permit2-signature-risk/index.mdx