Is an upgradeable contract automatically risky?

Not automatically, but upgradeability concentrates power: whoever controls the upgrade key can change the code and therefore the rules holding user funds. The risk comes from how that key is secured, not merely from being upgradeable. A timelock-gated multisig with an immutable fund-custody core can be very safe.

Why is a single EOA upgrade key the worst case?

A single externally owned account means one private key can rewrite the contract instantly with no delay, no quorum, and no warning. If that key is phished, leaked, or malicious, all user funds can be drained or frozen. It is the classic rug-pull and single-point-of-failure vector.

What does a timelock actually protect against?

A timelock forces a mandatory delay between proposing and executing an upgrade, giving users time to review the change and exit if they disagree. It does not stop a malicious upgrade, but it removes the element of surprise and converts a silent rug into a publicly visible, exitable event.

How is the Diamond pattern scored?

The Diamond (EIP-2535) pattern is powerful but adds complexity: multiple facets, shared storage, and a facet-management function expand the attack surface and make audits harder. The tool adds a modest complexity penalty for Diamond, partially offset if upgrades are timelock-gated.

Is the score a security guarantee?

No. It is a structured heuristic that reflects governance and centralisation risk, not code correctness. A perfectly decentralised contract can still have a reentrancy bug. Always commission a full professional audit and formal verification regardless of the score here.

Smart Contract Upgradeability Risk Checker

Upgradeable contracts let teams fix bugs and ship features, but they also hand someone the power to rewrite the rules around user funds. This checker scores how much that power is concentrated and what could go wrong, based on your proxy pattern, who holds the keys, and whether the money-handling core is immutable.

How it works

Each answer contributes points to a 0–100 centralisation risk score (higher = riskier). The weights reflect how much real control each choice grants:

Pattern:   none 0 · Transparent/UUPS 15 · Beacon 20 · Diamond 28
Key:       timelock+multisig 5 · multisig 20 · single EOA 45
Funds:     deployer can withdraw user funds +20
Pause:     un-timelocked pause power +8
Verified:  source not verified on explorer +10
Audited:   no public audit +12

The total is capped at 100 and mapped to Low (0–24), Moderate (25–49), High (50–74), and Critical (75–100) bands.

Notes and example

A UUPS proxy (15) with a single EOA owner (45) that can also withdraw user funds (20) and is unaudited (12) scores 92 — Critical, the canonical rug setup. Move the key to a 4-of-7 multisig behind a 48-hour timelock (5), remove the fund-withdraw path, and ship a public audit, and the same contract drops to around 20 — Low. The biggest single lever is almost always key custody, so a timelock-gated multisig is the highest-impact safeguard you can add.