Who can change the contract

Code is only one part of the control story

Reading a contract description is not the same as understanding who can change the system around it. A project may combine deployed code, administrative controls, off-chain services and interfaces. Map those parts before repeating a broad claim that a service is fixed or decentralised.

Ask what the documentation actually describes

Ethereum’s smart-contract introduction explains programs running on the network. That general description does not certify the permissions of a particular application. A product-specific review must identify the relevant deployment, documented administrative functions and any separate components that influence user-facing behaviour. [C02]

Build a change register

For each component, record the proposed change, who is said to authorise it and which source supports that description. Keep “documented permission” separate from “tested permission”. If you cannot verify a deployment or inspect the relevant evidence, mark the row unverified. An empty answer is more useful than a confident guess.

Consider an ordinary failure case

Imagine a user interface shows one policy while a connected service has changed its rules. This is a hypothetical research scenario. The contract may behave as written while the overall experience changes. Your review should therefore state whether it covers code, configuration, interface behaviour or all three. Scope labels prevent a narrow technical observation from becoming a broad assurance.

Publish a bounded conclusion

Explain the identified change mechanism and its evidence, then list unresolved control questions. Do not label a system safe merely because a repository is public, and do not treat the absence of a found permission as proof that no permission exists. Readers should be able to follow your path back to the source.

Sources

• Introduction to smart contracts — General program model; not a deployment audit.
• Oracles — External data routes; not service performance.