Aprobaciones de tokens: los permisos que sigues concediendo

Cada vez que interactúas con una aplicación DeFi — un swap en un DEX, un depósito en un mercado de préstamos, un bridge de un ERC-20 — casi con toda seguridad has concedido una aprobación de token. La mayoría de los usuarios las firman en segundos y se olvidan de ellas. Sin embargo, esa única transacción de aprobación es una de las cosas más trascendentes que haces en Ethereum: le otorga a un smart contract un permiso permanente para mover tus tokens, a menudo sin pedir más confirmaciones. Esta guía explica qué es una aprobación de token, por qué las dApp las solicitan, los riesgos de los allowance ilimitados y qué implica todo esto cuando firmas aprobaciones a través de SSP.

Por qué existen las aprobaciones

Los tokens ERC-20 no se guardan "dentro" de tu cartera como ocurre con ETH. Un contrato de token ERC-20 es un libro mayor: un mapa de direcciones a saldos. Cuando tienes 1.000 USDC, lo que existe en cadena es una fila dentro del contrato de USDC que dice que tu dirección posee 1.000 unidades.

Como el saldo vive dentro del contrato del token, solo ese contrato puede moverlo. Cuando envías USDC a un amigo, tu cartera llama directamente a la función transfer del token.

Pero un DEX, donde un contrato distinto (el router) necesita extraer USDC de tu dirección para ejecutar un swap, no puede meterse en el contrato del token y tomar tu saldo. ERC-20 resuelve esto con un patrón de delegación en dos pasos:

1. Tú llamas a approve(spender, amount) en el contrato del token. Esto establece un allowance: un registro de que el spender está autorizado a mover hasta amount de tus tokens.
2. El spender llama después a transferFrom(yourAddress, destination, amount) en el contrato del token. El contrato comprueba el allowance, lo decrementa y mueve los tokens.

La aprobación es la llave. Sin ella, el router no puede tocar tu USDC.

Qué se está concediendo realmente

Lee approve(spender, amount) de forma directa. Le estás diciendo al contrato ERC-20: "esta dirección puede retirar hasta esta cantidad de mis tokens, en cualquier momento, en cualquier número de transacciones, hasta que yo lo cambie."

De ahí se derivan varias cosas:

• Es un permiso permanente, no una acción única. Una vez concedido, el spender no necesita tu firma de nuevo para extraer tokens hasta que el allowance se agote o se revoque.
• Es por token. Aprobar al router del DEX para USDC no le permite tocar tu DAI; necesitas una aprobación separada para DAI.
• Es por spender. Un contrato distinto — incluso de la misma dApp — tiene su propio allowance.
• No caduca. ERC-20 no tiene una fecha límite incorporada. Un allowance concedido en 2023 sigue activo en 2026 a no ser que se gaste o se revoque.

Puedes inspeccionar cualquier allowance en un explorador de bloques como etherscan leyendo la función allowance(owner, spender) del contrato del token.

El patrón del allowance infinito

Si las aprobaciones son por importe, ¿por qué casi todos los DEX te piden un número enorme — habitualmente 2^256 - 1, mostrado como "ilimitado" o MaxUint256 — en lugar de solo el importe que estás intercambiando?

La respuesta es UX y gas. Si un DEX pidiese un allowance nuevo igual al tamaño del trade en cada swap, pagarías una transacción de aprobación cada vez y tendrías que confirmar dos transacciones para lo que parece una sola acción. Pedir un allowance ilimitado una sola vez te permite hacer swaps libremente después con una sola transacción por trade.

Es genuinamente cómodo. También es genuinamente más arriesgado. Un allowance ilimitado significa que el contrato del spender tiene permiso para drenar todo tu saldo actual de ese token — y cualquier saldo futuro — en cualquier momento, sin que firmes nada más.

Para un contrato conocido, auditado e inmutable, el riesgo práctico suele ser bajo. Para una dApp recién desplegada, un proxy actualizable o un contrato desconocido, un allowance ilimitado es una superficie mucho mayor que la operación que pretendías.

El riesgo real: una llave permanente a tus tokens

El peligro de las aprobaciones no es la propia transacción de aprobación. Es lo que ocurre después. Considera estos escenarios:

• El contrato del spender tiene un bug. Un atacante explota su lógica transferFrom y todas las carteras con un allowance no nulo son drenadas.
• El contrato del spender es actualizable. Quien controle las claves de upgrade despliega una nueva lógica que extrae tokens de cualquiera con un allowance activo.
• Aprobaste un clon malicioso. Un sitio de phishing imitó la URL de una dApp real, y el contrato que aprobaste estuvo controlado por un atacante desde el principio.
• Las claves de firma del spender se ven comprometidas. El contrato oficial está bien; la cartera del operador no, y un intruso ejecuta los allowance.

En todos los casos, no firmas nada cuando ocurre el drenaje. La aprobación que diste semanas antes es la única autorización que necesita el atacante. "Aprueba solo lo que necesites y revoca lo que ya no uses" no es paranoia; es el mismo principio que no dejar copias de las llaves de casa a todos los contratistas a los que has contratado.

Cómo se acumulan silenciosamente las aprobaciones

Una cartera activa durante uno o dos años en DeFi ha acumulado decenas de aprobaciones: cada DEX, cada agregador, cada depósito en mercados de préstamos, cada marketplace de NFT, cada bridge. Los usuarios casi nunca revocan. El resultado es una larga cola de permisos permanentes, muchos de ellos ilimitados, muchos concedidos a contratos con los que el usuario ya no interactúa.

Esta es la superficie de ataque silenciosa. No aparece en ninguna transacción concreta; es el poso acumulado del uso normal. Auditar y podar esa lista es uno de los hábitos de seguridad más efectivos en autocustodia — el siguiente artículo explica exactamente cómo en revocar aprobaciones de tokens desde SSP.

Un patrón más moderno: EIP-2612 permit

ERC-20 es anterior a gran parte del DeFi moderno, y el baile de dos transacciones approve-y-luego-swap lleva tiempo siendo incómodo. EIP-2612 introdujo una alternativa para los tokens que la implementan: en lugar de enviar una transacción approve en cadena, el usuario firma un mensaje fuera de cadena (un permit) que autoriza un spender, una cantidad y una fecha límite concretos. La dApp envía esa firma junto con el swap en una sola transacción.

permit es eficiente en gas, está acotado (lleva una cantidad y una expiración explícitas) y es más difícil de dejar colgando porque la fecha límite obliga a que caduque. No todos los ERC-20 lo soportan — USDC y DAI sí, muchos tokens más antiguos no — pero allá donde está disponible suele ser más seguro que un allowance approve de larga duración. Dicho esto, las propias firmas permit también pueden ser phisheadas: un sitio malicioso pidiéndote que "inicies sesión" puede colar un permit por debajo. Lee lo que estás firmando.

Qué significa todo esto dentro de SSP

SSP es una cartera multisig 2 de 2 autocustodiada: cada transacción on-chain es co-firmada por la extensión SSP del navegador y la app móvil SSP Key. En Ethereum y en las redes EVM que SSP soporta (Polygon, Base, BNB Smart Chain, Avalanche), esto se implementa como un smart account ERC-4337 con una firma Schnorr agregada — pero a nivel de aplicación, una aprobación se ve como cualquier otra transacción.

Cosas que conviene tener en cuenta:

• Una aprobación es una transacción que tu 2 de 2 debe co-firmar. Cuando una dApp pide approve, SSP la presenta como cualquier otra tx. Verás la dirección del spender y la cantidad solicitada en ambos dispositivos antes de confirmar.
• Una vez concedida, el spender no necesita a SSP para volver a actuar. El multisig protege el momento de la aprobación, no el permiso permanente posterior. Si concedes un allowance ilimitado a un contrato malicioso, tu multisig no te salvará del drenaje posterior.
• Vigila la dirección del spender. Las dApp a veces actualizan sus routers; si el spender que aparece en la pantalla de aprobación no coincide con el contrato que esperas, detente y verifica.
• Las aprobaciones iniciadas vía WalletConnect tienen el mismo aspecto. Tanto si la dApp te pide la aprobación dentro de su página como vía WalletConnect, el flujo y los riesgos son idénticos.

Hábitos que conviene cultivar

Algunas prácticas concretas mantienen manejable la superficie de aprobaciones:

• Prefiere el allowance más pequeño viable. Cuando una dApp ofrece "cantidad exacta" frente a "ilimitado", lo exacto es la opción más segura para contratos que no usas con regularidad.
• Trata los allowance ilimitados como compromisos. Resérvalos para un pequeño conjunto de contratos en los que confías y que usas a menudo. Para todo lo demás, acota.
• Audita periódicamente. Una vez al trimestre, lista tus aprobaciones activas en cada red y revoca lo que ya no uses. Herramientas como revoke.cash lo convierten en rutina.
• Desconfía de las dApp desconocidas. Un protocolo nuevo sin historial de auditorías que pide un allowance ilimitado es la combinación de mayor riesgo en DeFi.
• Protege las claves que conceden aprobaciones. El multisig de SSP eleva el listón, pero la higiene básica sigue aplicando — consulta buenas prácticas para la frase semilla.

El modelo mental con el que quedarte

Una aprobación de token no es un clic; es una llave. Cada una se queda en la cerradura hasta que la quitas, y cada una le otorga a quien la tenga la capacidad de mover tokens que aún no has ganado. Usados con cuidado, los allowance son la fontanería que hace que DeFi funcione. Tratados como clics desechables, son la acumulación lenta de riesgos que olvidaste haber asumido.

Entiende el permiso que estás concediendo, prefiere concesiones acotadas cuando la dApp lo permita y poda tus aprobaciones permanentes con cierta cadencia. Para más detalle del protocolo, la documentación del estándar ERC-20 en ethereum.org es la referencia canónica. ¿Eres nuevo usando SSP en Ethereum? Nuestra guía Ethereum en SSP cubre lo básico.