Upgradeable Proxy Contracts

Hoe het werkt

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.

Wat u daadwerkelijk kunt waarnemen

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.

Wat het meer of minder materieel maakt

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.