# Seed Phrase Security -- Generation, Storage, Backup, and Recovery **Applies to:** All Solana protocol teams managing on-chain authority, treasury, or multisig signing **Audience:** Signers, signer operators, security leads, protocol founders **Related:** [[hardware-wallets]], [[signer-devices]], [[hot-wallets]], [[multisigs]], [[squads]] --- ## 1. What Is a Seed Phrase and Why It Matters A seed phrase (also called a mnemonic or recovery phrase) is a sequence of 12 or 24 English words defined by the BIP39 standard. These words encode a master secret from which all private keys for a wallet are deterministically derived. From one seed phrase, an unlimited number of key pairs can be generated using different derivation paths. **Anyone who knows your seed phrase has full, unconditional control over every account derived from it.** There is no password reset, no customer support, no recovery mechanism, and no way to revoke access. If an attacker obtains your seed phrase, they can drain every token, transfer every authority, and sign every transaction -- from anywhere in the world, at any time. ### How it works on Solana On Solana, the seed phrase derives key pairs via the BIP44 derivation path. The standard path is: ``` m/44'/501'/0'/0' ``` Where `44'` is the BIP44 purpose, `501'` is the Solana coin type, and the remaining indices identify the specific account. Each different derivation path from the same seed produces a completely different key pair. ### Solana CLI keypair files The Solana CLI uses a different format: a JSON file containing a 64-byte array (the raw secret key concatenated with the public key). This file IS the private key in raw form. It must be treated with exactly the same care as a seed phrase. ```json [174,47,154,16,202,193,206,113,199,190,53,133,169,175,31,56,...] ``` When you generate a CLI keypair with `solana-keygen new`, the tool also displays a BIP39 seed phrase for backup. Both the JSON file and the displayed seed phrase grant full access to the key. Both must be secured. **Key principle:** The seed phrase (or keypair file) is not a backup of the wallet. It IS the wallet. Everything else -- the hardware device, the software app, the browser extension -- is just an interface for using the seed. If the seed is compromised, changing your PIN, replacing your device, or switching wallet apps does nothing. The attacker has the key itself. --- ## 2. Generation -- Do It Right The security of every key derived from a seed phrase depends entirely on how the seed was generated. A seed generated in an insecure environment is compromised from birth, and no amount of careful storage afterward can fix it. ### Generate on the hardware wallet device **ALWAYS generate your seed phrase on the hardware wallet device itself.** Ledger, Keystone, and Trezor devices contain hardware random number generators (HRNGs) on their secure elements. The seed is generated, stored, and used entirely within the secure element. It never touches your computer. When you power on a new hardware wallet and select "Set up as new device," the device generates the seed internally and displays the words on its own screen for you to write down. This is the only correct way to generate a seed for protocol use. ### What NEVER to do - **NEVER use an online seed phrase generator.** Any website or web app that generates seed phrases has access to the seed. The site operator, any malware on your computer, any malicious browser extension, and any network observer between you and the server can capture the seed. Even "open source" generators running locally in your browser are vulnerable to clipboard hijacking, screen capture, and memory inspection by malware. - **NEVER use a seed phrase that came pre-printed with a device.** This is a well-documented attack. The attacker (or a compromised supply chain) pre-generates the seed, writes it on the card, and initializes the device. You think you are the only one with the seed. The attacker has it too and is watching for deposits. If your device arrived with a seed phrase card already filled in, the device has been tampered with. Do not use it. - **NEVER generate a seed on a general-purpose computer** unless absolutely necessary (e.g., for a hot wallet automation key -- see [[hot-wallets]]). Computers are complex systems with large attack surfaces. Malware, keyloggers, clipboard monitors, screen capture tools, and memory inspection can all capture a seed during generation. ### For Solana CLI keypairs When you must generate a CLI keypair (for automation, development, or hot wallet use), use `solana-keygen`: ```bash solana-keygen new --outfile ~/my-keypair.json ``` The command will display a BIP39 seed phrase for recovery. Handle it carefully: 1. Write down the seed phrase on paper immediately. 2. Clear the terminal screen after recording: `clear` 3. Clear your shell history to remove any trace: ```bash history -c # bash # or fc -p # zsh (purge history) ``` 4. If using a terminal emulator with scrollback, close the terminal window entirely. 5. Verify the keypair works by checking the public key: ```bash solana-keygen pubkey ~/my-keypair.json ``` ### Use 24 words for high-value keys BIP39 supports both 12-word (128-bit entropy) and 24-word (256-bit entropy) seed phrases. For protocol keys -- multisig signers, authority keys, treasury keys -- always use 24 words. The additional entropy provides a much larger security margin against brute-force attacks, including potential future quantum computing threats. Most hardware wallets default to 24 words. If yours offers a choice, select 24. ### Verify the seed by restoring After generating a seed and writing it down, verify that your written copy is correct by restoring it on a second device: 1. Get a spare hardware wallet (the backup device you should have anyway -- see [[hardware-wallets]]). 2. Select "Restore from recovery phrase" and enter the seed words from your written backup. 3. Derive a Solana address on the spare device. 4. Compare the derived public key with the original device's public key. They must match exactly. 5. If they do not match, you wrote down a word incorrectly. Repeat the process. 6. Wipe the spare device after verification (or keep it as your backup device). This step catches transcription errors before they become catastrophic recovery failures. --- ## 3. Storage -- The Golden Rules Storing the seed phrase is the hardest part of seed security. The seed must be available when you need it (device failure, disaster recovery) but inaccessible to everyone else at all times. Every storage medium has different failure modes. ### Rule #1: NEVER store a seed phrase digitally This is the single most important rule and the most frequently violated. No digital storage medium is acceptable for a seed phrase protecting protocol assets. **Do NOT store a seed phrase in:** | Medium | Why Not | |--------|---------| | Photos on your phone | Photos sync to iCloud/Google Photos automatically. Phone malware can access the camera roll. Screenshots are trivially accessible. | | Notes app | Syncs to cloud. Accessible to any app with notes permissions. Not encrypted at rest on most platforms. | | Cloud storage (Google Drive, Dropbox, iCloud) | Accessible via account compromise. Indexed by cloud provider. Subject to subpoena. Employee access. | | Email (even drafts) | Stored on multiple servers. Email accounts are high-value phishing targets. Drafts are backed up and synced. | | Password managers | Password managers are designed for passwords (high-entropy, randomly generated, rotatable). A seed phrase is none of these. A password manager compromise means total seed compromise. Use password managers for service credentials, not for seed phrases. | | Chat messages (Signal, Telegram, Discord, SMS, iMessage) | Messages are stored on servers and/or synced across devices. Chat apps are primary phishing and social engineering vectors. Even E2E encrypted messages are stored on the recipient's device. | | Documents (Word, Google Docs, text files) | Files are synced, backed up, indexed, and accessible to malware. | | Clipboard | Clipboard contents are accessible to every application on your system. Clipboard history managers persist copied text indefinitely. | | QR codes | A QR code of a seed phrase is a photograph of the seed phrase with extra steps. Same risks as photos. | **The digital storage rule applies to every format:** plaintext, encrypted files, zip archives with passwords, steganography in images, encoded in any scheme. If the seed exists as bits on a general-purpose computing device, it is exposed to every piece of software on that device and every cloud service that device syncs to. ### Paper backup Paper is the simplest and most widely used seed backup medium. It has real advantages: it is air-gapped by nature, it requires physical access, it cannot be hacked remotely, and it is immediately readable without any technology. **How to create a paper backup:** 1. Use acid-free, archival-quality paper if available. Standard paper degrades over decades. 2. Write with a ballpoint pen, not pencil. Pencil fades over time and can be erased. 3. Write on a hard, smooth surface (a desk, a hardcover book). Do not write on top of a pad of paper -- the pressure leaves impressions on the sheets beneath, creating additional copies of the seed. 4. Write clearly and legibly. Print in block capitals. Number each word. 5. Double-check every word against the BIP39 word list. Common errors include confusing similar words (e.g., "abandon" vs "about", "letter" vs "litter"). 6. Do not label the paper as "seed phrase" or "crypto backup" or anything that identifies its purpose to a casual observer. If desired, use a code name or no label at all. 7. Store the paper in a waterproof, fireproof container (a fireproof safe, a sealed waterproof bag inside a safe). 8. Create at least two copies and store them in separate physical locations (see Section 4). **Failure modes of paper:** - Fire, flood, water damage - Ink fading over decades (mitigated by using quality ink and paper) - Physical theft - Discovery by household members, visitors, or service workers - Natural disasters destroying the storage location ### Metal backup (recommended for high-value keys) For any key protecting significant protocol value, a metal backup is strongly recommended. Metal backups survive fire, flood, and physical degradation that would destroy paper. **Options:** | Product | Method | Material | Notes | |---------|--------|----------|-------| | **Cryptosteel Capsule** | Slide letter tiles into a steel tube | Stainless steel | Compact, tamper-evident seal available | | **Billfodl** | Slide letter tiles into a steel frame | Stainless steel | Easy to use, stores 24 words | | **Blockplate** | Punch dots into a steel plate | Stainless steel | No moving parts, very durable | | **DIY steel washers** | Stamp letters onto stainless steel washers, thread onto a bolt | Stainless steel | Cheapest option, requires a metal stamp set | **Key properties of a good metal backup:** - Survives temperatures above 1000C / 1800F (house fires typically peak at 600C / 1100F) - Waterproof and corrosion-resistant (stainless steel or titanium) - No electronics, no batteries, no moving parts that can fail - Compact enough to store in a safe or safety deposit box ### BIP39 passphrase (optional additional security) A BIP39 passphrase (sometimes called the "25th word") is an additional word or phrase that is combined with the seed phrase during key derivation. The same 24-word seed with a different passphrase produces completely different keys. Without the correct passphrase, the seed phrase alone derives a different set of addresses. **Advantages:** - If someone finds your seed words but does not know the passphrase, they access the passphrase-less wallet (which should be empty or contain only a small decoy balance), not your real accounts. - Adds a knowledge factor on top of the physical seed backup. - The passphrase can be memorized, adding a "something you know" factor to the "something you have" (the seed backup). **Risks:** - If you forget the passphrase, you lose access permanently. There is no recovery. - If the passphrase is weak (short, common word, guessable), an attacker who has the seed can brute-force it. - Adds complexity to the recovery process. Every person involved in recovery must know that a passphrase is required and what it is. **If using a passphrase:** 1. Use a strong passphrase: at least 6 random words or 20+ characters of mixed-case alphanumeric with symbols. 2. Document the passphrase separately from the seed words. Store the passphrase in a different physical location from the seed backup. 3. Test recovery with the passphrase before relying on it. Restore on a spare device using the seed + passphrase and verify the derived addresses match. 4. Inform trusted recovery contacts that a passphrase exists (without revealing it) so they know to ask for it during an emergency. **SOS recommendation:** BIP39 passphrase is SHOULD for L2, MUST for L3+. ### Shamir's Secret Sharing (advanced) Shamir's Secret Sharing (SSS) splits a secret into N shares such that any M shares can reconstruct the original, but fewer than M shares reveal nothing about the secret. **Example:** A 3-of-5 Shamir split produces 5 shares. Any 3 shares reconstruct the seed. Having only 2 shares gives zero information about the seed. **Advantages:** - No single share is useful to an attacker. Stealing one share is useless. - Tolerates loss of up to N-M shares. With 3-of-5, you can lose 2 shares and still recover. - Can distribute shares across geographically separated locations without any single location holding the full seed. **Risks and limitations:** - Adds significant operational complexity. Every recovery event requires collecting M shares from M locations. - The reconstruction process must happen on a secure, air-gapped device. If you reconstruct the seed on a compromised computer, the seed is compromised. - Not all hardware wallets support Shamir natively. Trezor Model T supports SLIP39 (Shamir backup). Ledger does not. - If shares are not labeled and tracked carefully, you may not know which shares you still have or where they are. **Recommendation:** Shamir is appropriate for L4 protocols or organizations with strong operational discipline and multiple trusted custodians. It is not recommended for individuals or small teams where the complexity may lead to recovery failures. --- ## 4. Storage Locations and Separation The physical security of seed backups depends not just on how they are stored but on where they are stored and how the locations relate to each other. ### Rule #1: The seed backup and the hardware wallet must NEVER be in the same location If someone breaks into your home and finds your hardware wallet on your desk and your seed backup in your desk drawer, they have everything. The hardware wallet gives them the device. The seed backup lets them restore on a new device even if yours is PIN-locked. The entire point of a seed backup is to recover from device loss, theft, or destruction. If the backup is in the same location as the device, a single event (theft, fire, flood, seizure) eliminates both. ### Rule #2: Have at least two copies of the seed backup in different locations A single backup in a single location is a single point of failure. Examples of single-backup failures: - Your house burns down and the backup was in a home safe - A flood destroys the storage location - You move and the backup is lost in transit - The safety deposit box institution closes or restricts access - A natural disaster (earthquake, hurricane) destroys the area **Recommended two-location setup:** | Copy | Location | Medium | |------|----------|--------| | Primary backup | Home safe, fireproof and waterproof | Metal plate + paper | | Secondary backup | Safety deposit box, trusted family member's safe, or second secure location in a different area | Metal plate or paper in waterproof container | ### Rule #3: The backup locations should survive independent disasters Both copies in the same building, or even the same neighborhood, defeats the purpose of geographic separation. A fire, flood, earthquake, or tornado that destroys one location should not be able to destroy the other. **Good separation:** - Home safe + safety deposit box at a bank in a different part of the city - Home safe + trusted family member's safe in a different city - Two safety deposit boxes at different institutions in different areas **Bad separation:** - Home safe + filing cabinet in the same house - Two copies in the same safety deposit box - Home + office in the same building ### For protocol teams Each signer's seed backup is their **personal responsibility**. The organization should never hold or have access to individual signers' seed phrases. If the organization has the seed, it is not a true multisig -- the organization can unilaterally reconstruct any signer's key. **What the organization SHOULD do:** 1. **Verify backups exist.** During signer onboarding and quarterly verification, confirm (verbally or via attestation) that the signer has created and properly stored their seed backup. Do not ask them to show it or reveal any words. 2. **Provide guidance on storage standards.** Share this document. Require that signers follow the storage rules for their SOS level. 3. **Use tamper-evident envelopes.** For L3+, require signers to store their seed backups in tamper-evident envelopes or bags. Record the envelope serial number. If the seal is broken when the signer next checks, the backup may have been accessed by someone else, and the key should be rotated. 4. **At L3+, consider dual control for accessing the seed backup.** Opening the seed backup requires two people present -- for example, the signer plus a security officer. Neither can access the seed alone. This prevents a single insider from accessing the backup covertly. 5. **Document backup locations (not the seeds themselves) in the signer register.** The register should record that "Signer A's backup is in a safety deposit box at Institution X" -- never the seed words themselves. --- ## 5. Recovery Testing A seed backup that has never been tested is not a backup. It is a hope. Transcription errors, incorrect derivation paths, forgotten passphrases, and degraded storage media are all common. The time to discover these problems is during a planned test, not during an emergency. ### How to test recovery 1. **Get a spare hardware wallet.** This should be your backup device (see [[hardware-wallets]]). If you do not have one, purchase one. 2. **Restore from the seed phrase.** Power on the spare device and select "Restore from recovery phrase." Enter the seed words from your physical backup -- read them from the paper or metal plate, not from memory. This tests whether the backup is legible and correct. 3. **If you use a BIP39 passphrase, enter it.** This tests whether you have the passphrase documented correctly and accessibly. 4. **Derive a Solana address.** Install the Solana app (for Ledger) and derive an address using the same derivation path as your original key. 5. **Compare addresses.** The public key on the spare device must match the public key on your primary device exactly. Compare the full address, not just the first few characters. 6. **Send a small test transaction.** Transfer a small amount (0.01 SOL) from the restored device to verify full signing capability. Verify the transaction on a block explorer. 7. **Wipe the spare device after testing** (or keep it provisioned as your backup device in a separate location). ### For Solana CLI keypairs If your key is a Solana CLI keypair file (JSON), test that you can restore it: 1. From the seed phrase displayed during generation: ```bash solana-keygen recover -o /tmp/test-keypair.json ``` Enter the seed phrase when prompted. 2. Compare the public key: ```bash solana-keygen pubkey /tmp/test-keypair.json solana-keygen pubkey ~/my-keypair.json ``` They must match. 3. Delete the test file: ```bash rm /tmp/test-keypair.json ``` ### Testing frequency | Event | Test? | |-------|-------| | After initial seed generation and backup creation | MUST -- do not use the key for anything until the backup is verified | | Annually | MUST for L3+, SHOULD for L1-L2 | | After moving a backup to a new location | SHOULD -- verify the backup survived the move | | After any environmental event at a backup location (flood, fire nearby, construction) | SHOULD -- verify physical integrity | | When onboarding as a new multisig signer | MUST -- verify your setup works end-to-end before being added to production | ### Document the recovery procedure Write step-by-step recovery instructions specific to your setup: - Which hardware wallet model to use - Which wallet app to connect to (Phantom, Solflare, etc.) - Which derivation path to use - Whether a BIP39 passphrase is required - Which public key(s) should result from the restoration - How to verify the restoration was successful Store these instructions alongside (but physically separate from) the seed backup. If you are incapacitated and someone else must recover your key, they need to know the procedure. --- ## 6. Seed Phrase for Solana CLI Keypairs Solana CLI keypairs require special attention because they exist as files on a filesystem, making them easier to accidentally expose than a seed phrase written on paper. ### The keypair file IS the private key A Solana CLI keypair file is a JSON array of 64 bytes. The first 32 bytes are the secret key. The last 32 bytes are the public key. Anyone with the file can sign transactions. There is no PIN, no encryption, no access control beyond filesystem permissions. ```json [174,47,154,16,202,193,206,113,199,190,53,133,169,175,31,56,222, 20,220,4,119,128,233,207,216,171,199,222,137,162,184,11,43,246, 36,211,137,108,107,33,192,123,197,126,167,13,109,45,67,133,208, 76,68,167,238,65,57,215,119,246,140,88,31] ``` ### Security rules for keypair files **NEVER commit keypair files to git.** This is the most common mistake. Once a keypair file is in a git repository -- even in a private repository -- it is effectively public. Git history preserves it even if you delete the file later. GitHub scanning bots and attackers actively search for committed keys. Add to your `.gitignore`: ```gitignore # Solana keypair files *-keypair.json id.json *.keypair # Be specific to avoid blocking legitimate JSON files !package.json !package-lock.json !tsconfig.json !*.config.json ``` **NEVER leave keypair files on development machines that also browse the internet.** A dev machine with a browser is exposed to malicious websites, browser extensions, and downloaded malware. A keypair file on such a machine is one exploit away from theft. **NEVER use the same keypair for development/testing and production.** Dev keypairs are handled casually -- copied between machines, committed to repos accidentally, left in temp directories. Production keypairs must be treated with maximum care. Using the same keypair means the casual dev handling compromises the production key. **NEVER store keypair files in cloud-synced directories.** If `~/my-keypair.json` is inside a Dropbox, Google Drive, iCloud Drive, or OneDrive folder, the file is uploaded to cloud servers and synced to every device connected to that account. **NEVER share keypair files over chat, email, or file sharing services.** If you need to transfer a keypair (e.g., to set up a hot wallet on a server), use `scp` over SSH or a similar encrypted, authenticated channel. Delete the source copy after transfer if it should not remain there. ### File permissions On Unix systems, restrict keypair file permissions: ```bash chmod 600 ~/my-keypair.json ``` This ensures only the file owner can read or write it. Other users on the system cannot access it. ### For production use Production signing keys should live on hardware wallets, not as CLI keypair files. The CLI keypair format is appropriate for: - Development and testing - Automated bot operations (see [[hot-wallets]]) - Fee payer accounts with minimal balance - CI/CD deployment keys with strictly scoped permissions For any key that controls protocol authority, treasury, or significant value: use a hardware wallet. See [[hardware-wallets]]. ### For automation and bots Automated systems (liquidation bots, keeper bots, cranks) need CLI keypair files because they cannot interact with hardware wallets. These keys should be treated as hot wallets with all the associated precautions: - Minimize the balance on the key (only enough for operations plus a buffer) - Rotate the key periodically - Monitor the key's balance and transactions - Store the keypair file with restricted permissions on a hardened server - Use a dedicated key per bot -- do not reuse keys across services See [[hot-wallets]] for comprehensive hot wallet security guidance. --- ## 7. What to Do If a Seed Is Compromised If you suspect or confirm that a seed phrase has been compromised -- someone saw it, a photo exists, it was entered into a computer, the backup was accessed without authorization -- act immediately. Do not wait to confirm the compromise. Assume the worst. ### Assume total loss **Every account derived from the compromised seed is compromised.** Not just the account you used, but every possible derivation path. The attacker can derive every key you could derive and more. There is no partial compromise of a seed phrase. ### Immediate response Execute these steps as quickly as possible. The attacker may not have acted yet, but they could at any moment. **Step 1: Generate a new seed on a new, clean hardware wallet.** Do not reuse the compromised device. If the device itself may be compromised (e.g., it was in the attacker's possession), use a brand-new device from the manufacturer. **Step 2: Transfer all assets from compromised accounts to new accounts.** Move every token, every SOL balance, every staked position. Do this from a clean, dedicated signing device. Priority order: 1. Highest-value assets first 2. Liquid assets before illiquid (because liquid assets are easiest for the attacker to steal) 3. Authority keys last (but do not delay -- see steps 3 and 4) **Step 3: If the compromised seed was a multisig member -- remove it and add the new key.** Create a signer-set-change proposal on the multisig to remove the compromised key and add your new key. This requires the other signers' cooperation. Communicate the emergency through a pre-established out-of-band channel (phone call, in-person, Signal -- not the same channel the attacker may have compromised). **Step 4: If the compromised seed controlled an authority -- transfer authority to the new key.** If the compromised key is the upgrade authority, mint authority, freeze authority, or any other on-chain authority, transfer that authority to the new key immediately. If the authority is on a multisig and the compromised key is one of several signers, the priority is removing the compromised signer (Step 3). **Step 5: Rotate any credentials associated with the compromised accounts.** If the compromised public key was used as an identity for any service (RPC access, API keys, staking provider accounts), rotate those credentials. ### Investigate After the immediate response, investigate the root cause: - How was the seed phrase exposed? (Photo, digital copy, physical theft, shoulder surfing, social engineering, compromised device) - When was it exposed? (Determines how long the attacker may have had access) - What other keys or systems may have been exposed through the same vector? - Fix the root cause to prevent recurrence. ### Report If significant value was at risk or stolen: - Report to law enforcement (FBI IC3 for US-based incidents, local cybercrime units elsewhere) - Notify affected parties (protocol users, token holders, partners) - Publish a post-incident report if the compromise affected a public protocol - Consider engaging blockchain forensics firms (Chainalysis, TRM Labs, ZachXBT) to trace stolen funds --- ## 8. Common Mistakes | Mistake | Why It Is Dangerous | What to Do Instead | |---------|--------------------|--------------------| | **Storing seed in a notes app, cloud document, or email draft** | Syncs to cloud servers. Accessible via account compromise. Indexed and searchable. | Write on paper or stamp into metal. Never digitize. | | **Taking a photo of the seed (even "temporarily")** | Photos auto-sync to cloud (iCloud, Google Photos). Accessible to any app with photo permissions. "Temporary" photos are never deleted. | Write by hand on paper. | | **Sending seed phrase over any messaging app** | Messages are stored on servers, synced across devices, and subject to compromise of either party's account. Even E2E encrypted apps store messages on the recipient's device. | Never transmit a seed phrase electronically. Share only in person or not at all. | | **Using the same seed for personal and protocol wallets** | Personal DeFi activity exposes the seed to higher risk (malicious dApps, phishing). Compromising the personal use case compromises the protocol key. | Separate seeds on separate hardware wallets for personal and protocol use. | | **Only having one copy of the seed backup** | A single point of failure. Fire, flood, theft, or loss of that one copy means permanent loss of access. | At least two copies in geographically separated locations. | | **Seed backup and device stored in the same location** | A single event (theft, fire, natural disaster) eliminates both the device and the recovery material. | Store the backup in a different building from the device. | | **Never testing recovery** | Transcription errors, wrong derivation paths, forgotten passphrases, degraded media -- all discovered only when it is too late. | Test recovery after initial setup and at least annually. | | **Using a short or weak BIP39 passphrase** | An attacker with the seed can brute-force a weak passphrase. "password", "crypto", your birthday -- all trivially guessable. | Use a strong passphrase: 6+ random words or 20+ mixed characters. | | **Storing the passphrase with the seed words** | Defeats the purpose of the passphrase. If both are found together, the passphrase adds no protection. | Store the passphrase in a separate physical location from the seed words. | | **Not wiping seed from terminal history after CLI keygen** | Shell history files (`.bash_history`, `.zsh_history`) persist the displayed seed phrase. Anyone with access to the machine can read the history file. | Clear history immediately after keygen. Close the terminal window. | | **Keeping keypair JSON files on dev machines indefinitely** | Dev machines browse the internet, run untrusted code, and have large attack surfaces. A keypair file on a dev machine is one exploit away from theft. | Move production keypairs off dev machines. Use hardware wallets for production. | | **Importing seed into software wallets "just to check something quickly"** | The moment you enter a seed into a software wallet (Phantom, Backpack, Solflare as browser extension), the seed is decrypted in browser memory. Malware, extensions, and memory dumps can capture it. The seed is now as vulnerable as the least-secure device it has touched. | Never import a hardware wallet seed into a software wallet. Use the hardware wallet directly. | | **Sharing seed words with a "trusted" colleague or support agent** | No legitimate support agent will ever ask for your seed phrase. "Trusted" colleagues can be compromised, coerced, or may leave the organization. Once shared, the seed is no longer solely under your control. | Never share your seed phrase with anyone, for any reason. | | **Not adding keypair files to .gitignore** | A single accidental `git add .` commits the keypair to the repository. Git history preserves it permanently. Attackers and bots scan repositories for committed keys. | Add keypair patterns to `.gitignore` before creating any keypair files in the project. | --- ## Relevant Controls The following controls from the [[general/control-registry|Control Registry]] apply to this topic. Refer to the Control Registry for level-specific requirements (L1/L2/L3/L4). See the Control Registry for applicable controls related to this topic. --- ## References - [BIP39 Specification](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) - [BIP44 Specification](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) - [SLIP39 (Shamir's Secret Sharing for Mnemonics)](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) - [Solana Key Management Documentation](https://solana.com/docs/cli/manage-stake-accounts) - [[hardware-wallets]] -- Hardware wallet selection, setup, and operational use - [[signer-devices]] -- Dedicated signer device setup and maintenance - [[hot-wallets]] -- Hot wallet security for automation and bots - [[multisigs]] -- General multisig security principles - [[squads]] -- Squads Protocol v4 configuration and security