How to generate Solana wallets in bulk, safely and offline

The short answer

A Solana wallet is just an Ed25519 keypair, so generating hundreds of them is a local computation that takes seconds and needs no internet, no registration and no SOL. Use a tool that runs on your own device: the free SOLTidy Wallet Generator (up to 1,000 per run, in the browser), a solana-keygen new loop, or a few lines of JavaScript or Python. Then store the keys encrypted, and fund each address with at least 0.00065024 SOL, the rent-exempt minimum for a plain wallet as of November 2026.

Who needs wallets in bulk?

People who need many wallets are usually running an operation, not storing savings. The common cases:

• Testing: dozens of signers for a program on devnet or a load test.
• Airdrop and payout distribution: intermediate wallets that hold a slice of the supply, or one wallet per campaign.
• Team and payroll addresses: one receiving address per contractor, department or client, so payments are easy to reconcile.
• Bots: trading, sniping or market-making bots, each with its own signer.
• Events and paper wallets: pre-funded wallets printed on cards or QR codes and handed out.

For all of these, being able to generate fifty addresses and drop the keys into a script matters more than hardware-grade isolation. That is exactly why the storage step matters so much.

What is a Solana keypair?

A Solana keypair is an Ed25519 private and public key. The secret is 32 random bytes, often called the seed, and the public key is 32 bytes derived from it with one elliptic-curve computation. The wallet address is that public key written in base58, which is why addresses are 32 to 44 characters long and never contain 0, O, I or l.

Nothing about this touches the network. An address exists mathematically the moment it is computed, but it has no on-chain account until someone sends it SOL. There are roughly 2^255 possible keys, so two properly random keys colliding is not a practical concern.

A seed phrase is a different layer on top. A BIP39 mnemonic is 12 or 24 words that encode 128 or 256 bits of random entropy. Wallets stretch the phrase into a 64-byte seed and then derive one Ed25519 key per account with SLIP-0010, along the path m/44'/501'/i'/0', where i is the account number. Phantom, Solflare and Backpack all use that path by default, which is why importing one phrase into any of them shows the same accounts in the same order. Every level is hardened, because Ed25519 has no public derivation; you cannot derive addresses from a public key alone, as you can with an Ethereum xpub.

Which key formats do you need?

You need two formats: a JSON byte array for the CLI and scripts, and a base58 string for wallet apps. Both hold the same 64 bytes, the 32-byte secret followed by the 32-byte public key.

Format	What it looks like	Used by
JSON byte array	[174,47,154,...], 64 numbers	solana-keygen, the Solana CLI --keypair flag, ~/.config/solana/id.json, Keypair.fromSecretKey in web3.js
Base58 secret key	One string of about 87 to 88 characters	Phantom and Solflare "Import private key", Keypair.from_base58_string in solders
Seed phrase	12 or 24 English words	Any wallet's "Import recovery phrase"; recreates every derived account
Address list	One base58 public key per line	Multisenders, balance checkers, explorers; contains nothing secret

The most common mistake is pasting a CLI JSON file into Phantom, which fails because Phantom expects the base58 form. In Node.js the conversion is one line, bs58.encode(Uint8Array.from(JSON.parse(file))), but a generator that exports both saves the step.

How do the methods compare?

All five methods below generate keys locally from your operating system's secure random source; they differ in convenience, format and how easy it is to work offline.

Method	Works offline?	Formats out	Max count	Imports into Phantom?
SOLTidy Wallet Generator	Yes, after the page loads	Per-wallet JSON, combined JSON, CSV with base58, addresses TXT, seed phrase	1,000 per run	Yes, base58 from the CSV or the seed phrase
solana-keygen new in a loop	Yes	JSON file per wallet	Unlimited	Only after converting to base58
solana-keygen grind	Yes	JSON file named after the address	Unlimited (the COUNT you pass)	Only after converting to base58
JavaScript (@solana/web3.js or @solana/kit)	Yes	Whatever you write: JSON, base58	Unlimited	Yes, if you write base58
Python (solders)	Yes	Whatever you write: JSON, base58	Unlimited	Yes, if you write base58

The free command-line and script options are perfectly good if you are comfortable in a terminal. The browser tool earns its place when you want both formats, a seed-phrase mode and an address list in one click, without installing anything.

How does the SOLTidy Wallet Generator work?

I built the Wallet Generator to make bulk keys in the browser without anything leaving the page. This is what the code does:

• Independent keypairs mode calls Keypair.generate() from @solana/web3.js once per wallet. Its randomness comes from crypto.getRandomValues, the browser's cryptographically secure generator.
• Seed phrase mode generates a 12 or 24 word BIP39 phrase with @scure/bip39, then derives accounts 0 to N−1 at m/44'/501'/i'/0' with a SLIP-0010 implementation built on @noble/hashes. The BIP39 passphrase is left empty, as wallets normally do, so the phrase imports into Phantom or Solflare and shows the same addresses.
• Verification: every wallet's public key is re-derived from its secret before it is displayed. A mismatch is discarded with an error, never shown.
• Count: 1 to 1,000 wallets per run.
• Exports: a .json per wallet in the solana-keygen format, named after the address; one combined JSON array of all keys; a CSV with index,address,secretBase58 (plus a path column in seed phrase mode); and an addresses-only TXT that is safe to share.
• No network: the generator code makes no request. Files are created locally as blob downloads, nothing is written to local storage or cookies, and Clear overwrites the key bytes in memory.

One honest caveat: like every page on the site, the generator page loads Google Analytics when it opens. The generator never passes keys to it or to any other network call, and the simplest way to be sure is the offline routine below: load the page, then disconnect before you generate. The tool is free, needs no wallet connection and sends no transaction.

How do you generate wallets with solana-keygen?

Use solana-keygen new in a shell loop, with an explicit output file and no passphrase prompt. The flags below come from the current Agave keygen source:

mkdir -p wallets
for i in $(seq 1 100); do
  solana-keygen new --no-bip39-passphrase --silent -o "wallets/wallet-$i.json"
done
for f in wallets/*.json; do solana-keygen pubkey "$f"; done > addresses.txt

-o sets the file (the default is ~/.config/solana/id.json, so always pass it), --no-bip39-passphrase skips the passphrase prompt, and --silent hides the printed seed phrase, which makes each JSON file the only copy of that key. --force overwrites an existing file; leave it off so a typo cannot destroy a key.

One detail trips people up. Without --derivation-path, solana-keygen new derives the key directly from the BIP39 seed with no path, so if you note down its printed phrase and import it into Phantom, you get a different address than the one in the file. Pass --derivation-path with no value to use m/44'/501'/0'/0' and get a phrase that matches Phantom's first account.

solana-keygen grind is the CLI's vanity search, but with a one-character pattern it doubles as a fast multi-threaded bulk generator: solana-keygen grind --starts-with A:100 writes 100 keypairs named <address>.json in the current directory. --ends-with, --ignore-case, --num-threads and --use-mnemonic are also available. How long longer patterns take is covered in how long a Solana vanity address takes, and the browser version is the Vanity Address Generator.

How do you generate wallets in JavaScript or Python?

In JavaScript, Keypair.generate() from @solana/web3.js 1.x still works and gives you the 64-byte secret key directly:

import { Keypair } from "@solana/web3.js";
import bs58 from "bs58";
import { writeFileSync } from "node:fs";

const rows = ["address,secretBase58"];
for (let i = 0; i < 100; i++) {
  const kp = Keypair.generate();
  writeFileSync(`wallets/${kp.publicKey.toBase58()}.json`, JSON.stringify(Array.from(kp.secretKey)));
  rows.push(`${kp.publicKey.toBase58()},${bs58.encode(kp.secretKey)}`);
}
writeFileSync("wallets.csv", rows.join("\n"));

The newer @solana/kit (version 5.x as of November 2026) is built on Web Crypto, and its generateKeyPairSigner() deliberately creates a non-extractable private key: good for a signer that lives only in memory, useless if you need to save the key. To generate savable keys with Kit, make the 32 random bytes yourself and import them:

import { createKeyPairSignerFromPrivateKeyBytes, getAddressEncoder } from "@solana/kit";

const secret = crypto.getRandomValues(new Uint8Array(32));
const signer = await createKeyPairSignerFromPrivateKeyBytes(secret);
const keypairBytes = new Uint8Array([...secret, ...getAddressEncoder().encode(signer.address)]);

keypairBytes is the same 64-byte layout the CLI uses.

In Python, solders does the same thing: Keypair() makes a random keypair, str(kp.pubkey()) is the address, str(kp) is the base58 secret Phantom imports, and json.dumps(list(bytes(kp))) writes the CLI JSON. Keypair.from_seed_phrase_and_passphrase and Keypair.from_seed_and_derivation_path cover the seed-phrase route.

How do you generate wallets safely?

The generation itself is the easy part; the risk is in where the keys go afterwards. Follow these steps:

1. Use a clean device. A browser extension or malware that can read the page or the clipboard can read your keys, whatever tool made them. A fresh browser profile with no extensions, or a separate laptop, is a big step up.
2. Go offline to generate. Load the tool or install the CLI first, then turn off Wi-Fi and unplug Ethernet before generating. For wallets that will hold real value, an air-gapped machine with solana-keygen is the strongest option.
3. Trust the randomness source. Every method above draws from the operating system's secure random generator. Never use keys from a "brain wallet", a phrase you made up, or Math.random().
4. Save straight into encrypted storage. Move the files into an encrypted volume, an encrypted archive or a password manager that supports attachments, then confirm one key imports correctly before you fund anything.
5. Delete the leftovers. Empty the Downloads folder and the trash, clear the clipboard by copying something harmless, and close the tab. Browser downloads and cloud-synced folders are where bulk keys usually leak.
6. Split what you can. Keep the address list (public) separate from the secrets, and store a backup in a second location. For a seed phrase, a written copy offline beats a screenshot.
7. Never paste keys into a website. No legitimate airdrop checker, support agent or "wallet validator" needs your private key. The broader rules are in the Solana wallet security checklist.

One seed phrase or 1,000 random keys?

One seed phrase with many derived accounts is often safer and easier, because there is one secret to protect instead of a thousand. A single 12 or 24 word backup, written down offline, recreates every account in Phantom, Solflare or Backpack in order, and losing a file on your laptop costs nothing.

Independent keys win when wallets leave your hands. If you give a key to a bot server, a contractor or an event attendee, you must never give them the phrase, because the phrase controls every account derived from it, now and in the future. Independent keys keep each wallet separate, so a leaked file exposes exactly one wallet. A sensible split is one phrase for the wallets you operate yourself and independent keys for anything you hand out.

	One seed phrase, derived accounts	Independent keypairs
Backup	One phrase recovers all	Every key must be stored
Blast radius of a leak	Phrase leak exposes every account	One key exposes one wallet
Wallet import	Phrase shows all accounts in order	One import per key
Best for	Wallets you manage yourself	Bots, handouts, team members

How much SOL does each new wallet need?

Each new wallet needs at least 650,240 lamports, or 0.00065024 SOL, before it can exist on chain. That is the rent-exempt minimum for a plain 0-byte System account, which I checked with getMinimumBalanceForRentExemption(0) on November 4, 2026. A first transfer below that fails with an "insufficient funds for rent" error, because Solana does not allow an account to sit between zero and its minimum. The Solana docs on rent explain the rule.

Plan for more than the minimum if the wallet will do anything:

• Network fees: 5,000 lamports (0.000005 SOL) base fee per signature.
• Token accounts: 0.00148844 SOL of rent the first time a wallet holds a given token, unless the sender pays it.
• A practical number: about 0.0025 SOL covers the minimum, one token account and a few hundred transactions' fees.

To fund many wallets at once, paste the addresses-only TXT into the Solana Multisender, which fits 20 SOL recipients per transaction and charges 0.0005 SOL per recipient, and flags any line below the rent minimum before you sign. For 100 wallets, the CLI alternative is a solana transfer <address> 0.0025 --allow-unfunded-recipient loop, which costs only network fees. For token distributions, how to airdrop tokens on Solana covers the per-recipient costs.

How do you get the SOL back when you are done?

Check the set in bulk, close each wallet's leftover token accounts, then send each full balance home. The free Batch Balance Checker reads up to 1,000 addresses per run from the same TXT, so you can see which wallets still hold anything. A plain wallet can be emptied to exactly zero, which returns its 0.00065024 SOL too.

The full procedure, including the CLI loop that closes token accounts and sweeps balances across a folder of keypair files, is in how to clean up multiple Solana wallets. Keep in mind that sweeping many wallets into one main wallet links them publicly on explorers such as Solscan.

Bottom line

Generating Solana wallets in bulk is easy and should always happen locally: every wallet is 32 random bytes and an Ed25519 public key, so no legitimate tool needs a server. Pick the format you need first (JSON for the CLI and scripts, base58 for Phantom and Solflare), prefer one seed phrase for wallets you keep and independent keys for wallets you hand out, generate offline, store the result encrypted and delete the leftovers. Budget at least 0.00065024 SOL per new address. For up to 1,000 wallets with JSON, CSV and address exports in one step, use the free SOLTidy Wallet Generator; for unlimited counts on an air-gapped machine, solana-keygen is all you need.