Most Ethereum smart contracts cannot be changed once deployed, but many use a "proxy" design that lets their owners swap the logic behind the scenes. That upgrade power is useful for fixing bugs, and risky, because whoever controls it can also change the rules. This guide explains how upgrades work, the main patterns, and how to check a contract yourself.
Can a smart contract really be changed after launch?
By default, no: a deployed contract's code is fixed forever, and that permanence is a core feature of Ethereum. The bytecode you deploy is what runs, and nobody, not even the author, can edit it in place. This is what lets people trust a contract without trusting its creator, because the rules cannot quietly shift.
But "cannot edit the code" is not the same as "cannot upgrade the application." Developers found a clever way around the limit: instead of putting all the logic in one fixed contract, they split it in two. One contract, called the proxy, holds your funds and data and never changes its address. A second contract holds the logic, and the proxy forwards every request to it. To upgrade, the team deploys new logic and tells the proxy to point at it instead. Your address and balance stay put; the brain behind them gets replaced.
A useful picture is a shopfront with a fixed street address but interchangeable staff. Customers always come to the same door, and their accounts stay with the shop, but management can swap the team that actually serves them. The address, the proxy, is permanent; the staff, the logic, can be replaced. That single trick is what makes most "upgradeable" Ethereum apps possible, and it is why the question is not just whether code can change, but who is allowed to change it. The rest of this guide unpacks how that works and what it means for your risk.
How do proxy contracts make upgrades possible?
A proxy works by separating storage from logic, then forwarding calls from the storage contract to a swappable logic contract. The proxy keeps your balances and the contract's data, and it uses a special instruction to run the logic contract's code as if it were its own. Upgrading just means changing which logic address the proxy points to.
User / wallet Proxy contractpermanent address,holds your data Logic contractswappable code(upgrade = swap this) calls delegatecall To upgrade, the team points the proxy at new logic; your address and balance stay put.
The mechanism rests on one technical move worth naming simply. When you interact with the proxy, it uses a special instruction called delegatecall. That instruction borrows the logic contract's code but runs it inside the proxy's own storage, so the data never leaves the stable address (source: Ethereum.org upgrading smart contracts). Picture the proxy as a building that hires a blueprint from elsewhere: the work happens inside the building, using the building's own files, but the instructions come from a document that can be reissued. Swap the blueprint, and the same building behaves differently the next day.
This design is powerful but introduces a clear dependency: the upgrade itself is controlled by someone, usually an admin address. Whoever holds that admin key can point the proxy at new logic at will. In well-run projects, that key is not a single person but a multi-signature wallet, requiring several parties to agree, often combined with a timelock that delays any change so users can see it coming. From Blofin's operational perspective, when we assess a contract's risk, two questions matter as much as the code itself: is it upgradeable, and who holds the key that can upgrade it. A great contract with a single unknown upgrade key is still a trust risk.
What are the main proxy patterns?
The three main patterns are the transparent proxy, the UUPS proxy, and the diamond, which differ mainly in where the upgrade logic lives and how much they can hold. All achieve the same goal, a stable address with swappable logic, but they make different trade-offs in cost and complexity. You do not need to code them to recognize their names in an audit or explorer.
The table sums up the practical differences.
Pattern | Where upgrade logic sits | Best suited for |
|---|---|---|
Transparent proxy | In the proxy, with admin separated from users | Simple, widely used upgrades |
UUPS proxy | In the logic contract itself, making the proxy lighter | Cheaper deployment, slightly more care needed |
Diamond (EIP-2535) | Split across many logic contracts called facets | Large apps that exceed a single contract's size limit |
Each suits a different need. The transparent proxy is the long-standing, well-audited choice, keeping admin actions and normal user actions strictly separate so they cannot collide. The UUPS proxy moves the upgrade function into the logic contract. That makes the proxy cheaper to deploy, but it means a careless upgrade could accidentally remove the ability to upgrade again (source: OpenZeppelin proxy documentation). The diamond pattern is defined in a standard called EIP-2535. It lets one address route to many logic contracts, called facets. That is how very large applications get around Ethereum's limit on how big a single contract can be (source: EIP-2535 diamonds standard). For a user, the pattern matters less than the upgrade controls around it.
How can you tell if a contract is upgradeable?
You can usually tell from a block explorer like Etherscan, which flags proxy contracts and shows the logic contract behind them. When a contract is a recognized proxy, the explorer adds "Read as Proxy" and "Write as Proxy" tabs and links to the current implementation address. Seeing those is your first clue that the logic can change.
A short routine gets you most of the way. Open the contract on a block explorer and look at the Contract tab. If you see a proxy notice and an "implementation" address, the contract is upgradeable, and that implementation is the current logic the proxy points to. From there, the deeper questions are about control. Who is the admin that can trigger an upgrade? Is it a multi-signature wallet or a single address? And is there a timelock delaying changes? Some of this is visible on-chain, and reputable projects document it openly. If a project is vague about who can upgrade its contracts, treat that as a warning sign in itself.
What you find shapes how much you trust the contract. An upgradeable contract controlled by a well-known team through a multi-signature wallet with a timelock is a managed, reasonably transparent risk. An upgradeable contract whose admin is a single unknown address is a much sharper one. That party could change the rules or, in a worst case, route funds in ways you never agreed to. An immutable contract removes upgrade risk entirely, at the cost of never being fixable, a control trade-off that mirrors choices in how crypto wallets work. None of these is automatically right; the point is to know which one you are dealing with before you deposit.
Is upgradeability good or bad for you?
It is a genuine trade-off: upgradeability lets teams fix bugs and add features, but it also means someone can change the contract you trusted. Immutability is the opposite, safe from meddling but unable to be repaired. Neither is strictly better, and the right answer depends on the contract's purpose and who controls it.
The case for each side is real. Upgradeable contracts can patch a discovered vulnerability before it is exploited, adapt to new standards, and improve over time, which is why most large, actively developed protocols use them. The case against is equally concrete. The upgrade key is a single point of trust. If it is compromised or controlled by bad actors, the "fixable" contract can be changed against users, a risk closely related to the exploit patterns covered in the pillar's guide on smart contract security. This is the same control-versus-safety tension that runs through self-custody choices, which our guide on custodial versus self-custody wallets explores from the wallet angle.
Even an honest upgrade can go wrong, which is the risk beginners least expect. Because the proxy and its logic share one storage layout, a new logic contract that arranges its variables differently can scramble the existing data, a bug called a storage collision. A related trap, where a proxy's admin function accidentally shares an identifier with a logic function, is called a function-selector clash. Neither involves a malicious actor; both are why upgrades demand careful testing and why a standard called EIP-1967 fixes the exact storage slots a proxy uses, to keep them from colliding. A related quirk: upgradeable contracts cannot use a normal constructor, so they run a one-time "initializer" function just after deployment instead, and forgetting to lock it down has itself caused incidents.
The sensible reader's stance is to judge the controls, not the label. A timelock that delays upgrades gives you a window to exit if you dislike a change. A multi-signature admin spreads trust across several parties instead of one. Public, documented governance beats an unknown key every time. High yields on a freshly deployed, upgradeable contract with opaque control deserve real skepticism. Outsized returns often signal outsized risk, a link our overview of DeFi yield risks draws out. Upgradeability is not a red flag on its own; unaccountable upgrade power is.
Frequently asked questions
What does it mean for a contract to be immutable?
Immutable means the contract's code is fixed permanently once deployed and can never be edited by anyone, including its creator. This is Ethereum's default, and it is what lets people trust a contract's rules without trusting the team behind it. The downside is that bugs cannot be patched, so a flaw is permanent too. Immutability removes the risk of someone changing the rules on you, at the cost of the contract never being able to improve or be repaired.
Can an upgradeable contract steal my funds?
In the worst case, yes, if a malicious or compromised admin upgrades the logic to route funds improperly. This is the core risk of upgradeability: the party holding the upgrade key has real power over how the contract behaves. Good projects reduce this risk with multi-signature control and timelocks that delay and reveal changes. Before depositing into an upgradeable contract, it is worth knowing who controls upgrades and what safeguards limit them, because an unknown single key is a serious red flag.
What is a proxy contract in plain words?
A proxy is a contract that holds your funds and data at a permanent address while borrowing its actual logic from a second contract that can be swapped. You always interact with the proxy, but the behavior comes from the logic contract behind it. Upgrading means pointing the proxy at new logic, which changes how the application works without moving your balance. It is like a building with a fixed address that can hire a new operating manual whenever the owners choose.
What is a diamond contract?
A diamond is a proxy pattern, defined in the EIP-2535 standard, that routes a single address to many separate logic contracts called facets. It exists mainly to get around Ethereum's limit on how large one contract can be, letting big applications split their code into modular pieces under one address. For users, a diamond works like any other upgradeable contract: the same questions about who controls upgrades and what safeguards exist still apply, just across more moving parts.
How do I check upgradeability on a block explorer?
Open the contract on an explorer like Etherscan and look at the Contract tab. If the contract is a recognized proxy, the explorer flags it (source: Etherscan proxy contract reads). It shows a proxy notice, "Read as Proxy" and "Write as Proxy" options, and a link to the current implementation address. That tells you the logic can change. To judge the risk, look further into who the admin is, whether it is a multi-signature wallet, and whether a timelock applies, checking the project's documentation alongside the on-chain data.
Is an immutable contract always safer than an upgradeable one?
Not always, because each removes a different risk. An immutable contract cannot be changed against you, but it also cannot be fixed if a bug is found, so a flaw is permanent. An upgradeable contract can be patched, but only by trusting whoever holds the upgrade key. The safer choice depends on the situation: immutability suits simple, finished contracts, while upgradeability suits complex, evolving ones, provided its controls are transparent and well-distributed. Judge the specific design, not the category.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the Ethereum.org documentation on upgrading smart contracts, the OpenZeppelin proxy documentation, and the EIP-2535 diamonds standard. All facts independently verified against cited documentation current as of June 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Smart contracts carry technical risk, and upgradeable contracts add governance and key-control risk that can result in loss of funds. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making decisions.