Who can upgrade 7 tokenized treasury/gold tokens on Ethereum? A read-only look at upgrade control

Magicians
1

I read the upgrade control of 7 tokenized treasury and gold fund tokens on Ethereum straight from the chain. Snapshot: 9 Nov 2026. Read-only; nothing was tested on live contracts.

Result (7 tokens I looked at, not a market ranking):

  • 3: the upgrade owner is one externally owned address (no contract code), no on-chain delay
  • 2: Safe multisig, 4-of-7, no delay found
  • 1: older multisig, 3-of-6, no delay found
  • 1: timelock, 24h minimum delay

What this does NOT say: that any key is stored badly (it may sit behind HSM/MPC or issuer processes that are invisible from outside), that assets are at risk, or that other controls (pauses, legal, off-chain) are missing. It only shows who can change token code on-chain.

How to reproduce with any public RPC. Three patterns cover all 7:

A) EIP-1967 proxy: read the admin slot, then ask the admin for its owner.

cast storage <token> 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103
cast call <admin> "owner()(address)"

B) Owner stored on the token/proxy itself:

cast call <token> "owner()(address)"

C) Older proxy admin slot:

cast storage <token> 0x10d6a54a4754c8869d6886b5f5d7fbfa5b4522237ea5c60d11bc4e7a1ff9390b

Then check what the owner is:

cast code <owner>          # empty = externally owned
getThreshold()             # Safe
getMinDelay()              # timelock

I am not naming the tokens: this is about the pattern, not about any one issuer. Questions I would like feedback on: is “no on-chain delay” the right thing to flag for tokenized funds, and what other control signals (pause roles, mint/burn roles) would be worth adding to a standard check?

Short version on X: it it on X: "Who can change the code of a tokenized treasury or gold fund on Ethereum, and how fast? I read the upgrade control of 7 of them straight from the chain. Snapshot: 9 Nov 2026. Read-only; nothing was tested on live contracts." / X
Corrections welcome.

2

For a standard check, tokens on AccessControl need a fourth pattern. On UUPS the 1967 admin slot is empty and there’s no owner(), because _authorizeUpgrade checks a role, so the real controller is whoever holds that role’s admin (getRoleAdmin, DEFAULT_ADMIN_ROLE unless it was changed). It can grant itself the upgrader role and upgrade right after. Without AccessControlEnumerable the holders only show up in the RoleGranted and RoleRevoked logs.

For the Safes, 4-of-7 only holds if no module is enabled. A module calls execTransactionFromModule with no owner signatures at all, so getModulesPaginated(0x0000000000000000000000000000000000000001, 10) belongs in the check.

On your question, I’d flag no delay, yes. For fund tokens I’d put the roles that move balances without any upgrade right next to it: forced transfer or seize, burn from any address, freeze, mint. They take effect in the same block, so who holds them and who can grant them says as much as the upgrade owner.