Upgradeable Proxy Contracts
The contract that holds funds can be pointed at new code, so the audited behavior of today is not necessarily the behavior of tomorrow.
How it happens
A proxy holds the assets and the storage while delegating execution to a separate implementation contract whose address can be changed by whoever holds the upgrade right. This pattern is genuinely useful, since it allows a bug to be fixed without migrating users, but it means the code a depositor reviewed is a snapshot rather than a commitment. Two additional exposures follow. Storage layout must remain compatible across upgrades, and a mistake there can corrupt balances rather than merely change behavior. And the implementation is itself a dependency that can be removed, so the proxy pattern makes the contract's future contingent on both the upgrade key and the continued existence of the code it points to.
What you can actually observe
Check whether the address is a proxy by reading the standard implementation and admin storage slots, then identify who holds the upgrade right and whether upgrades pass a timelock. Count how many times the implementation has changed and compare the currently deployed implementation against the specific commit that was audited. Where a timelock exists, its queue of pending changes is public and can be monitored.
Precedent
In 2017 a shared library that many Parity multisig wallets delegated to was self-destructed, freezing the balances of every wallet that depended on it and demonstrating that the code behind a proxy is a live dependency.
What makes it more or less material
Consider whether the contract is upgradeable at all, who holds that right, whether a timelock and an exit window exist, how frequently the implementation has changed, and whether the current code matches an audited version.
Related factors
Assets this applies to
The largest assets we classify in the categories this factor applies to. Presence here means the factor is relevant to that kind of asset, not that it has occurred.