A smart contract can follow its code exactly and still produce the wrong outcome. The program may contain an incorrect rule, unsafe permission or faulty assumption about outside information. Blockchain consensus does not automatically repair that error.
A fictional school science fair issues certificates when two authorised judges approve a project. Alicia submits her entry. Tricia discovers that the program checks only one approval. Kai Kai asks whether the code is functioning or the rule is wrong. Both can be true: the program may run correctly while implementing the wrong policy.
The answer in everyday language
Start by identifying the claim, the people authorised to act, and the exact digital evidence. A network’s accepted record is not a substitute for accurate source information, fair rules or a responsible recovery process.
Why a simpler alternative matters
Before building a blockchain application, compare an ordinary database, signed documents and an accountable service provider. If those meet the actual requirement, additional network complexity may not be justified.
1. Write the intended rule first
A requirement such as Two different authorised judges must approve is understandable before coding. The implementation must enforce that rule rather than merely accept any valid signature. Test the difference between the human requirement and actual code.
2. Consensus does not validate human intention
Network participants check transactions against protocol and contract rules. They do not know that the school’s policy requires two judges unless the application expresses that requirement correctly.
3. Bugs are not limited to crashes
A program may fail to check caller authority, mishandle state, use an outdated balance or rely on a service that returns misleading data. It can continue running while creating wrong results.
4. Dependencies and contract interactions matter
A contract can call other contracts or depend on external reports. Its behaviour may depend on those components and the timing of their responses. The application needs to understand each trust boundary.
5. An audit has a defined scope
An audit can examine a specific code version, configuration and set of assumptions. It is not a lifetime guarantee of safety. Users should ask whether the audited version matches the deployed code and whether privileged administrators can upgrade it.
6. Test the failure cases, not only the happy path
Try both judges approving, one judge missing, a repeated request, a revoked judge and an unavailable external service. Record expected and observed outcomes. One successful demonstration is not enough.
7. Upgrade powers require governance
Some contracts can be upgraded under defined permissions. That may help correct defects but also gives power to whoever controls upgrades. Other contracts cannot be changed directly. Explain who can alter behaviour and how users learn about changes.
8. A correction does not always undo the consequence
An incorrect certificate may be revoked and reissued under the application’s rules. A digital-asset transfer may not be reversible merely by writing a correction note. Recovery depends on the actual contract and network.
9. Paper exercise: the missing second judge
Give children cards labelled Applicant, Judge A and Judge B. Write Two judges must approve. Run one case with two approvals and one with only Judge A. Ask why software that accepts both cases has a defect even if it never crashes.
A parent-and-child learning check
Use only paper and invented records. Ask the learner to name what the system knows, what an external person must verify and what should happen if the two disagree. No real wallet, key or cryptocurrency is required.
Questions to ask before trusting a result
Who supplied the source information? Which key or role was authorised? What network and state reference are being used? What was actually accepted? Is the displayed result current? Who handles a dispute or missing response?
Frequently asked questions
Does the blockchain guarantee the application is correct?
No. It provides network-specific mechanisms for validating and accepting digital actions. Incorrect inputs, software bugs and mistaken business rules remain possible.
Can a signed message be false?
Yes. A signature can support attribution and integrity under the relevant assumptions. It does not automatically make the statement accurate.
Is this suitable for children?
Yes, when taught as a paper exercise about evidence, permissions and responsibility rather than a cryptocurrency investment activity.
Continue through the eduKateSG learning system
Use the specialist technical companion for implementation details. The English guide, Chinese guide and main hub connect the wider series.
Sources and limits
Primary reference: https://docs.soliditylang.org/en/latest/security-considerations.html. General context: NIST Blockchain Technology Overview. The story is a fictional learning example, not an actual school blockchain deployment or a recommendation to transact with real assets.