Search across all documentation pages
Every wallet does the same two jobs - hold a keypair, and sign transactions with it - but they differ enormously in how that keypair is stored and who can trigger a signature. This tutorial walks through the five categories of Solana wallets you'll encounter, what each is actually for, and why a growing number of teams add a multisig on top of all of them.
A wallet is not a container for your SOL. Your balance lives on-chain, in an account the network already knows about. A wallet is the software or hardware that holds the private key for that account and uses it to sign transactions on your behalf.
Every Solana wallet is built around a keypair - a public key that identifies the account, and a private key that proves ownership. If you already read Keypairs & Addresses, this is the same keypair; a wallet is simply the layer of software that stores it safely and asks for your approval before signing.
Most Solana wallets are non-custodial, meaning only you hold the private key, and losing it means losing access permanently - there is no password reset. A smaller number of exchange-hosted wallets are custodial, meaning the exchange holds the key on your behalf and you trust them to sign correctly.
The type of wallet you pick is really a decision about where that private key lives - in a browser process, on your phone, on a separate physical device, in a plain file, or spread across several signers who must all agree. Each answer trades convenience for security differently.
| Term | Plain-language meaning |
|---|---|
Non-custodial | You alone hold the private key; no company can recover or freeze it for you. |
Custodial | A third party (usually an exchange) holds the private key on your behalf. |
Seed phrase | A 12-24 word recovery phrase that can regenerate your private key - anyone with it fully controls the wallet. |
Hot wallet | A wallet whose keys live on an internet-connected device (browser, phone, desktop). |
Cold wallet | A wallet whose keys are generated and stored on a device that is never connected to the internet. |
Air-gapped | A signing method where the device that holds the key never touches a network - transactions are moved via QR code or USB instead. |
Multisig | An account that requires signatures from multiple approved keys before a transaction is considered valid. |
M-of-N | The threshold rule for a multisig - e.g. "2-of-3" means any 2 of the 3 approved signers must sign. |
The public devnet examples throughout this guide use a single CLI keypair file, because that's the simplest way to follow along. Real usage looks different depending on who is signing and what's at stake.
An individual holding a small amount of SOL for testing has very different needs than a DAO treasury holding millions of dollars in community funds. The first can reasonably prioritize convenience; the second cannot afford a single compromised laptop to drain the treasury.
As a rule of thumb, convenience and security move in opposite directions. Browser wallets are the fastest to use and the easiest to compromise via phishing; hardware wallets are the slowest to use and the hardest to compromise remotely. Multisigs add friction (every transaction needs multiple approvals) specifically to remove the single point of failure that any one wallet - hot or cold - still has on its own.
Internet-connected apps and extensions for daily use, dApps, trading, NFTs, and staking. Convenient but less secure for large holdings.
Top popular ones:
Apps for iOS/Android, often overlapping with hot software wallets since many have browser extensions too. Great for on-the-go use.
Top popular ones:
Physical devices for offline key storage. Highest security for long-term holdings; usually paired with hot wallet software for signing.
Top popular ones (fewer dedicated options):
Command-line tools for developers and advanced users. Minimalist, scriptable, no GUI - this is what every CLI example earlier in this guide has used.
Main options (not many "popular" consumer ones):
~/.config/solana/id.json.solana commands).A multisig is not a wallet you sign into personally - it's an on-chain account controlled by a set of approved signers, each of whom typically uses one of the wallet types above (often a hardware wallet) to approve or reject a proposed transaction. Nothing executes until enough of those signers agree.
Top popular ones:
Why use a multisig? A single keypair is a single point of failure - if that one device, seed phrase, or key is compromised, everything it controls is gone. A multisig removes that single point of failure by requiring, say, 2 of 3 or 3 of 5 approved signers to agree before a transaction executes. This is why DAO treasuries, company funds, and program upgrade authorities are usually held in a multisig rather than one person's wallet: no single compromised laptop, phished signer, or departing team member can move funds or push an upgrade alone.
Notes: Most individual users stick to non-custodial self-custody wallets from the first four categories. Popularity is driven by user base (Phantom leads with millions of users), dApp compatibility, and Solana-native features. Multisigs matter once funds or authority are shared across more than one person - always verify security assumptions and use hardware wallets for the individual signers on anything holding significant value. Data reflects 2026 ecosystem trends and shifts as new wallets and tooling ship.
For following the code examples in this guide, a CLI file system keypair is enough - it's already what solana-keygen produces.
solana-keygen new --no-bip39-passphrase -o ./dev-keypair.json --force
solana-keygen pubkey ./dev-keypair.jsonThis keypair is a plain JSON file. Treat it like any other secret - never commit it, and never reuse a devnet keypair file for mainnet funds.
Any tool built for real users should be able to load the same file format the CLI produces, so you can test locally with the exact keypair a wallet would otherwise sign with.
import { readFileSync } from "node:fs";
import { createKeyPairSignerFromBytes } from "@solana/kit";
const secretKeyBytes = new Uint8Array(
JSON.parse(readFileSync("./dev-keypair.json", "utf-8"))
);
const signer = await createKeyPairSignerFromBytes(secretKeyBytes);
console.log("Loaded signer:", signer.address);Once you're testing an actual frontend, a CLI keypair can't approve a browser popup - you need an extension wallet like Phantom or Solflare installed and pointed at the same devnet cluster your code uses.
// Detect an installed browser wallet before prompting for connection
const provider = (window as any).phantom?.solana;
if (!provider?.isPhantom) {
throw new Error("Install Phantom or another Solana wallet extension");
}
const { publicKey } = await provider.connect();
console.log("Connected wallet:", publicKey.toString());Before any real value is involved, the signing key should move off a browser process and onto a hardware device, so a compromised machine can't silently drain the account.
# Point the CLI at a Ledger-backed keypair path instead of a JSON file
solana config set --keypair "usb://ledger?key=0"
solana balanceFor anything controlled by more than one person - a team fund, a DAO treasury, a program upgrade authority - the destination isn't a single hardware wallet at all, it's a multisig account that several hardware-wallet-holding signers control together.
# Conceptual - actual commands depend on the multisig tooling (e.g. Squads CLI/SDK)
# 1. Create a multisig with a signer list and threshold (e.g. 2-of-3)
# 2. Set the multisig's vault address as the program's upgrade authority
# or as the recipient of treasury funds
solana program set-upgrade-authority <PROGRAM_ID> --new-upgrade-authority <MULTISIG_VAULT_ADDRESS>// wallet-selection.ts - Solana Kit 7.0.0
import { readFileSync } from "node:fs";
import { createKeyPairSignerFromBytes, address } from "@solana/kit";
// Local dev: load a CLI file system keypair directly
async function loadDevSigner(path: string) {
const bytes = new Uint8Array(JSON.parse(readFileSync(path, "utf-8")));
return createKeyPairSignerFromBytes(bytes);
}
// Production reads: never assume a single signer - a treasury address
// may resolve to a multisig vault rather than a personal wallet
async function describeAuthority(authority: string) {
const knownMultisigVault = address("REPLACE_WITH_YOUR_SQUADS_VAULT");
const isMultisig = address(authority) === knownMultisigVault;
console.log(
isMultisig
? "Authority is a multisig vault - expect multiple approvals before changes land"
: "Authority is a single keypair - one signature is sufficient"
);
}
const devSigner = await loadDevSigner("./dev-keypair.json");
console.log("Dev signer:", devSigner.address);
await describeAuthority(devSigner.address);This is the shape most real projects converge on: a plain file system keypair for local development, a browser or hardware wallet for anything a human signs directly, and a multisig vault address - not a personal key at all - for anything the team or a DAO controls together. Your application code mostly just needs to know which kind of address it's dealing with, since a multisig vault signs the same way any other account does from the network's point of view.
Many wallets span categories - Phantom, Solflare, and Backpack all ship as both a browser extension and a mobile app. The categories describe capability, not a requirement to install five different products.
Neither is inherently safer - both store a private key on a general-purpose, internet-connected computer. A CLI keypair file is arguably more exposed since it has no popup confirmation step; either one is unsuitable for large amounts compared to a hardware wallet.
Hardware wallets are the most common form of cold wallet - a dedicated device that never exposes the private key to your computer. "Cold" more broadly just means offline; a well-managed paper wallet is also cold, just without a device's convenience.
An on-chain account that requires signatures from multiple approved keys, not just one, before any transaction it controls is considered valid.
Because trusting one person's wallet means trusting that their device is never compromised, they never leave the project, and they never make a mistake alone. A multisig spreads that risk across several independent signers.
It's the most widely used Solana-native option, but not the only approach - SPL Governance/Realms handles treasury control through DAO voting, and the SPL Token program supports setting a token's mint or freeze authority to a multisig account directly without any third-party product.
Yes - this is one of the most common uses. Setting a program's upgrade authority to a multisig vault means no single team member can push an upgrade unilaterally.
Nothing breaks immediately as long as the remaining signers still meet the threshold (e.g. 2 of 3 still available in a 2-of-3 setup). Losing enough signers to fall below the threshold, however, can permanently lock the account - choose the threshold and signer count carefully.
No. Multisigs add real friction to every transaction and exist specifically to remove a single point of failure across multiple people. For funds only you control, a well-secured hardware wallet is the appropriate step up from a hot wallet.
Not really - this guide focuses on non-custodial wallets, where you hold the key. A custodial exchange balance is controlled by the exchange's own infrastructure, which may include its own internal multisig, but you never hold a private key for it yourself.
Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, @solana/kit 7.0.0, and Squads V4 (multisig program).
Reviewed by Chris St. John·Last updated Jul 19, 2026