A Solidity enum defines a limited set of named alternatives, such as Requested, Approved, Cancelled and Completed. It can make a contract’s status easier to reason about, but an enum does not by itself enforce which status changes are allowed.
Alicia submits a fictional science-kit booking. Tricia approves it, and Kai Kai later records its cancellation. They agree to use a short list of named statuses instead of free-form messages that can be misspelled.
This is a beginner-friendly guide for parents, children and adults. The school examples are fictional and do not require cryptocurrency, real wallets or private student information.
The answer in one minute
A Solidity enum defines a limited set of named alternatives, such as Requested, Approved, Cancelled and Completed. It can make a contract’s status easier to reason about, but an enum does not by itself enforce which status changes are allowed.
A familiar example
Alicia submits a fictional science-kit booking. Tricia approves it, and Kai Kai later records its cancellation. They agree to use a short list of named statuses instead of free-form messages that can be misspelled.
1. An enum gives states names
Developers define a fixed set of alternatives in Solidity. A value can represent one of those alternatives, making code more readable than arbitrary unexplained numbers.
2. Named states are not a workflow
An enum containing Approved and Cancelled does not stop a function from jumping directly between them. The contract must separately check which transitions are permitted.
3. Default values matter
A Solidity enum’s default corresponds to its first member. If the first member is Approved, an uninitialised value can misleadingly appear approved. Designers often use a deliberate initial state.
4. Underlying representation is numeric
Enums are encoded through integer-like values under Solidity’s rules. Interfaces and storage readers may display a number unless they know the enum definition.
5. Changing definitions can break interpretation
Reordering enum members in a contract upgrade can change how existing stored values are interpreted. Storage compatibility must be reviewed before deployment.
6. Events and current state differ
A booking can have historical Approved and Cancelled events while its current enum status is Cancelled. The last visible notification is not necessarily the current answer.
7. Status does not prove a physical outcome
A contract may mark a kit Returned even if nobody checked the cupboard. The system still needs authorised observations and a correction process.
8. Paper activity: four status cards
Give children Requested, Approved, Cancelled and Completed cards. Ask them to define allowed transitions, then attempt a prohibited jump and explain why the status names alone did not prevent it.
9. When a database status field is enough
A school can use ordinary status codes in a database. Solidity enums are relevant when an on-chain state machine is genuinely needed.
A five-question understanding check
What does the code represent? What does it read or change? Who is authorised to act? Which state or network reference applies? What physical-world fact remains outside the software? These questions separate technical validity from the truth of external claims.
A family learning activity
Use the paper exercise in the chapter. Introduce one mistake, stale value or missing approval, then ask the learner what can still be established. Paper analogies are not cryptographically secure systems.
When a simpler approach is better
A conventional database, signed form or ordinary program may meet a school’s needs with less complexity. Blockchain is justified only where its specific independent verification or governance properties solve a real requirement.
Frequently asked questions
Does this prove a real-world claim is true?
No. Code establishes a defined digital property under its rules. External facts need appropriate evidence.
Can children learn without buying cryptocurrency?
Yes. The examples use invented records and paper activities only.
Is this universal to all blockchains?
No. These are Solidity-specific concepts. Other platforms may use different languages and execution models.
Continue learning
Read the related chapter, the English learning guide, the Chinese learning guide and the Master Blockchain hub.
Sources and scope
Primary technical source: https://docs.soliditylang.org/en/latest/types.html#enums. General context: NIST Blockchain Technology Overview. The classroom scenarios are fictional.