---
title: "Condición de carrera en las aprobaciones ERC-20"
description: "Un gastador de ERC-20 puede usar una asignación anterior antes de que se confirme una aprobación que la sustituya y, después, usar la nueva asignación. Descubre cómo funciona esta condición de carrera y cómo cambiar o revocar aprobaciones de forma más segura."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Condición de carrera en las aprobaciones ERC-20

> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

<a id="answer"></a>

## Respuesta directa

La condición de carrera en las aprobaciones ERC-20 puede producirse cuando un propietario sustituye una asignación distinta de cero por otra mediante una llamada a `approve(spender, newAmount)`. Un gastador puede detectar el cambio pendiente, gastar primero la asignación anterior con `transferFrom` y, después de que se confirme la sustitución, gastar también la nueva asignación.

Por eso, la especificación ERC-20 recomienda que las interfaces cliente establezcan primero la asignación en `0` antes de fijar un nuevo valor para el mismo gastador. Cada transacción debe confirmarse en orden. Cuando el token las admite, las llamadas atómicas a `increaseAllowance` o `decreaseAllowance` evitan sustituir directamente una asignación distinta de cero.

<a id="mechanism"></a>

## Cómo funciona

ERC-20 define `approve` como una sobrescritura: una llamada correcta a `approve(spender, amount)` establece la asignación del gastador en `amount`. Por otra parte, `transferFrom(owner, recipient, amount)` permite a ese gastador transferir los tokens del propietario y normalmente reduce la asignación restante. Las transacciones pendientes no reservan un orden de ejecución, por lo que un gastador puede enviar una transferencia que se ejecute antes del cambio de aprobación del propietario.

La transición arriesgada es `N -> M`, donde tanto `N > 0` como `M > 0`. Si el gastador consume `N` antes de que se ejecute la aprobación sustitutiva, la aprobación posterior establece una nueva asignación de `M`. Por tanto, el máximo gastado durante esa secuencia puede ser `N + M`, sujeto al saldo de tokens del propietario y a la implementación del token.

<a id="example"></a>

## Ejemplo

Alice ha autorizado a un protocolo a gastar `100` tokens. Envía `approve(protocol, 50)` con la intención de reducir la asignación restante a `50`. Antes de que se confirme esa transacción, el gastador del protocolo envía `transferFrom(Alice, recipient, 100)` y consigue que se ejecute primero. Después, la aprobación de Alice establece la asignación en `50`, que el gastador puede usar en otra transferencia. Las dos transferencias suman `150` tokens.

Un flujo de sustitución más seguro consiste en enviar `approve(protocol, 0)`, esperar la confirmación, comprobar la asignación y el saldo resultantes y, solo entonces, enviar `approve(protocol, 50)` si la nueva aprobación sigue siendo adecuada. Si el gastador usa la asignación anterior antes de que se confirme la transacción que la reduce a cero, Alice puede ver el cambio en el saldo y detenerse antes de conceder los nuevos `50`.

<a id="risks"></a>

## Riesgos

- Establecer la asignación en `0` no revierte gastos ya ejecutados ni impide usar la asignación anterior antes de que se confirme la transacción que la reduce a cero.
- Enviar juntas las aprobaciones de reducción a cero y sustitución, sin esperar a que se confirme la primera, vuelve a introducir el riesgo del orden de ejecución.
- `increaseAllowance` y `decreaseAllowance` no forman parte del estándar ERC-20 básico; utilízalas solo cuando el contrato verificado del token las admita.
- Una asignación ilimitada puede exponer todo el saldo de tokens del propietario mientras siga activa. Verifica la red, el contrato del token, el gastador y el importe antes de firmar.
- Algunos tokens tienen comportamientos de aprobación no estándar. Lee la simulación de la cartera y los calldata de la transacción, y confirma la asignación on-chain después de cada paso.

<a id="misconceptions"></a>

## Errores comunes

- «La transacción de aprobación más reciente sustituye de inmediato a la anterior». Solo cambia el estado cuando se ejecuta on-chain.
- «Reducir una asignación limita todo el gasto futuro al nuevo importe». Un gastador puede usar la asignación anterior antes de que se ejecute el cambio.
- «Reducir primero la asignación a cero garantiza que no puedan salir más tokens». La asignación anterior sigue disponible hasta que se confirme la transacción que la reduce a cero.
- «Todos los ERC-20 tienen `increaseAllowance` y `decreaseAllowance`». Son extensiones opcionales, no requisitos de ERC-20.
- «Revocar la conexión con el sitio web revoca la aprobación del token». El estado de conexión de la cartera y la asignación on-chain del contrato del token son independientes.

<a id="related"></a>

## Temas relacionados

- [Cómo distinguir entre tokens canónicos y envueltos](/es/crypto/canonical-vs-wrapped-token/)
- [Mempool](/es/crypto/mempool/)
- [Riesgo de las firmas Permit2](/es/crypto/permit2-signature-risk/)
- [Órdenes de solo reducción](/es/crypto/reduce-only-order/)
- [Aprobación de la cartera](/es/crypto/wallet-approval/)

<a id="sources"></a>

## Fuentes

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultado: 2026-08-20)
- [ERC20 | OpenZeppelin Docs](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20) - OpenZeppelin (consultado: 2026-08-20)

Source: https://wiki.fcontext.com/es/crypto/erc20-approval-race-condition/index.mdx