¿Por qué existen las aprobaciones de tokens?

Intermedio4 nov 2026 · 6 min de lectura

Las aprobaciones de tokens existen para que un smart contract concreto pueda gastar después un token de su wallet — hasta un allowance que usted fija — bajo reglas comunes de tokens que prohíben los retiros libres. El contrato no puede llevarse los tokens así nomás.

Puntos clave

Las aprobaciones de tokens existen porque las reglas comunes de tokens impiden que un contrato saque libremente sus saldos: un spender nombrado necesita primero un allowance.
En recorridos DEX y dApp desde el wallet, Approve / aprobar es la capa de permiso. El swap o el depósito suelen ser una confirmación aparte.
El allowance suele ser por token y por spender. Una aprobación no cubre todos los tokens ni todos los contratos.
Las aprobaciones ilimitadas existen por comodidad (menos repeticiones, menos gas). También dejan un riesgo persistente más amplio si ese spender falla después.
El allowance remanente es estado on-chain. Cerrar el sitio o desconectar el wallet no lo borra.
Los flujos más nuevos estilo Permit / Permit2 siguen otorgando poder de gasto: a menudo con menos fricción, no con lectura opcional.

Respuesta corta

Las aprobaciones de tokens existen para que un smart contract concreto pueda gastar después un token de su wallet — hasta un allowance que usted fija — bajo reglas comunes de tokens que prohíben los retiros libres.

En palabras simples:

El contrato no puede llevarse los tokens así nomás. Primero necesita permiso de gasto. Ese permiso queda escrito on-chain. Puede durar más que el clic del trade. Ilimitado, remanente, revocar y los atajos estilo Permit salen de ese diseño.

La definición del glosario — qué es una aprobación — está en ¿Qué es una aprobación de tokens?.

Esta página deja claro un solo juicio: Approve / aprobar no es fricción al azar. Es cómo se delega el poder de gasto.

La pregunta de trading que importa

Usted abre un swap desde el wallet. La cotización se ve bien. Sigue adelante — y el wallet pide Approve / aprobar antes de que el trade pueda terminar.

Pregunte:

¿Esto es solo clics de más — o la plataforma pide el poder de gasto que exigen las reglas del token?

Son dos historias distintas.

Verlo como clics de más lleva a confirmar sin leer.

Verlo como diseño le hace leer token / spender / monto antes de firmar.

Escena en vivo: el swap se bloquea hasta Approve

Usted sostiene USDC y quiere hacer un swap en un DEX desde el wallet.

Conecta el wallet. Conectar no es aprobar.
Ingresa el tamaño y ve una cotización.
La confirmación se traba: el wallet muestra Approve USDC / aprobar USDC para un contrato spender (a menudo un router).
Firma el allowance. Eso suele costar gas.
Una segunda confirmación ejecuta el swap.
Después de la ejecución, el allowance no usado puede seguir on-chain para ese token y ese spender.

Aha:

«Ah — el trade necesitaba permiso primero. Y el permiso puede quedar después del trade.»

Qué es el allowance y cómo leer el prompt → ¿Qué es una aprobación de tokens?.

Cómo revisar o revocar permisos remanentes → cuando necesite la checklist, vea las User Guides de gestionar/revocar.

Motivo de diseño: por qué existe la regla

Bajo reglas estilo ERC-20 muy usadas, los saldos no entran a un contrato cualquiera solo porque un sitio lo pidió.

Un recorrido típico de retiro necesita:

Usted (el owner) autoriza a un spender.
Ese spender después llama algo como `transferFrom` dentro del allowance restante.

Sin esa autorización, el contrato no debería poder vaciar el token de su dirección.

Ese es el valor por defecto de seguridad — y la razón por la que los flujos DEX muestran Approve cuando necesitan mover un token que usted ya sostiene.

Las monedas nativas de la red suelen saltarse ese mismo paso approve estilo ERC-20.

Las aprobaciones de operador estilo NFT son una familia de permiso relacionada: un clic puede autorizar un contrato sobre muchos ítems.

Esta página se queda en el patrón fungible de approve que los traders spot DEX encuentran primero.

Por qué el DEX pide antes (o alrededor) del trade

Una plataforma que hace swap, depósito u otro movimiento del saldo ERC-20 suyo necesita poder de gasto para un spender concreto.

Así que el producto suele:

pedir allowance cuando no existe (o cuando un allowance tope se agotó)
luego pedirle que confirme la acción de mercado

Aprobar otorga permiso.

El trade gasta tokens bajo ese permiso (o falla si falta el permiso).

Tratar ambos clics como «solo continuar» funde dos decisiones distintas en un solo hábito.

Consecuencias de diseño que seguirá viendo

Por token, por spender

Aprobar USDC para el Router A no aprueba USDT, y no aprueba el Router B.

Una primera visita con varios tokens puede traer varios prompts de Approve. Es la regla de alcance en acción — no la app inventando clics de más por deporte.

Por qué existe lo ilimitado

Las aprobaciones ilimitadas (o al máximo) son comunes porque cortan prompts repetidos y gas repetido.

También amplían el riesgo persistente: si ese spender es malicioso ahora, tiene un bug, o queda comprometido después, puede ya tener permiso para sacar ese token sin un nuevo Approve suyo.

Comodidad y riesgo persistente son la misma moneda de diseño.

Por qué persisten los allowances remanentes

El allowance queda registrado on-chain para esa relación owner–token–spender.

El frontend puede desaparecer. Su «desconectar» puede funcionar. El mapeo puede quedar hasta que se consuma, se baje o se revoque.

Por eso plataformas viejas que usted ya no usa pueden seguir contando en su libro de riesgos.

Por qué existe revocar / bajar

Limpiar es otra escritura on-chain. Suele costar gas y necesita su firma.

Desconectar ≠ revocar.

Revocar/bajar ayuda a detener retiros futuros. No revierte tokens ya tomados.

Pasos prácticos y herramientas → User Guides de gestionar/revocar. Detalle de comisiones → ¿Qué es la comisión de red (gas)?.

Patrones más nuevos: menos fricción, misma familia de permiso

Algunos flujos usan firmas estilo Permit para fijar el allowance sin una transacción approve separada.

Algunos diseños (incluidos hubs estilo Permit2) pasan por un contrato de aprobación compartido: una aprobación persistente al hub, luego firmas con alcance de monto/tiempo para las apps.

Estos patrones existen para bajar el dolor de dos pasos y, en algunos diseños, sumar vencimiento o alcances más finos.

No hacen opcional la lectura. Una página de phishing que cosecha una mala firma estilo permit puede seguir otorgando poder de gasto en la misma familia que un Approve clásico malo.

La arquitectura profunda de Permit2 queda fuera de esta página. El juicio de estado actual aquí es simple: los atajos siguen moviendo poder de gasto.

Por qué a los atacantes les importa el mismo diseño

A los drainers les gustan las aprobaciones y las firmas estilo permit porque pueden monetizar permiso de gasto persistente sin robar su frase semilla.

Los prompts falsos de «claim», «verify», «sync» o «mint» suelen pedir la misma superficie de permiso que el DEX real necesita para swaps honestos.

El motivo va aquí. El recorrido completo de enlaces oficiales y phishing → Cómo verificar enlaces oficiales y evitar phishing.

Escenas trabajadas (lectura rápida)

Escena	Qué explica el diseño
Swap bloqueado hasta Approve	El spender no puede sacar sin allowance
Ilimitado «para no aprobar otra vez»	Comodidad de UX vs. riesgo persistente más amplio
Trade listo; allowance sigue vivo	Permiso on-chain ≠ sesión del sitio
Hub estilo Permit2 aprueba una vez	Permiso persistente del hub + firmas posteriores con alcance
Claim falso pide Approve / Permit	Los atacantes reutilizan la capa de permiso de gasto

No necesita cada fila cada vez.

Nombre si está otorgando poder de gasto — y a quién — antes de fijar el tamaño.

No lo confunda con

Qué es una aprobación (definición / reconocimiento) → ¿Qué es una aprobación de tokens?
Cómo revisar o revocar (checklist práctica) → User Guides de gestionar/revocar
Cálculo de comisión de gas → ¿Qué es la comisión de red (gas)?
Enlaces oficiales / how-to de phishing → Cómo verificar enlaces oficiales y evitar phishing
Conectar / claves / modelo de custodia → hermanos de wallet y auto-custodia

Esta página no es «definir otra vez la aprobación.»

Es por qué existe la capa de permiso — y por qué ilimitado, remanente, revocar y los atajos estilo Permit salen de ese diseño.

Si opera desde el wallet — incluso en una plataforma como edgeX — trate cada prompt Approve / aprobar o estilo permit como una concesión de poder de gasto persistente bajo las reglas del token, no como una casilla decorativa.

Lea token, spender y monto antes de firmar.

Para la definición simple, quédese con ¿Qué es una aprobación de tokens?.

¿Listo para el siguiente paso?

Continúa al registro o al trading desde esta página usando los enlaces oficiales.

Empieza a operar en edgeX

Aviso legal

Este contenido tiene fines exclusivamente educativos y no constituye asesoramiento de inversión. Operar con activos digitales y derivados implica riesgos. Asegúrate de entender los productos y de considerar tu situación antes de operar.

Explicaciones