An upgrade proxy is a smart-contract design in which users interact with a relatively stable contract address while execution can be delegated to a separate implementation whose code may change under defined authority. It can support fixes and improvements, but it also creates a powerful governance question: who can change the rules after users have begun relying on them?
Tricia’s school uses a digital science-kit booking counter. Alicia likes having one familiar booking address. Kai Kai proposes letting an authorised administrator replace the program behind that address when the school changes its rules. The address may stay the same while the behaviour changes.
This chapter is for children, parents and adult beginners. It explains blockchain as technology rather than cryptocurrency investment. All school examples are fictional, and no real wallets or student information are needed.
The answer in one minute
An upgrade proxy is a smart-contract design in which users interact with a relatively stable contract address while execution can be delegated to a separate implementation whose code may change under defined authority. It can support fixes and improvements, but it also creates a powerful governance question: who can change the rules after users have begun relying on them?
A school story to make it clear
Tricia’s school uses a digital science-kit booking counter. Alicia likes having one familiar booking address. Kai Kai proposes letting an authorised administrator replace the program behind that address when the school changes its rules. The address may stay the same while the behaviour changes.
1. Why upgrades are difficult
Code deployed to many blockchain platforms is not simply edited in place like a word-processing document. A proxy pattern can route calls through a stable address to separately deployed implementation code, allowing certain upgrades when the architecture permits.
2. The proxy and implementation have different jobs
The proxy receives calls and may delegate execution to implementation logic. The precise storage and call semantics depend on the proxy pattern and platform. A familiar address alone does not identify the current implementation.
3. Upgrade authority is a security boundary
An administrator, multisignature arrangement or governance process may control the implementation pointer. That authority can repair defects but may also introduce malicious or accidental changes. Users need to know who holds it.
4. Storage layout can break an upgrade
Some proxy designs rely on compatible storage layouts between versions. A poorly planned upgrade can reinterpret existing stored values or make the application unusable. Tests must check existing state, not only the new code in isolation.
5. Audits are version-specific
An audit of one implementation does not automatically cover a later implementation or changed administrator permissions. A verified source-code badge is not a permanent safety certificate.
6. Timelocks and review windows
A project may use a published delay before an upgrade becomes effective, giving participants time to inspect changes. The delay’s usefulness depends on real authority, notification and emergency exceptions. It does not guarantee every user can exit safely.
7. A proxy does not make physical promises true
If the school falsely reports that a kit was returned, upgrading the booking code does not independently inspect the cupboard. The digital rules and physical evidence remain separate.
8. Paper activity: one sign, changing instructions
Put a sign labelled Booking Desk above a classroom table. Change the instruction sheet behind the desk from Version 1 to Version 2. Ask who authorised the change, which old bookings it affects and why the unchanged sign does not guarantee unchanged rules.
9. When a simpler system is preferable
A school booking database with documented releases and rollback procedures may be more suitable. Upgradeable blockchain contracts are justified only when the shared-verification and governance requirements warrant the additional risk.
A five-question evidence check
What was requested? Who had permission? What digital result can be checked? Which network and state reference apply? What physical or institutional fact remains uncertain? These questions keep technical validity separate from real-world truth.
A parent-and-child activity
Use the paper exercise above. First complete the normal sequence. Then change a rule, hide a message or introduce an incorrect entry. Ask which evidence is missing and how a responsible person should resolve it. The exercise illustrates logic, not cryptographic security.
When a simpler system is enough
A school can often use a conventional database, signed approvals and an audit log. Blockchain adds value only if its independent verification or governance properties address a specific requirement that simpler alternatives do not meet.
Frequently asked questions
Does this guarantee the physical-world claim is true?
No. The mechanism supports a defined digital check under its assumptions. Physical delivery, fair decisions and educational achievement need separate evidence.
Do children need cryptocurrency to understand this?
No. Paper cards and fictional records are sufficient. No investment, keys or live accounts are necessary.
Does every blockchain work this way?
No. These mechanisms have platform-specific rules, particularly for Ethereum. Check the actual network and contract design before applying them.
Continue through the learning hubs
Read the related practical chapter, the English learning hub, the Chinese learning hub and the Master Blockchain hub.
Sources and scope
Technical source: https://docs.openzeppelin.com/upgrades-plugins/proxies. General background: NIST Blockchain Technology Overview. School scenarios are fictional and do not describe a deployed eduKateSG blockchain.