What is an Upgrade Authority
A program upgrade authority is simply an account that has permission to replace the on-chain code for a Solana program. Programs on Solana deploy as upgradeable by default: whoever controls the upgrade authority - a single keypair or a multisig - can swap out the program's bytecode to a new version at the same address, without migration, and instantly. A program becomes immutable only when its developers decide to remove the upgrade authority, permanently freezing the code in place.
Think of the upgrade authority as a landlord's master key for your apartment. In most cases, the master key is a good thing—a burst pipe will get fixed while you're out at work, without you needing to show up. But the master key means that anyone who has the master key could enter your apartment whenever they want: either the landlord, or anyone else who steals that key. When you deposit money into a Solana program, it's like living in that apartment: your deposit is repaired quickly, but it all depends on who has the master key.
Upgrade Mechanics
The upgrade authority is a program account that the Solana BPF upgradeable loader keeps updated as the program is upgraded. Every upgradeable Solana program is controlled by an upgradeable loader program. The loader program stores the executable bytecode in a separate program data account and stores the address of the upgrade authority. Any transaction that calls the program has to pay the upgradeable loader program first to check the bytecode. An upgrade takes one transaction: the upgrade authority signs a transaction to change the program data account to point to the new bytecode. Future transactions will use the new bytecode. The bytecode is always loaded at the same program address so integrations and bookmarks to the program's address don't need to change. The upgrade authority can be updated or removed at any time: an authority can be set to a specific keypair address, to a multisig address, or set to null to remove the authority entirely. If the upgrade authority is removed, no one can change the program bytecode anymore and the program becomes immutable.
A program with a keypair as the upgrade authority is generally considered to be unacceptable. Many well run projects use a Squads multisig as the upgrade authority: the authority address on chain would be the program data account address for a Squads program, and the program would be configured to require several members from different physical machines to sign the transaction to change the bytecode. At the time of writing, a large fraction of DeFi on Solana has its program upgrade authority controlled by a Squads program.
Protocols such as Drift prominently post their Squads multisig address on their site because advanced users want to verify it.
Ethereum vs. Solana
On Ethereum, upgradeable programs are rare. In practice, the rule is that a deployed contract is immutable and that is that. Teams who want an upgradeable contract have to architect it such that the deployed contract delegates to a new set of instructions on each upgrade via a proxy contract. After a handful of incidents in which people lost ETH when upgrading proxy contracts via a delegatecall to an unknown implementation, users were told to ask if "there is an upgrade admin" before depositing into Ethereum DeFi. Solana users are in the habit of asking that same question because all programs are upgradeable by default and only some are made immutable by removing the upgrade authority.
In a sense the comparison goes both ways, although Ethereum is currently doing better. On Ethereum the default behavior is the more secure one, so a handful of incidents occurred in which users lost their funds when developers tried to remove and deploy a new contract due to a previously frozen bug, or an upgrade proxy contract was exploited. On Solana the default behavior is to be immediately fixable for a developer to be able to patch a bug on the same day they found it and deploy immediately for users. But if the developer's upgrade authority credentials are stolen, an attacker doesn't need to look for a bug- they already have one. They replace the bytecode at your address.
Why do I need to check?
Before you deposit your Sol or your USD into any on-chain program, you need to check if there is an upgrade authority. Go to a Solscan page for the program's bytecode and check if the "Program Upgrade Authority" is set. If it is an address you recognize it as a Squads multisig for a known project, it is a reasonable assumption that a developer can still update the program when they encounter a bug. A developer who keeps a single keypair as the upgrade authority should be considered suspect: anyone with their laptop could drain your deposit. If you see a program with no upgrade authority that doesn't mean the program will never be hacked, but it does at least mean the developer cannot remotely upgrade it to a drainer contract and steal your deposit. You have to assume a bug in the bytecode will exist forever though: immutability is a trade.
A caveat: a multisig is no more secure than the private keys of the people managing that multisig, and you can't tell from the on-chain information who those are.
Can an upgraded program drain deposits?
Yes- an upgraded program can access your funds and drain your account. The upgrade authority controls not only how the contract runs, but what accounts the program owns. The upgrade authority can grant themselves access to every account owned by the program, even those with funds from the past. This is exactly why I keep telling people to check the upgrade authority instead of the APY.
