Is a contract really immutable?
Almost every project says its contract cannot be changed. The claim is unusually easy to verify, which is why it is worth verifying rather than believing. It takes a few minutes and needs no special tools.
What the word has to mean
Immutable means one thing: the code executing at an address today is the code that will execute there tomorrow, and nobody can replace it. Not the team, not a vote, not a guardian, not an emergency. If any path exists by which the executing code changes, the contract is upgradeable — which is a legitimate design choice, but a different one, and it should be described in those words.
The question is never “can they change it” in the abstract. It is: what specific mechanism would they use, and does that mechanism exist at this address?
The four places the claim usually fails
- A proxy. The address you interact with holds no logic; it forwards every call to another address it stores. Change the stored address and the behaviour changes completely while the address you were given stays the same. This is the most common exception by a wide margin.
- An owner with powers. The logic is fixed, but privileged functions let an owner change fees, pause transfers, mint, or move funds. The code did not change; what it does changed anyway.
- A module or a registry. The core is fixed but reads its parameters, or delegates parts of its work, to another contract that is not. The mutable part has simply moved one address away.
- A pause that has no end. An emergency stop with no automatic expiry and no obligation to lift it is, in practice, the power to end the protocol. It changes nothing in the code and everything about what you can do.
How to check, in order
- Is the source verified? On the block explorer, the address should show verified source matching the deployed bytecode. If it does not, everything below is unverifiable and you can stop.
- Is it a proxy? Explorers usually say so outright. If not, look for an implementation slot, a fallback that delegates, or an upgrade function. A proxy is not a flaw, but it moves the question to who can call the upgrade.
- What privileged functions exist? Read the list of functions with an access modifier. Ask of each: what is the worst it can do to someone holding this token?
- Who holds the privileged addresses? An owner address that is a multi-signature wallet with a timelock is a different risk from a single key. Both are different from an owner that has been set to an address nobody controls.
- Is there a constructor-only path? Values fixed at deployment and never written again are the strongest form of immutability, and they are visible as such in the code.
Five steps, each answerable from the explorer and the source. At the end you have not taken anyone’s word for anything, and you can say precisely what could and could not change.
What immutability does not give you
It is worth being clear about the limits, because the word is sometimes used as if it settled everything. An immutable contract can still hold a bug, and immutability means the bug cannot be patched either. It says nothing about the quality of the code, nothing about the assets the contract depends on, and nothing about whether the economics work.
What it does give you is a fixed object to evaluate. Whatever you conclude about the code today remains true about the code tomorrow. That is worth a great deal and is not the same as safety.
Common questions
Is an upgradeable contract a bad sign?
Not by itself. Upgradeability lets a team fix a defect, which immutability does not. What matters is whether it is disclosed plainly and who controls it. An upgradeable contract described as immutable is the bad sign.
Does renouncing ownership make a contract immutable?
It removes the owner’s powers, which is part of it. If the contract sits behind a proxy whose admin is separate, renouncing ownership on the logic changes nothing about who can replace that logic.
Can a vote change an immutable contract?
Only if the contract contains a mechanism that lets it. Governance over parameters the contract exposes is not the same as governance over the code, and the difference should be stated in both directions.
Where this project stands on it
Assetrix is deployed as an immutable contract with no upgrade path and no proxy, and nothing in this section asks you to take that on trust: the check above applies to it exactly as it applies to anything else, once the contract is deployed and its source verified.
Two roles exist and their powers are listed rather than described: a guardian appoints and removes an operator; the operator sets the protocol fee within a ceiling fixed in the code, announces currencies for a vote, and can raise the reserve-loss flag subject to holder confirmation. Neither can alter the mint price, the growth ladder or the rules of backing, introduce a fee on redeeming a position, admit a currency against a vote, or halt the return of funds. Those last items are properties of the contract, outside the reach of any role and any vote.