Contract upgrades: map who can change the rules
Contract upgrade research asks who can change the code or parameters that determine an asset’s behavior. Reading the visible token interface is only the beginning. Trace the proxy, implementation, administrator, authorization path, and any delay or emergency power before describing a deployment as immutable or decentralized.
OpenZeppelin’s proxy reference describes several upgrade-related components and patterns. These are possible building blocks. Their documentation does not prove a specific project uses a particular pattern or has configured authorization safely.
Map the authority chain
Identify the actual deployment address and determine whether a proxy relationship exists using appropriate deployment records and state. If so, record the implementation associated with the observation block. The code currently displayed for an implementation is not automatically the code that governed an earlier transaction.
Next trace authorization. An administrator may be another contract, a multisignature account, or a governance process. Follow that relationship until the controlling conditions are understandable. A label saying governed is insufficient if a separate emergency key can bypass the ordinary process.
| Map node | Evidence to retain |
|---|---|
| User-facing deployment | Address, network, and observed block |
| Implementation | Code identity and version relationship |
| Upgrade authority | Role or account that authorizes change |
| Control of authority | Signers, threshold, governance, or other rule |
| Delay and exceptions | Normal waiting rule and bypass powers |
| Historical change | Transaction, prior state, and resulting state |
Distinguish code upgrades from parameter administration. Even a deployment with fixed code may expose mutable permissions or settings. Conversely, an upgrade mechanism may exist while the effective authority has been constrained in a documented way.
Hypothetical timelock with emergency authority
Assume a fictional protocol advertises a two-day upgrade delay. Its ordinary upgrade path indeed passes through a timelock. However, a separate role can immediately change a parameter affecting transfers. A research note that says every rule change requires two days would exceed the evidence.
The accurate control map shows the delayed code-upgrade path and the immediate parameter path separately. If the emergency role’s controller cannot be verified, mark that controller unknown. Do not assign it to a named team because a forum comment speculates about ownership.
Now suppose an implementation changes after the research cutoff. Preserve the original version in the historical note and open a review task for the new one. All entities and timing in this example are hypothetical; the example does not describe any real protocol’s controls.
Compare claims with deployed permissions
Collect the project’s own descriptions of immutability, governance, or administrative control. Translate each into a checkable question: which function, which authority, which delay, and which exception? A broad slogan is difficult to verify, while a specific permission claim can be compared with code and state.
Inspect recent upgrade or role-change events as leads, then confirm the resulting state. An event log helps locate a change but should not replace checking the authority currently relevant to the question. Record whether the observation relies on verified source code, bytecode analysis, official deployment information, or an unverified third-party summary.
A public research review may stop before a full code audit. State that scope clearly. Mapping who can change a rule is useful even when the researcher cannot establish every possible consequence of the rule’s implementation. Do not imply a control map guarantees secure code.
Limits and common mistakes
Unknown controllers, complex delegation, undisclosed operational procedures, and cross-network dependencies can leave parts of the map unresolved. Present a partial graph with unknown nodes rather than converting missing evidence into a claim that no authority exists.
Common mistakes include reading only the implementation, equating a multisignature label with a verified signer policy, treating a delay as universal, and assuming fixed code means fixed economic behavior. The method supports a dated description of control dependencies. It does not predict whether authorized parties will act, or establish an expected return for the spot asset.
FAQ
Does verified source code prove the deployment cannot change?
No. Verification and upgrade authority answer different questions. Inspect the deployment relationships and relevant permissions.
Is a timelock sufficient evidence that every action is delayed?
No. Examine which actions enter the timelock and whether separate roles or emergency paths can act under other conditions.