---
title: "Firma del permiso ERC-2612: cómo verificar el nonce y la fecha límite"
description: "El permiso ERC-2612 le permite configurar la autorización del token con una firma. Este artículo explica la inspección artículo por artículo de Propietario, Gastador, Valor, Nonce y Fecha límite."
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.

# Firma del permiso ERC-2612: cómo verificar el nonce y la fecha límite

> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

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

## Respuesta directa

ERC-2612 usa una firma EIP-712 para establecer el `allowance` de un token ERC-20 sin una transacción `approve` separada. Este artículo explica cómo revisar Owner, Spender, Value, Nonce y Deadline y comprobar el estado en la cadena.

Cuando se mina un `permit` válido, el contrato fija `allowance(owner, spender)` en `value` e incrementa el `nonce` del propietario en 1. Un relé o un tercero puede enviar la firma, así que el propietario no tiene que enviar la transacción ni pagar su gas. `deadline` solo se comprueba al enviar `permit`; no hace que una autorización ya escrita expire automáticamente. Mientras siga siendo distinta de cero, Spender puede llamar a `transferFrom` dentro del límite.

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

## Cómo funciona

El mensaje vincula `owner`, `spender`, `value`, `nonce` y `deadline`; el dominio EIP-712 vincula la firma al contrato del token y al ID de cadena correctos. El contrato solo la acepta cuando `block.timestamp <= deadline`; al tener éxito, escribe la autorización e incrementa `nonce`, pero una fecha posterior no reduce una autorización ya escrita. Una página maliciosa puede sustituir Spender por un contrato de ataque, fijar `value` en `2^256-1` o alejar mucho la fecha límite.

Las operaciones en cadena deben dividirse en cuatro capas: interfaz de billetera, transmisión RPC, ejecución de contrato y finalidad del bloque. El éxito de cualquier capa no puede reemplazar la verificación de otras capas. Los resultados reales se basan en los recibos de transacciones, eventos, almacenamiento de contratos y saldos en la cadena correcta.

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

## Ejemplo

El usuario solo quiere autorizar 100 USDC, pero el `value` firmado es `2^256-1` y el `deadline` es diez años después. Una llamada exitosa fija ese máximo e incrementa `nonce`; aunque la transacción inicial transfiera solo 100, el atacante puede transferir USDC depositado después mientras exista la autorización. Cuando vence la fecha, un permiso no usado ya no puede enviarse, pero la autorización escrita no pasa automáticamente a 0. Revócala con `approve(spender, 0)` u otro cambio confiable.

En este caso, el gas, el tipo impositivo y el tiempo de bloqueo sólo muestran órdenes de magnitud. El estado actual del contrato, la liquidez del grupo y los permisos deben leerse antes de la operación. Las cantidades registran simultáneamente cantidades legibles por humanos, valores en dólares y números enteros sin procesar en la cadena para evitar errores de precisión.

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

## Riesgos

Compare las ganancias del protocolo con las pérdidas de salida en el peor de los casos. Supongamos que el gas se expande cinco veces, el impacto en el precio se expande dos veces y la moneda estable se descuenta un 5%. Si te unes un día más no podrás salir. Si los rendimientos semanales o mensuales no pueden cubrir estas fricciones, los llamados rendimientos altos no proporcionan una compensación adecuada. Cualquier falla en un solo protocolo no debería hacer que toda la billetera sea incapaz de pagar gas o transferir activos.

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

## Errores comunes

- Mito 1: La pantalla frontal es un hecho en la cadena. La interfaz puede estar almacenada en caché, indexada tarde o conectada a la red incorrecta y debe someterse a una validación cruzada.

- Mito 2: Aumentar el Gas o el Deslizamiento puede solucionar cualquier falla. El gas sólo afecta a la clasificación y el deslizamiento sólo relaja el precio; Los errores de permiso, Nonce y condiciones del contrato no se repararán automáticamente.

- Mito 3: Las pruebas exitosas en pequeñas cantidades significan seguridad permanente. Las actualizaciones de administradores, los parámetros dinámicos y los cambios de liquidez cambiarán los resultados y deben revisarse antes de cada expansión de posición.

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

## Temas relacionados

- [Firma estructurada EIP-712](/es/crypto/eip712-typed-signature/)
- [Cliente ligero del nodo ligero](/es/crypto/light-client/)
- [Firma del permiso2](/es/crypto/permit2-signature-risk/)
- [Conflicto de almacenamiento del contrato del agente: por qué el saldo puede alterarse después de la actualización](/es/crypto/proxy-storage-collision/)
- [Autorización de billetera](/es/crypto/wallet-approval/)

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

## Fuentes autorizadas

- [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/es/crypto/erc2612-permit-nonce-deadline/index.mdx