Docs

Documentation / Dark Wallet

Procedure-first documentation: verify installs, enforce Tor/I2P-only routing, keep keys off the online host, and run privacy workflows predictably.

Verify releases Tor / I2P only (fail-closed) PSBT / Watch-only / Airgap

Getting started

Baseline posture before you fund.

Your goal is predictable behavior: keys stay where you intend, routing does not leak to clearnet, and address hygiene behaves consistently.

Dark Wallet is built around three operational primitives: Tor/I2P-only connectivity, disciplined receiving hygiene, and controlled sending that becomes “deep” only when you opt in.

Choose your operating mode early:

  • Hot wallet: keys on the online machine. Use only for small, routine spending.
  • Watch-only: monitor balances and generate receive details without private keys present.
  • Air-gapped (PSBT): build online, sign offline, broadcast intentionally.

Before depositing meaningful funds, run a full dry cycle: receive a small amount, then send a small amount using your intended posture (hot or PSBT/airgap). Confirm Tor/I2P routing is enforced and your backup process is realistic under pressure.

Install & setup

Verify the binary. Verify the route. Verify the server.

Installation is not “download and click.” Confirm release integrity, then ensure networking remains Tor/I2P-only with fail-closed behavior.

1) Verify release integrity. Compare your local SHA-256 with the published checksums from the release source. This is the primary defense against compromised mirrors and poisoned download paths.

2) Confirm Tor/I2P-only routing. Dark Wallet is designed to refuse silent clearnet fallback. If the anonymity chain is unhealthy, networking should pause until it is restored (fail-closed). Expected behavior is “no traffic,” not “quietly works.”

3) Establish Electrum connectivity posture. Decide whether you want predictable repeatability (pin a server) or routine rotation (switch as needed). Where supported, enable TLS pinning for recurring connections. Unexpected pin changes should be treated as a security event until proven benign.

Force Tor / Prefer .onion

Enforce anonymity routing and prioritize onion endpoints where available.

Fail-closed routing

On route instability the wallet stops networking; it does not degrade into clearnet.

Server switching

Switch quickly if a node degrades; switching remains within Tor/I2P.

Server pinning + TLS pinning

Use for stable sessions. Treat unexpected changes as suspicious until explained.

If you see repeated disconnects, check in this order: Tor/I2P health, system time correctness, then server stability. Time drift is a common cause of “everything looks broken” in security-sensitive setups.

Backup & recovery

Recovery is a procedure, not a screenshot.

Your backup plan must work on a clean machine, under pressure, with minimal judgment calls.

The recovery phrase (and any optional passphrase you set) is the highest-value secret in your stack. Store it offline. Do not type it into chat, email, cloud notes, or support forms. Do not photograph it.

If you run an air-gapped posture, keep signing keys exclusively on the cold device. The online machine remains useful as watch-only: monitor balances, build PSBT, and broadcast signed results. This preserves convenience without placing keys on the highest-risk host.

If you use large address pools (deep derivation ranges, stealth/disposable pools), perform a restore drill to confirm discovery works end-to-end. Incomplete discovery is usually a scanning posture issue, not “funds disappeared.”

  • Back up: recovery phrase; passphrase (if used); written restore steps.
  • Do not back up digitally: phrase photos, plaintext seed files, copied private keys.
  • Practice: at least one dry restore before meaningful deposits.

Security model

Threat surfaces mapped to controls.

What Dark Wallet enforces by design, and where your operational decisions remain decisive.

Dark Wallet prioritizes a strict network posture: Tor/I2P-only, explicit route visibility, and fail-closed behavior. This is meant to reduce IP and metadata leakage even during unstable routing.

For recurring connectivity, server pinning provides predictable behavior across sessions. TLS pinning reduces downgrade and interception risk when returning to the same endpoint. If a pinned profile changes unexpectedly, treat it as suspicious until you can explain it.

On the wallet side, hygiene is a workflow: Address Vault pre-generates pools of standard, stealth, and disposable receive details; supports deep scanning across large index ranges; and marks used addresses as burned to reduce reuse. Private Address Book keeps contacts local and supports expiry/autopurge.

Network metadata

Tor/I2P-only routing + fail-closed reduces IP/metadata leakage under failure.

Connection integrity

Server pinning + TLS pinning for repeatable, less interceptable recurring connections.

Linkability hygiene

Address pools, burned marking, tags/pins, contact expiry, and controlled send features reduce unintentional linkage.

Key safety

Airgap/PSBT isolates keys from the online host. Watch-only preserves visibility without signing exposure.

Recipient-side identity and behavioral patterns can still deanonymize you. The model here is “reduce preventable leakage,” not promise impossibilities.

Security

Operational playbooks.

Procedures for receiving, sending, and minimizing local traces—where defaults become routine discipline.

Receiving: issue a fresh receive detail per counterparty/context. Use Address Vault tags to keep intent explicit (invoice, donor, savings). Treat burned addresses as non-fresh. Use Receive HUD to generate QR, copy, print, or save an image without third-party generators.

Contacts: Private Address Book keeps entries local. Prefer expiring contacts and one-time QR sharing for low-linkability workflows. If a contact is truly “one-off,” let it auto-purge after use.

Sending: keep the default flow simple, and opt into depth only when needed. Advanced Send can expose coin control, split sends, fee randomization, delayed broadcast, optional hop routing, PSBT preparation for offline signing, and multipath broadcasting to reduce simplistic network-correlation heuristics.

Local traces: enable auto-lock, consider balance masking on shared screens, clear sessions on close, and use cleanup tools to remove local residue. A strict network posture does not help if the host preserves sensitive traces.

Coin control

Reduce accidental linkage by selecting inputs deliberately instead of letting convenience decide.

Split + delay

Break deterministic patterns: split outputs, vary timing, and avoid “one obvious transaction shape.”

Hop routing

Optional internal hop before the final recipient can reduce naive sender-recipient correlation.

Multipath broadcast

Propagate raw tx via multiple nodes/timers to make simple network analysis less reliable.

Contact

Support inputs that don’t leak secrets.

Provide reproducible symptoms and posture, not private material. This makes troubleshooting faster and safer.

When reporting issues, include: app version, OS, whether you route via Tor or I2P, whether Force Tor / Prefer .onion is enabled, and whether you use server pinning or TLS pinning. Add the exact error text and the steps to reproduce.

For security reports: describe impact, reproduction steps, and the earliest version you suspect is affected. Avoid doxxing yourself. Do not paste complete address histories unless necessary for analysis.

If the issue is “routing feels unstable,” include: whether Tor/I2P is healthy outside the wallet, whether system time is accurate, and whether the problem reproduces across multiple servers.

Email: support@darkwallet.example

Changelog

Release notes, operationally.

What changed, why it matters, and whether you need to do anything.

Release

v0.9.3

Stability + routing posture Published:

This release focuses on keeping network behavior predictable under adversity: better route health detection, clearer state in the UI, and safer failure handling when Tor/I2P is unstable.

Area
Change
User action
Connectivity
Improved Tor/I2P health checks and fail-closed consistency. Clearer route visibility during reconnects.
Re-check pinned servers if you rely on pinning across environments.
Server pinning
Safer handling of TLS pins and reduced “silent accept” behavior for unexpected endpoint changes.
If a pin changes unexpectedly, treat it as a security event until explained.
Address Vault
More robust deep-scan coverage for large derivation ranges. Clearer burned marking and export reliability.
If you maintain large pools (thousands of indices), run a restore/discovery drill.
Advanced Send
Clearer labels and guardrails for split/delay/hop and multipath broadcast workflows.
No action required. Optional modes may increase fees.

Notes

  • Privacy controls can reduce simplistic correlation; they do not guarantee anonymity.
  • Host compromise defeats wallet guarantees. Prefer PSBT/airgap for meaningful balances.
Release

v0.9.2

Hygiene + UX clarity Published:

Improvements to receiving hygiene defaults, fixes across PSBT import/export, and clearer warnings around optional obfuscation controls.

  • Receive HUD: clearer address format labeling (Native SegWit / P2SH / Legacy).
  • Sanitizer: more consistent session clearing on close.
  • Docs: updated operational checklists for routing and backups.

Upgrade discipline

Verify checksums before first run after every update. If you use pinned servers or TLS pins, validate that your expected endpoint identity still matches your posture. Unexpected pin changes should be treated as a security event until explained.

Report regressions

Include: version, OS, Tor/I2P posture, whether Force Tor / Prefer .onion is enabled, pinning status, and exact error text. Never send seeds or private keys.