---
title: "¿Por qué algunas aprobaciones de tokens deben ponerse primero a cero?"
description: "Algunos tokens ERC-20 rechazan el cambio directo de un allowance distinto de cero a otro. Aprende cuándo hace falta ponerlo primero a cero, por qué deben confirmarse dos transacciones en orden y qué riesgos persisten."
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.

# ¿Por qué algunas aprobaciones de tokens deben ponerse primero a cero?

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

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

## Respuesta directa

Algunas implementaciones de ERC-20 rechazan `approve(spender, newAmount)` cuando tanto el allowance existente como `newAmount` son distintos de cero. Con esos tokens, primero envía `approve(spender, 0)`, espera su confirmación y solo entonces envía la nueva aprobación distinta de cero.

Esta restricción no es obligatoria para todos los tokens ERC-20. ERC-20 define `approve` como la sustitución del allowance actual y recomienda que las interfaces cliente lo pongan primero a cero para mitigar una carrera al cambiar aprobaciones; también dice que los contratos de tokens no deberían imponerlo por compatibilidad. Aun así, algunos tokens desplegados sí lo imponen. Por tanto, ponerlo primero a cero es tanto un procedimiento de compatibilidad como un punto de control útil, pero no garantiza que el allowance anterior no se gaste antes de confirmarse la puesta a cero.

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

## Cómo funciona

1. Verifica la cadena, el contrato del token, el propietario, el spender y el importe previsto. Lee `allowance(owner, spender)` directamente del contrato del token en lugar de confiar solo en una etiqueta de la cartera.
2. Si el allowance ya es `0`, envía una vez la aprobación deseada. Si no es cero, sustituirlo directamente por otro valor distinto de cero puede funcionar en una implementación estándar o revertir en un token que exija ponerlo primero a cero.
3. Para este procedimiento, envía `approve(spender, 0)` y espera un recibo correcto. Después vuelve a leer el allowance del mismo par propietario-spender y confirma que sea `0`.
4. Vuelve a comprobar el saldo del token, el spender y el propósito. Solo entonces envía `approve(spender, newAmount)` y espera la confirmación antes de considerar activo el nuevo allowance.
5. Verifica el allowance final y revisa los eventos `Transfer` y `Approval` intermedios. Un recibo correcto demuestra la ejecución; el estado actual del contrato muestra el permiso restante.

`SafeERC20.forceApprove` de OpenZeppelin ofrece a los contratos una alternativa de compatibilidad: intenta el valor deseado y, si la llamada falla, prueba `0` seguido del valor deseado. Esta utilidad modifica el allowance propio del contrato que llama. No corrige automáticamente la aprobación de la cartera de un usuario ni elimina la necesidad de verificar el orden de las transacciones y el estado final.

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

## Ejemplo

Un propietario ha concedido a un spender un allowance de `1000` tokens y quiere reducirlo a `100`. En un token que exige ponerlo primero a cero, `approve(spender, 100)` revierte, por lo que el allowance on-chain sigue siendo `1000`; una llamada revertida no actualiza parcialmente el estado.

En su lugar, el propietario envía `approve(spender, 0)`. Antes de que se confirme, el spender usa `400` y quedan `600`; la puesta a cero confirmada después sustituye el resto por `0`. Tras comprobar que su saldo de tokens ha disminuido, el propietario puede decidir si concede los nuevos `100`. Si lo hace, el spender ya ha usado `400` y después puede usar hasta `100` más. El procedimiento reveló el gasto intermedio antes de conceder el nuevo permiso, pero no lo deshizo.

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

## Riesgos

- El allowance anterior puede usarse hasta que se ejecute la puesta a cero. Un spender puede adelantarse a una revocación o reducción pendiente.
- Enviar la puesta a cero y la sustitución sin esperar la primera confirmación elimina el punto de control previsto y puede ocultar un gasto intermedio.
- Una cadena, dirección de token o dirección de spender incorrecta puede crear o revocar un permiso distinto del previsto. Los símbolos de tokens no son identificadores únicos.
- El proceso de dos pasos cuesta dos transacciones cuando ambas son necesarias; cualquiera puede fallar, ser reemplazada o quedar pendiente. No deduzcas el estado solo de una firma enviada.
- Las aprobaciones ilimitadas y los spenders actualizables o comprometidos pueden exponer depósitos futuros. Usa el menor importe práctico y comprueba el allowance restante tras utilizarlo.
- Las integraciones de contratos deben manejar deliberadamente los valores de retorno y comportamientos de aprobación no estándar. Una capa de compatibilidad no vuelve seguro a un spender que no es de confianza.

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

## Errores comunes

- **Todos los ERC-20 exigen poner el allowance primero a cero.** El estándar recomienda la secuencia en el cliente, pero dice que los contratos de tokens no deberían imponerla; solo algunas implementaciones rechazan el cambio entre dos valores distintos de cero.
- **Ponerlo primero a cero resuelve por completo la carrera de aprobación.** El spender aún puede usar el allowance anterior antes de que se confirme la puesta a cero.
- **Una sustitución revertida borró el allowance anterior.** Un revert deshace el cambio de estado intentado, por lo que normalmente permanece el allowance previo.
- **Enviar las dos transacciones juntas equivale a esperar.** El punto de control surge al confirmar e inspeccionar el estado cero antes de decidir sobre la sustitución.
- **Desconectar un sitio web revoca su aprobación.** El estado de conexión de la cartera y el allowance on-chain del contrato del token son independientes.

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

## Temas relacionados

- [Carrera de aprobación de ERC-20](/es/crypto/erc20-approval-race-condition/)
- [Aprobación de cartera](/es/crypto/wallet-approval/)
- [Nonce y deadline de Permit ERC-2612](/es/crypto/erc2612-permit-nonce-deadline/)
- [Riesgo de las firmas Permit2](/es/crypto/permit2-signature-risk/)

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

## Fuentes

- [ERC-20: estándar de tokens](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultado: 2026-08-21)
- [ERC20 | Documentación de OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20) - OpenZeppelin (consultado: 2026-08-21)
- [SafeERC20.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol) - OpenZeppelin (consultado: 2026-08-21)

Source: https://wiki.fcontext.com/es/crypto/token-approval-zero-first/index.mdx