In this track: Smart contract security foundations
advanced · 4 MIN READ
Cross-function reentrancy
A callback can enter a different function sharing the same state.
LET’S PICTURE IT
A person can reuse an unfinished account update at another service window.
SEE IT FOR YOURSELF
A valid counter call, step by stepStep 1 / 4
This example begins with count zero and a request to call increment(). No real contract is deployed.
This example begins with count zero and a request to call increment(). No real contract is deployed.Execution follows the code’s input and permission rules. A website button is not the access-control mechanism.The function reads zero, calculates zero plus one, and writes one to persistent storage.The accepted state contains count one. Later reads can inspect it. Events are emitted only if the code implements them.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Map shared state
List every function that reads or changes the same credit, reserve or ownership fields. A vulnerability can cross function names.
Trace an alternative entry
A callback blocked from repeating withdraw may call transferCredit or another reachable operation instead. The shared state can still be inconsistent.
Protect the shared invariant
Choose guards and transitions covering the relevant state machine. A function-specific lock is not automatically enough when another path uses the same assumptions.
Test multiple entry points
A hostile receiver should attempt the reachable alternatives at each interaction boundary. Verify the accounting property across the entire sequence.
Reason about the scenario
withdraw → external call
callback → transferCredit
shared credit state is still mid-transition
Pseudocode or a simplified scenario for local reasoning. This is not a production contract or a completed security review.
QUICK CHECK · NO PRESSURE
Can reentry through a different function still matter?
The functions may share vulnerable state assumptions.