---
title: "Condição de corrida de aprovação ERC-20"
description: "Um spender ERC-20 pode usar a allowance antiga antes da confirmação de uma aprovação substituta e, depois, usar a nova allowance. Entenda como essa corrida funciona e como alterar ou revogar aprovações com mais segurança."
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.

# Condição de corrida de aprovação ERC-20

> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

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

## Resposta direta

A condição de corrida de aprovação ERC-20 pode ocorrer quando um proprietário substitui uma allowance diferente de zero por outra chamando `approve(spender, newAmount)`. O spender pode ver a alteração pendente, gastar primeiro a allowance antiga com `transferFrom` e, depois da confirmação, gastar a allowance substituta.

Por isso, a especificação ERC-20 recomenda que as interfaces de cliente primeiro definam a allowance como `0` antes de atribuir um novo valor ao mesmo spender. Cada transação deve ser confirmada na ordem. Quando o token oferece suporte a elas, as chamadas atômicas `increaseAllowance` ou `decreaseAllowance` evitam a substituição direta de uma allowance diferente de zero.

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

## Como funciona

O ERC-20 define `approve` como uma sobrescrita: uma chamada bem-sucedida a `approve(spender, amount)` define a allowance do spender como `amount`. Separadamente, `transferFrom(owner, recipient, amount)` permite que esse spender mova os tokens do proprietário e normalmente reduz a allowance restante. Transações pendentes não reservam uma ordem de execução, então um spender pode enviar uma transferência que seja executada antes da alteração de aprovação do proprietário.

A transição arriscada é `N -> M`, em que tanto `N > 0` quanto `M > 0`. Se o spender consumir `N` antes que a aprovação substituta seja executada, a aprovação posterior estabelece uma nova allowance de `M`. Portanto, o valor máximo gasto nessa sequência pode ser `N + M`, sujeito ao saldo de tokens do proprietário e à implementação do token.

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

## Exemplo

Alice aprovou um protocolo para gastar `100` tokens. Ela envia `approve(protocol, 50)`, pretendendo reduzir a allowance restante para `50`. Antes da confirmação dessa transação, o spender do protocolo envia `transferFrom(Alice, recipient, 100)` e consegue executá-la primeiro. A aprovação de Alice define então a allowance como `50`, que o spender pode usar em outra transferência. As duas transferências totalizam `150` tokens.

Um fluxo de substituição mais seguro é enviar `approve(protocol, 0)`, aguardar a confirmação, verificar a allowance e o saldo resultantes e só então enviar `approve(protocol, 50)`, caso a nova aprovação ainda seja adequada. Se o spender usar a allowance antiga antes da confirmação da transação de zeragem, Alice poderá ver a alteração no saldo e parar antes de conceder os novos `50`.

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

## Riscos

- Definir a allowance como `0` não revoga gastos já executados nem impede o uso da allowance antiga antes da confirmação da transação de zeragem.
- Enviar as aprovações de zeragem e substituição juntas, sem aguardar a primeira confirmação, reintroduz o risco de ordenação.
- `increaseAllowance` e `decreaseAllowance` não fazem parte do padrão ERC-20 básico; use-as somente quando o contrato verificado do token oferecer suporte a elas.
- Uma allowance ilimitada pode expor todo o saldo de tokens do proprietário enquanto permanecer ativa. Antes de assinar, verifique a rede, o contrato do token, o spender e o valor.
- Alguns tokens apresentam um comportamento de aprovação fora do padrão. Leia a simulação da carteira e os calldata da transação e confirme a allowance on-chain após cada etapa.

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

## Erros comuns

- "A transação de aprovação mais recente substitui a antiga imediatamente." Ela só altera o estado quando é executada on-chain.
- "Reduzir uma allowance limita o total de gastos futuros ao novo valor." Um spender pode usar a allowance antiga antes da execução da alteração.
- "Zerar primeiro garante que nenhum outro token possa sair." A allowance antiga permanece utilizável até a confirmação da transação de zeragem.
- "Todo ERC-20 tem `increaseAllowance` e `decreaseAllowance`." Elas são extensões opcionais, não requisitos do ERC-20.
- "Revogar a conexão com o site revoga a aprovação do token." O estado da conexão da carteira e a allowance on-chain do contrato do token são independentes.

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

## Tópicos relacionados

- [Como distinguir tokens canônicos de tokens wrapped](/pt-br/crypto/canonical-vs-wrapped-token/)
- [Mempool](/pt-br/crypto/mempool/)
- [Risco de assinatura Permit2](/pt-br/crypto/permit2-signature-risk/)
- [Ordens reduce-only](/pt-br/crypto/reduce-only-order/)
- [Aprovação da carteira](/pt-br/crypto/wallet-approval/)

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

## Fontes

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

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