How to tell whether a team can still change the contract

The question under the question

“Can the team change the contract?” is really three questions, and mixing them is why the answers people get are confusing.

• Can the code itself be replaced? That is upgradeability, and it is the largest lever.
• Can a value inside the code be changed without replacing it? Fee rates, limits, addresses, whether transfers are paused.
• Who is allowed to pull either lever, and does anything slow them down? A single key, a multisig, a vote, a delay.

A contract can be immutable and still let one address drain the reserve, if the code says so. A contract can be upgradeable and safe in practice, if the upgrade takes a week and a vote. The word alone tells you nothing.

Check one: is the source published and does it match?

On the block explorer, an unverified contract shows bytecode and nothing else. Verified means someone uploaded source that compiles to exactly that bytecode. If the source is not verified, stop: you cannot check anything else, and you are being asked to trust a screenshot.

Verified source is necessary and not sufficient. What is published might be honest and still give the deployer powers you would not accept.

Check two: is it a proxy?

A proxy holds your funds and forwards every call to a second contract that holds the logic. Change the second address and the behaviour changes completely while the address you interacted with stays the same. Most upgrades work this way, and most rug pulls that survive an audit work this way too.

• Explorers usually label it: a “Read as Proxy” tab, or a note that the address is a proxy.
• In the source, look for a function that sets an implementation address — the name varies, the shape does not.
• If it is a proxy, the only question that matters is who can call that function, and how fast it takes effect.

Check three: what does an owner do?

Read the source for the functions guarded by an owner or an admin role, and read them as a list of things that can happen to you without your consent. The names differ between projects; the shapes are the same everywhere:

• Minting. Can new units be created outside the published rule? A supply cap in a document is not a cap; a cap in code is.
• Withdrawal. Is there a path by which collateral leaves without a user asking for it?
• Pausing. Can transfers or redemptions be stopped? Who restarts them?
• Fees. Is there an upper bound in the code, or can the rate be set to anything?
• Allow-lists. Can an address be blocked from selling? This is how a token becomes a one-way door.

For each one, the useful follow-up is not “would they?” but “what stops them?” The answer is a rule in the code or it is nothing.

Check four: who holds the key, and what slows it down

A single externally owned account means one person, one phishing email, one compelled signature. A multisig is better and the numbers matter: three of five is a committee, one of three is a single point wearing a costume. A timelock does not prevent an action; it gives you notice, which is the whole point — you can leave before it takes effect.

Governance by token vote moves the question again: now it is who holds the tokens. If a handful of addresses can pass anything, the vote is a formality with extra steps.

What an audit does and does not settle

An audit checks whether the code does what its authors intended, and whether it can be broken by an attacker. It does not tell you whether the intended design is one you want. A contract can pass an audit cleanly and still contain an owner function that empties the reserve, because that function was intentional and disclosed. Read the report for scope: what was reviewed, at which commit, and what was excluded.

The order that saves time

• Source verified? If no, stop.
• Proxy? If yes, find who can swap the implementation and how fast.
• Owner functions: mint, withdraw, pause, fee, block. Note each one.
• Key holder: single key, multisig with real numbers, or a vote.
• Delay: is there a timelock, and is it long enough to act on?
• Only then read the audit, and read its scope before its conclusion.