[Technical] Private Key Security Requirements

I have some (kind of technical) questions regarding the security of private keys:

  1. Once a mint account was created, we don’t care about that accounts private key anymore? It’s no problem if it get’s leaked/might be known to the public?
  2. Once a program is uploaded, we don’t care about that accounts private key anymore? It’s no problem if it get’s leaked/might be known to the public?
  3. Once an account is not longer owned by the System Program, but by my custom Program, we don’t care about that accounts private key anymore? It’s no problem if it get’s leaked/might be known to the public?

I statement I’ve read (but I couldn’t find the source again) that would match those “questions” is, that only the owner (in the technical sense and meaning the owner program) of an account can withdraw lamports from that account.
And in the cases above, the System Program is not the owner of any of these accounts (in 1 its the Token Program, in 2 it’s the choosen Loader Program, and in 3 it’s my Custom Program).

Reason for these questions is that I wan’t to create such three accounts, using a vanity address (generated using solana-keygen grind), but the keypairs I found are already commited to a private bitbucket git and I’m concrened that if these get leaked something bad happens…

I’m always happy for links to the documentation clarifying these questions :slight_smile:

I believe that a program’s private can be used to update the program, by default, so anybody who has that private key could publish new versions of your program, unless you marked it as non-upgradable.

I’d have to double-check to be sure.


What you say about once an account is owned by a program other than the system program, that it’s the only program that can modify the account, though.

Still, it is possible for that program to transfer ownership back to the system account ( not that it would, but it could ). And at that point, anybody who has the private key could take back control over the account.


In short, it’s bad if those keys get leaked. You might be safe, but you don’t want to risk it.

The most important one that I think you need to keep private and make sure you don’t lose is the program key.

As for the mint account, and other accounts that will be owned by programs other than the system program, I think it’s usually safe to throw away the private key and not store it anywhere. I think that’s usually what apps do when they create accounts that are specifically owned by a program.

But I would still keep those private keys from being public, just in case.


You know it is possible to remove those keys from the git history, though. You can do a Git rebase and a force push to remove the commit that added those files. Or you can create a new commit that deletes those files, and then squash that commit into the commit that added them and that will keep all the other files in the commit, but make sure that the keys themselves are removed from the Git history.

Thanks for the answer!

Reading the solana doc here it says that if not specified otherwiese, the default keypair is the upgrade authority.
So unless the programs keypair is explicitly specified as upgrade authority (which I don’t plan to do), the programs private key can not be used to uprade the program.


Your second point is very interesting. I never thought of the possibility that the account might change it’s owner back to the system program again… If interacting with foreign programs without source knowledge this should definitely be a concerne!

1 Like

Yep, you are right. I just tested it: while you need a keypair to do an initial program deployment, after that, you only need to have the keypair of the update authority to update it.

So after program deployment it’s probably fine just to trash the program keypair.