Upgradeability

One of the hardest smart contract tradeoffs is choosing between immutability and upgradeability. Immutability is powerful because users know the code at an address cannot silently change. Upgradeability is attractive because bugs and product requirements do change after launch.

Proxy systems try to separate storage from logic. Users keep interacting with one stable proxy address, while an admin can point that proxy at a new logic contract when an upgrade is approved.

Upgradeability is not automatically bad, but it changes what users must verify. You are no longer only trusting the current code. You are also trusting the process and keys that can replace that code later.

That is why mature protocols document upgrade delays, multisigs, and governance procedures. The technical pattern matters, but the human control structure around it matters just as much.