What is upgradeable contract?

A deployed contract whose behavior can be changed after launch by whoever holds the upgrade key.

Contract code deployed to a chain is immutable, which is a security property until there is a bug in it. Upgradeability is the workaround: separate the address and the stored data from the logic, and let the logic be swapped. Most large protocols and most major stablecoins use it.

The point people miss is that upgradeability does not remove a trust question, it relocates it. You are no longer trusting audited code. You are trusting whoever can replace that code, on whatever notice they choose to give.

How it works

The dominant pattern is a proxy. Users interact with a proxy contract that holds the balances and the storage, and the proxy forwards every call to a separate implementation contract holding the logic. Upgrading means pointing the proxy at a new implementation address. Your balance never moves and the address you interact with never changes, because neither lives in the part being replaced.

Who may point it is set by the contract. In ascending order of restraint: a single externally owned account, which is one compromised key away from total loss; a multisig requiring several signers; a multisig behind a timelock, which publishes a pending change and enforces a delay before it can take effect; and governance by token vote, which adds a public process.

The timelock is the feature that matters most to a user, because it is the only one that gives you time to withdraw before a change lands. A protocol with a 48-hour timelock is making a different promise from one that can be rewritten in a single block.

All of this is publicly readable. The proxy's admin address, the current implementation, and any timelock delay are on chain, and reputable projects state them in their own documentation.

Example

Illustrative. You deposit stablecoins into a lending market at a proxy address. The proxy holds your balance. The implementation contract holds the logic that decides who may withdraw it.

The team pushes an upgrade. With a timelock, the queued change appears on chain, a delay of some hours or days runs, anyone watching can read the new code, and you can withdraw first if you dislike it. Without one, the implementation address changes in a single transaction and the rules governing your deposit are different in the next block. In both cases a previous audit described code that is no longer running.

Why it matters when you buy

This is a self-custody and decentralized finance concern rather than an exchange one, and it also applies to the stablecoins you may hold on an exchange, several of which are upgradeable and include freeze functions. Before depositing into any protocol, find the admin address, the timelock, and the upgrade history. The guide on verifying a token contract covers how to read these on an explorer.

Related terms

• proxy contract: the mechanism behind most upgrades
• multisig: shared control of the upgrade key
• smart contract audit: what an upgrade can invalidate
• governance token: voting control over changes
• counterparty risk: what the keyholder represents
• smart contract: the immutable default this departs from

Questions

How do I tell whether a contract is upgradeable?

Block explorers flag proxy contracts and link the current implementation. Seeing a proxy pattern, an admin address, and an upgrade history in the transaction log is the practical check.

Is upgradeability always bad?

No. Immutable code with a bug cannot be fixed, and several large losses would have been preventable with an upgrade path. The question is who holds the power and what constraints sit on its use.

Can an upgrade take my tokens?

In principle yes, if the upgrade key is unconstrained, because the new logic governs the same stored balances. That is why timelocks and multisig control are the features to look for rather than nice-to-haves.