Deployed contracts are immutable, and almost every substantial protocol has a mechanism to change behaviour anyway, which is where the real trust assumption sits.
The proxy pattern
A contract holding state delegates execution to a separate implementation contract.
Which allows the implementation to be replaced while addresses and balances persist.
Users interact with the proxy and are generally unaware of the implementation behind it.
Storage layout
The proxy holds state according to a layout the implementation expects.
Which means a new implementation with a different layout corrupts existing state.
This is a documented cause of serious incidents and is why storage gaps and structured layouts are used.
Initialisation
Proxied contracts cannot use constructors and instead use initialiser functions.
Which must be protected against being called again.
Unprotected initialisers have allowed attackers to take ownership of contracts, more than once.
Who can upgrade
An administrative address, generally a multisignature wallet or a governance contract.
Which is the actual answer to how much trust a protocol requires.
Public trackers document these arrangements per protocol, and they vary enormously.
Timelocks
A delay between an upgrade being scheduled and executed.
Which allows users to exit if they disagree.
The delay length determines how much protection this actually provides, and short delays offer little.
Emergency mechanisms
Most protocols retain a faster path for security incidents.
Which is genuinely necessary and is also a bypass of the protection timelocks provide.
Whether the emergency path can do everything or only pause is the meaningful distinction.
Immutable deployments
Some protocols deliberately deploy without upgrade capability.
Which removes the trust assumption entirely and removes the ability to fix bugs.
New versions are deployed as separate contracts requiring users to migrate voluntarily.
Verifying for yourself
The proxy's admin address is readable on chain, as is the current implementation.
Which means the trust assumption is checkable in a few minutes rather than taken on faith.
Diamond and modular patterns
Architectures splitting functionality across multiple contracts with a routing layer.
Which allows partial upgrades and increases complexity considerably.
Auditing these architectures is harder, and the added surface has produced its own incidents.
Governance-controlled upgrades
Where token holders vote on implementation changes.
Which distributes the authority and introduces governance attack risk.
The combination of governance control and a short timelock is a specific and dangerous configuration.
Verification after upgrade
Confirming the new implementation matches audited source.
Which is checkable on chain and is rarely checked by users.
Monitoring services alert on implementation changes for major protocols.
Migration approaches
Deploying a new version and asking users to move rather than upgrading in place.
Which preserves immutability and produces liquidity fragmentation during transition.
Incentives to migrate are commonly used to accelerate it.
Assessing a protocol
Read the admin address, the timelock duration and the emergency powers before depositing anything substantial.
Multisignature configuration
The number of signers, the threshold and who they are.
Which is publicly readable and varies from two-of-three to substantially larger arrangements.
Low thresholds among closely associated individuals provide limited assurance.
Signer key security
Each signer's key management practice affects the whole arrangement.
Which has been the failure point in documented incidents where signers were individually compromised.
Hardware wallets and distributed geography are standard mitigations.
Renouncing ownership
Permanently removing the admin capability.
Which is checkable and is done by some protocols after a stabilisation period.
It is irreversible, which is the point and also the risk.
Monitoring services
Tools alerting on admin transactions and implementation changes.
Which allow users to react within the timelock window.
These are free and are used by very few individual users.
Reading the risk
An upgradeable contract with a short timelock and a small multisignature is a trusted arrangement, whatever the surrounding language says.
Why this is the key question
Audits assess the current code, and upgrade authority determines what the code can become.
Which makes the admin arrangement more consequential than any individual finding in an audit report.
It takes minutes to check and is checked by very few people.
A short checklist
Is the contract upgradeable, who holds the admin key, how many signers, what is the timelock, and what can the emergency path do.
Five questions, all answerable from public data in under ten minutes.
Why protocols keep upgrade authority
Bugs happen, dependencies change and parameters need adjustment.
Which is a legitimate reason rather than an excuse.
The question is not whether the capability exists but how it is constrained.
A closing observation
A great deal of discussion about protocol trust could be settled by reading two on-chain values: who the admin is and how long the timelock runs. The answers are frequently less reassuring than the documentation surrounding them.
Tools available
Public risk trackers document these arrangements for major protocols and are updated as configurations change.
Which removes the excuse of it being hard to find out.