In this track: Smart contract security foundations
advanced · 4 MIN READ

Approval race conditions

Replacing an allowance can interact with pending spending.

LET’S PICTURE IT

Changing a permission limit while an earlier permission is still usable creates an ordering problem.

SEE IT FOR YOURSELF
From a public address to a verified signatureStep 1 / 4
From a public address to a verified signaturePublic address0x0000…0001Share to receiveAnother personCan read the addressCannot sign for youPublic identifier ≠ secret authorizationLocal signerPrivate key stays hereSign the chosen requestSigned requestMessage + signatureSecret key not includedThe moving packet represents a signature, not a keySignatureCheck the exact messageCheck the signing contextVerificationAuthorization checkedIntent still mattersValidity and safety are different questionsWallet interfaceReads public dataRequests authorizationNetwork stateBalances and recordsIndependent verificationNo wallet is connected in this local illustration

An address is public receiving information. It is not the private key that authorizes actions.

Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.

Understand replacement semantics

A standard approve call replaces the allowance with a new value. It does not necessarily mean add exactly this much permission to what remains.

Consider transaction ordering

A spender may use an existing allowance before a replacement is included. The resulting total spending can differ from a user’s simple before-and-after expectation.

Review safer workflows

Zeroing before a later nonzero approval can address a known transition issue, but pending use of the old permission still needs to be understood. Token-specific increase or permit mechanisms have their own rules.

Explain the actual authority

Show the spender, network, token and intended amount. An interface should describe permission changes without promising that a UI action cancels already included spending.

Reason about the scenario

old allowance 10
spender uses old permission before replacement
new approve 20 is included

Reason about ordering, not just the final displayed number.

Pseudocode or a simplified scenario for local reasoning. This is not a production contract or a completed security review.

QUICK CHECK · NO PRESSURE

Does a later approval undo spending already included?

Your progress stays in this browser.
Keep exploring the original referenceEthereum Improvement Proposals ↗

Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.