Condición de carrera en las aprobaciones ERC-20

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

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.

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.

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.

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.

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.

Temas relacionados

• Cómo distinguir entre tokens canónicos y envueltos
• Mempool
• Riesgo de las firmas Permit2
• Órdenes de solo reducción
• Aprobación de la cartera

Fuentes

• ERC-20: Token Standard - Ethereum Improvement Proposals (consultado: 2026-08-20)
• ERC20 | OpenZeppelin Docs - OpenZeppelin (consultado: 2026-08-20)