The phrase "code is law" entered the crypto vocabulary early and stuck — implying that once a smart contract is deployed, it's permanent, neutral, and beyond anyone's control. This framing helped establish trust in early DeFi protocols. It also created a widely held misunderstanding about how most smart contracts actually work in 2026.
The answer to whether a smart contract can be changed is: it depends on how it was written. Many — perhaps most — deployed contracts in active use today are explicitly designed to be upgradeable. The immutability assumption isn't the default; it's an explicit design choice that some protocols make and others don't.
How Smart Contract Immutability Actually Works
When a contract is deployed on a blockchain like Ethereum, its bytecode — the compiled instructions the EVM (Ethereum Virtual Machine) executes — is written to a permanent address on the chain. That specific bytecode, at that specific address, cannot be altered. This is the source of the "immutable" claim, and it's technically accurate for what it describes.
But it doesn't describe how most complex protocols are structured.
The dominant pattern in deployed DeFi and application-layer contracts is the proxy pattern. Instead of interacting directly with a contract containing the full application logic, users interact with a thin "proxy" contract. The proxy stores no logic itself — it stores the address of a separate "implementation" contract and forwards all calls to it. The implementation contract contains the actual code.
If a protocol team (or its governance system) wants to change how the contract behaves, they don't modify existing bytecode — which they can't. They deploy a new implementation contract with different logic and update the proxy to point to the new address. From the user's perspective, the contract address they're interacting with is unchanged. From a technical standpoint, the code being executed is different.
This is the mechanism behind OpenZeppelin's widely used proxy implementations: the Transparent Proxy and the UUPS (Universal Upgradeable Proxy Standard). A third variant, the Diamond pattern (EIP-2535), allows more granular upgrades by routing different function calls to different implementation contracts.
What "Upgrade" Actually Requires
The ability to upgrade doesn't mean anyone can do it at any time. Upgrade authority is controlled by whoever holds the admin key — and the nature of that key matters considerably.
In early DeFi deployments, admin keys were often held by a small number of team members, sometimes a single Ethereum address. This meant a protocol could be technically decentralized at the execution layer while being entirely centralized at the governance layer. A compromised key or a rogue team member could change the contract's behavior entirely.
The industry has moved, unevenly, toward better models:
- Timelocks: A timelock contract introduces a mandatory delay between a proposed upgrade and its execution — typically 24 hours to a week. This gives users time to exit before a change takes effect, and makes the governance process observable.
- Multisig control: Instead of a single admin key, upgrade authority is held by a group — often a 3-of-5 or 4-of-7 Gnosis Safe multisig. Multiple independent parties must sign before an upgrade can proceed.
- DAO governance: Some protocols have passed full upgrade authority to on-chain governance. MakerDAO, Compound, and Uniswap governance allow token holders to vote on protocol changes, including contract upgrades.
None of these fully eliminates trust requirements; they distribute or delay them. A DAO vote can still pass a malicious upgrade if governance is manipulated. A multisig can collude. Timelocks only protect users who are actively monitoring. The architecture improves the threat model — it doesn't eliminate it.
The Immutable Exception
Some protocols have made a deliberate choice in the other direction: no admin key, no upgrades, full immutability.
Uniswap v1 and v2 core contracts are the canonical examples. No upgrade mechanism, no admin key. If there's a bug, the only recourse is deploying new contracts and migrating users. This creates a credibility guarantee — no one can rug the protocol through a code change — but it also means a critical vulnerability can't be patched without a full migration.
Uniswap v3 introduced some admin controls, including fee configuration, which led to legitimate debate about what "decentralized" means in that context. There's no clean resolution; it's a genuine trade-off between flexibility and trustlessness.
The SELFDESTRUCT opcode historically offered another mechanism: a contract could be programmed to delete itself. Ethereum's Cancun upgrade (EIP-6780, shipped March 2024) heavily restricted this — SELFDESTRUCT now only works within the same transaction the contract was created in, effectively making it a no-op for most existing contracts. This removed a longstanding attack vector.
Where the Trust Actually Lives
The practical implication is this: "has this contract been audited?" is necessary but not sufficient. The more complete question is: who controls the upgrade keys?
A well-audited implementation contract sitting behind an upgradeable proxy controlled by a 2-of-3 multisig of anonymous signers isn't the same security proposition as a fully immutable contract. The audit covers the current code. The multisig determines whether the current code stays current.
This is why DeFi risk assessments increasingly focus on governance surfaces alongside code correctness. Protocols like Aave and Compound publish their governance architecture — timelock durations, voting thresholds, guardian multisig configurations — as part of their security documentation. That transparency is meaningful; the absence of it is also a signal.
What's Changing
The trajectory is toward more robust governance rather than back to simple immutability. Timelock minimums have generally lengthened as protocols matured. Multisig configurations have grown in size and signer independence. DAO governance participation remains low in absolute terms, but the on-chain infrastructure has improved.
The more structurally interesting development is progressive decentralization — protocols launching with significant admin control (for iteration speed and bug response) and explicitly committing to relinquishing it over time. Whether these commitments are honored varies enormously by team.
Confirmation signals: longer timelocks, admin key sunset announcements with public timelines, governance contract audits from independent parties. Invalidation: persistent admin multisigs with no disclosed sunset path, governance capture by concentrated token holders, upgrade frequency inconsistent with claimed decentralization.
Timing
Now — when using a protocol, checking the upgrade mechanism is reasonable due diligence, not paranoia. This information is typically on-chain and surfaced by tools like DefiLlama's protocol pages and individual protocol documentation.
Next — progressive decentralization commitments from major protocols will either be honored or not over the next 12–24 months. The ones that follow through will be distinguishable from the ones that don't.
Later — whether full immutability or governed upgradeability becomes the dominant model in mature DeFi remains genuinely open. The case for immutability is strongest in commodity infrastructure (AMM primitives, lending base layers); the case for upgradeability is strongest in complex, evolving applications.
Boundary
This covers the mechanism behind smart contract upgradeability and the governance structures that control it. It doesn't identify which protocols are safe or unsafe, nor does it constitute advice on using any of them. The architecture described here is publicly documented and observable on-chain — the conclusions you draw from it depend on your own assessment of the governance participants involved.
The audit tells you about the code. The admin key tells you about the team.
