Buy Crypto
Markets
Spot
FuturesBTC
Earn
Event Center
More
0-Fee Fest
Función Permit (EIP-2612): ¿Qué es la función Permit (EIP-2612)?La función Permit, definida por EIP-2612, es una extensión de los tokens ERC-20 que permite al titular de un token autorizar a un gastador mediante la firma de un Función Permit (EIP-2612): ¿Qué es la función Permit (EIP-2612)?La función Permit, definida por EIP-2612, es una extensión de los tokens ERC-20 que permite al titular de un token autorizar a un gastador mediante la firma de un

Función Permit (EIP-2612)

2026/10/13 16:44
#Advanced
Humanity
H$0.05579-0.78%
Lagrange
LA$0.06402-1.06%
PX
PX$0.0129+0.78%
PortugalNationalTeam
POR$0.06773-2.29%
TokenFi
TOKEN$0.001996-0.05%

¿Qué es la función Permit (EIP-2612)?

La función Permit, definida por EIP-2612, es una extensión de los tokens ERC-20 que permite al titular de un token autorizar a un gastador mediante la firma de un mensaje off-chain, en lugar de enviar una transacción de aprobación on-chain por separado.

En el ámbito cripto, esto es importante porque facilita las aprobaciones de tokens, reduce su coste y permite combinarlas con otras acciones de contratos inteligentes.

La especificación oficial de EIP-2612 explica que el estándar amplía ERC-20 con una nueva función llamada

permit
, que modifica el mapeo de allowance mediante un mensaje firmado, en lugar de hacerlo a través de
msg.sender
.

En términos sencillos, EIP-2612 permite que un usuario diga: «Autorizo a este contrato inteligente a gastar esta cantidad de mis tokens» firmando un mensaje en una wallet.

Otra cuenta o contrato puede enviar después esa aprobación firmada a la blockchain.

Esto significa que el titular del token no tiene que enviar directamente la transacción de aprobación.

También significa que quizá no necesite tener el token nativo de la red para pagar la comisión de gas y aprobar el gasto de un token ERC-20.

La función Permit no transfiere tokens por sí misma.

Solo establece una allowance, que más adelante puede utilizar

transferFrom
u otro flujo de contrato que consuma la allowance aprobada.

Esta distinción es fundamental, porque aprobar a un gastador no es lo mismo que enviarle tokens.

La mejor forma de entender un permit es como una autorización firmada que actualiza el estado de allowance de ERC-20 on-chain una vez enviada la firma.

Aspectos clave de la función Permit

    • EIP-2612 añade
      permit
      ,
      nonces
      y
      DOMAIN_SEPARATOR
      a los tokens ERC-20.

    • La función Permit permite aprobar el gasto de ERC-20 mediante una firma off-chain.

    • El mensaje firmado sigue las reglas de datos estructurados tipados de EIP-712.

    • Un permit modifica la allowance, pero no transfiere tokens por sí mismo.

    • Los nonces impiden reutilizar la misma firma de permit.

    • Los plazos límite restringen durante cuánto tiempo puede seguir siendo válido un permit firmado.

    • Permit mejora la experiencia de usuario, pero no elimina el riesgo de las aprobaciones ni el phishing de firmas.

Por qué se creó EIP-2612

Los tokens ERC-20 utilizan un modelo de aprobación que permite a una dirección autorizar a otra para gastar tokens en su nombre.

El estándar ERC-20 original define funciones como

approve
,
allowance
y
transferFrom
.

Este modelo de aprobación permitió reutilizar los tokens en wallets, contratos inteligentes, sistemas de pago, interfaces de trading, protocolos de préstamo, contratos de staking y otras aplicaciones descentralizadas.

Sin embargo, el flujo habitual de aprobación de ERC-20 suele requerir dos transacciones on-chain.

La primera es una transacción

approve
.

La segunda es la acción del contrato inteligente que utiliza los tokens aprobados.

Esto genera fricción para los usuarios, que deben pagar la comisión de gas dos veces, esperar dos confirmaciones y entender dos solicitudes distintas de la wallet.

También supone un problema para quienes tienen tokens ERC-20, pero no el token nativo necesario para enviar la transacción de aprobación.

EIP-2612 resuelve este problema concreto al permitir aprobar mediante un mensaje firmado.

El titular del token firma el permit off-chain y otra parte puede enviarlo on-chain.

Así, un flujo de contrato inteligente puede combinar la aprobación y la acción de forma más eficiente.

Por ejemplo, un usuario podría firmar un permit y, a continuación, un contrato podría consumirlo y transferir los tokens en un único flujo de transacción.

Esto no hace que las transacciones sean gratuitas a nivel de red.

Alguien sigue teniendo que pagar la comisión de gas para enviar el permit on-chain.

La ventaja es que quien paga el gas no tiene por qué ser el titular del token.

Cómo funciona la función Permit

La función principal de EIP-2612 tiene esta estructura:

permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)
.

owner
es el titular del token que firma la aprobación.

spender
es la dirección que recibirá la allowance.

value
es la cantidad de tokens aprobada para gastar.

deadline
es el último momento en que se puede utilizar el permit.

Los valores

v
,
r
y
s
son partes de la firma criptográfica.

Cuando se envía el permit, el contrato del token comprueba si la firma es válida.

También comprueba si ha vencido el plazo límite.

Además, verifica si el nonce del mensaje firmado coincide con el nonce actual del titular.

Si se superan todas las comprobaciones necesarias, el contrato establece

allowance[owner][spender]
en el valor aprobado.

A continuación, el contrato incrementa el nonce del titular para impedir que se reutilice la misma firma.

El contrato también emite un evento

Approval
, con lo que mantiene el comportamiento esperado de las aprobaciones ERC-20.

Este proceso convierte una firma de wallet en una actualización on-chain de la allowance.

Las tres funciones principales de EIP-2612

EIP-2612 exige que los tokens compatibles añadan tres funciones a ERC-20.

La primera es

permit
.

La función

permit
verifica una aprobación firmada y actualiza la allowance.

La segunda es

nonces
.

La función

nonces
devuelve el nonce actual de una dirección de titular.

La tercera es

DOMAIN_SEPARATOR
.

La función

DOMAIN_SEPARATOR
devuelve el separador de dominio de EIP-712, que se utiliza para asociar la firma a un contrato de token y a un dominio de firma concretos.

Estas tres funciones trabajan conjuntamente.

La firma del permit define la aprobación.

El nonce impide la repetición.

El separador de dominio ayuda a vincular la firma al contrato y al contexto de red correctos.

Sin estos elementos complementarios, sería mucho más fácil hacer un uso indebido de las firmas permit o reproducirlas en un contexto incorrecto.

¿Qué es una allowance?

Una allowance es la cantidad de tokens ERC-20 que un titular ha autorizado a un gastador a utilizar.

Por ejemplo, si Alice autoriza a un contrato inteligente a gastar 100 tokens, la allowance de Alice para ese contrato será de 100 tokens.

El gastador podrá llamar a

transferFrom
para transferir hasta la cantidad aprobada, en función del contrato del token y del flujo de la aplicación.

La función Permit no elimina el sistema de allowances.

Cambia la forma de crear una allowance.

En vez de exigir que el titular del token llame directamente a

approve
, EIP-2612 le permite firmar un mensaje que autoriza la actualización de la allowance.

Esto mejora la usabilidad y mantiene la compatibilidad con el conocido modelo de allowance de ERC-20.

Los usuarios deben seguir gestionando las allowances con cuidado, ya que un gastador aprobado puede transferir tokens hasta el importe autorizado.

Una aprobación permit ilimitada puede resultar cómoda, pero también puede provocar grandes pérdidas si el contrato gastador es malicioso, se ve comprometido o no se entiende correctamente.

Función Permit frente a función Approve

La función tradicional

approve
la invoca directamente el titular del token en una transacción on-chain.

La función Permit cuenta con la autorización del titular mediante una firma off-chain y otra parte la envía posteriormente on-chain.

Con

approve
, el titular del token debe pagar la comisión de gas de la transacción de aprobación.

Con

permit
, el titular firma un mensaje y un relayer, una aplicación o el gastador puede pagar el gas para enviarlo.

Con

approve
, la acción de aprobación queda vinculada inmediatamente a
msg.sender
.

Con

permit
, la aprobación queda vinculada a una firma verificada del titular.

El resultado puede ser la misma actualización de allowance, pero la experiencia de usuario es distinta.

Por eso suele decirse que EIP-2612 permite realizar aprobaciones sin gas.

Más exactamente, permite aprobar sin que el titular del token tenga que enviar la transacción de aprobación.

La blockchain sigue necesitando una transacción y gas para actualizar el estado.

Por qué EIP-712 es importante para Permit

EIP-2612 utiliza datos estructurados tipados basados en EIP-712.

EIP-712 es un estándar para aplicar hash y firmar datos estructurados, en lugar de cadenas de bytes opacas.

Esto es importante porque los usuarios de wallets necesitan entender qué están firmando.

Una solicitud de firma hexadecimal sin procesar puede resultar confusa y peligrosa.

Una firma tipada puede mostrar con más claridad campos como el titular, el gastador, el valor, el nonce y el plazo límite.

EIP-712 también utiliza un separador de dominio.

Este ayuda a distinguir un contexto de firma de otro.

En EIP-2612, suele incluir información como el nombre del token, la versión, el ID de la red y la dirección del contrato verificador.

Este diseño ayuda a evitar que una firma destinada a un token o una red sea válida en otro contexto.

El propio EIP-712 indica que no incluye protección contra la repetición por sí mismo.

EIP-2612 añade esa protección mediante nonces individuales para cada titular.

Nonces y protección contra la repetición

Un nonce es un número que se utiliza una sola vez.

En EIP-2612, el contrato del token lleva el registro de un nonce para cada dirección de titular.

Cuando un usuario firma un permit, los datos firmados incluyen el nonce actual del titular.

Cuando el permit se utiliza correctamente, el contrato del token incrementa ese nonce.

Si alguien intenta enviar de nuevo el mismo permit, el nonce ya no coincidirá.

Por tanto, la firma reutilizada fallará.

La protección mediante nonce es esencial, porque las firmas se pueden copiar.

Sin ella, un gastador o atacante podría reutilizar varias veces el mismo permit firmado.

Una implementación correcta de permit debe incluir los nonces en el mensaje firmado y actualizarlos solo cuando el permit se ejecute correctamente.

Para los usuarios, la idea práctica es sencilla.

Una firma permit válida debería poder utilizarse una vez, no para siempre.

Plazos límite y caducidad de las firmas

El parámetro

deadline
limita el tiempo durante el que se puede utilizar una firma permit.

Si la marca de tiempo del bloque actual es posterior al plazo límite, el permit debería fallar.

Esto protege a los usuarios frente a la presentación de firmas antiguas mucho después del momento en que estaba previsto utilizarlas.

Un plazo límite corto puede reducir el riesgo, ya que limita el periodo de envío.

Un plazo límite largo puede resultar más cómodo porque la firma sigue siendo utilizable durante más tiempo.

Un plazo ilimitado o muy lejano puede ser arriesgado, porque la aprobación firmada podría seguir siendo válida durante mucho tiempo, salvo que se consuma, se invalide o se sustituya mediante el mecanismo de nonce.

Los usuarios deben prestar atención a los plazos límite cuando las wallets muestren datos permit tipados.

Los desarrolladores deben evitar plazos demasiado amplios, salvo que exista un motivo claro.

Las aplicaciones deben explicar el significado del plazo límite de forma comprensible para los usuarios.

Separador de dominio y contexto de red

El separador de dominio es una parte clave de la firma EIP-712.

En EIP-2612, ayuda a vincular el permit a un contrato de token y un dominio concretos.

Un dominio habitual incluye el nombre del token, la versión del token, el ID de la red y la dirección del contrato verificador.

Esto reduce el riesgo de que un permit firmado para un contrato se reproduzca contra otro.

También reduce el riesgo de reutilizar en otra red un permit firmado en una red determinada.

Sin embargo, la seguridad del separador de dominio depende de una implementación correcta.

Si un contrato de token utiliza un separador de dominio incompleto, el riesgo de repetición puede aumentar.

Si cambia el ID de la red o un contrato se despliega en varias redes, los desarrolladores deben analizar cuidadosamente cómo separar las firmas.

Para los usuarios, el separador de dominio suele quedar oculto tras la interfaz de la wallet.

Para los desarrolladores, es uno de los aspectos más importantes de una implementación segura de permit.

Explicación de las aprobaciones sin gas

La expresión «aprobación sin gas» puede resultar confusa.

EIP-2612 no hace que las transacciones de Ethereum o EVM sean gratuitas.

Permite que el titular del token apruebe el gasto firmando un mensaje en lugar de enviar una transacción.

Después, un relayer, una aplicación, un contrato inteligente o el gastador puede enviar el permit firmado on-chain y pagar el gas.

Esto puede ayudar a los usuarios que tienen tokens ERC-20, pero no suficiente token nativo para aprobarlos.

También puede ayudar a las aplicaciones a ofrecer flujos más sencillos en un solo paso.

Por ejemplo, un usuario puede firmar un permit y completar después un depósito, un pago o una acción con tokens sin enviar manualmente antes otra transacción de aprobación.

La experiencia parece más sencilla, pero la blockchain sigue registrando el cambio de estado mediante una transacción on-chain.

Los desarrolladores deben explicarlo con claridad, ya que, de lo contrario, los usuarios podrían pensar que los mensajes firmados no tienen consecuencias.

Una firma permit puede tener consecuencias on-chain reales cuando alguien la envía.

Casos de uso habituales de EIP-2612 en cripto

EIP-2612 se utiliza con frecuencia en DeFi y en aplicaciones basadas en tokens.

Un protocolo de préstamo puede utilizar permit para que un usuario apruebe una garantía y la deposite en un único flujo.

Un contrato de staking puede utilizar permit para que un usuario apruebe tokens para staking sin una transacción de aprobación independiente.

Una aplicación de pagos puede utilizar permit para que quien paga autorice el movimiento de tokens mediante un proceso de pago más sencillo.

Una wallet puede utilizar permit para reducir los pasos de las interacciones habituales con ERC-20.

Un servicio de relayer puede pagar el gas en nombre de un usuario y recuperar las comisiones de otra forma.

Un contrato inteligente puede combinar permit con

transferFrom
para que la aprobación y el movimiento de tokens tengan lugar en el mismo flujo de transacción.

Este patrón puede reducir los flujos fallidos, ya que no es necesario minar la aprobación por separado antes de realizar la acción principal.

También puede reducir la confusión, porque la aplicación puede guiar al usuario a través de un único proceso combinado.

La principal ventaja no es solo ahorrar gas.

La principal ventaja es reducir la fricción al autorizar el uso de tokens.

Función Permit y abstracción de cuentas

A veces se habla de la función Permit junto con la abstracción de cuentas, porque ambas ideas mejoran la experiencia de usuario de las wallets.

Permit permite al titular de un token ERC-20 autorizar cambios en la allowance mediante firmas.

La abstracción de cuentas pretende que las cuentas cripto sean más programables y flexibles.

Son herramientas distintas, pero comparten un objetivo similar.

Ambas intentan reducir la fricción de las interacciones con blockchain.

Permit se centra en las aprobaciones de tokens.

La abstracción de cuentas se centra, de forma más amplia, en cómo autorizan y pagan las cuentas las acciones.

Una aplicación cripto puede utilizar ambas ideas en el diseño de un mismo producto.

Por ejemplo, una wallet o un sistema de smart accounts puede admitir transacciones patrocinadas y, al mismo tiempo, utilizar aprobaciones de tokens compatibles con permit.

Los usuarios no necesitan entender todos los niveles técnicos, pero los desarrolladores deben implementar correctamente cada uno.

Riesgos de seguridad de la función Permit

El principal riesgo para los usuarios es el phishing de firmas.

Un sitio web malicioso puede pedir a un usuario que firme un permit que autorice a un gastador peligroso.

Como una firma permit no es una transferencia normal de tokens, algunos usuarios pueden pensar que es inofensiva.

Es una suposición peligrosa.

Un permit puede autorizar a un gastador a transferir tokens más adelante.

Antes de firmar, los usuarios deben leer la dirección del gastador, la cantidad de tokens, el nombre del token y el plazo límite.

Deben rechazar las firmas que no estén claras, sean inesperadas o las soliciten sitios web desconocidos.

Otro riesgo son las aprobaciones ilimitadas.

Si un usuario firma un permit con un valor muy elevado, el gastador puede obtener amplios permisos para gastar tokens dentro de esa allowance.

Un tercer riesgo es una implementación defectuosa.

Si el contrato del token gestiona incorrectamente los nonces, la separación de dominios, la recuperación de firmas o los plazos límite, las firmas podrían reproducirse o aceptarse cuando deberían fallar.

Un cuarto riesgo es la confusión de la interfaz de usuario.

Si una wallet no muestra con claridad los datos tipados, los usuarios podrían firmar aprobaciones que no entienden.

Permit mejora la usabilidad, pero también hace que sea más importante enseñar a los usuarios a interpretar las firmas.

Permit no elimina el riesgo de las aprobaciones

EIP-2612 cambia la forma de autorizar una aprobación, pero no altera el riesgo básico de aprobar a un gastador.

Si un gastador es malicioso, se ve comprometido o recibe una allowance demasiado amplia, el usuario aún puede perder tokens.

Una aprobación permit puede ser tan potente como una transacción

approve
normal.

La diferencia es que la aprobación comienza como una firma, en lugar de como una transacción del titular del token.

Por eso, los usuarios deben tratar las firmas permit con la misma cautela que las transacciones de aprobación.

Deben evitar firmar permits ilimitados, salvo que confíen plenamente en el gastador y entiendan el riesgo.

También deben revocar las allowances que ya no necesiten.

Es recomendable utilizar wallets distintas para las interacciones de mayor riesgo con dApps y para los activos que se mantienen a largo plazo.

Antes de aprobar el acceso a tokens de valor, los usuarios deben verificar las direcciones de los contratos mediante fuentes fiables.

Permit y front-running

Cualquiera que tenga el mensaje firmado puede enviar las firmas permit.

Esto plantea una cuestión específica relacionada con el front-running.

Si un usuario firma un permit y lo envía a una aplicación, otra parte que vea la firma podría enviarlo primero.

En muchos casos, esto solo consume el permit y establece la misma allowance que pretendía el usuario.

Sin embargo, si una aplicación espera que la ejecución del permit y otra acción tengan lugar conjuntamente, un permit enviado mediante front-running podría hacer que fallara la transacción combinada posterior, porque el nonce ya habría cambiado.

Los desarrolladores deben diseñar flujos que gestionen correctamente esta situación.

A menudo, un contrato inteligente puede comprobar si la allowance esperada ya está disponible y continuar, en lugar de fallar innecesariamente.

Las interfaces también deben explicar con claridad por qué han fallado los flujos permit.

Para los usuarios, lo importante es que los permits firmados se pueden transferir hasta que se utilicen o caduquen.

No compartas datos permit firmados salvo que confíes en el flujo.

Consideraciones de implementación para desarrolladores

Los desarrolladores deben seguir de cerca la especificación EIP-2612.

El hash del tipo permit debe coincidir con la estructura firmada prevista.

El digest debe utilizar la codificación EIP-712 con el separador de dominio y el hash de la estructura permit.

El contrato debe rechazar los permits caducados.

El contrato debe rechazar las firmas no válidas.

El contrato debe rechazar los permits cuyo firmante recuperado no sea el titular.

El contrato debe rechazar los casos inadecuados en los que el titular sea la dirección cero.

El contrato debe incrementar el nonce del titular tras ejecutar correctamente el permit.

El contrato debe emitir el evento estándar

Approval
después de cambiar la allowance.

Siempre que sea posible, los desarrolladores deben utilizar bibliotecas revisadas por expertos.

La documentación de ERC20Permit de OpenZeppelin ofrece un patrón de implementación ampliamente utilizado en proyectos Solidity.

OpenZeppelin también documenta el uso de ERC-20 Permit en otros entornos, como ERC-20 Permit para Stylus.

Incluso cuando se utiliza una biblioteca, los desarrolladores deben probar cuidadosamente el comportamiento concreto del token.

Función Permit frente a meta-transacciones

Una meta-transacción es un patrón más amplio en el que un usuario firma un mensaje y otra parte envía una transacción en su nombre.

EIP-2612 puede entenderse como un patrón específico de firma centrado en las aprobaciones.

No convierte todas las acciones con tokens en acciones firmadas.

Solo estandariza las aprobaciones firmadas de allowances ERC-20.

Este alcance limitado es intencionado.

Un estándar mínimo es más fácil de adoptar e integrar en wallets, contratos y aplicaciones.

Los desarrolladores que quieran transferencias firmadas, acciones agrupadas o patrocinio de gas personalizado pueden necesitar contratos o estándares adicionales.

Permit es útil porque resuelve un problema habitual sin cambiar todo el modelo ERC-20.

Complementa los sistemas de meta-transacciones, en lugar de sustituirlos por completo.

Función Permit frente a transferencia de tokens

Un permit no es una transferencia.

Una transferencia mueve tokens de una dirección a otra.

Un permit actualiza la allowance que una dirección concede a otra.

Esto significa que un usuario puede firmar un permit y mantener los tokens en la misma wallet hasta que el gastador utilice la allowance.

El movimiento efectivo de los tokens suele realizarse mediante

transferFrom
.

Esta diferencia es importante para la seguridad de las wallets.

Es posible que el usuario no vea un cambio inmediato en el saldo de tokens después de firmar un permit.

Eso no significa que la firma sea inofensiva.

El gastador aún podría tener permiso para transferir tokens más adelante.

Después de utilizar dApps, los usuarios deben revisar las allowances activas y revocar las aprobaciones que ya no necesiten.

Función Permit frente a Permit2

EIP-2612 es un estándar a nivel de token.

El propio contrato del token debe implementar la función permit para que el token sea compatible con EIP-2612.

Otros sistemas de aprobación pueden ofrecer un comportamiento similar a permit mediante contratos externos.

Estos sistemas no equivalen a la compatibilidad nativa con EIP-2612.

La diferencia es importante porque las solicitudes de las wallets, las direcciones de los gastadores, los sistemas de nonce, los ámbitos de aprobación y los métodos de revocación pueden variar.

Al firmar una aprobación similar a permit, los usuarios deben comprobar qué contrato recibe la autorización.

Al integrar permits, los desarrolladores deben verificar si el token es compatible directamente con EIP-2612 o si requiere otro mecanismo de aprobación.

Llamar «EIP-2612» a todas las aprobaciones firmadas puede generar confusión.

EIP-2612 tiene una interfaz y una estructura de firma específicas.

Cómo interpretar una solicitud de firma Permit

Lo primero que debe comprobar un usuario es el nombre del token.

A continuación, debe comprobar la dirección del gastador o la aplicación que solicita permiso.

También debe comprobar la cantidad aprobada.

Debe verificar si el valor está limitado o es, en la práctica, ilimitado.

Debe comprobar el plazo límite.

También debe confirmar que la solicitud aparece después de una acción deliberada.

Si aparece de forma inesperada, debe rechazarla.

Es necesario tener especial cautela si el sitio web solicita muchas firmas seguidas.

Los usuarios deben evitar firmar mensajes permit desde enlaces recibidos por mensajes directos, chats de soporte falsos, anuncios sospechosos o páginas de tokens desconocidas.

Es importante recordar que firmar un permit puede otorgar a otra dirección capacidad para gastar tokens.

Una solicitud segura de la wallet debería mostrar estos campos de forma legible, pero los usuarios no deben confiar únicamente en el diseño de la interfaz.

Por qué Permit mejora la experiencia de usuario

Permit mejora la experiencia de usuario al reducir el número de transacciones on-chain necesarias.

Puede eliminar el paso de aprobación independiente en muchos flujos de dApps.

Puede permitir que los usuarios interactúen con tokens ERC-20 aunque no tengan suficiente token nativo para una aprobación independiente.

Puede ayudar a las aplicaciones a patrocinar el gas o agrupar la aprobación con otra acción.

Puede reducir los flujos fallidos que se producen cuando los usuarios aprueban un token y después olvidan completar la segunda transacción.

Puede facilitar la incorporación de usuarios nuevos a las aplicaciones on-chain.

Estas ventajas son especialmente importantes porque las aprobaciones ERC-20 son uno de los puntos de fricción más habituales en cripto.

Sin embargo, una aprobación más sencilla no es automáticamente más segura.

Una buena experiencia de usuario debe ir acompañada de solicitudes de firma claras, un diseño cuidadoso de los gastadores y una gestión sencilla de las allowances.

Errores habituales con EIP-2612

Un error habitual es creer que permit transfiere tokens inmediatamente.

Permit solo actualiza la allowance.

Otro error habitual es pensar que una aprobación sin gas significa que nadie paga gas.

Un permit sigue necesitando una transacción on-chain para actualizar el estado del contrato.

Un tercer error habitual es firmar aprobaciones ilimitadas sin entender el riesgo del gastador.

Un cuarto error es ignorar el campo del plazo límite.

Un quinto error es confiar en una solicitud de firma solo porque no parece una transacción normal.

Un sexto error es asumir que todos los tokens ERC-20 son compatibles con EIP-2612.

Un séptimo error es integrar permit sin probar el ID de la red, el separador de dominio y el comportamiento de los nonces en distintos despliegues.

Un octavo error es tratar todos los sistemas similares a permit como si fueran idénticos a EIP-2612.

Un noveno error es no gestionar los permits enviados mediante front-running en flujos de contratos combinados.

Un décimo error es mostrar las solicitudes permit de forma que los usuarios no puedan entenderlas.

Buenas prácticas para los usuarios

Firma mensajes permit únicamente en sitios web y aplicaciones de confianza.

Antes de firmar, revisa el token, el gastador, la cantidad y el plazo límite.

Evita las aprobaciones ilimitadas salvo que exista un motivo sólido.

Siempre que sea posible, utiliza importes de aprobación reducidos.

Revoca las allowances antiguas que ya no necesites.

No firmes mensajes permit desde enlaces aleatorios, mensajes de soporte falsos ni páginas de airdrops desconocidas.

Utiliza una wallet distinta para las dApps experimentales y otra para los activos que mantengas a largo plazo.

Lee atentamente las advertencias de la wallet.

No des por hecho que una firma es segura solo porque no muestre directamente una comisión de gas.

Recuerda que otra persona puede enviar un permit firmado antes de que caduque.

Buenas prácticas para desarrolladores

Siempre que sea posible, utiliza implementaciones de permit auditadas y con un mantenimiento adecuado.

Si afirmas que existe compatibilidad con EIP-2612, sigue exactamente su interfaz oficial.

Utiliza datos tipados de EIP-712 para que las wallets puedan mostrar información clara sobre la firma.

Implementa correctamente la separación de dominios.

Lleva el registro de los nonces por dirección de titular.

Rechaza las firmas caducadas.

Rechaza las firmas de firmantes no válidos y los casos en que la dirección del titular sea cero.

Emite el evento

Approval
después de actualizar correctamente la allowance.

Diseña los flujos permit combinados para que puedan gestionar que el permit se envíe antes que la transacción principal.

Muestra a los usuarios, en lenguaje sencillo, los nombres de los gastadores, las cantidades de tokens y los datos de caducidad.

Ofrece documentación clara para explicar cómo revocar allowances.

Prueba las firmas con distintos ID de red, bifurcaciones, actualizaciones y proveedores de wallets.

La función Permit en una frase

La función Permit de EIP-2612 permite al titular de un token ERC-20 aprobar a un gastador mediante una firma EIP-712, lo que permite actualizar la allowance on-chain sin que el titular tenga que enviar una transacción de aprobación independiente.

Preguntas frecuentes

¿Qué es la función Permit de EIP-2612?

La función Permit es una extensión de ERC-20 que permite al titular de un token aprobar a un gastador mediante una firma off-chain que puede enviarse on-chain más adelante.

¿Permit transfiere tokens?

No. Permit solo establece una allowance y no transfiere tokens por sí mismo.

¿Por qué es útil EIP-2612?

EIP-2612 es útil porque reduce la fricción de las aprobaciones, permite experiencias de aprobación sin gas y permite combinar las aprobaciones con otras acciones de contratos inteligentes.

¿El titular del token paga gas al utilizar permit?

El titular del token no necesita enviar la transacción de aprobación, pero alguien debe pagar el gas para enviar el permit firmado on-chain.

¿Cuál es la diferencia entre approve y permit?

Approve es una transacción on-chain enviada por el titular del token, mientras que permit es una firma off-chain que otra parte puede enviar on-chain.

¿Qué relación tiene EIP-712 con permit?

EIP-712 permite firmar datos estructurados tipados, lo que ayuda a las wallets a mostrar los detalles del permit con más claridad y a vincular las firmas a un dominio definido.

¿Qué es un nonce en EIP-2612?

Un nonce es un valor asociado a cada titular que impide reutilizar la misma firma permit.

¿Qué es el plazo límite de un permit?

El plazo límite es la fecha y hora de caducidad a partir de la cual la firma permit deja de ser válida.

¿Es seguro EIP-2612?

EIP-2612 puede ser seguro si se implementa y utiliza correctamente, pero los usuarios deben seguir atentos al phishing de firmas, las aprobaciones ilimitadas, los gastadores maliciosos y las solicitudes poco claras de las wallets.

¿Todos los tokens ERC-20 son compatibles con permit?

No. Solo los tokens ERC-20 que implementan la extensión EIP-2612 son compatibles con la función Permit estándar.

¿Se puede hacer front-running de una firma permit?

Sí. Cualquiera que tenga una firma permit válida puede enviarla antes que otra transacción, por lo que los desarrolladores deben diseñar flujos que contemplen esta posibilidad.

¿Cómo pueden los usuarios reducir el riesgo de permit?

Los usuarios pueden reducirlo comprobando el gastador, limitando los importes aprobados, utilizando plazos límite cortos, evitando sitios web sospechosos y revocando las allowances que no utilicen.

Conclusión

La función Permit de EIP-2612 es una de las mejoras más útiles para la experiencia de aprobación de ERC-20.

Permite a los usuarios autorizar allowances de tokens mediante firmas, en lugar de enviar transacciones de aprobación independientes.

Esto puede reducir la fricción asociada al gas, facilitar la incorporación a las dApps, admitir flujos de transacciones patrocinadas y simplificar la combinación de interacciones con ERC-20 en una sola experiencia de usuario.

El estándar utiliza datos estructurados tipados de EIP-712, separación de dominios, nonces y plazos límite para que las aprobaciones firmadas sean más seguras y específicas.

Sin embargo, permit no elimina el riesgo básico de las allowances de tokens.

Un permit firmado aún puede otorgar a un gastador poder real sobre los tokens de un usuario.

Los usuarios deben tratar las firmas permit con la misma seriedad que las transacciones de aprobación.

Los desarrolladores deben implementar el estándar con cuidado, mostrar información clara sobre las firmas y gestionar casos límite como la protección contra la repetición, las firmas caducadas y los permits enviados mediante front-running.

Cuando se utiliza correctamente, EIP-2612 facilita el uso de los tokens ERC-20 sin cambiar la idea central del gasto de tokens basado en allowances.

Es un estándar pequeño, pero importante, que mejora la usabilidad práctica de las aplicaciones cripto y mantiene la compatibilidad con el ecosistema ERC-20 en su conjunto.
¿Retroceso u oportunidad?
¿Retroceso u oportunidad?¿Retroceso u oportunidad?
$2400M en entradas a ETF de BTC pese a liquidaciones