A service tells you its contract address has not changed. That may be true even when the code handling calls through that address has changed. Some smart-contract systems use a proxy that delegates work to a separate implementation.
OpenZeppelin’s upgrade documentation explains this pattern: a new implementation can be deployed and the proxy’s implementation reference updated. The proxy address can remain the same. This is a particular architecture, not a feature of every contract.
Ask for more than one address
When reviewing a system, identify the network, proxy address and current implementation address through reliable documentation and appropriate explorer tools. An explorer may provide a recognised proxy view, but verify what it is displaying rather than assuming every label is complete.
Record the point in time or block at which you checked. A statement about the current implementation can become outdated after an authorised upgrade. An old audit report should be compared with the version actually in use.
Read the authority behind the change
Ask who can approve an upgrade and what controls apply. A single administrator, a multisignature arrangement and a governed process create different operational questions. A delay mechanism may give observers notice, but its presence does not by itself prove the new code is safe.
For an invented example, a project keeps one user-facing proxy address while moving from implementation A to implementation B. A screenshot showing the unchanged address does not establish that all behaviour is unchanged. The new implementation and the upgrade process both need examination.
Keep the conclusion narrow
Upgradeability can support maintenance, but it also introduces authority and compatibility risks. Verified source code, a recognised library or an unchanged address is not a security guarantee. Conversely, an upgrade is not automatically evidence of wrongdoing.
Reading public contract information should not require disclosing a recovery phrase or signing an unexplained wallet message. If you cannot establish the architecture or authority, leave that uncertainty visible. The useful record identifies what can change, who can change it and which version your assessment actually covers.