Can this protocol change under me?
If a DeFi program is upgradeable, the authority can replace its logic. Knowing that is the first step in judging the risk.
DWG NO. PDX-001 · SHEET 1 OF 6 · REV LIVE
Who can change
the code you
trust?
Every Solana program is either frozen forever or upgradeable by someone. ProgramDex reads the program's accounts straight from the chain and draws the answer: loader, upgrade authority, last deploy slot, size and rent — as a live schematic.
CA
2VyQ72GWXKXLEu3qGfnSoGpTzegtnRxWe2977BARd6wH
SHEET 2 · INSPECTOR
Inspect a program
Paste a program ID. We make 3–4 read-only RPC calls: the program account, its ProgramData + authority, and recent activity on the ProgramData account.
Samples:
Recent transactions touching ProgramData
Upgrades, authority changes and extensions write to this account. Ordinary use of the program does not.
SHEET 3 · CATALOGUE
Well-known programs, scanned live
Pick a group and scan it: two batched RPC calls read every program and its ProgramData at once. Names are descriptive labels for widely used program IDs; status is read live, not from a list.
| Program | ID | Loader | Status | Upgrade authority | Last deploy slot | Size | Inspect |
|---|
SHEET 4 · PROCEDURE
How the inspection works
- 01
Read the program account
getAccountInforeturns the owner (the loader) and whether the account is executable. For the upgradeable loader, its 36 bytes hold one thing: the ProgramData address. - 02
Slice the header
We fetch only the first 45 bytes of ProgramData: a 4-byte tag, the 8-byte deploy slot, a 1-byte “has authority” flag and the 32-byte authority. No megabytes of code are downloaded.
- 03
Look at the authority
The authority's own account is read too: is it a plain system account (a wallet or a program-derived vault), or owned by another program such as a multisig?
- 04
Date the deploy
The deploy slot is converted to a time using the ProgramData's own recent transactions when available, otherwise estimated from the live slot pace and marked “≈”.
SHEET 5 · APPLICATIONS
What you can learn
Single key or shared control?
An authority owned by a multisig program is different from one plain key. We show the authority's owner so you can tell.
When did it last change?
The deploy slot tells you whether code shipped yesterday or two years ago — handy after an incident or a surprise feature.
Who controls a family of programs?
Scanning a catalogue group reveals programs that share one upgrade authority — one key, many contracts.
Is it really frozen?
An authority of “None” means the code can never be upgraded again. Some core programs show exactly that.
How much space is reserved?
ProgramData size reveals how much headroom the deployer allocated for future versions, and how much SOL is locked as rent.
SHEET 6 · REFERENCE
Anatomy of an upgradeable program
On Solana, code and state live in separate accounts. A program is an account flagged executable and owned by a loader — a built-in program that knows how to verify and run the compiled code (an ELF file built for the Solana virtual machine). Which loader owns a program decides whether it can change.
The four loaders you'll meet
- Native loader — owns built-in programs compiled into the validator itself (System, Vote, Compute Budget). They change only with validator software releases, through the feature-activation process.
- BPF Loader 2 (
BPFLoader2111…) — the older, non-upgradeable loader. Code lives directly in the program account and can never be replaced. The Memo and Associated Token Account programs are examples. - Upgradeable loader (
BPFLoaderUpgradeab1e…) — the default for nearly every modern program. The program account stays small (36 bytes) and permanent; the code lives in a separate ProgramData account that can be rewritten by the upgrade authority. - Loader v4 (
LoaderV4111…) — a newer loader where the program account holds the code plus a header with an authority and a status: retracted, deployed or finalized (finalized means immutable).
How an upgrade happens
The authority writes new code into a temporary buffer account, then sends an Upgrade instruction. The loader verifies the ELF, copies it into ProgramData, and stamps the current slot into the header — the “last deploy slot” shown here. The program ID never changes, so users and integrations keep pointing at the same address while the logic underneath is replaced.
Setting the authority to None is a one-way door: no one can upgrade the program again. Teams often keep upgradeability early on to fix bugs and later hand the authority to a multisig or governance program, or renounce it entirely. Several core SPL programs have been migrated to the upgradeable loader with no authority, which is why they show up here as “immutable” despite the loader name.
What this does not tell you
Upgradeability is about who can change the code, not whether the code is safe. An immutable program can still contain a bug, and an upgradeable one can be well governed. Match the deployed bytes against published source with a verified-build tool if you need certainty about what the code does.
APPENDIX A
FAQ
Does “upgradeable” mean a program is dangerous?
No. It means someone can change it. Most active protocols keep that ability to fix bugs. What matters is who holds the authority and how they're governed.
Can you tell if the authority is a multisig?
Partly. If the authority account is owned by a multisig program, we show that owner. Many modern multisigs use a program-derived “vault” address that is owned by the System Program and holds no data, which looks the same as an ordinary wallet on-chain. We say so rather than guess.
Why is the deploy time marked “≈”?
Public RPC nodes keep only recent block history, so the exact time of an old slot often isn't available. We then estimate from the live slot pace, which drifts for older slots.
Why does the size say 10 MiB for some programs?
Deployers can allocate extra space up front so future upgrades fit. The figure is the allocated ProgramData size, not necessarily the current code length.
What about the program's IDL or source?
ProgramDex only reads loader data. IDLs and verified builds are separate systems; we don't fetch or display them.
Is anything sent from my browser besides the program ID?
No. Requests go straight to the public Solana RPC with the addresses being inspected. There are no accounts, wallets, analytics or cookies.
Why does the catalogue scan in groups?
The public node allows at most 10 accounts per batched call, so each group is limited to 10 programs and costs two calls.
Limits & honesty
- Source: public Solana RPC (publicnode) only:
getAccountInfo,getMultipleAccounts,getSignaturesForAddress,getEpochInfo,getRecentPerformanceSamples. - Can't see: source code, IDLs, verified-build status, who is behind an authority key, or off-chain governance.
- Deploy times are exact only when the deploy transaction is still in the node's recent history; otherwise estimated and marked ≈.
- Catalogue names are descriptive labels for widely published program IDs, not endorsements or affiliations. Status is always read live.
- Rate limits: one inspection every 2 seconds; the slot ticker polls every 10 seconds.
- Read-only. No wallet connection, no signing, no transactions.