Why are some core programs on Solana mutable?

Question

I have a few questions regarding the upgrade authority on basic programs deployed on the Solana blockchain, i.e. the Stake Pool Program or the Token-2022 Program.

1. Why do these programs still retain an upgrade authority and are not native, like e.g. the System Program? Is this primarily for development flexibility or security concerns?

2. What are the potential risks associated with an upgrade authority that has not been frozen, particularly regarding security or trust within the ecosystem? Additionally, could the entity holding this key, in theory, have access to all the assets managed by the program, such as all Sanctum LSTs, or other similar assets?

3. Are there any plans or discussions around making certain key programs immutable in the future, to ensure greater transparency and security?

Thank you for your time and any insights you can provide!

Answer 1

Going through your questions:

1. In general, native programs are not a good idea, unless they absolutely need to do things that aren't possible in the VM. Every validator client team, like Firedancer and Sig, need to reimplement all of them, which is a big source of potential forking. For the Stake Pool program, even though it's feature-complete, the program remains upgradeable to address changes to native staking. For example, if the network adopts the 1 SOL minimum for stake accounts, then the stake pool program will immediately fail. Token-2022, on the other hand, is not feature complete yet. Once the program is done and hasn't had any security issues for some time, it will be frozen or given to the community.

2. The upgrade authority owns everything on a program, so it's the most sensitive authority. For example, if the Stake Pool program multisig wanted to, they could upgrade the program to include an instruction which reassigns all stake accounts to one of them, and steal everything.

3. There are constant discussions about the best way to handle upgrade authorities in way that makes users feel safe. The classic dilemma: when a program is upgradeable, it's possible to patch security vulnerabilities. When a program is frozen, it's impossible to rug. Typically, my view is to default to frozen if it's possible for users to migrate in the case of an upgrade. For example, in an AMM protocol, you can deploy a new program, and get users to withdraw from the old program and deposit in the new one.