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

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.

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

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.

O ID da cadeia e a verificação do contrato correspondem à aplicação pretendidaFunção, gastador, token, valor, nonce e prazo são decodificadosA permissão existente e a semântica de substituição foram verificadasForam simuladas alterações de saldo e aprovaçãoChamadas, delegações ou transferências de valor inesperadas causam rejeição

0 / 5

0 itens revisados; 5 itens ainda não resolvidos

A conclusão desta revisão não prova que um ativo, transação ou sistema seja seguro.

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.

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.

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.

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.

Tópicos relacionados

Fontes

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