Week in literacy
Five short literacy notes from ethereum.org and block-explorer education pages. Original paraphrases only—link out to read the originals. Educational content only — not investment advice.
1. Verified means readable, not correct
ethereum.org separates two ideas that often get blurred together. Source code verification checks that published code compiles to the bytecode running at an address. Formal verification asks whether the contract behaves as intended. The green badge on an explorer is almost always the first kind.
Literacy takeaway: A badge lets you read the code; it doesn’t vouch for it. New walkthrough: verified contracts: what the badge proves.
Source: Verifying smart contracts — ethereum.org (accessed 2026-10-30) — https://ethereum.org/en/developers/docs/smart-contracts/verifying/
2. Exact, Similar, and Runtime matches check different things
Etherscan lists four states for a contract’s code. Unverified is the default. A Similar Match is applied automatically when the bytecode matches an already-verified contract, but it ignores the starting settings. Exact Match covers those settings too, and Runtime Match checks only the code stored at the address.
Literacy takeaway: Read the label next to the check mark, not just its color. Background: how to read a blockchain transaction.
Source: Types of Contract Verification — Etherscan Information Center (accessed 2026-10-30) — https://info.etherscan.com/types-of-contract-verification/
3. Comments can lie in a partial match
Comments and variable names don’t change compiled bytecode, so ethereum.org warns that someone could verify a contract using source with misleading comments or names. Full verification adds a check on the compiler’s metadata fingerprint to rule that out. The same page notes that partial matching is still more common.
Literacy takeaway: Judge a contract by what its functions do, not by what its comments say. Related: common crypto scams.
Source: Verifying smart contracts (full verification section) — ethereum.org (accessed 2026-10-30) — https://ethereum.org/en/developers/docs/smart-contracts/verifying/
4. A proxy keeps the address and can swap the code
Etherscan explains that a proxy contract forwards each call to a separate implementation contract, and that the implementation can be upgraded without changing the address people use. Its proxy tabs show the implementation it last detected, and the check has to be re-run after an upgrade.
Literacy takeaway: Same address, same badge, possibly different logic. See smart accounts and EIP-7702 for a related idea about delegated code.
Source: Proxy Contracts — Etherscan Information Center (accessed 2026-10-30) — https://info.etherscan.com/what-is-proxy-contract/
5. Timelocks give users time to react
ethereum.org’s upgrade guide describes timelocks as a forced delay between approving a change and running it. Users get a window to leave if they disagree with a new logic contract or fee. Without one, the guide says, users have to trust developers not to change things without notice.
Literacy takeaway: Who can upgrade, and how much warning you get, are questions a badge doesn’t answer. Related: what is a token approval?
Source: Upgrading smart contracts (timelocks) — ethereum.org (accessed 2026-10-30) — https://ethereum.org/en/developers/docs/smart-contracts/upgrading/
Educational content only — not investment advice. This digest paraphrases public educational pages for literacy. It does not recommend buying, selling, or holding any cryptocurrency or token, and it is not financial, tax, or legal advice.