Where Did Immutable Smart Contracts Go?

When DeFi was first gaining momentum, one of its strongest selling points was immutability. Advocates would contrast smart contracts with centralized services like exchanges or casinos.

The narrative was simple and compelling.

• Centralized exchanges, casinos, payment processors and similar services require trust in their owners. The owner can freeze your account, change fees, run off with your cryptocurrency, or hand it over to the government at the first request.
• DeFi, by contrast, was supposed to require trust only in the reliability of smart contract code. A smart contract was presented as a vending machine encased in the concrete of the blockchain. Its rules were known in advance, and no one - not the developer, not the police, not a court - could change them after launch.

A few years have passed. Today, this narrative is effectively dead, even though it is rarely acknowledged out loud. The overwhelming majority of modern DeFi protocols (Aave, Compound, Uniswap V3, Sky Protocol, various bridges and L2 solutions) are, from a technical standpoint, upgradeable. Their administrators hold keys that turn a smart contract into something closer to a regular web server, where the backend can be updated at any moment.

How did this quiet revolution happen? How exactly did developers learn to bypass blockchain immutability? And is there still anything truly immutable left in what we continue to call "decentralized finance"?

Anatomy of Control: How Proxy Contracts Work

Many readers may object at this point: “Wait a second. DeFi ideology emerged within Ethereum. And after the controversial The DAO episode, no one would dare to rewrite anything on that blockchain ever again. So the code of any smart contract must remain immutable after deployment.”

That is true. Not only Ethereum, but any blockchain is an append-only database. No one can erase a contract once it has been written to the chain.

However, developers found an elegant workaround that eventually became an industry standard: the Proxy Pattern.

Imagine that an application consists not of a single contract, but of two.

• The Proxy is the external interface. It has a fixed on-chain address that users interact with, and this is where all tokens and balance records are stored. But this contract is deliberately shallow: it contains no core financial logic.
• The Implementation is the internal mechanism. This is where the formulas live: how interest is calculated, how tokens are swapped, who is allowed to withdraw how much. But this contract holds no cryptocurrency itself.

When you deposit or withdraw tokens, you interact with the Proxy. The Proxy uses a low-level instruction called delegatecall to read the Implementation contract and execute its code in the context of the Proxy’s own storage.

Inside the Proxy contract, there is a variable (often exposed via an internal _implementation function) that stores the address of the current Implementation. There is also a special function, accessible only to the administrator: upgradeTo(newAddress).

At any moment, the Proxy administrator can:

• deploy a new Implementation contract to the blockchain (for example, with a new feature or a bug fix);
• call upgradeTo on the Proxy and point it to the new Implementation address.

After that, the Proxy immediately starts using the new logic.

From the user’s perspective, nothing has changed. The contract address is the same, and their cryptocurrency is still stored there. In reality, however, the rules of the system may have changed completely.

If the administrator deploys a malicious Implementation (for example, one that allows the admin to withdraw all funds), the Proxy will obediently hand over all cryptocurrency - because it blindly executes whatever code it is told to use.

Why Did We Agree to This?

The shift from immutability to upgradability wasn’t born of malice - it was driven by necessity.

First, let’s recall the story of The DAO. A vulnerability in its smart contract allowed a hacker to drain a huge amount of funds. To reverse this, Ethereum node operators made a move that was heresy to crypto purists: they rewrote the blockchain history to undo the hacker’s transaction. The whole episode made one thing clear - immutable code means immutable bugs. If a contract has a flaw, it can’t be patched. That leaves only two options: centralized control over the whole network (as happened with Ethereum at that moment), or centralized control over individual contracts. Over time, the industry settled on what seemed the lesser evil: allowing centralized control at the contract level while preserving the appearance of decentralization at the ecosystem level.

Second, many DeFi projects are effectively startups. They need to evolve - add new strategies, support new tokens, fix edge cases. Without proxy contracts, every update would force users to withdraw funds from an old contract and deposit them into a new one. That’s clunky, expensive, and bad for adoption.

Third, regulators entered the chat. DeFi depends heavily on stablecoins, and regulators insist these must include features like address blacklisting and upgradable logic to comply with financial rules. Even MakerDAO - the issuer of DAI, once the poster child for decentralized stablecoins - had to bow to pressure. When it rebranded under the Sky Protocol, it added admin-controlled features to its new stablecoin, USDS.

And users? They voted with their wallets. High yields (APY) and slick interfaces matter more to most people than abstract ideals like decentralization.

The Decentralization Illusion: Who Holds the “Red Button”?

Many projects claim to be decentralized simply because their admin key isn’t controlled by a single individual. But does that really change anything?

When the upgrade key is held by a single developer, that’s clearly the riskiest scenario. If that person gets hacked or pressured (physically or legally), user funds could be gone in an instant. And yet this setup is still common - especially in meme coin contracts, which are often treated as unserious.

Sometimes the key is split into multiple parts - say, five people (often founders and early investors) each hold one, and three signatures are required to make changes. But this is still centralized. Collusion is possible. So is state intervention.

A slightly safer option is the Timelock mechanism. Here, an admin can schedule an upgrade, but it only takes effect after 24 - 48 hours. This gives users time to review the new code and withdraw their funds if the change is malicious. But in reality, no one monitors smart contracts 24/7. And in emergencies (like an active exploit), 24 - 48 hours is plenty of time for an attacker to drain everything.

The lesser evil is DAO-based governance. In protocols like Compound and Uniswap, upgrade authority is handled by smart contracts tied to token-holder voting. Changes only happen if enough votes are cast in favor. In theory, this is a step toward true decentralization. But in practice, large VC funds (like a16z or Polychain) hold so many governance tokens that they can push through almost any decision. Moreover, voter turnout is often minimal, making the process easy to control.

Islands of Immutability: Who Still Stays Unchanged?

Are there still DeFi services where “code is law”? Yes - but they now occupy a very narrow niche in the ecosystem. These are rare examples of truly immutable smart contracts.

Uniswap V1 / V2
The liquidity pools in these versions are completely immutable. Neither developers, investors, nor even governments can withdraw funds, alter formulas, or change the rules. The smart contracts are set in stone - no admin key, no upgrade path.

Liquity USD (LUSD)
The LUSD contract has no admin keys and no upgrade function. The system parameters were mathematically hardcoded at launch and can never be changed. That makes it one of the most resilient stablecoins in DeFi. It's not widely used - perhaps because people assume it lacks liquidity. But that’s a misconception:

• On the protocol level, every LUSD can always be redeemed for the ETH that backs it.
• On rabbit.io, LUSD can be exchanged for any crypto with no limits or restrictions.

Tornado Cash V1 / V2
Early versions of Tornado Cash contracts initially had admin keys - necessary for patching bugs in the live environment. But once the protocol proved stable, control was renounced: the admin key was given to the 0x00...0000 address, making the contracts fully immutable.

This decision highlighted a fundamental truth about immutability: it protects against governance attacks.

Take Tornado Cash V3 as a cautionary tale. This version introduced improvements: flexible deposit sizes (not just 0.1, 1, 10, or 100 ETH) and an L2-based private transfer system via Gnosis Chain. To enable upgrades and security patches for such a complex protocol, governance was handed over to a DAO - specifically, holders of the TORN token.

In 2023, an attacker proposed a seemingly harmless governance update. Hidden in the code was a backdoor. Once passed, it gave the attacker full control over the DAO. They hijacked the contract logic and stole a portion of the governance tokens.

Such an attack would have been physically impossible in the immutable versions. There were no upgrade paths. No votes. No red buttons.

Beyond Ethereum: How Other Ecosystems Handle Contract Upgrades

Proxy contracts have become the de facto standard across EVM-compatible blockchains. But what about non-EVM ecosystems?

Solana
In many cases, immutability is even weaker than in Ethereum. By default, Solana smart contracts can be upgraded using an Upgrade Authority. Developers can relinquish this power to make a program immutable, but in Solana’s fast-moving, innovation-first culture, doing so is rare. A similar situation exists in Near Protocol, where upgradability is also the norm.

Polkadot and Cosmos
These ecosystems follow a different approach: updates happen not through admin functions inside contracts, but via governance at the validator level. When you deposit funds into a smart contract in these networks, you're not trusting a contract admin - you're trusting the validators of the entire chain to act honestly.

Cardano
Cardano supports several types of smart contracts, but the primary one is Plutus scripts, which are built around a strict immutability model.

• A Plutus script is tied to a specific UTXO and its code is hashed into the address itself.
• Once deployed, the code cannot be changed - period.
• If developers need to fix a bug or change the business logic, they must deploy a new script with a different hash and migrate funds manually.
• Because of this architecture, proxy patterns are impossible.

Technically, Cardano also supports off-chain logic contracts, which could be used to build upgradeable systems with admin control. But in practice, such designs are rare - unlike in EVM chains.

Bitcoin Ecosystem
Yes, Bitcoin has smart contract protocols too.

• RGB
  Here, both the smart contract and the token state are stored locally on users’ devices rather than on-chain. There’s no centralized contract that can be upgraded by an admin. If a token issuer releases new rules, users must opt in to the update - just like upgrading an app on your device. There's no way to force changes on all users simultaneously.
• Stacks
  All smart contracts in Stacks become immutable once deployed. Updates can only be introduced through a modular architecture: new functionality is added via separate contracts that interact with the original contract, but they cannot override or alter the existing rules. In other words, any update is an addition, not a modification. The original logic remains intact and enforceable, and no part of the deployed contract can be changed retroactively.
• Elastos and Rootstock
  These are EVM-compatible sidechains, meaning they follow the same upgrade patterns as Ethereum. Developers can implement proxy contracts and retain admin control, just like in any EVM chain.

Thus, even in the Bitcoin community - which has traditionally valued immutability over flexibility - there are now smart contract protocols that allow service operators to modify the rules after accepting users’ funds.

Conclusion

It seems that the term “decentralized application” is often little more than a marketing trick. That’s not necessarily a bad thing: the ability to update smart contracts has saved billions of dollars when vulnerabilities were discovered. But users must understand the risks:

• In a traditional centralized service, you can lose your crypto simply because you don’t hold the keys to your wallet.
• In modern DeFi, you can lose your crypto simply because the admin can change the lock (the rules of the smart contract).

True immutability remains the domain of conservative protocols like Tornado Cash Classic, Liquity, and native solutions in Cardano or on top of Bitcoin, which sacrifice flexibility for the sake of security. Everything else ultimately comes down to trust - in teams hiding behind the shiny label of a “DAO”.