Who can change a Solana application? Upgrade authority and governance

Begin with the changes that matter to users

An application can have several kinds of control. One role may publish new program code. Another can change a lending parameter or price feed. A token issuer may retain mint or freeze permissions. A website operator can change the interface without changing any onchain program.

These actions affect users differently. Changing a page colour is different from changing the rule that calculates a position's health. Calling a project community-run does not identify the actual authority for either action.

Start with the workflow you depend on. For a lending position, inspect the lending program, market configuration, eligible assets and oracle path. For a digital asset, inspect the asset standard's own update and delegate rules.

Make an initial list of material actions and the account that stores each control. The investigation then becomes a set of concrete state lookups rather than a judgement based on branding.

Read the deployed program and its upgrade authority

A program's deployment structure depends on its loader. Identify the executable program and use the loader's documented layout to find the relevant code and authority records.

For loader-v3, the Program account and associated ProgramData have distinct purposes. ProgramData contains deployment information and the upgrade-authority option. Reading only the executable flag does not establish whether code can be upgraded.

If a supported authority remains, the authorised process can replace code under that loader's rules. If upgrade authority has been removed under the relevant mechanism, record that observation specifically. It answers the upgrade question for that program identity.

Also identify the code users actually invoke. A newly published program address, a proxy-like application arrangement or a different front-end route can change the user's workflow without being an in-place upgrade of the program you first inspected.

A multisig has membership, a threshold and an execution path

In a teaching multisig, five member keys control a vault and three approvals are required. That describes a 3-of-5 threshold. It does not establish that five independent people or organisations hold the keys.

Read the current members, threshold and permissions of the actual multisig implementation. Some roles can propose, approve or execute particular operations. Determine which account is the authority recognised by the target program.

A proposal collecting enough approvals can still need a separate execution transaction. The target action happens when the supported execution path invokes it with the necessary authority. A vote count on a website is not a replacement for observing the executed instruction.

If there is a delay or timelock, inspect how it is enforced and which actions it covers. Record the actual value and any bypass or emergency path described by the implementation. Do not assume every governance-controlled action uses the same delay.

A multisig approval is part of an execution path

Immutable code can still use changing configuration

Consider a lending program whose executable code can no longer be upgraded. It may still read a market account with configurable collateral factors or an oracle address. Those changes can materially affect a position while the code remains identical.

Likewise, a program can depend on a token with its own issuer controls or a price feed with an external update mechanism. Analyse the dependency that supplies the behaviour you are relying on.

For a teaching control map, suppose code upgrades require the multisig, market parameters use a separate administrator and token freezing belongs to the issuer. These are three distinct permissions. Evidence for the first does not establish the second or third.

Follow the configured account to the role that authorises its update, then to the mechanism controlling that role. This is how a practical governance diagram connects real state rather than merely arranging project logos.

Build a dated authority record

For each action, record the affected program or configuration account, current authority, controlling mechanism and source observation. Add the deployment or observation context required to reproduce the lookup.

Separate verified state from interpretation. You may verify five member public keys and a threshold of three, while lacking evidence that those keys represent independent operators. Keep that attribution uncertainty in the relevant field.

For an update event, save the proposal, approvals where available, execution signature and resulting state. This connects the announced decision to what actually changed.

A useful review might conclude: code upgrade controlled by this vault; threshold observed as three; parameter updates controlled by this other role; issuer controls remain separate. That is more actionable than a single decentralised badge.

Apply the map when opening or maintaining a position

Before using a product, identify which controls could alter its operation and how updates are communicated. For a long-lived position, retain those addresses so you can observe relevant changes over time.

When an interface changes, compare the requested program IDs and instructions with the known workflow. When a protocol announces an update, inspect the affected layer: front end, configuration, program deployment or dependency.

The authority guide explains the underlying runtime/program distinction. The DeFi product review applies the same map to a complete financial position.

Common questions