Wallets, keys and safety basics

The short answer

A Solana wallet is a pair of numbers. One of them, the public key, is your address and can be given to anyone. The other, the private key, proves you control that address, and anyone who obtains it controls the address permanently. There is no password reset, no support desk and no reversal. The private key is the wallet, not a way of getting into it.

Everything else on this page follows from that. A seed phrase is a human-readable way of storing private keys, so it is worth exactly as much as they are. Software that asks for either is asking to become you. Software that asks you to sign something is asking for permission to do one specific thing, which is a completely different request and is examined below.

What a wallet actually is

Underneath the app, a Solana wallet is a cryptographic keypair. The private key is a random number. The public key is derived from it by a one-way calculation, meaning you can always compute the public key from the private one and never the reverse. Your address is the public key written in a compact text form.

The word wallet is unhelpful, because it suggests a container holding coins. Nothing is inside it. Your balance is a number recorded on the chain against your address, and every full node has a copy. The wallet application does not store your tokens; it stores the key that lets you authorise changes to that record, and it shows you the record by asking a node about it.

This is why an uninstalled wallet app loses nothing, provided you still have the key material, and why a compromised key loses everything, even if the app is still sitting there looking normal. The app is a viewer and a signer. The key is the asset.

The address, or public key

A Solana address is a string of letters and digits, typically 32 to 44 characters, encoded in a scheme that deliberately leaves out characters people confuse, such as zero and capital O. It is public information. Publishing it lets people send you tokens and lets anyone inspect every transaction it has ever made.

That last part deserves emphasis, because newcomers often assume the opposite. The chain is not private. Anyone with your address can see the full history: what came in, what went out, when, and which other addresses were involved. This is the basis of every analysis in the rest of this subject, including the way self-generated trading activity becomes visible to anyone who bothers to look.

The private key and the seed phrase

The private key is the secret half. Applications usually never show it to you directly; instead they give you a seed phrase, also called a recovery phrase, which is a sequence of twelve or twenty-four ordinary English words drawn from a fixed standard list. Those words encode a random number from which keys are generated.

A seed phrase is not a password. A password protects an account that exists on somebody's server, and that somebody can reset it. A seed phrase generates the keys themselves. There is no server, no account and nobody who could help. If two people have the phrase, two people have the wallet, and the chain cannot tell which one you intended.

One phrase, many wallets

A single seed phrase can generate an effectively unlimited number of keypairs, following a standard derivation scheme. Wallet applications use this to give you multiple accounts from one backup: account one, account two and so on, all recoverable from the same twelve words.

This has a consequence people miss. Those accounts are not independent. They share a root, so anyone who obtains the phrase obtains all of them, including the ones you thought of as separate. If you want genuine separation between a wallet holding something valuable and a wallet used for experiments, they need different seed phrases, not different account numbers under one phrase.

Automation tools often generate keys directly instead, producing standalone keypairs with no shared root. That is a different trade-off: no single phrase can lose everything, but there are now many separate secrets to store and lose.

Connecting versus importing

These two phrases sound similar and mean opposite things. Getting the difference straight is probably the single most protective piece of knowledge on this page.

Connecting is safe in the sense that it hands over no secret. Signing is bounded, though the bound is only as good as your ability to read what you are signing. The bottom two rows are not steps in a process; they are the process ending, with the wallet now belonging to whoever asked.

What you agree to when you sign

A signature authorises a specific list of instructions. Most of the time your wallet app will summarise it: this transaction sends 0.2 SOL to that address, or swaps this for that. Sometimes the summary is thin, because the instructions call a program the wallet does not recognise, and then you are being asked to trust the requester rather than the description.

There is also a category of approval that grants ongoing permission rather than performing a one-off action, letting another program move a particular token from your account later. That is legitimate and common in ordinary trading, and it is also how a malicious site turns one careless click into a slow drain. Wallet applications and explorers can list outstanding approvals, and reviewing them occasionally is a cheap habit.

The practical rule is proportion. A signature on a wallet holding a small experimental balance is a small decision. The same signature from a wallet holding everything you own is not. Which is the entire argument for the separation described next.

Funding wallets and worker wallets

Anything that automates trading needs to sign transactions without asking you each time, which means it needs key material of its own. This is unavoidable: a program cannot pause four hundred times to wait for a human click. So the honest question is not whether keys are involved but which keys, holding what, generated where.

The structure almost every tool uses has two tiers. A funding wallet holds the budget for the run. Worker wallets are generated for the run, hold small amounts, do the trading, and are disposable afterwards. The important property is that the workers are not your main wallet and are not derived from the same phrase as anything you care about.

Where the keys are generated is the question worth asking of any hosted service. Keys created in your browser and never transmitted are a different proposition from keys created on somebody's server. Neither arrangement is automatically fine, and the answer is usually discoverable from the documentation. Any tool describing itself as a SOL volume bot is by definition signing transactions on your behalf, so how it obtains the authority to do so is the first thing to establish, before any question about features.

• Fund in stages. Send the run's budget, not the wallet's balance. A funding wallet holding exactly what the campaign needs bounds the worst case to that amount.
• Keep the main wallet out of it. The wallet holding anything long term should never be the wallet that automation touches, and should not share a seed phrase with one that does.
• Expect to lose the workers. Treat every worker key as disposable. If losing them all would be a disaster, they are holding too much.
• Sweep and close afterwards. Recover leftover SOL and close empty token accounts to release the rent deposits, then stop thinking about those keys entirely.
• Write down what you did. Which addresses, funded when, with how much. Reconstructing this later from an explorer is possible but tedious.

Requests that are always theft

These are worth memorising as patterns, because the wrapping changes constantly and the underlying request does not.

• Any request for a seed phrase. Framed as verification, migration, support, recovery, eligibility or synchronisation. Always theft, without exception.
• Any request for a private key export. Sometimes dressed up as importing your wallet into a tool. Handing over the key is handing over the wallet.
• A support agent who contacted you first. Real support does not appear unprompted in a direct message offering to fix your problem.
• A validation or unlock transaction to free stuck funds. Funds are not stuck in a way a stranger's transaction can release.
• A recovery service after a theft. The second theft aimed at people who have already had one.
• A downloadable tool sent privately, with a promise about returns. Two warning signs at once, and the download is the point.

The reason this list stays short is that the underlying trick does not vary. Either somebody wants the secret, or somebody wants a signature on a transaction you have not read. Everything else is theatre around those two requests.

Practical hygiene

None of this requires special equipment or expertise. It requires separating things that should be separate and slowing down at the moment of signing.

Separate by purpose

One wallet for holding, one for day-to-day interaction, one set for automation. Different seed phrases, not different accounts under one phrase. If you would be upset to lose a wallet, it should never sign anything experimental.

Back up the phrase offline

On paper or metal, stored somewhere physical. Not in a photo, not in a notes app, not in an email to yourself, not in a password manager entry that syncs to a device you also browse on. The phrase is the only thing that cannot be regenerated.

Use a hardware wallet for anything long term

A hardware device keeps the private key on the device and signs there, so a compromised computer cannot extract it. Solana is supported by the mainstream devices, and the general guidance is set out in the Solana wallet documentation. It does not make signing safe; it makes key extraction hard, which is a different and useful guarantee.

Read the summary before approving

Every time. If the wallet cannot tell you what a transaction does, that is information. Declining costs nothing but a little time, and a transaction you decline can always be requested again.

Review approvals occasionally

Outstanding permissions accumulate quietly. Revoking the ones you no longer need takes minutes and removes a whole class of later surprise.

If something goes wrong

If a key or phrase has been exposed, the wallet is gone and speed is the only variable. Move anything remaining to a wallet generated from a phrase that has never touched the compromised machine. Do not move it to another account under the same phrase, because that is the same wallet with a different label.

Then assume the compromised device is compromised until proven otherwise. Generating a fresh wallet on the machine that leaked the last one repeats the exercise. There is no way to undo a transaction on Solana and no authority that can reverse one; the record is the record.

What you can do is look. Every movement is visible on an explorer, and reconstructing exactly what happened and when is usually straightforward. That will not return anything, but it does tell you which key was the problem, which is the only thing that stops it happening twice.

The last explainer on this site steps back from mechanics and asks the awkward question: given the costs, the risks and the rules, is any of this actually worth doing, and what can it honestly not achieve.