SKN3X.COM

Actually checking upgrade and proxy rights

Four questions answerable from chain state — and what to do when one of them stays open.

This lesson has had no expert review. It was written for this platform and against the evidence it cites; nobody has gone through it independently.

Learning objectives

  • You can name the four details an upgrade review has to document.
  • You can distinguish “not established” from “no admin right” and record both correctly.

Check your prior knowledge

Answer these for yourself before reading on. Wherever you hesitate is where this lesson pays off.

Core concept

Fact

Four details, all checkable from chain state

First: is there a proxy behind the address, or is the logic fixed? Second: which address may replace it? Third: is that address a multisig, and at what threshold? Fourth: is a timelock in between, and how long? All four sit in chain state and can be answered without the protocol's cooperation — unlike almost everything else in a security review.

Interpretation

A multisig is a number, not a property

“Secured by a multisig” says nothing on its own. Three of five is not two of three, and both are something else again if the signers belong to the same organization. A defensible note gives the threshold, the count and — as far as it can be established — whether the signers are independent of one another. Where that cannot be established, that is what belongs in the note.

Uncertainty

Open is not the same as unremarkable

Being unable to answer one of the four is a finding, not a missing chapter. The note reads “not established”, with a date and a reason — neither omission nor “no admin rights”. That difference later decides whether someone repeats the review or relies on an absence that was never established.

Definitions

Proxy
A contract forwarding calls to a replaceable logic address.
Admin address
The address entitled to replace the logic behind a proxy.
Threshold
The number of signatures a multisig requires for a transaction.

Model

  1. Address users interact with

  2. Proxy — points to replaceable logic

  3. Admin — may change that pointer

  4. Timelock — does it sit between admin and proxy?

  5. Multisig — threshold, count, independence

The chain that has to be checked — If step 4 is missing from the chain, warning time is zero regardless of what delay is documented.

Worked example

The same claim, two depths of review

The protocol's claim
“upgrades via multisig with timelock”
Review A
claim adopted as stated
Review B
proxy confirmed, admin = timelock contract, its owner = 4/7 multisig, delay 48 h

Review B additionally establishes that the timelock actually sits between the multisig and the proxy — rather than beside it. That order decides whether the 48 hours apply to an upgrade at all, or only to other actions.

The same claim, once repeated and once evidenced.

Reading: The difference costs an hour and is the one part of a security review that can be completed entirely without the protocol's cooperation.

Retrieval

A review cannot determine the admin address unambiguously. How do you record that?
Why is “secured by a multisig” not enough as a finding?

Exercise on real data

Compare the guiding questions with the four details above and record that this platform carries no field for them — the answers come from chain state.

Dimension 4: smart contracts →

Application

Which five lines document an upgrade review to an auditable standard?

Related case studies

Institutional reading

Bank
Is the upgrade review repeated after every observed upgrade?
Insurance
Does the cover attach to the address, or to the reviewed code version?

Key takeaways

Evidence