Aprobaciones de tokens, allowances y Permit: qué firmas realmente

Una aprobación de token es un permiso on-chain almacenado dentro de un contrato de token ERC-20 — una allowance — que registra que un contrato concreto puede gastar hasta una cantidad concreta de tus tokens, en cualquier momento posterior, sin volver a preguntarte. La crea una transacción approve() y sobrevive a la interacción para la que la concediste: el sitio web puede desaparecer, la allowance sigue ahí. Permit (EIP-2612) sustituye esa transacción aparte por una firma off-chain que la dApp envía junto con su propia acción, y Permit2 extiende ese mismo modelo — con caducidad y cantidad acotada — a tokens que nunca implementaron EIP-2612, lo que significa que ahora una firma puede ceder poder de gasto: las solicitudes de firma merecen el escrutinio que antes recibían las aprobaciones. La defensa es poco vistosa: aprueba cantidades acotadas en lugar de ilimitadas y revoca las allowances que ya no uses. En una cartera totalmente non-custodial como WATS — donde el usuario tiene sus claves y WATS nunca tiene ninguna — ninguna aprobación, firma Permit ni revocación puede ocurrir sin que tu propia clave la firme, y como WATS cobra las comisiones de red de las cadenas EVM en un solo token, ATS, allí una transacción de limpieza nunca se aplaza por no tener el token de gas nativo de esa cadena.

Por qué las dApps piden aprobación

Los tokens ERC-20 tienen una peculiaridad que da forma a la mitad de la UX de Web3: un contrato inteligente no puede simplemente tomar tokens de tu dirección, ni siquiera cuando tú quieres que lo haga. Un DEX que intercambia tu USDC necesita primero tu permiso explícito. Por eso tantas interacciones son de dos pasos — primero una transacción de approve, luego el intercambio o depósito real. La aprobación no es un formalismo; es una concesión permanente de poder de gasto, y sobrevive a la transacción para la que la diste.

Qué concede realmente approve()

Cuando firmas una aprobación, el contrato del token registra una allowance: la dirección X (el contrato de la dApp) puede gastar hasta N de tus tokens, cuando quiera, hasta que la allowance se agote, se reduzca o se revoque. Dos propiedades importan. Primera: la allowance vive en el contrato del token y se concede al contrato que aprobaste, no al sitio web que visitaste — la interfaz puede desaparecer y el permiso permanece. Segunda: nada en una allowance requiere tu participación en el momento del gasto — una vez concedida, el contrato aprobado puede retirar tokens en cualquier transacción posterior sin otra firma tuya. Eso es exactamente lo que hace útiles a las aprobaciones — y exactamente lo que las convierte en superficie de ataque.

Aprobaciones infinitas: cómodas, y un riesgo permanente

Como cada aprobación cuesta gas, muchas dApps piden una allowance efectivamente ilimitada para que nunca tengas que aprobar de nuevo. La comodidad es real, pero también el trato: una allowance ilimitada a un contrato significa que todo tu saldo de ese token depende para siempre de la seguridad de ese contrato. Si el contrato es explotado años después — o era malicioso desde el principio — el atacante no necesita tu clave ni tu firma; la allowance que concediste es suficiente. Muchos de los mayores incidentes de vaciado de carteras no fueron robos de claves, sino viejas aprobaciones cobradas.

Permit y Permit2: aprobaciones por firma

El refinamiento moderno es Permit (EIP-2612): en lugar de una transacción approve on-chain, firmas un mensaje off-chain que la dApp envía junto con su acción — una transacción en vez de dos, sin gas de aprobación separado, y el permiso puede acotarse con una fecha límite. Permit2 generaliza la idea a tokens que nunca implementaron EIP-2612, actuando como un hub compartido de aprobaciones: haces una única aprobación on-chain ordinaria al propio contrato Permit2, y a partir de ahí cada dApp queda autorizada por una firma que lleva su propia cantidad y su propia caducidad. Conviene ser preciso sobre ese trato: Permit2 no elimina las aprobaciones, las concentra, así que la allowance permanente que le concediste a Permit2 es en sí misma una aprobación a la que hay que seguir la pista. Son mejoras genuinas, pero fíjate en lo que cambian: las firmas hacen ahora el trabajo que hacían las transacciones. Un sitio de phishing que te haga firmar el mensaje Permit equivocado logra lo mismo que una aprobación maliciosa — así que leer lo que firmas importa más que nunca, no menos.

La superficie de ataque: drainers y allowances rancias

El abuso de aprobaciones viene en dos sabores. Activo: los sitios drainer suplantan dApps reales y piden aprobaciones (o firmas Permit) disfrazadas de acciones inocuas como "reclamar" o "verificar cartera". Pasivo: allowances que concediste hace años a contratos legítimos permanecen latentes hasta que el contrato, sus claves de administración o su ruta de actualización se ven comprometidas. Ambos son motivos para tratar el flujo de conectar-y-aprobar como el momento crítico de seguridad de Web3; la forma segura de hacerlo la cubrimos en cómo conectar tu cartera a una dApp.

Higiene de aprobaciones que funciona de verdad

Tres hábitos cubren la mayor parte del riesgo. Aprueba cantidades acotadas cuando la dApp lo permita, sobre todo para saldos grandes — la aprobación extra posterior es un seguro barato. Revisa y revoca allowances periódicamente con un verificador de aprobaciones reputado, tratando lo que ya no uses como peso muerto a eliminar — revocar es en sí una transacción on-chain que devuelve la allowance a cero, así que cuesta gas y necesita tu firma como cualquier otra. Y mantén las tenencias serias en una dirección que simplemente nunca firme aprobaciones, separada de tu cartera activa de dApps. Más hábitos en capas en nuestras mejores prácticas de seguridad de carteras. Cuando aparezca una solicitud de firma, léela por tipo antes de firmar:

• Aprobación de token (approve o setApprovalForAll): comprueba la dirección del gastador y la cantidad; una cantidad ilimitada para un gastador que no reconoces es una señal de alarma.
• Datos tipados de EIP-2612 Permit o Permit2: comprueba el gastador, la cantidad y la fecha límite; una firma con un gastador desconocido o una fecha límite larga cede poder de gasto sin ninguna transacción visible.
• Autorización EIP-7702: comprueba la dirección del delegado, porque firmarla apunta el código de tu cuenta a ese contrato; si no reconoces al delegado, recházala, y consulta cómo comprobar y revocar una delegación EIP-7702.
• Mensaje personal_sign simple: comprueba que el texto sea legible y coincida con lo que estás haciendo, como un mensaje de inicio de sesión de un sitio que reconoces, y desconfía de los datos hexadecimales ilegibles presentados como una verificación inofensiva.

Dónde encaja WATS

Las aprobaciones son firmas, y las firmas son territorio de la cartera. WATS es totalmente non-custodial — tú tienes tus claves, WATS nunca tiene ninguna — así que cada aprobación, firma Permit y revocación ocurre solo cuando tu clave la firma, desde la extensión de Chrome o la app móvil, a través de Ethereum, BNB Smart Chain, Arbitrum One, Optimism, Base, Polygon, Gnosis, Celo, Mantle, Cronos, Solana y TON. Eso marca también el límite honesto de lo que cualquier cartera puede hacer por ti: una cartera puede mostrarte la solicitud, pero solo tú puedes decidir que el gastador y la cantidad son los que querías.

El lado de las comisiones elimina la otra excusa habitual para dejar viejas allowances en pie. En WATS, en las cadenas EVM cada acción, incluidas las transacciones de aprobación y revocación, se cobra en un solo token, ATS, en lugar del gas nativo de la cadena, mediante un paymaster ERC-4337; el modelo es el mismo en la extensión de Chrome y la app móvil. Solana y TON son cadenas totalmente soportadas en WATS; las transacciones en Solana simplemente pagan su propia comisión nativa en SOL, mientras que las comisiones en TON también se pagan en ATS. Esto no es un descuento: la red sigue cobrando lo que le corresponde y el coste subyacente no cambia — lo que cambia es qué token paga. El ATS recaudado se quema desde un suministro de 100M hacia un suelo de 30M. Como el saldo de ATS está en BSC (BNB Chain), nunca puenteas ATS ni recargas un saldo separado por cadena, así que la comisión de cualquier red EVM sale de ese único saldo. WATS Wallet combina comisiones en un solo token, ATS, cobradas por un paymaster ERC-4337 desde un único saldo en BSC, con esa quema; los detalles están en la página de la comisión ATS.

Así que la versión práctica de este artículo es una rutina corta: prefiere aprobaciones acotadas, lee qué autoriza realmente una firma Permit antes de firmarla y, una vez por trimestre, abre un verificador de aprobaciones y limpia los gastadores que ya no uses. El paso concreto es ejecutar esa rutina desde una cartera que nunca se interpone entre tú y la clave: en la extensión de Chrome o la app móvil de WATS, cada aprobación y cada revocación existe solo porque tu propia clave la firmó — WATS nunca tiene ninguna — y en las cadenas EVM la revocación se paga en ATS en lugar del token de gas nativo que esa cadena en concreto exija.