Permisos de tokens, aprobaciones y riesgos de contratos de farm en BNB Chain: qué son y cómo gestionarlos

Cuando usas PancakeSwap, un yield farm, un pool de liquidez o casi cualquier protocolo DeFi en BNB Chain, el contrato te pedirá que apruebes un token antes de interactuar con él. Esa transacción de aprobación es separada del swap o depósito que sigue. La mayoría de los usuarios la confirman rápidamente y se concentran en la acción principal. Es un error que vale la pena entender, porque la aprobación suele ser la acción más relevante: otorga a un contrato inteligente permiso permanente para mover tus tokens, en cualquier cantidad, en cualquier momento futuro, hasta que lo revoques explícitamente.

Qué es técnicamente una aprobación de token

La aprobación de token es una función estándar de los estándares ERC-20 y BEP-20 que utilizan tanto Ethereum como BNB Smart Chain. La función se llama approve(spender, amount). Cuando tu wallet llama a esta función en un contrato de token, estás instruyendo al contrato de token para que registre que una dirección específica — el spender — tiene permitido llamar a transferFrom en tu nombre por hasta el monto indicado. El contrato de token no mueve fondos en este momento. Solo registra el permiso. El contrato spender puede ejercer ese permiso en cualquier momento posterior llamando a transferFrom(tuDirección, destino, monto) directamente en el contrato de token, sin que tú realices ninguna acción adicional.

Este diseño existe por una razón práctica: los protocolos DeFi necesitan retirar tokens de tu wallet para ejecutar swaps, depósitos, repagos y liquidaciones en tu nombre. Sin el mecanismo de aprobación, cada acción on-chain requeriría que enviaras tokens explícitamente en una transacción separada. Las aprobaciones permiten que los contratos actúen como agentes autorizados para operaciones específicas.

Por qué las aprobaciones infinitas son la norma y cuál es el riesgo

Cuando una dApp solicita una aprobación, establece el parámetro amount. En principio, podría ser exactamente la cantidad de tokens que planeas usar en la transacción actual, de modo que el contrato solo pueda retirar lo necesario y el permiso se agote. En la práctica, la mayoría de las dApps en BNB Chain solicitan type(uint256).max — el entero más grande posible — lo que equivale a permiso ilimitado para transferir cualquier cantidad de ese token desde tu wallet, indefinidamente.

Las dApps hacen esto para evitar que los usuarios paguen gas por una nueva aprobación en cada interacción futura. Desde la perspectiva de la experiencia de usuario, apruebas una vez y luego realizas swaps o depósitos todas las veces que quieras sin confirmaciones adicionales. Desde la perspectiva de seguridad, una aprobación infinita a un contrato legítimo y seguro no presenta riesgo adicional respecto a una aprobación limitada, porque un contrato legítimo solo ejerce lo que autorizas en cada transacción. El problema surge cuando el contrato receptor es malicioso, resulta comprometido más adelante o contiene vulnerabilidades que no tenía en el momento de tu aprobación.

Un escenario habitual: apruebas un contrato de yield farm por USDT ilimitado, depositas, ganas recompensas y retiras. Nunca revocas explícitamente la aprobación. Meses después, el contrato del farm es explotado — tal vez mediante un ataque de flash loan sobre su oráculo de precios, por una clave de administrador comprometida o porque una actualización del contrato introdujo una vulnerabilidad. Un atacante que controla o manipula ese contrato puede llamar a transferFrom en cada wallet que tenga una aprobación activa, vaciando el saldo aprobado de cada una, incluso de wallets que retiraron sus depósitos hace mucho. La aprobación persiste hasta que la revoques.

EIP-2612: firmas permit y por qué son especialmente peligrosas para phishing

El mecanismo de aprobación estándar requiere una transacción on-chain, lo que significa que consume gas y deja un registro en BscScan. EIP-2612, el estándar permit, permite un enfoque diferente: en lugar de llamar a approve on-chain, firmas un mensaje fuera de la cadena con tu clave privada de wallet, y ese mensaje firmado lo envía al contrato de token la aplicación receptora. El contrato valida la firma y registra la aprobación sin que hayas enviado ninguna transacción.

Esto resulta útil para protocolos que quieren ahorrar a los usuarios el costo de gas de la transacción de aprobación. Varios tokens importantes en BNB Chain admiten EIP-2612, incluyendo algunas versiones de USDC y varios tokens de gobernanza DeFi. El riesgo es que un sitio de phishing o un contrato malicioso puede solicitar una firma permit que parezca un mensaje fuera de cadena ordinario. Como no se requiere gas para firmar, los usuarios pueden no reconocer la acción como una aprobación. Como la firma es off-chain, no aparece en el historial de transacciones de tu wallet. Un permit firmado puede enviarse en cualquier momento por quien lo tenga, y una vez enviado crea una aprobación on-chain completa que el contrato puede ejercer de inmediato.

La defensa práctica es la misma que para las aprobaciones estándar: nunca firmes un mensaje que no entiendes. Las firmas permit incluyen la dirección del token, la dirección del spender, el monto de la allowance y una fecha de vencimiento. Rabby Wallet, en particular, simula el efecto de transacciones y firmas permit antes de que las confirmes, mostrando cómo quedará el estado de tu wallet tras firmar. Este tipo de simulación previa hace visible el impacto de una aprobación o permit antes de que sea irrevocable.

Cómo los contratos de farm usan tus aprobaciones para mover tokens

Un yield farm típico en BNB Chain sigue este patrón: depositas tokens de un solo activo o tokens LP en un contrato de farm, que registra tu stake. Con el tiempo, el contrato acumula recompensas que puedes cosechar. Cuando llamas a emergencyWithdraw o withdraw, el contrato te devuelve el principal y posiblemente las recompensas acumuladas. Nada de esto involucra la aprobación que otorgaste por el token de depósito — el contrato de farm ya tiene tus tokens en custodia tras el depósito.

Sin embargo, muchos contratos de farm también solicitan aprobación para el token de recompensa o para operaciones LP adicionales. Cuando apruebas un contrato de farm por el token X de recompensa, le estás otorgando permiso para mover cualquier cantidad de X desde tu wallet. Si el farm distribuye recompensas haciendo que los usuarios primero aprueben el contrato y luego llamen a una función de claim, existe una aprobación en tu wallet para ese token independientemente de si mantienes un stake activo.

Un riesgo estructural específico que las auditorías no siempre detectan: muchos contratos de farm se despliegan como proxies actualizables. Un contrato proxy separa el almacenamiento de datos del usuario de la lógica que actúa sobre ellos. El equipo desplegador puede actualizar el contrato de lógica — que implementa todas las funciones de retiro, cosecha y acceso — sin cambiar la dirección del proxy ni requerir que los usuarios vuelvan a aprobar. Si la lógica se actualiza a una versión maliciosa tras el despliegue, la nueva lógica se ejecuta contra la aprobación original y los saldos almacenados originales. Otorgaste permiso a la dirección del proxy; la lógica detrás de esa dirección cambió sin tu conocimiento. Esta es una de las razones por las que el marketplace de seguridad AvengerDAO, ampliado en agosto de 2026, evalúa el control de acceso y la actualizabilidad como categorías de riesgo separadas en su estándar BNB-SS.

Cómo revisar las aprobaciones activas en BNB Chain

BscScan ofrece un verificador de aprobaciones de tokens en bscscan.com/tokenapprovalchecker. Conecta tu wallet o ingresa tu dirección para ver todas las aprobaciones activas emitidas por esa dirección en BNB Smart Chain. La tabla muestra el token, el spender aprobado y el monto aprobado. Los spenders con montos ilimitados aparecen como tales. Puedes enviar una revocación directamente desde esta interfaz, lo que envía una transacción approve(spender, 0) para establecer la allowance en cero.

Revoke.cash es compatible con BNB Chain (Chain ID 56) y ofrece una interfaz más detallada. Tras conectar tu wallet en revoke.cash, lista todas las aprobaciones activas con el nombre del spender si se reconoce, el monto de la aprobación y la fecha de la última aprobación. También indica si un contrato spender está verificado on-chain y si alguna herramienta de seguridad lo ha señalado. Revocar desde Revoke.cash envía la misma transacción approve(spender, 0). El proceso cuesta una pequeña cantidad de BNB en gas — típicamente una fracción de 0,01 dólares a los precios de gas estándar de BSC — y tiene efecto de inmediato.

La revisión periódica de aprobaciones es un hábito que vale la pena establecer. Una práctica útil es revisar las aprobaciones activas después de cualquier interacción DeFi con un nuevo protocolo, cuando terminas de usar un protocolo al que no planeas volver, y a intervalos fijos — mensual o trimestralmente — para identificar y revocar aprobaciones antiguas que puedas haber olvidado. Las aprobaciones a protocolos que ya no usas representan un riesgo sin beneficio continuo.

Riesgos específicos en contratos con recompensas

Algunos contratos de yield tienen un patrón en el que la función de distribución de recompensas retira tokens de una wallet de recompensas aprobada controlada por el equipo del proyecto. Si la aprobación de esa wallet al contrato de distribución es ilimitada y el contrato de distribución es comprometido, el atacante puede vaciar la wallet de recompensas. Los usuarios que aprobaron el farm recuperan su stake principal si está en un contrato separado, pero pierden las recompensas pendientes. Este es un patrón de diseño que conviene reconocer antes de depositar en farms desconocidos.

Otra variante: farms que permiten al propietario del contrato llamar a una función que transfiere todos los tokens a una dirección de su elección. Esta función a veces se llama emergencyWithdraw pero se aplica a todos los fondos de usuarios del contrato, no solo a tu posición. Un farm con una función que permite al administrador retirar todos los depósitos de usuarios se conoce comúnmente como vector de rug pull. Verificar si esta función existe requiere leer el código fuente del contrato en BscScan o revisar el informe de auditoría si está disponible públicamente.

Buenas prácticas para gestionar aprobaciones en BNB Chain

Limita los montos de aprobación cuando la interfaz de la dApp lo permita. Algunas dApps ofrecen un campo de monto personalizado junto al valor ilimitado predeterminado. Establecer la aprobación exactamente por la cantidad que necesitas para la transacción actual elimina el riesgo residual, a costa de pagar gas por una nueva aprobación en cada interacción futura. Para protocolos que usas frecuentemente y en los que confías, la aprobación ilimitada es pragmáticamente aceptada. Para protocolos desconocidos o nuevos, la aprobación limitada es la opción de menor riesgo.

Usa separación de wallets. Mantén una wallet para grandes saldos sin aprobaciones activas a dApps, y una wallet separada para interacciones DeFi activas. Si las aprobaciones de la wallet activa son explotadas, la pérdida está acotada por lo que esa wallet contiene. Este es el control de riesgo operativamente más efectivo disponible sin cambiar tus patrones de interacción.

Verifica la verificación del contrato y el estado de auditoría antes de aprobar. Un contrato verificado en BscScan significa que el código fuente es legible públicamente y coincide con el bytecode desplegado. Un informe de auditoría de una firma del marketplace AvengerDAO significa que el código fue revisado. Ninguno es una garantía — pero la ausencia de ambos debería elevar el umbral para proceder.

No ignores las solicitudes de firma permit. Cualquier solicitud de firmar un mensaje que involucre una dirección de token y una dirección de spender debe tratarse con la misma seriedad que una aprobación de transacción. Lee la dirección del spender contra la lista oficial de contratos del protocolo antes de firmar.

Fuentes

• BscScan Token Approval Checker
• Revoke.cash — compatible con BNB Chain (Chain ID 56)
• EIP-2612: Extensión Permit para aprobaciones firmadas ERC-20
• BNB Chain Blog — AvengerDAO expande soporte de seguridad (agosto 2026)
• AvengerDAO marketplace de seguridad: qué es y qué no puede garantizar