Guides
Guides / Dark Wallet
Operational answers to the common questions: how to route only through Tor/I2P, keep receiving clean, send with intention, and move value safely through PSBT/airgap workflows.
Orientation
Decide posture before funds move.
Pick a mode and test it with trivial amounts before you trust it. Everything else builds on that decision.
Choose early: hot (keys on this machine), watch-only (monitor, no signing keys), or air-gapped/PSBT (build online, sign offline). Your workflow, device hygiene, and tolerance for inconvenience should match that pick.
- Test loop: receive a small amount, then send it out using the exact posture you plan to use in production.
- Routing discipline: ensure Force Tor / Prefer .onion is enabled and that failed routes stop traffic instead of leaking to clearnet.
- Backup realism: perform at least one restore drill with your seed + optional passphrase on a clean machine.
If a step surprises you, fix it before you add meaningful value. Predictability beats speed.
Receive
Clean inputs start with intent.
Fresh details per context, explicit tags, and predictable discovery keep your incoming funds clean and traceable to intent—not to each other.
Use Address Vault to pre-generate pools: standard, stealth, and disposable. Keep labels obvious (invoice, donor, payroll). If a contact is one-off, prefer disposable or expiring contacts in Private Address Book.
When you expect multiple deposits, widen discovery depth and test a restore that scans your chosen range. Deep ranges without a discovery drill are the most common source of “missing funds” reports.
For shared screens or recorded calls, enable balance masking and avoid exposing QR codes that are not intended for that audience.
Tags + pins
Label by purpose so future sends avoid accidental merges.
Burning
Once used, mark as burned; do not recycle for convenience.
Discovery drill
Restore on a clean host and scan your real derivation depth before trusting large deposits.
One-time shares
Use QR/print/share from Receive HUD; avoid third-party generators or screenshots stored in cloud chats.
Send
Default simple. Go deep only when needed.
Routine spending should be fast and predictable. Privacy-heavy flows should be deliberate, labeled, and repeatable.
Start with the simple send flow. If the context demands it, enable Advanced Send: coin control, split outputs, delay, hop routing, PSBT prep, and multipath broadcast.
- Coin control: pick inputs deliberately to avoid linking unrelated contexts.
- Split + delay: break deterministic shapes; stagger broadcast times to avoid “one obvious transaction.”
- Hop routing: optional intermediate hop reduces naive sender-recipient linkage.
- Fee posture: choose urgency; randomize slightly only if you understand the fee impact.
If you run PSBT/airgap, treat the “build” step as online-only and keep signing keys off the hot host. Use watch-only for visibility and broadcasting.
Advanced Send
Expose coin control, split/delay, and hop routing only when you need them.
Broadcast posture
Multipath broadcast can reduce simplistic network correlation. Expect extra latency.
Label outputs
Tag outputs by recipient or purpose to avoid later merges when spending again.
Watch-only
Keep signing keys offline while still preparing and broadcasting transactions from the hot host.
PSBT / Airgap
Build online, sign offline, broadcast with intent.
Keep signing keys on the cold device. The hot device builds, the cold device signs, then the hot device broadcasts.
1) Build on the hot host. Prepare the transaction, verify outputs/amounts/fees, then export PSBT. Keep labels intact so you can confirm purpose on the cold device without guessing.
2) Transfer safely. Move the PSBT via QR, USB you control, or a clean SD card. Avoid cloud drives and chat apps; they create copy trails and potential tampering points.
3) Sign offline. On the cold device, inspect the PSBT: destinations, amounts, change, fees. Sign only if it matches intent. Export the fully signed transaction, not the keys.
4) Return + broadcast. Import the signed transaction to the hot host. Broadcast through Tor/I2P and, if appropriate, use multipath broadcast to reduce simple network correlation.
Routing
Connectivity that fails closed.
The wallet should refuse silent clearnet fallback. Server choices should be deliberate and documented.
Enable Force Tor / Prefer .onion. Confirm behavior: if Tor/I2P is unhealthy, networking should pause, not “just work.” If you must test over clearnet, do it intentionally and turn it off after.
Decide your server posture: pin for predictability or switch for availability. If you pin, enable TLS pinning where supported and document which endpoint you expect.
If the route feels unstable, check in order: Tor/I2P health outside the wallet, system time accuracy, server status. Time drift is the most common non-obvious culprit.
Tor/I2P only
Prefer onion endpoints. Fail-closed when anonymity routing is unhealthy.
Server pinning
Consistency across sessions; re-verify pins after updates or environment changes.
TLS pinning
Reduces downgrade/interception risk on repeat connections.
Health checks
Watch for route drops; verify system time if you see repeated connection errors.
Upkeep
Maintenance that keeps you predictable.
Routine checks reduce emergencies: verify releases, rehearse restores, and document your posture so you can repeat it.
Verify every update. Compare SHA-256 against the published checksums before first run. If you pin servers or TLS certificates, confirm they remain what you expect after upgrades.
Keep secrets offline. Seeds and passphrases stay physical. No photos, no cloud notes, no chats. If you must store instructions, store the “how,” not the secret itself.
Audit local traces. Enable auto-lock, consider balance masking, clear sessions on close, and use cleanup tools if you handle sensitive contexts on shared machines.
If things break: check Tor/I2P health, system time, then server status. Reproduce on a second server before assuming wallet fault.
Contact: support@darkwallet.is. Provide posture and reproduction steps; omit sensitive material.