Reentrancy is a smart-contract risk that can arise when one contract calls another and control returns to an earlier contract before its relevant state or assumptions have been safely settled. It is about call order and visible state, not simply a hacker guessing a password.
Imagine a fictional school voucher desk. Alicia asks to redeem a voucher. Before the clerk updates the ledger to show it was redeemed, the clerk asks another desk to process a related request. That desk calls back to redeem the same voucher again. The paper analogy reveals why an unfinished state change can be dangerous.
This article is a clear learning route for parents, children and adult beginners. The classroom situation is fictional. No cryptocurrency investment, real account, private key or live contract is needed.
The short answer
Reentrancy is a smart-contract risk that can arise when one contract calls another and control returns to an earlier contract before its relevant state or assumptions have been safely settled. It is about call order and visible state, not simply a hacker guessing a password.
The story: why the problem matters
Imagine a fictional school voucher desk. Alicia asks to redeem a voucher. Before the clerk updates the ledger to show it was redeemed, the clerk asks another desk to process a related request. That desk calls back to redeem the same voucher again. The paper analogy reveals why an unfinished state change can be dangerous.
1. Begin with the expected state transition
A redemption should check that the voucher is available, apply the authorised change and produce the permitted effect. The intended invariant is that one voucher cannot be redeemed twice.
2. An external call can return control unexpectedly
In an Ethereum-like execution environment, a contract may call another contract that can execute code and call back into the original contract. If the original contract’s bookkeeping is not safely ordered or protected, the callback may encounter an inconsistent intermediate state.
3. Reentrancy is not always one simple function
A vulnerability can involve callbacks across different functions or shared state. Developers must reason about every relevant entry point and the invariants that should remain true during nested calls.
4. Checks-effects-interactions is a useful pattern
A common design principle is to perform appropriate checks, update internal state and then interact externally where feasible. It is not a universal substitute for careful design, because complex systems may have cross-function or cross-contract dependencies.
5. Reentrancy guards have a scope
A guard can prevent certain nested entries, but it must cover the relevant paths and work with the application’s intended behaviour. A label saying Protected is not proof that all possible interactions are safe.
6. A transaction can be atomic yet still contain harmful intermediate behaviour
A blockchain transaction may execute a sequence of nested calls as one state transition, but the sequence of operations inside it still matters. A later revert can undo state changes within its scope; it does not mean every possible contract design is safe.
7. Test the callback path
A responsible test suite includes a normal redemption, an attempted repeated callback, calls through a second function and failure cases. The test should check final balances and invariants, not merely whether the transaction returned a success flag.
8. Paper activity: the unfinished voucher register
Write Available beside one imaginary voucher. Let a clerk begin a redemption but delay changing the status. Have another child request redemption during the pause. Ask how updating state at the correct point or refusing nested requests changes the outcome.
9. This is a defensive lesson, not a deployment guide
The classroom story explains why state order matters. Real contracts require qualified security review, threat modelling and platform-specific testing before they control valuable assets.
A family exercise: what can we check?
Draw three columns labelled Proposed Action, Digital Evidence and Real-World Result. Put an event from the story in each relevant column. Ask which claim the software can verify, which person has authority and which outcome still needs a separate check.
Now add a deliberate error, such as a duplicate request, wrong amount, missing approval or delayed message. Ask the learner whether the process should continue, stop or request additional evidence. The exercise is an analogy and does not implement cryptographic security.
What an adult should check before relying on it
Identify the actual network, software version, permissions, accepted state, key management, source of outside facts and incident owner. A technically valid transaction does not automatically establish an authorised human decision or completed physical result.
When a simpler solution is better
For one school or small organisation with a trusted administrator, a conventional database and well-designed access controls may meet the real need with less complexity. Blockchain should be justified by specific independent verification, settlement or governance requirements.
Frequently asked questions
Does this make the system automatically safe?
No. Security depends on the particular implementation, threat model, data sources, operational controls and assumptions. A correct explanation of one mechanism is not a security audit.
Can children learn without using real digital assets?
Yes. Fictional records, paper counters and role cards are enough for the core concept. There is no reason to give children real keys or speculative assets for this exercise.
Does every blockchain use this same mechanism?
No. Networks and applications differ. Do not copy a technical claim from one protocol to another without checking the specific design.
Continue through the eduKateSG learning system
Continue with the specialist technical lesson, the English Blockchain Learning Guide, the Simplified Chinese guide and the main Blockchain hub. The Complete System provides the wider architecture.
Sources and limitations
Technical source: https://docs.soliditylang.org/en/latest/security-considerations.html. Foundational context: NIST Blockchain Technology Overview. This article explains concepts, not investment, security certification or legal advice. The fictional examples do not describe a deployed eduKateSG blockchain service.
Takeaway: Reentrancy is a smart-contract risk that can arise when one contract calls another and control returns to an earlier contract before its relevant state or assumptions have been safely settled. It is about call order and visible state, not simply a hacker guessing a password.