Upgradeable Contracts
Definition
An upgradeable contract is a smart contract whose logic can be replaced after deployment while keeping its address and stored data. The usual design splits the token into a proxy, which holds the balances and is the address holders and applications use, and an implementation contract, which holds the code; the proxy forwards every call to the implementation. Whoever holds the upgrade authority can point the proxy to a new implementation, changing how the token behaves for everyone at once. Standards such as EIP-1967 fix where proxies store the implementation address, and common patterns include transparent proxies, universal upgradeable proxies and beacon proxies. Issuers of tokenized securities use upgradeability to fix bugs, adapt to new rules and add features without migrating holders to a new token. The cost is that the token's rules, including transfer restrictions, fees in code and even balance accounting, are only as fixed as the upgrade authority allows.
Why it matters
Upgradeability is the most powerful administrator right in a token, because it can change every other rule, including who holds the other rights. It is also close to universal in tokenized securities, for good operational reasons. The result is that the code reviewed in an audit, and the restrictions described on a product page, describe the token as it is today, not as it must be tomorrow. Investors do not need to avoid upgradeable tokens; they need to know who can upgrade, how many approvals that takes, whether there is a delay and notice, and whether new code is reviewed before it goes live. An upgrade path controlled by a single key with no delay is a materially different risk from one controlled by a multisignature with a public timelock.
Common misconceptions
- •Immutable is not always safer for securities. A token that cannot be changed cannot be fixed or brought into compliance.
- •The proxy address does not change, so holders may not notice an upgrade. Check the implementation history.
- •An audit of the old code says nothing about the new code. Each implementation needs its own review.
- •Upgrades are not limited to new features. They can change balances, restrictions and roles.
- •Documents limit upgrades legally, not technically. Controls on the key are what stop an improper upgrade from executing.
Technical details
How a proxy upgrade works
Proxy: holds the storage (balances, roles, allowlist) and the public address; forwards calls to the implementation using delegatecall.
Implementation: the code; it runs against the proxy's storage.
Upgrade: the upgrade authority stores a new implementation address in the proxy (EIP-1967 defines the storage slot); the next call runs the new code.
Patterns: transparent proxy (admin calls handled separately), UUPS (upgrade logic in the implementation), beacon (many proxies follow one beacon).
What an upgrade can change
Transfer rules and compliance checks.
Roles and permissions, including adding new administrator powers.
Accounting of balances and supply, if the new code chooses to.
Integrations: oracles, bridges and redemption contracts the token calls.
Storage layout errors in an upgrade can corrupt data, a known source of incidents.
Controls to look for
Upgrade authority held by a multisignature with independent signers, separate from day-to-day agent keys.
A timelock with a public queue of pending upgrades.
Advance notice to holders with the new code and its audit.
A published upgrade history, matching the block explorer's record.
Documented limits in the offering terms on what upgrades may do to holders' rights.
How investors apply the term
Investors usually apply this term by tying the definition back to the controlling documents and then asking which cash flows, rights, restrictions, or valuation assumptions it changes. A useful review looks at the term alongside fees, leverage, liquidity, reporting frequency, and manager discretion rather than treating it as a standalone concept.
The practical diligence test is simple: identify who benefits if the assumption is wrong, who has control when conditions change, and what evidence the investor receives after closing. Terms that cannot be reconciled to documents, cash movements, and monitoring data should be treated as marketing shorthand until proven otherwise.
Frequently asked questions
- Can a token's rules change after issuance?
- If the contract is upgradeable, yes. The holder of the upgrade authority can replace the code, and the new code applies to every holder immediately unless a timelock delays it. Superstate's documentation, for example, states that its smart contracts are upgradeable. The offering documents and the law limit what the issuer may change; the code itself does not.
- Why do issuers make tokens upgradeable?
- To fix vulnerabilities, comply with new regulations or exchange requirements, support new chains or features, and correct errors, without asking every holder to move to a new token. For a regulated security with a transfer agent, the ability to change the code is often treated as a necessity.
- What controls should apply to upgrades?
- Multisignature approval by independent signers, a timelock that delays execution so holders can see the change before it takes effect, public notice with the new code, an audit of each new implementation before deployment, and a published history of upgrades.
- How can I check whether a token is upgradeable?
- On a block explorer, a proxy contract is usually labeled as such and shows its current implementation address and history; the issuer's documentation and audits should also say. Then find who holds the upgrade role and whether a timelock applies.