Setup guide: Wallet seed phrase storage for 100 plus sybils
Setup guide: Wallet seed phrase storage for 100 plus sybils
Managing a handful of wallets is easy. You write the seed phrases on paper, stuff them in a drawer, done. But when you scale past 50, then 100, then several hundred wallets, that approach falls apart fast. You lose track of which phrase belongs to which address, you have no reliable backup strategy, and one bad moment, a spilled coffee, a corrupted USB drive, a laptop theft, wipes out months of farming work.
This guide is for operators running 100 or more wallets across EVM chains, Solana, and Cosmos-ecosystem airdrops. You know what sybil farming is. You’ve probably already got a proxy setup and some form of browser profile rotation. The missing piece, the one that kills accounts and burns hours, is a structured, encrypted, recoverable system for seed phrase management. That’s what we’re building here.
By the end of this guide you’ll have an encrypted offline vault organized by wallet index, a backup protocol that survives hardware failure, and a retrieval workflow fast enough to use daily without cutting corners on security.
what you need
- KeePassXC (free, open source): the core vault. download from keepassxc.org
- VeraCrypt (free, open source): for an encrypted container holding the KeePassXC database file, docs at veracrypt.fr
- two USB drives, minimum 16GB each. Kingston IronKey Locker+ costs around $25-35 for 32GB on Amazon as of May 2026
- a dedicated offline machine or air-gapped partition. a $120 refurbished ThinkPad works fine
- Python 3.10+ if you plan to script wallet generation (covered in step 4)
- 2-4 hours for initial setup; 20 minutes per batch of 50 wallets after that
optional but useful: - a hardware wallet (Ledger Nano X, ~$149) for high-value farming accounts - a fireproof document bag or small safe for the USB backups
step by step
step 1: set up an air-gapped workspace
The vault machine should never touch the internet while you’re working with seed phrases. this doesn’t require a separate computer, a VM with networking disabled works, but a dedicated cheap laptop is cleaner. wipe it with a fresh Ubuntu 22.04 install and disable WiFi at the hardware level (flip the physical switch or remove the card).
install KeePassXC and VeraCrypt from their official sources before you disconnect. verify the checksums shown on each project’s download page before installing.
expected output: an offline machine with both tools installed and network access removed.
if it breaks: if Ubuntu shows network activity in a VM after you’ve disabled the adapter, shut down, reconfigure the VM’s network adapter to “not connected” rather than relying on the guest OS toggle.
step 2: create an encrypted VeraCrypt container
VeraCrypt wraps your KeePassXC database inside an encrypted volume. even if the USB is stolen, the container is unreadable without the passphrase.
# open VeraCrypt GUI, then:
# Tools > Volume Creation Wizard
# Select: Create an encrypted file container
# Volume type: Standard VeraCrypt volume
# Size: 500MB (plenty for thousands of entries)
# Encryption: AES + SHA-512 (default, fine for this use case)
set a passphrase of at least 30 characters. use a diceware-style phrase, four or five random words you can remember. write it on paper and store it separately from the USB.
expected output: a .vc file on your desktop, mountable as a drive letter (Windows) or mount point (Linux).
if it breaks: if the volume won’t mount, check that you’re running VeraCrypt as the same user who created it. permissions mismatches cause most mount failures on Linux.
step 3: create the KeePassXC database inside the container
mount the VeraCrypt container first, then create the KeePassXC database (.kdbx file) inside the mounted volume, not on your desktop.
File > New Database
Database name: wallets_main
Encryption: AES-256 (default)
Key: use a strong password, different from your VeraCrypt passphrase
create a folder structure inside KeePassXC that matches your farming workflow:
/EVM/
batch_001/ (wallets 001-050)
batch_002/ (wallets 051-100)
/Solana/
batch_001/
/Cosmos/
batch_001/
expected output: a .kdbx file inside the VeraCrypt volume with your folder tree created.
if it breaks: KeePassXC on Linux sometimes shows a blank screen on first launch after install. run keepassxc --debug from terminal to catch the error. usually a missing libxcb dependency on minimal Ubuntu installs.
step 4: generate and import wallets in batches
for EVM wallets, the fastest approach is a Python script using the eth-account library. run this on the air-gapped machine.
from eth_account import Account
import csv, secrets
Account.enable_unaudited_hdwallet_features()
wallets = []
for i in range(1, 101):
mnemonic = Account.create_with_mnemonic()[1]
acct = Account.from_mnemonic(mnemonic)
wallets.append({
"index": f"{i:04d}",
"address": acct.address,
"mnemonic": mnemonic
})
with open("wallets_batch001.csv", "w", newline="") as f:
writer = csv.DictWriter(f, fieldnames=["index", "address", "mnemonic"])
writer.writeheader()
writer.writerows(wallets)
print(f"Generated {len(wallets)} wallets")
install the dependency first: pip install eth-account. the CSV output is a temporary file only, import it into KeePassXC and then delete (shred) it immediately.
for each wallet entry in KeePassXC, use this convention:
Title: EVM_0001
Username: 0xYourAddress
Password: (leave blank)
Notes: <paste the 12/24-word mnemonic here>
URL: (leave blank)
expected output: 100 entries in KeePassXC, each titled with a zero-padded index.
if it breaks: if eth-account throws an encoding error on the mnemonic, check that your Python environment is UTF-8. add import sys; sys.stdout.reconfigure(encoding='utf-8') at the top of the script.
step 5: shred the temporary CSV
the CSV file is the most dangerous artifact in this process. don’t just delete it.
# Linux
shred -u -z wallets_batch001.csv
# macOS
rm -P wallets_batch001.csv
# Windows (PowerShell)
cipher /w:C:\path\to\folder
verify it’s gone. empty the recycle bin. if you used a VM, take a snapshot now that you can revert to, so you’re not starting from scratch for the next batch.
expected output: the CSV is unrecoverable.
if it breaks: on SSDs, shred doesn’t guarantee overwriting due to wear leveling. the safest option is to do all generation inside a RAM-disk (tmpfs on Linux) so nothing touches persistent storage.
sudo mkdir /mnt/ramdisk
sudo mount -t tmpfs -o size=100m tmpfs /mnt/ramdisk
# run your script here, output goes to /mnt/ramdisk/
# unmount when done: sudo umount /mnt/ramdisk
step 6: copy the database to both USB drives
with the KeePassXC database saved and the VeraCrypt volume locked, copy the .vc file to both USB drives. label them physically: “primary” and “backup”. store backup in a different physical location, a drawer at a friend’s place, a fireproof bag, anywhere that isn’t the same room as your main machine.
schedule a monthly reminder to sync updates to the backup USB. most operators skip this and then discover their backup is three months stale after a hardware failure.
expected output: two USB drives with identical, current .vc files.
if it breaks: if the VeraCrypt file won’t copy due to size, your USB is probably FAT32 formatted and can’t handle files over 4GB. format as exFAT or ext4.
step 7: test a full recovery
before you load up any wallets for actual use, test the recovery flow. take the backup USB, plug it into a different machine that has VeraCrypt and KeePassXC installed, mount the container, open the database, and confirm you can read five random seed phrases. if this works cleanly, your setup is operational. if it doesn’t work now, it won’t work during an emergency.
expected output: confirmed you can retrieve any seed phrase from backup within two minutes.
if it breaks: if the container mounts but KeePassXC shows “database format error”, the .kdbx file was corrupted during the copy. always copy with verification: rsync -c source.vc /media/usb/ uses checksums automatically on Linux.
common pitfalls
using a cloud password manager. 1Password, Bitwarden, and similar tools are excellent for everyday passwords. they are not appropriate for seed phrases. you’re trusting their servers, their employees, and their breach history. seed phrases go offline only.
one seed per wallet, not one seed with HD paths. many operators try to be clever and derive all 100 wallets from a single BIP-44 seed using different derivation paths. this is efficient but catastrophic when a project’s sybil detection flags one address and you need to retire the whole batch. keep each wallet’s seed independent.
no naming convention. after six months you’ll have wallets spread across five chains with no idea which KeePassXC entry maps to which farming campaign. the zero-padded index system (EVM_0001 through EVM_0100) combined with a separate spreadsheet tracking which batch is active on which protocol takes ten minutes to set up and saves hours later.
skipping the recovery test. see step 7. do this every time you set up a new vault. non-negotiable.
storing the VeraCrypt passphrase in the same place as the USB. write it down on paper, keep it physically separated. a USB with the container and the passphrase taped to it is not encrypted storage, it’s a box with the key taped to the lid.
scaling this
at 10 wallets, a KeePass database with no folder structure is fine. one file, one backup.
at 100 wallets, the system described above handles this cleanly. the main overhead is the monthly backup sync and the time to generate batches in groups of 50.
at 500+ wallets, you need to think about database size (still manageable, KeePass handles thousands of entries), but more importantly, operational workflow. at this scale most operators move to a dedicated offline machine permanently, often a cheap NUC or mini-PC that never connects to a network. retrieval becomes a daily operation, so the two-minute unlock-mount-retrieve-lock-unmount flow needs to be internalized.
the antidetect and browser profile side of the stack also gets more complex at 500+. if you’re at that scale and haven’t structured your profile management, antidetectreview.org/blog/ has reviews of the main tools used for high-volume multi-account setups that are worth reading alongside your storage setup.
at 1000+ wallets, you’re running an operation that needs team access controls. at that point, the correct answer is a dedicated secrets management system with role-based access, audit logs, and a proper offboarding process for anyone who leaves the team. that’s a different guide, but the NIST SP 800-111 storage encryption guidelines are the right starting point for thinking about the security model at enterprise scale.
where to go next
once your seed phrase vault is solid, the next operational gaps are usually wallet funding workflows and browser profile hygiene.
- how to fund 100 EVM wallets without linking them on-chain covers batched funding via intermediate wallets and timing strategies
- browser profile management for airdrop farming: antidetect setup guide walks through matching browser fingerprints to wallet identities at scale
- multi-wallet EVM farming checklist is a quick-reference list to run through before each new campaign
Written by Xavier Fok
disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.