An upgradeable smart contract is a contract whose logic can be replaced after deployment while its address, balances, and stored data stay the same. On Ethereum and similar chains, deployed code cannot be edited, so upgradeability comes from a design pattern: users interact with one contract that forwards calls to a separate logic contract, and an authorized key can point it at new logic. For a token issuer, the key question is who holds that upgrade authority.
Last updated: November 9, 2026.
How does an upgrade work if code cannot change?
The most common design is the proxy pattern. The proxy contract is the address users interact with, and it holds all of the token's storage, such as balances and allowances. It does not contain the business logic. Instead, it delegates each call to an implementation contract that holds the logic.
To upgrade, the authorized account deploys a new implementation contract and tells the proxy to use it. Holders keep the same token address and balances, but the rules that run on their next transaction come from the new code. ethereum.org describes this pattern and several alternatives.
Who controls the upgrade?
The contract records an admin or owner, either in the proxy or in the logic it runs, and only that account can change the implementation. In practice, it can be:
| Upgrade authority | How an upgrade is approved | What holders can rely on |
|---|---|---|
| Single key | One signature | The key holder's own controls |
| Multisig wallet | A set number of signers out of a larger group | No single signer can upgrade alone |
| Timelock | A delay between proposing and applying a change | Time to review a pending change before it runs |
| Governance vote | Token holders or a council approve the change | The governance process and its rules |
| None | The contract cannot be upgraded | The deployed code is final |
These options can be combined. A multisig can propose an upgrade that only takes effect after a timelock.
Why does upgrade authority matter to an issuer?
The upgrade authority can change every rule of the token, including minting, transfers, and restrictions. For an asset issuer, holding that authority directly means the issuer decides when the contract changes. When a service provider deploys or operates the token, the contracts record which party holds the upgrade authority and who must approve a change.
The same question applies on every network where the token is deployed. Each deployment has its own contracts, and each can have its own upgrade authority. The overview of cross-chain token standards explains how one token can span several deployments.
Questions we get asked
Is an upgradeable contract less secure than an immutable one?
It carries a different risk. An immutable contract cannot fix a bug after deployment. An upgradeable contract can, but holders have to trust whoever controls the upgrade.
Can an upgradeable contract be made immutable later?
Often, yes. The admin can renounce the upgrade role or upgrade to logic that has no upgrade function. After that, the current implementation cannot be replaced.
Does an upgrade change the token's address?
Not with a proxy. Holders and applications keep using the proxy's address, and only the implementation behind it changes.
Plan who controls the token
To discuss how an asset's contracts and permissions are set up across chains, request a custom briefing.