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

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.

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

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.

El Chain ID y el contrato verificador coinciden con la aplicación previstaSe decodificaron función, spender, token, cantidad, nonce y deadlineSe comprobaron el allowance existente y las reglas de sustituciónSe simularon los cambios de saldo y aprobacionesLas llamadas, delegaciones o transferencias de valor inesperadas causan rechazo

0 / 5

0 elementos revisados; 5 elementos pendientes

Completar esta revisión no demuestra que un activo, una transacción o un sistema sean seguros.

Cómo funciona

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.
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.
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.
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.
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.

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.

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.

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.

Temas relacionados

Fuentes

ERC-20: estándar de tokens - Ethereum Improvement Proposals (consultado: 2026-08-21)
ERC20 | Documentación de OpenZeppelin - OpenZeppelin (consultado: 2026-08-21)
SafeERC20.sol - OpenZeppelin (consultado: 2026-08-21)