A smart contract interface describes the functions another program expects to call. On Ethereum, a Solidity interface declares callable functions and related definitions without supplying their implementation. It makes programs easier to connect, but does not establish that the contract behind an address is trustworthy.
Alicia’s school robotics club asks several teams to use the same booking commands: check availability, reserve a kit and cancel a booking. Tricia publishes the agreed command sheet. Kai Kai points out that two teams can advertise the same commands while implementing very different rules.
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
A smart contract interface describes the functions another program expects to call. On Ethereum, a Solidity interface declares callable functions and related definitions without supplying their implementation. It makes programs easier to connect, but does not establish that the contract behind an address is trustworthy.
A school example
Alicia’s school robotics club asks several teams to use the same booking commands: check availability, reserve a kit and cancel a booking. Tricia publishes the agreed command sheet. Kai Kai points out that two teams can advertise the same commands while implementing very different rules.
1. The interface is a promise about how to communicate
A caller needs to know function names, argument types, return values and other expected behaviours. A Solidity interface helps express this shape for contracts. It does not by itself say what happens internally when the function is called.
2. Interface and implementation are different
A contract implementing an interface supplies executable logic. Two implementations can satisfy the same function signatures yet apply different fees, permissions or business rules. Compatibility at the call level is not equivalent to economic or security equivalence.
3. Solidity interfaces have specific restrictions
Solidity interfaces declare external functions and can describe events and errors; they do not provide ordinary state-variable storage or function implementations. A developer should check the language version and current compiler documentation for precise restrictions.
4. An ABI is related, not identical
An ABI is a machine-readable encoding description used by tools to prepare calls and decode results. A Solidity interface is a source-code construct. Both help applications communicate, but neither is a security audit.
5. A contract address matters more than the brand label
A website might claim to connect to a school’s booking interface. The user still needs the actual network, contract address, code and authority information. A counterfeit contract can expose a familiar interface.
6. Errors are part of the usable interface
A function can revert when the caller lacks permission or the requested action is unavailable. A well-designed interface and client should explain such failures rather than show a misleading Success message.
7. Upgradeability can change the behaviour
An upgrade proxy may retain an address while the implementation changes. The callable interface may remain stable even when the rules behind it change. Users should understand who has upgrade authority.
8. The paper activity: one command sheet, two machines
Give two students the same booking-command sheet. One implementation accepts only teacher approval; the other accepts any student. Ask why the same interface does not guarantee the same policy.
9. When an ordinary API is enough
A school may use a conventional application API and database. A blockchain interface is useful only if the application’s justified on-chain interactions require it.
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.soliditylang.org/en/latest/contracts.html#interfaces. General blockchain foundation: NIST IR 8202. The school scenarios are fictional and do not describe an actual eduKateSG blockchain deployment.