An access control role defines which account or actor may perform particular actions in a smart-contract system. It separates identity from permission. A valid signature can show that a key authorised a request, but the application must still check whether that key holds the right role for that action.
Alicia can submit a robotics project. Tricia is authorised to approve results. Kai Kai maintains the equipment inventory. They all have accounts, but the club does not allow a student to award themselves a prize or an equipment officer to change competition marks.
This educational article is for parents, children and adult beginners. The school example is fictional and requires no cryptocurrency purchase, live wallet or student personal information.
The answer in one minute
An access control role defines which account or actor may perform particular actions in a smart-contract system. It separates identity from permission. A valid signature can show that a key authorised a request, but the application must still check whether that key holds the right role for that action.
A school example
Alicia can submit a robotics project. Tricia is authorised to approve results. Kai Kai maintains the equipment inventory. They all have accounts, but the club does not allow a student to award themselves a prize or an equipment officer to change competition marks.
1. Authentication is not authorisation
Knowing which key signed a request does not automatically mean the action is permitted. The contract or institution must apply explicit rules about which roles can call protected functions.
2. Roles can be narrower than administrator
A system might distinguish issuer, revoker, auditor, treasurer and emergency pauser. Granting every function to one all-powerful account may simplify development but concentrates operational risk.
3. Role assignment itself needs authority
Who can grant or revoke roles? In common role-based designs, an administrative role manages membership of other roles. A compromised role administrator can create a serious security incident.
4. OpenZeppelin provides one common implementation
OpenZeppelin’s AccessControl utilities illustrate role identifiers and checks, but they are not the only possible design. A project must inspect the exact contract version, inheritance and role hierarchy rather than assume a library name guarantees safety.
5. Role changes have timing consequences
If a judge leaves, the institution may revoke their permission. The application needs a clear effective state and a way to distinguish earlier valid approvals from future unauthorised attempts.
6. Multisignature can govern sensitive roles
Some projects place administrative authority behind a multisignature or governance process. This can distribute control but introduces its own quorum, recovery and coordination requirements.
7. A permitted action can still be wrong
An authorised judge may enter the wrong score. The role check can succeed while the real-world claim remains incorrect. Audit trails, correction processes and source evidence still matter.
8. The family activity: five role cards
Create cards for Student, Judge, Issuer, Revoker and Administrator. Write six pretend actions and ask which roles may perform each. Then revoke one role and test the same action again.
9. When a standard school system is enough
An ordinary school information system can enforce roles with well-established access controls. Blockchain should be chosen only when its specific shared verification or governance properties are necessary.
How to check the evidence
Ask what the code is meant to establish, who has authority, what current state the result refers to, what assumptions were made and which real-world facts remain unverified. A valid digital record is not a guarantee that every external statement is true.
A parent-and-child exercise
Use the paper activity in this chapter. Run the normal case, then introduce a mistake, missing approval or outdated record. Ask the learner which conclusion remains justified and what evidence would resolve the problem. Paper analogies do not implement cryptographic security.
When a simpler system is enough
A school may meet its requirements using a conventional database, signed records, established access controls and an audit trail. Blockchain adds value only when a specific shared verification or governance need justifies the additional complexity.
Frequently asked questions
Does this guarantee the physical-world claim is true?
No. The mechanism establishes a defined technical result under its assumptions. External events and institutional decisions need appropriate evidence.
Can children learn this without investing?
Yes. Fictional examples and paper exercises are sufficient. No money, private keys or real accounts are needed.
Does every blockchain implement this the same way?
No. The relevant contract language, platform and governance design matter. Ethereum-specific mechanisms should not be applied indiscriminately to every blockchain.
Continue through the learning library
Read the related practical chapter, the English learning guide, the Simplified Chinese learning guide and the Master Blockchain hub.
Sources and limits
Technical reference: https://docs.openzeppelin.com/contracts/5.x/access-control. General blockchain foundation: NIST IR 8202. The school scenarios are fictional and do not describe an actual eduKateSG blockchain deployment.