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

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 o se cambie. Dos propiedades importan. Primera: la allowance la posee el contrato que aprobaste, no el 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 con concesiones que expiran y limitadas en cantidad. 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 — cubrimos la forma segura de hacerlo 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). 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.

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 navegador o la app móvil, a través de EVM, Solana y TON. El lado de las comisiones es donde WATS no se parece a nada más: 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 en EVM y un fee-payer/relayer equivalente en Solana y TON — de modo que limpiar allowances viejas nunca se atasca porque te quedaste sin token de gas. El ATS recaudado se quema de un suministro de 100M hacia un suelo de 30M, y como ATS es un OFT de LayerZero, un solo saldo cubre todas las cadenas. WATS es la primera y única cartera que combina las comisiones de token único ERC-4337 + OFT con esa quema — detalles en la página de la comisión ATS.