Upgradeable contracts as a governance question

Two liabilities

A contract that cannot be changed is a liability: a defect found after deployment has no remedy short of migration, and migrations of a live register are expensive and public. A contract that can be changed by one party is a different liability: every assurance the code provides is conditional on that party’s continued good behaviour. Neither is the safe option, and choosing between them is a governance decision that engineering should not make alone.

Upgrade capture

The failure mode we see most often: an upgradeable contract whose administrative key is held by the vendor who built it, arranged that way for operational convenience during delivery and never moved. It reads as a technical convenience and is a governance failure — the client’s assurances about their own system are, on paper, assurances about their supplier.

The approval that is not one

A multi-signature upgrade path where all signers report to the same executive is a single approval with extra ceremony. Independence in the approval set is the property being purchased; if the institution cannot supply it, that should be recorded as an accepted risk rather than disguised by a threshold.

What an auditor asks

• Who can change this, today?By name and role, not by address. If the answer requires an investigation, that is the finding.
• What approval is required, and is it independent?Independence is judged by reporting line, not by key count.
• Has the upgrade path been executed?An upgrade mechanism that has never been exercised on a staging deployment is untested code in the most sensitive position in the system.