Types of Wallets

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.

What Is a Solana Wallet?

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.

Key Terms

Why Wallet Type Matters

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.

Main Types of Solana Wallets (as of 2026)

1. Hot Software Wallets (Browser Extensions / Web / Desktop Apps)

Internet-connected apps and extensions for daily use, dApps, trading, NFTs, and staking. Convenient but less secure for large holdings.

Top popular ones:

• Phantom - Most popular overall, multi-chain, excellent UX, NFTs, and dApp integration.
• Solflare - Strong Solana-native focus, advanced staking/DeFi, hardware support.
• Backpack - Power users, xNFTs, advanced tools.
• Glow - iOS-friendly, Solana-native with swaps/staking.
• Others (e.g., Jupiter Wallet, Exodus) - Trading-focused or multi-chain options.

2. Mobile Wallets

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:

• Phantom (mobile app)
• Solflare (mobile app)
• Backpack (mobile app)
• Trust Wallet or Coinbase Wallet (multi-chain with strong Solana support)
• Glow or others like TokenPocket/FoxWallet.

3. Hardware / Cold Wallets

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):

• Ledger (Nano S, Flex, Stax, etc.) - Most widely used, integrates with Phantom/Solflare.
• Solflare Shield - Native mobile-first cold storage.
• Keystone - Air-gapped QR signing.
• Trezor (Model T/Safe) - Good multi-chain support.
• Tangem or OneKey - Card-style or open-source alternatives.

4. CLI / File System Wallets

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):

• Solana CLI default file system keypair, e.g. ~/.config/solana/id.json.
• Paper wallets, generated via CLI tools and kept entirely offline.
• Hardware integration with the CLI (e.g., signing with a Ledger from solana commands).

5. Multisig Wallets (Team / DAO / Treasury Use)

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:

• Squads (squads.so) - The dominant Solana-native multisig/smart-account protocol, used by many DAOs, protocol treasuries, and program upgrade authorities.
• SPL Governance / Realms - The Solana Foundation's on-chain governance program; DAOs use it for treasury control and proposal voting, which functions similarly to a multisig with a voting threshold instead of a fixed signer list.
• SPL Token native multisig - Not a standalone app, but a feature of the SPL Token program itself: a token's mint or freeze authority can be set to an M-of-N multisig account directly, independent of any third-party product.

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.

Step-by-Step Walkthrough

Step 1: Pick a wallet for local development

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.json

This 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.

Step 2: Read the same keypair from code

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);

Step 3: Add a browser wallet for dApp testing

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());

Step 4: Move meaningful funds to a hardware wallet

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 balance

Step 5: Move shared or high-value funds to a multisig

For 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>

Putting It Together

// 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.

Common Beginner Mistakes

• Keeping meaningful funds in a hot browser wallet long-term - browser extensions are the most common phishing target in the ecosystem. Fix: treat hot wallets as spending money, and move anything you'd be upset to lose to a hardware wallet.
• Losing the seed phrase, or storing it digitally - a screenshot or cloud note of a seed phrase is one data breach away from a fully compromised wallet. Fix: write it down physically, store it offline, and never type it into a website.
• Assuming a hardware wallet alone is enough for a team fund - one hardware wallet is still one point of failure if that one person leaves, loses the device, or is compromised. Fix: use a multisig once more than one person needs control, not just a "better" single wallet.
• Treating a multisig as a substitute for good key hygiene per signer - a 2-of-3 multisig where all three signers store their keys the same insecure way isn't much safer than one wallet. Fix: each individual signer should still follow hardware-wallet-grade practices.
• Reusing a devnet CLI keypair as a mainnet signer "just this once" - the keypair works on both, so it's easy to do by accident. Fix: keep separate keypair files per cluster, matching the guidance in Clusters & Networks.
• Approving a multisig transaction without independently reading what it does - rubber-stamping proposals defeats the purpose of requiring multiple signers. Fix: every signer should decode and verify a proposal before approving, not just trust that someone else checked.

FAQs

Related

• Wallets & Explorers - devnet workflow, faucets, and reading Solana Explorer
• Keypairs & Addresses - how the keypair every wallet type wraps actually works
• Clusters & Networks - matching wallet network selection to the right cluster
• RPC Providers - the endpoint your wallet or app talks to when it reads or sends on your behalf

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).