ERC-2612: el límite de una firma no hace caducar el permiso ya creado
La fecha deadline limita cuándo puede aceptarse un permit. Una cronología ficticia permite distinguir ese plazo del saldo de autorización que queda en el contrato.
Una fecha de vencimiento en una solicitud de firma puede parecer un límite para toda la autorización. En el estándar ERC-2612 hay una distinción decisiva: deadline establece hasta cuándo puede aceptarse la llamada permit que utiliza la firma. No programa, por sí mismo, la eliminación posterior del permiso de gasto que esa llamada haya dejado establecido. La diferencia importa al interpretar cuánto tiempo dura la capacidad de una aplicación para usar tokens.
La especificación exige comprobar el tiempo del bloque, la firma, su titular y el nonce correspondiente. Si se cumplen las condiciones, permit fija allowance para el par titular y destinatario autorizado en el valor firmado, incrementa el nonce y emite el evento Approval. Si no se cumplen, la llamada debe revertirse. En esa actualización se fija una cantidad; la regla base no añade un temporizador que ponga automáticamente esa cantidad a cero cuando llegue deadline.
Consideremos una cronología ficticia con 30 unidades de un token imaginario. Una persona firma una autorización que puede presentarse hasta las 12:00 y alguien la presenta válidamente a las 11:50. Supongamos que no hay gasto, otra autorización que la sustituya ni condiciones adicionales del contrato. A las 12:01, el mero paso de esa hora no transforma en cero las 30 unidades de allowance. Si la misma autorización nunca se hubiera presentado y el tiempo del bloque ya superase deadline, esa llamada tardía a permit no cumpliría el requisito temporal. Son dos situaciones diferentes.
La lectura práctica requiere separar tres momentos: cuándo se firmó, si la firma llegó a convertirse en una autorización aceptada por el contrato y qué autorización queda ahora. La pantalla de una firma antigua no responde a la tercera pregunta. Para resolverla hacen falta la red, el contrato y el destinatario autorizado correctos, además del estado correspondiente. Esta guía no ha conectado una cartera, consultado saldos particulares o ejecutado operaciones; el ejemplo explica la secuencia del estándar.
Tampoco hay que identificar automáticamente a quien presenta la firma con quien puede gastar. ERC-2612 permite que cualquier dirección llame a permit con los datos válidos; spender es el destinatario autorizado que figura dentro del mensaje. Que un intermediario envíe la llamada no cambia por sí solo ese destinatario. El nonce sirve para impedir la reutilización de una autorización ya consumida conforme a las comprobaciones del protocolo; no equivale a una fecha de caducidad del permiso restante.
La etiqueta permit no basta para extrapolar esta explicación a cualquier token. La propia especificación compara variantes con parámetros y efectos distintos: describe, por ejemplo, una implementación que sí condiciona transferFrom a un campo de expiración. Esa diferencia obliga a comprobar la implementación concreta antes de interpretar una interfaz. No se afirma que todos los tokens admitan ERC-2612 ni que una firma con fecha corta convierta en fiable al contrato o a la aplicación.
Para revisar una explicación de una cartera, conviene formular dos preguntas por separado: hasta cuándo puede presentarse esta firma y qué limita el permiso después de aceptarse. Si el texto solo responde a la primera, todavía no ha explicado la segunda. Una respuesta útil debe identificar el estándar y las condiciones del contrato, sin presentar el vencimiento del mensaje como prueba de que una autorización ya registrada ha desaparecido.
Se trata de una guía del estándar publicado en 2020, consultado el 27 de octubre de 2026; no anuncia una modificación de hoy. Su aportación es la cronología y el criterio para leer los dos plazos. No contiene instrucciones para firmar, revocar o modificar permisos reales, ni una evaluación de seguridad de un token particular.