Chapter 9 · What Smart Contracts Changed
What happens when rules themselves become software?
- Capabilities practiced
- Protocol LiteracyMental Model
- Hands on
- Open a verified contract in a block explorer and find its owner and upgrade entry point.
- AI Lab
- Have AI explain three core functions of an unfamiliar contract. Find a permission risk it did not mention yourself.
A Real-World Problem
You rent a room and pay three months' rent as a deposit.
The agreement clearly says the deposit returns in full within three days if the property is undamaged at lease end.
At the end, the landlord deducts eight hundred for nail holes and six hundred for deep-cleaning the kitchen, then asks you to wait until another tenant pays because cash is short.
The contract has not changed a word, but the landlord executes it.
You can arbitrate or sue. Even if you win, is recovering two thousand worth the time and effort?
The structure is widespread. Most contracts fail because an interested party enforces them, not because their wording is unclear. Society adds intermediaries, custodians, notaries, and courts; each charges, and each itself requires trust.
What if enforcement no longer needed a person?
Thought Experiment
Start with a vending machine.
Insert three yuan, press a button, and receive cola. No clerk, bargaining, or machine mood changes the outcome. Both rules and execution are inside it.
Expand the machine step by step.
Step one: the rules are publicly inspectable. Anyone can inspect its wiring and verify that three yuan buys cola rather than air. You need not trust the manufacturer blindly.
Step two: anyone can connect machines. Someone connects one outlet to another input: six yuan produces cola, which the next machine exchanges for a movie ticket. Their owners do not know one another, have never negotiated, and require no approval.
Someone adds a third machine. A pipeline nobody planned grows.
Step three: there is no key after assembly. The machine is welded shut, even for the manufacturer.
This is both its greatest advantage and danger. Nobody can secretly change rules overnight; today's wiring still applies ten years later. But if a missing zero prices three-yuan cola at thirty cents, the mistake persists forever, until the stock is drained.
Step four: the manufacturer retains a backdoor key. A key opens the rear panel for repairs.
Now every promise of unchangeability needs the qualification “except the person holding the key.”
Which machine would you entrust with your deposit: step three or step four?
Your Decision
The machine holds your two-thousand-yuan deposit. After three months it refunds automatically, unless the landlord raises a dispute and you agree to an allocation.
Four versions are available.
What Happens
All four choices express one exchange:
Software removes dependence on an enforcer's interests but executes errors just as faithfully.
The question shifts from possible reneging to whether the rules are correct and who can change them.
Compare the approaches:
| Paper contract | Software rules | |
|---|---|---|
| Enforcer | A party or third party | The chain automatically follows rules |
| Trigger | Human initiation, consent, and confirmation | Conditions cause execution |
| Interested party? | Yes | No |
| Incorrect wording | Interpretation, negotiation, or law | Executes anyway |
| Others connecting to it | Requires agreement | Anyone can call it |
| Can it change? | Parties sign changes | Depends on retained authority |
The final row is the real dividing line and often becomes a slogan.
Immutability is a spectrum, not a switch. Real on-chain rules occupy positions on it:
| Position | Who can change it | What you trust |
|---|---|---|
| Completely immutable | Nobody | Original code is correct |
| Multiple approvals and a delay | A group, with advance visibility | You can exit during the delay |
| Multiple approvals, immediate effect | A group | No collusion or simultaneous key loss |
| One address changes it anytime | One person | That person and their key security |
People often assume the first while actually using the third or fourth. The lab asks you to inspect this firsthand.
Build a Model
Model one: the chain is a state machine
Imagine a machine doing one thing:
- Current state
- Incoming transaction
- Compute under rules
- New state
This clarifies Bitcoin and Ethereum:
| What rules process | Who writes them | Result | |
|---|---|---|---|
| Bitcoin | Mainly whether money can be spent and to whom | The protocol, modified cautiously by the community | Programmable money |
| Ethereum | Programs anyone uploads, recording and changing arbitrary data | Anyone, anytime, without permission | Programmable state |
The core sentence is:
Bitcoin is programmable money; Ethereum is programmable state.
The distinction is who writes the rules, not a universal strength ranking. Bitcoin keeps them at protocol level, taking years to change. Ethereum lets anyone define assets, markets, and organizations—and deploy flawed or malicious rules.
Model two: rules that connect to one another
A deeper change is often missing from whitepaper opening pages.
Because rules share one chain, are public, and can be called directly, they connect like building blocks without authorization.
Lending rules call trading rules for liquidation. A new product accesses existing liquidity on launch day. Someone's work enters a larger system built by a stranger.
This helps explain decades of traditional financial product categories emerging on-chain within years. It also explains contagious incidents:
Your security equals the weakest rule in your dependency chain, even one whose name you have never heard.
Model three: four questions about upgrade authority
For any on-chain rules, ask in this order:
- Can anyone change them? Find the entry point or establish its absence.
- Who? An address, a group, or governance?
- How long before changes take effect? Can users exit during a delay?
- Can you notice a change? Events, announcements, or monitoring?
Most people ask the first two and omit the last two. Those determine whether you can leave during an incident.
What It Is Called
A program deployed on-chain and automatically executed under its defined rules.
The name misleads twice: it is neither intelligent nor a legal contract. It resembles a welded-shut vending machine, executing conditions without understanding intent or accepting explanations.
Its hard boundary is reading on-chain data only. It cannot see nail holes. Physical-world information requires external inputs, a separate risk in chapter 24.
The loop “current state + input = new state.”
A useful chain model is a machine whose every computation anyone can verify, rather than merely a database. Identical rules and inputs yield identical results, implementing untrusted-bookkeeper accounting technically.
One set of on-chain rules directly calls another without permission, business negotiations, or interface integration.
It underpins rapid innovation and rapid risk contagion. Those are the same property.
Spend ten minutes mapping a protocol's external dependencies. You may find risks from components you never knew existed.
Rules cannot change after deployment.
Remember the spectrum rather than a switch. A contract retaining an entry point to replace core logic has only verbal immutability.
That is why the lab asks you to find the entry rather than trust marketing.
Replacing contract logic through a retained mechanism.
It is a trade-off: without upgrades, bugs cannot be fixed; with them, authority can be abused. A common compromise requires multiple approvals and a public delay.
Ask multisig operators how many people, who they are, where keys reside, and whether a timelock exists. Only after those questions do you know who can change the system.
Hands-on
This is read-only. Do not connect a wallet or sign anything. Inspect public source code only.
Find a contract with verified source. Open a familiar protocol's address in a block explorer and visit its source tab.
If only hexadecimal bytecode appears, source verification is absent. That is an important finding itself; record it and choose another.
Find the owner. Read fields such as owner and admin and record their addresses.
Inspect the address: ordinary account or multisig? If multisig, how many signatures are required? Its page usually supplies this.
Find upgrade entry points. Look for a proxy: an implementation field, another contract address, or the explorer's proxy label.
Record the logic contract's address and who can replace it.
Find the timelock. If the owner is a timelock contract, read its delay from proposal to effect.
This is the lab's most valuable cell. A delay offers an exit opportunity; no delay lets one transaction change the rules.
Complete the table and one judgment.
| Question | Finding |
|---|---|
| Verified public source? | |
| Owner: single address, multisig, or governance? | |
| Multisig threshold? | |
| Upgrade entry point? | |
| Timelock and delay? | |
| Can changes be detected? |
Judge what you lose if the owner takes the worst possible action tomorrow.
Do not ignore Not Found cells. Not knowing who can change it is itself a conclusion.
AI Lab
Give AI the source from the previous lab:
This is source code for a deployed on-chain contract. Do three things:
1. Explain its three central functions: callers, changed state, and preconditions.
2. List every restricted function and the source line enforcing the restriction.
3. List all external contract addresses or interfaces it calls.
Use only the supplied source. Write “not reflected in source” for absent information.
Do not fill gaps with assumptions about similar protocols.Your job is to find omitted categories, not merely confirm the explanation.
Models explain what code does better than who it permits to act. They may explain an admin function clearly without asking who the admin is, where its key resides, or whether one transaction replaces it.
Look specifically for these frequent omissions:
- Functions transferring funds to arbitrary addresses
- Functions changing fees, limits, or price sources
- Ownership transfer and whether the recipient must confirm
- Pausing and whether users can withdraw while paused
- External data origins and who can change them
For every item, write its worst-case consequence. Chapter 24 expands this into a full risk model.
Verify these points yourself after using AI
- Find every described function by the same name in source
- Check access controls and functions limited to particular addresses
- Check whether it finds upgrades or mistakes a proxy for final logic
- Check what the owner actually is whenever it says owner-only
- Check external contract dependencies
- Check that an audit is not equated with safety; identify its date and scope
- Reread any section it declares standard and risk-free
Real-World Case
A project entrusted substantial raised funds to on-chain rules. An attacker used a logic flaw to repeatedly withdraw assets.
The rules executed normally: the attacker followed programmed operations rather than breaking into a system. A welded-shut machine faithfully executes flawed rules.
The response changed chain history and split the community into two chains. “Code is law” has never been fully realized since.
Large losses have come from stolen upgrade-admin keys rather than contract bugs: phishing, compromised development machines, or former employees' backups.
Attackers replace implementation logic and drain the pool in one call.
Contract audits cannot help in this scenario, because the audited code is correct. Audits cover code, not key custody.
Some protocols deliberately prohibit upgrades. When a nonfatal but continually costly flaw appears, they can only urge users to exit and watch funds drain.
The choice can be legitimate, but demands correct code before deployment, extremely difficult for complex systems.
Several protocols share an external price source. During volatility it reports a wrong price, and every dependent protocol executes liquidations at that price.
They have no business partnerships and their users may not know each other.
Composability connections become network effects in success and contagion paths in failure. Chapter 24 treats this separately.
Change One Variable
Stolen upgrade-key risk and change-authority questions disappear.
But iteration changes entirely: costly predeployment verification, redeployment for every feature change, and risky user and fund migrations.
Fewer things can launch, and bugs in launched systems cause greater losses.
This is one of the chapter's most practical suggestions.
Authority remains, but users gain seven days to exit. A malicious upgrade becomes a visible announcement rather than one surprising transaction.
Emergency repair is also delayed. Systems therefore often timelock routine changes but separately authorize emergency pausing. Then ask who can pause and whether users can withdraw while paused.
Deployers can conceal logic and backdoors.
The chain still works and transfers remain visible. But users lose advance assessment and retain only retrospective tracing.
Source verification does not prove correctness; it gives you the opportunity to inspect.
Permissionless composability disappears. New protocols negotiate partnerships and interfaces rather than immediately connecting to liquidity.
Risk contagion is constrained and dependencies become explicit.
But much recent on-chain innovation depends on permissionless connection. Removing it leaves a traditional financial system with less convenient interfaces.
Takeaway Questions
Smart contracts address an interested enforcer, not unclear wording.
Ask whether disputes concern enforcement or judging reality. Chains cannot judge wall damage.
The concrete answer is independent execution without an interested party.
If users accept one company setting and executing rules, a server suffices. A chain adds cost and risk.
Composability means risk includes every dependency.
Draw who calls whom and their dependencies. If you cannot map them, you do not know the risk you bear.
Upgrade authority is this industry's human-in-the-loop mechanism.
Remove it and bugs cannot be repaired; grant it freely and assets depend on one key. The common compromise is intervention with multiple approvals, public delays, and monitorable traces.
Chapter 34 revisits almost the same trade-off for agent-wallet permissions.
Chapter Check
It understands no intent, makes no judgment, accepts no explanation, and executes even flawed conditions, like a welded-shut vending machine.
Legal contracts permit interpretation, negotiation, and courts. On-chain rules simply run as written.
Also remember that it reads only on-chain data. Physical information requires external inputs, a separate risk.
Both compute current state plus transaction into new state. The difference is who writes the rules.
Bitcoin's protocol chiefly determines whether money can be spent and where. Changing it requires lengthy community agreement.
Ethereum lets anyone deploy programs defining assets, markets, and organizations without permission.
That also means anyone can deploy flawed or malicious rules.
Because anyone can directly call anyone else's rules without permission.
New products immediately use existing liquidity and functionality, accelerating innovation.
But security equals the weakest dependency, possibly an unknown component. One wrong source can damage several unrelated protocols.
At least four questions:
- Who are the five? Independent entities or one team's accounts?
- Where are keys kept? One device or process undermines the threshold's practical value.
- Is there a timelock? How long before effect, and can users exit?
- What can it change? Parameters only, or all logic and funds?
The third is crucial. Delay offers an exit; no delay lets one transaction change everything.
There is no answer key. Include these checks:
- Verified public source? If absent, further inspection is limited.
- Upgrade entry points? Map proxy and implementation.
- Single owner, multisig, or governance?
- Timelock and delay?
- External contracts and data sources?
- Arbitrary fund-transfer functions?
Finally ask your loss under the authority holders' worst action tomorrow. Without an answer, the investigation is unfinished.
Key idea
Bitcoin is programmable money; Ethereum is programmable state.