dgb-wallet/RESEARCH.md

DigiByte Mobile Wallet — Research Report

Compiled 2026-08-02, revised 2026-08-03. Purpose: decide the shape of a new DigiByte mobile wallet that supports BIP39 seed phrase recovery and raw private key (WIF) import, given the ecosystem's current state.

Note on Jared Tate (correction, 2026-08-03): the "founder gone" phrasing in §1 below overstates the situation. Per the user, Tate has remained active in 2025–2026. Treat the 2020 stepdown / 2023 disengagement quotes as historical, not current, and re-verify current activity before treating "founder absent" as a real ecosystem risk.

Architecture note (2026-08-03): §4 and §7 recommend Blockbook as the default backend. That recommendation is superseded by §10 — the P2P-native SPV design with user-selectable privacy modes. §4 and §7 are retained as history of the design evolution.

---

1. Is DigiByte actually dying?

Short answer: the chain is alive, the ecosystem is thin. Building is feasible; you'd be one of the more active teams in it.

• Core is maintained. DigiByte Core v8.26.2 released 2026-01-16 (previous 8.26.1 Oct 2025 shipped Taproot). Dev branch is 9.26.0.
• Founder gone. Jared Tate stepped down in May 2020, publicly disengaged in July 2023 ("$500 of DGB left, no longer meaningful involvement").
• No foundation, no funded dev org. Everything is volunteer. DGBAT (~20-person outreach team) does marketing/exchange liaison, not development.
• Market cap roughly $65–107 M — small-cap altcoin tier. Never listed on Coinbase. Still on Binance/Kraken/KuCoin as of the search snapshot (verify directly if load-bearing).
• Official mobile wallet. iOS listing id6481703766 "DigiByte - Wallet" by Sigma Systems Inc. — a replacement for the old official app (the prior repo is marked DEPRECATED---digibyteios). Newer repo digibytewallet-ios is Electrum-based; recent App Store notes mention an "Urgent Electrum blockchain connection error fix" — reliability has been actively patched but the whole thing rests on one small publisher.

Implication for us: low competition, but no external funding, small user base to distribute to, and real bus-factor risk in the wider ecosystem.

---

2. Recent hardfork — what changed, what's dead

• Last activated fork: Taproot at block 21,168,000 (2025-04-07 UTC), shipped in Core v8.22.2, productized in 8.26.0.
• Next scheduled: DigiDollar / AlgoLock at block 23,869,440 (not yet reached; defined in chainparams.cpp).

Consensus/protocol changes in the recent line:

• BIP 340/341/342 Taproot / Schnorr / MAST / Tapscript, BIP 86 descriptors, new witness-v1 HRP dgb1p….
• BIP 157/158 compact block filters (server-side).
• BIP 324 encrypted v2 P2P transport.
• Protocol version 70018 → 70019.
• Coinbase maturity dropped to 8 blocks after a height threshold.
• v8.22.0 removed legacy Odocrypt pre-fork code — anything before Odocrypt (block 9,112,320, July 2019) is on a dead fork.

Historical relevant forks: DigiShield, MultiAlgo (5 PoW algos: SHA256, Scrypt, Skein, Qubit, Odocrypt), MultiShield, DigiSpeed, SegWit (activated April 2017 — DGB was first major altcoin).

Third-party wallet compatibility right now:

• Atomic, Exodus, Coinomi, Trust, Guarda — all light/hosted, none stranded by any recent fork.
• None of them issue dgb1p… (Taproot) addresses yet. That is a genuine differentiation opening for a new wallet.

---

3. Full-node reality (why mobile can't just run one)

• Chain height: ~22.77 M blocks as of 2026-01-09.
• Block time: 15 seconds (target across 5 algos combined).
• Full node on disk: roughly 45–60 GB; pruned recommended at prune=8192 (~8 GB).
• Blocks/year: ~2,102,400 — 40× Bitcoin's rate.
• Just the header chain is ~1.8 GB (22.7 M × 80 bytes) vs Bitcoin's ~70 MB. Header download + per-algo PoW validation dominate any attempted mobile sync — this is why prior "load-all-blocks" mobile approaches failed.

---

4. Lightweight-wallet options

Approach	Verdict for DGB
BIP37 bloom-filter SPV	Defaults are off in Core 8.x (following Bitcoin's 2019 deprecation). Not recommended.
BIP157/158 Neutrino	Server-side code is in Core, but no maintained DGB fork of btcd/lnd/neutrino with DGB net params. Effectively unavailable.
Electrum-DGB servers	ibbtco/electrum-dgb-server (ElectrumX fork) exists. ~5–15 usable public servers (electrum1.cyberbits.eu:50022 etc.). Thin but usable.
Blockbook / hosted indexer	Best option. SatoshiLabs' Blockbook has first-class DGB config; Trezor Suite uses it in production. NOWNodes offers hosted. Self-host for reliability.

Recommended architecture:

┌────────────────────────────────────────────────┐
│              Mobile Wallet App                 │
│                                                │
│  Key management: bitcoinjs-lib + DGB network   │
│    - BIP39 seed (12/24 word)                   │
│    - BIP44/49/84/86 derivation (coin type 20)  │
│    - PSBT construction & signing on-device     │
│    - WIF import                                │
│                                                │
│  Never leaves the phone: keys, seed, xprv      │
└──────────────────┬─────────────────────────────┘
                   │ HTTPS + WebSocket
                   ▼
┌────────────────────────────────────────────────┐
│      Self-hosted Blockbook (DGB config)        │
│      + fallback Electrum-DGB pool              │
│      - address balance / UTXO / history        │
│      - tx broadcast                            │
└──────────────────┬─────────────────────────────┘
                   │
                   ▼
             DigiByte Core 8.26.x

Optional: background SPV header verification for trust-minimization.

Delivery estimate: weeks (hosted-indexer), not months (Neutrino port).

---

5. Seed-phrase & private-key recovery — the actual problem

The user's stated pain point: existing wallets don't reliably let you recover DGB from a seed. Findings:

DigiByte Core (desktop) — the root of the confusion

• Uses wallet.dat (BDB/sqlite) + dumpprivkey/dumpwallet RPC.
• Newer builds do expose an HD seed, but it is NOT a portable BIP39 mnemonic. The DigiByte Wiki explicitly warns: "DigiByte Core wallets cannot be restored on other BIP39-compatible apps."
• Do not copy this design. This non-portability is exactly the interoperability failure users complain about.

Third-party wallets today — the important distinction

Having a seed phrase is not the same as being able to import one. Most consumer wallets generate their own seed on first launch and only "restore" seeds they themselves issued. Verified empirically:

Wallet	Lists DGB	Can I import an external DGB seed and see my coins?	Verification status
Atomic	Yes	No — restore only accepts Atomic-generated seeds; no per-coin import; derivation path not user-visible	✅ User-verified 2026-08-03
Exodus	Yes	No — restore only accepts Exodus-generated seeds; legacy P2PKH only; no bech32; no derivation-path exposure	✅ User-verified 2026-08-03
Guarda	NO — does not list DGB	n/a	✅ User-verified 2026-08-03 (contradicts earlier research claim)
Trust Wallet	Reportedly yes	Reportedly imports a "multi-coin wallet" seed at Trust's fixed paths; no path selection	⚠️ Needs re-verification — earlier research on this table has been wrong twice
Coinomi	Reportedly yes	Reportedly yes, but often needs manual account-index tweak (…/0'H vs …/1'H); recurring support ticket	⚠️ Needs re-verification
DigiByte Go / DigiWallet (official)	Yes	Yes — BIP39 since v1.2 per README	⚠️ Repo state should be re-verified given the ecosystem's small size
Ian Coleman BIP39 tool (offline)	n/a	Yes — the community fallback when everything else fails	✅ Source-verified (hdCoin: 20)

Health warning on this table: the automated research populating the first version overstated wallet support in at least two rows. Rows marked ⚠️ should be treated as unverified until the user or a fresh, hands-on check confirms them. In particular, "wallet lists DGB" and "wallet lets you import an external BIP39 seed for DGB" are separate capabilities and the earlier research conflated them.

The ecosystem summary in one sentence: you can back up seeds from most of these wallets, but you cannot bring an existing DGB seed into the mainstream ones (Atomic, Exodus, Trust with caveats). This is the exact gap your v1 must fill.

The community's "Wallet Warning" article (Medium, pappawecho) describes a past incident where a third-party DGB wallet went offline without following BIP44 — users' seeds couldn't be restored anywhere. That is the incident your requirement is really guarding against.

Chain parameters our wallet must implement

From src/kernel/chainparams.cpp CMainParams:

Parameter	Value
PUBKEY_ADDRESS	30 (0x1E) → D…
SCRIPT_ADDRESS	63 (0x3F) → S…
SECRET_KEY (WIF)	128 (0x80) → Q/L/K compressed, 6 uncompressed
EXT_PUBLIC_KEY (xpub)	04 88 B2 1E
EXT_SECRET_KEY (xprv)	04 88 AD E4
bech32 HRP	dgb (→ dgb1q… v0, dgb1p… v1/Taproot)
Magic bytes	FA C3 B6 DA
P2P port	12024 (RPC 14022)
DNS seeds	seed.digibyte.io, seed.diginode.tools, seed.digibyte.link, seed.aroundtheblock.app, seed.tuyul.cc
SLIP-0044 coin type	20 (0x80000014)

Derivation paths to support

m/44'/20'/0'/0/x   →  D…    (legacy P2PKH)
m/49'/20'/0'/0/x   →  S…    (P2SH-wrapped SegWit)
m/84'/20'/0'/0/x   →  dgb1q…  (native SegWit v0)   ← default
m/86'/20'/0'/0/x   →  dgb1p…  (Taproot v1)          ← differentiator

Supporting all four keeps us interoperable with everything above and Ian Coleman's BIP39 tool (which has DGB in its coin dropdown at hdCoin: 20 — the community's recommended fallback).

Recovery tools users already trust (cross-check against these)

• Ian Coleman BIP39 tool — iancoleman.io/bip39, source has "DGB - Digibyte" entry
• btcrecover / seedrecover.py
• hd-wallet-derive (PHP)
• bip_utils (Python) — DigibyteMainNet

---

6. Libraries for the build

• JS (recommended): upstream bitcoinjs-lib accepts a custom Network object — pass DGB's version bytes above and you get keygen, address derivation, and PSBT for all four descriptor classes without needing a fork. Cleanest path.
• Fork alternatives: DigiByte-Team/digibytejs-lib, RenzoDD/digibyte-js (Bitcore-style).
• .NET/C++/Python: no maintained DGB-specific forks; NBitcoin and python-bitcoinlib both accept custom chain params.
• Blockbook client: SatoshiLabs ships a JS/HTTP client — WebSocket subscriptions for real-time balance updates.

---

7. Proposed build shape

Client (mobile, React Native or Flutter):

1. Onboarding: generate BIP39 12/24-word seed OR import existing seed OR import raw WIF.
2. Derive addresses at all four descriptor classes; default receive to dgb1q…, offer dgb1p… (Taproot) as an opt-in per-account setting.
3. Keys/xprv encrypted with device secure enclave + PIN; seed export available in Settings > Backup.
4. Build & sign transactions on-device with bitcoinjs-lib (PSBT).

Backend (self-hosted, one small VM):

1. DigiByte Core 8.26.x full node.
2. Blockbook (Trezor's digibyte.json config).
3. HTTPS + WebSocket exposed to mobile client.
4. Fallback list of public Electrum-DGB servers baked into the app.

Explicit non-goals (v1): no lightning, no DigiAssets, no in-app swap, no in-app buy. Ship the recovery-first wallet first.

7a. Import UX requirements (first-class, not buried in settings)

Recovery is the product's reason to exist. It gets primary onboarding real estate, not a "restore" link in a menu.

Onboarding entry points (equal weight on first screen):

1. Create new wallet (generate BIP39 12/24-word seed).
2. Import from seed phrase — accepts any BIP39 seed from any source.
3. Import single private key (WIF) — accepts Q…/L…/K… compressed and 6… uncompressed.
4. Import from xprv/xpub — for advanced users or watch-only.

"Import from seed phrase" flow — must-haves:

• Accept 12, 15, 18, 21, or 24 words (all BIP39 lengths).
• Live word-list validation and checksum verification as the user types.
• Optional BIP39 passphrase field ("25th word"), clearly labeled as optional, with a warning that it changes the wallet.
• Derivation-path selection is visible, not hidden:
  • Default: "Scan all standard paths" — derives at BIP44/49/84/86, coin type 20, accounts 0 through 4, and shows every path where funds are found. This is what solves the Coinomi account-index problem without making the user diagnose it.
  • Advanced: manual path entry (m/44'/20'/0'/0/*, etc.) for non-standard wallets and forensic recovery.
• Show the derivation path next to each discovered address in the review screen — no opacity. Users need to know what they're importing.
• Detect and warn on non-portable seeds: if the user pastes a seed that decodes as valid BIP39 but yields no addresses at any standard path, offer a "This may be a DigiByte Core wallet seed — Core seeds are not BIP39-compatible. See recovery guide." link.

"Import private key (WIF)" flow — must-haves:

• Validate base58 checksum before accepting.
• Verify the version byte is 0x80 (DGB WIF); reject with a clear message if it's 0x9E (DGB testnet), 0xEF (Bitcoin testnet), or any other prefix. Do not silently accept the wrong network.
• Detect compressed vs uncompressed and derive both P2PKH and P2WPKH addresses; check balances on both; show whichever has funds (or both if both do).
• Import as watch-with-key by default — the imported key is stored separately from the HD seed and clearly labeled as "Imported" in the account list. Do not silently merge it into the HD tree.

"Compatibility test matrix" (must pass before ship):

• Round-trip: Ian Coleman → our wallet → Ian Coleman.
• One-way import: seed generated in DigiByte Go → our wallet → balance and full history visible.
• One-way import: seed generated in Coinomi at both account-index variants (…/0'H and …/1'H) → our wallet auto-discovers both.
• One-way import: seed generated in Trust Wallet → our wallet.
• WIF export from Core dumpprivkey → wallet import → balance appears.
• Legacy-only Exodus seed → our wallet → derives D… addresses and finds funds without user having to guess the format.
• Negative test: DigiByte Core HD seed (non-BIP39) → wallet shows the warning above, does not silently produce empty addresses.

Copy positioning: the app-store one-liner is literally "Recover any DigiByte wallet from your seed phrase or private key." That's the differentiator. Lead with it.

---

8. Browser-extension variant (MetaMask / Rabby / Xverse style)

The mobile wallet solves the recovery pain. A browser extension solves the DigiDollar pain — because DigiDollar's whole promise is web-based stablecoin usage, and without a signing surface in the browser it can't have web dApps. This is exactly the position MetaMask created for Ethereum in 2016.

Is a UTXO-chain browser extension even a thing? Yes.

The MetaMask model was invented for account-based EVM chains, but the same pattern has been ported to UTXO chains successfully:

Extension	Chain	Model
Xverse	Bitcoin, Stacks, Ordinals	Chrome/Firefox extension + mobile; injects window.XverseProviders
Unisat	Bitcoin, BRC-20, Ordinals	Extension only; injects window.unisat — became de-facto for BRC-20 dApps
Leather (ex-Hiro)	Bitcoin, Stacks	Extension; PSBT signing surface
OKX Wallet	Multichain incl. BTC	Extension
Sparrow	Bitcoin (desktop, not extension)	Reference for advanced PSBT UX

For DigiByte the space is empty — there is no equivalent of any of these. That's a moat opportunity if DigiDollar picks up.

Architecture (extension shares almost everything with mobile)

┌──────────────────────────────────────────────────────────┐
│              Browser Extension (Manifest V3)             │
│                                                          │
│  Popup UI (React) — send/receive, DigiDollar mint/burn   │
│  Options page — seed backup, imports, network settings   │
│                                                          │
│  Background service worker                               │
│    - key storage (encrypted with password + WebCrypto)   │
│    - PSBT signing (bitcoinjs-lib)                        │
│    - Blockbook RPC client                                │
│                                                          │
│  Content script → injects into every page:               │
│    window.digibyte = { request, on, ... }                │
└──────────────────────┬───────────────────────────────────┘
                       │ postMessage
                       ▼
             dApp page (DigiDollar web app)
             calls window.digibyte.request(...)

Key management: same bitcoinjs-lib + DGB network params as mobile. Keys encrypted with WebCrypto (AES-GCM derived via PBKDF2 from a password), stored in chrome.storage.local. Never leaves the service worker; popup and content scripts only ever see PSBTs and signed transactions.

Manifest V3 constraints to be aware of:

• No persistent background page — service worker only. Long-running Blockbook WebSockets need reconnection logic on wake.
• chrome.storage.local has a 10 MB cap; fine for keys, but tx history should stay in IndexedDB or be re-fetched from Blockbook.
• Content-script → dApp communication via postMessage; requests must be origin-checked and user-approved in a popup, MetaMask-style.

Provider API — the DigiDollar dApp contract

Define window.digibyte (name TBD; consider window.digibyteWallet to avoid collisions) with a small, versioned interface:

window.digibyte = {
  isConnected(): boolean,
  request({ method, params }): Promise<any>,
  on(event, handler): void,
}

Core methods to ship for DigiDollar to be usable:

Method	Purpose
dgb_requestAccounts	Connect flow; returns array of {address, path} after user approves in popup
dgb_getAccounts	Cached read; returns [] if not connected
dgb_getBalance	For a given address
dgb_signPsbt	The workhorse — dApp builds PSBT, extension signs after user approval
dgb_sendPsbt	Sign + broadcast in one call
dgb_signMessage	BIP-322 message signing for auth flows
dgb_getPublicKey	For dApps building PSBTs client-side
dgb_switchNetwork	mainnet ↔ testnet
Events: accountsChanged, networkChanged, disconnect	Match EVM conventions so dApp developers coming from MetaMask feel at home

For DigiDollar-specific operations (mint, burn, transfer of the stablecoin), add higher-level convenience wrappers only after the DigiDollar spec lands — until block 23,869,440 activates the AlgoLock fork the surface area isn't final.

Delivery — extension after mobile, share the crypto core

Extract keys, derivation, psbt, blockbook-client, and network-params into a single @dgb-wallet/core TypeScript package. Mobile (React Native) and extension (React + MV3) both depend on it. This means:

• One place to fix a signing bug.
• Compatibility matrix runs against the shared core, not per-app.
• The core can also be published standalone as an SDK for DigiDollar dApp developers who want to build PSBTs without the extension.

Effort estimate

• Mobile v1 (recovery-focused, hosted-indexer): ~6–10 weeks, one engineer.
• Shared core extraction: ~1 week additional if planned from day one.
• Extension v1 (send/receive/PSBT sign + provider API): ~4–6 weeks once the core exists.
• DigiDollar-specific dApp integrations: dependent on the DigiDollar spec finalizing.

Strategic framing given DigiDollar

The decline symptom you named — no mobile wallet, hard recovery — is mostly a distribution and UX failure, not a protocol failure. Core is being maintained and DigiDollar is being built. Without a wallet that (a) any user can recover on their own and (b) any web dApp can sign through, DigiDollar ships to no one. A mobile wallet + browser extension pair, sharing one crypto core, is the smallest set of software that makes DigiDollar usable at all.

That reframes the build as "critical DigiDollar infrastructure" rather than "another altcoin wallet," which is a much stronger pitch to the DGBAT community for adoption, listing, and any grant funding that might appear once DigiDollar activates.

---

9. Open decisions for you

1. Platform mix: mobile-first (RN), extension-first (Chrome MV3), or parallel from day one with a shared TypeScript core?
2. RN vs Flutter vs native for the mobile side. RN wins if we're also shipping an extension — shared bitcoinjs-lib + core package.
3. Backend hosting: self-hosted Blockbook on a VPS (one-time setup, full control) vs paid NOWNodes (zero infra, ongoing cost)?
4. Fork vs greenfield: ignore the existing digibytewallet-ios (Sigma Systems / Electrum-based) and build fresh, or fork it?
5. Taproot (dgb1p…) support at launch: yes (differentiator, needed for DigiDollar path) or defer?
6. Extension provider-API naming: window.digibyte (short, may collide) or window.digibyteWallet (safer, longer)?
7. DigiDollar coordination: wait for the DigiDollar spec to finalize before adding stablecoin surface area, or engage DGBAT / Core devs now to co-design the provider API?

---

10. Revised architecture (2026-08-03) — supersedes §4 and §7

The earlier sections defaulted to "hosted-indexer (Blockbook)" for practical reasons — fewer moving parts, faster to ship. During review the user made a series of points that changed the default:

1. Bitcoin/DGB is a P2P system by design. Connecting to one node isn't the model; connecting to many is. Any architecture that pretends otherwise inherits centralization the base protocol doesn't require.
2. Centralized indexers (Blockbook, public block explorers) collect wallet-address queries by IP and expose full transaction histories of every address to the world. This is a real privacy regression from Satoshi's design, not a feature of the chain.
3. Pruned nodes are more capable than the industry narrative suggests — scantxoutset answers current-balance queries against the UTXO set directly, without any indexer, on a pruned node.

The revised default is a P2P-native SPV wallet with user-selectable privacy modes. Indexers remain available as an explicit convenience option, never as the default.

10.1 Reorg safety — findings

• No documented DGB reorg deeper than a handful of blocks in ~12 years of operation. April 2020 51%-attack speculation was investigated and publicly refuted by Jared Tate. No chain-explorer or post-mortem citing a deeper reorg was surfaced.
• Peer comparison: Vertcoin 307-block reorg (Dec 2018), Ravencoin X16R exploit (May–June 2020, ~$5.7 M), Litecoin 13-block MWEB reorg (25 Apr 2026). No 5-algo multi-PoW chain has been documented as 51%-attacked. DGB is essentially the only widely-observed 5-algo chain, so this is weak evidence rather than proof, but empirically the MultiShield + 5-algo defense has held.
• DGB Core MIN_BLOCKS_TO_KEEP = 288, unchanged from Bitcoin (src/validation.h:56). At 15-second block time that is ~72 minutes of chain — a much thinner wall-clock buffer than Bitcoin's ~48 hours. Empirically fine given DGB's reorg history, but worth knowing when sizing a pruned node.
• prune= semantics: value in MiB, minimum 550. Core always keeps at least MIN_BLOCKS_TO_KEEP recent blocks regardless of the disk budget. prune=550 therefore covers days of recent chain in DGB terms; you cannot practically go lower.

10.2 Dandelion++ (BIP156) — what it protects

Standard tx relay floods to all peers immediately; a network observer can identify the originating node from broadcast pattern. Dandelion++ splits relay into two phases:

• Stem phase. Tx is forwarded hop-by-hop through one random peer at a time.
• Fluff phase. At a probabilistic point (~10 hops), some node in the stem switches to normal flooding.

Effect: the fluff-origin is somewhere random along the stem, not the true origin. Passive observers cannot link the tx back to the sender's IP from broadcast timing.

What Dandelion protects — and does not:

Concern	Protected?
Passive network observer identifying originating IP	✅
Correlating multiple txs to same wallet via broadcast timing	✅ Partial
On-chain address clustering (change-address heuristics etc.)	❌
Indexer server (Blockbook / Electrum) learning your addresses	❌
Sybil attacker controlling many peers in the stem	⚠️ Degraded

Architectural consequence: Dandelion protects broadcasts that enter the P2P network directly. Broadcasting via a Blockbook HTTP endpoint bypasses Dandelion's protection for you specifically — the operator sees your IP and the raw tx before P2P relay begins, regardless of what Dandelion does downstream. Any privacy-conscious mode broadcasts through a peer relationship (own local Core, or wallet-as-P2P-participant), not through an indexer's HTTP API.

Verification pending: confirm activation height and default-on status of Dandelion in DGB Core 8.26. Server-side BIP156 support is in the Bitcoin Core lineage DGB 8.x tracks; needs source check.

10.3 Broadcast semantics — correction

Blockbook does expose a broadcast endpoint (POST /api/v2/sendtx), but it is a submission funnel, not a P2P relay participant. The flow is:

Wallet → HTTPS → Blockbook → RPC → its Core → P2P peers
                    ▲
                    operator sees raw tx + your IP + timestamp

Three consequences: Dandelion protection is defeated for you specifically (operator sees pre-relay); every user's tx goes through one operator's Core (single-point censorship risk); the operator can correlate the tx with prior address queries in the same session.

Blockbook broadcast belongs in the "Convenience mode with explicit warning" bucket, never as a default.

10.4 Architecture — default (Maximum Privacy)

┌────────────────────────────────────────────────────────────┐
│           Mobile Wallet / Browser Extension                │
│                                                            │
│  Key management (@dgb-wallet/core):                        │
│    BIP39 seed · BIP32/44/49/84/86 derivation · PSBT sign  │
│    WIF import · seed import w/ multi-path scan            │
│                                                            │
│  P2P client:                                               │
│    • Connect to ~8 DGB peers via DNS seeds                │
│    • Download block headers (~1.8 GB one-time, then trickle)│
│    • Download BIP158 compact block filters per block      │
│    • Probe filters LOCALLY against wallet's scripts       │
│    • Request only filter-hit blocks from any NODE_NETWORK │
│      peer                                                  │
│    • Broadcast via P2P (Dandelion protects origin)        │
└────────────────────────────────────────────────────────────┘
                    │
                    │ speaks native DGB P2P (BIP324 encrypted)
                    ▼
        DGB peers on the public network

Properties: no third-party server ever sees a wallet address. No single point of failure. Broadcast benefits from Dandelion. Read privacy is preserved by filter-probing locally.

Cost: 2–4 weeks of client-side work to implement P2P + BIP158 in TypeScript. Nearest bases: bcoin (JS), nakamoto/neutrino (Rust/Go). Any of them needs DGB chainparams + a light wrapper.

10.5 Architecture — optional (broadcast bastion)

Users who run their own hardware can add a small pruned DGB Core:

Wallet ──► own pruned Core (prune=550, ~600 MB)
                │
                └──► P2P peers (Dandelion)

• Broadcast privacy: only you see the raw tx before P2P entry.
• Wallet still uses P2P + BIP158 for reads; Core is broadcast-only.
• Fits on ~600 MB, runs on a €4/month VPS or a local desktop.

10.6 Privacy modes (settings)

Four modes. Shown side-by-side in first-run wizard with one-line trade-offs. Changeable any time. Current mode surfaced as an icon in the app bar; per-op badges when a request leaks to a third party.

🛡️ Maximum Privacy (default, recommended)

• Reads: P2P + BIP158
• Broadcast: P2P direct (or own Core if configured)
• No third-party server touched
• Trade-off: slower initial sync, more device work

⚖️ Balanced

• Reads (address-revealing): P2P + BIP158
• Reads (metadata: fee estimate, chain tip, mempool stats): Blockbook
• Broadcast: P2P or own Core
• Trade-off: Blockbook knows you're active, not which addresses

⚡ Convenience

• Reads: Blockbook (yours or vetted public)
• Broadcast: Blockbook or Core, user's choice
• Fastest UX
• Trade-off: Blockbook operator sees every address you query

🔧 Custom

• Per-op toggles: reads / fees / broadcast independently
• Optional Tor per surface
• One-line privacy note next to every toggle

10.7 Design principle (for future contributors)

Default to preserving the P2P properties of the chain. Make convenience the user's explicit trade-off, not our default.

Any PR that moves a read or broadcast from the P2P path to a third-party indexer must (a) be opt-in only, (b) surface the privacy consequence in the UI at the moment of use, and (c) not change the Maximum Privacy mode's behavior.

10.7a DGB has TWO version bytes per address type — recovery must handle both

Discovered 2026-08-03 during implementation cross-check against Ian Coleman's BIP39 tool. src/kernel/chainparams.cpp CMainParams on the DGB Core master branch defines four legacy-compatibility constants that matter for wallet recovery:

Constant	Value	Purpose
PUBKEY_ADDRESS	30 (0x1e)	Current P2PKH → D…
SCRIPT_ADDRESS	63 (0x3f)	Current P2SH → S…
SCRIPT_ADDRESS_OLD	5 (0x05)	Legacy P2SH → 3… (Bitcoin-compatible)
SECRET_KEY	128 (0x80)	Current WIF
SECRET_KEY_OLD	158 (0x9e)	Legacy WIF

Why this matters: Ian Coleman's BIP39 tool (the community's gold standard for offline recovery) uses scriptHash = 0x05 for DGB — the legacy prefix. Any BIP49 address it generates starts with 3…, not S…. Older Atomic/Exodus vintages, hd-wallet-derive, and various bitcoinjs-lib forks inherited the same legacy value.

On-chain reality: a P2SH output on the DGB chain is OP_HASH160 <20-byte-script-hash> OP_EQUAL — the version byte is not in the output, only in the human-readable encoding. So 3XXX… and SXXX… addresses referring to the same script-hash refer to the same on-chain output. But wallets that store addresses as strings (and query indexers by string) will silently miss funds unless they derive both variants.

The recovery failure mode our wallet exists to prevent:

1. User creates seed in Ian Coleman / older Atomic / etc → receives DGB at 3XXX… addresses.
2. Later imports that seed into a modern wallet.
3. Modern wallet only derives SXXX…, queries indexer for SXXX…, sees nothing.
4. User believes funds are gone; they are not.

Same problem class for WIF: DGB Core keeps SECRET_KEY_OLD = 0x9e for backward compat. Older private-key exports may have prefix 0x9e rather than the current 0x80. Import must try both.

Implemented fix in @dgb-wallet/core:

• network.ts exports digibyte (current), digibyteLegacyP2SH (scriptHash 0x05), and digibyteLegacyWIF (wif 0x9e).
• address.ts exports p2shP2wpkhAddressesBoth(node) returning { modern, legacy }.
• wif.ts importWif(wif) tries modern 0x80 first, falls back to legacy 0x9e, returns { keyPair, variant }.
• Recovery script now scans both P2SH variants explicitly.

Consequences downstream:

• Any indexer-facing query for a P2SH address must be issued with both version bytes when the seed came from an unknown source.
• New receive addresses generated by our wallet always use the current (0x3f / 0x80) bytes.
• UX must surface when a legacy variant successfully decoded a user's import ("This is a legacy-format key from an older DGB tool") so they aren't confused when the same key looks different in other apps.

10.7b Tor by default — a fourth design principle (added 2026-08-03)

"Every outbound socket the wallet opens goes through Tor by default. Direct connections require an explicit user opt-out with a visible warning."

Applies uniformly to all backends: P2P peers, Electrum servers, HTTP explorers, broadcast targets. No exceptions.

This tightens §10.7 from "prefer P2P over indexers" to also "prefer Tor-wrapped sockets over clear ones." Combined, they make the wallet's default privacy posture materially better than any other DGB wallet currently in the ecosystem.

Architecture:

• A single NetProvider abstraction handles all outbound TCP.
• Implementations: DirectNet, Socks5Net (any local proxy), TorNet (embedded).
• Every package that opens sockets (@dgb-wallet/p2p, @dgb-wallet/electrum, any HTTP client) accepts a NetProvider and never calls net.connect / fetch directly.

Mobile: embed Tor via libtor (Guardian Project, Android) and Tor.framework (iCepa, iOS). ~5–10 MB app size, ~5–15s bootstrap first launch (cached after).

Extension: detect Tor Browser; on Firefox use per-request browser.proxy API; on Chromium recommend Tor Browser (MV3 extensions can't easily embed Tor).

Graceful degradation: if Tor bootstrap fails, prompt user with the consequence and require explicit opt-in to direct: "Tor unavailable. Continue over direct connection? Your IP will be visible to DGB peers."

Cost accepted: +5–10 MB app size, ~5–15s first-launch bootstrap, ~300–800ms per-connection latency. All acceptable for a wallet's request profile (low-frequency reads, low-frequency broadcasts).

10.7c PKI via BCH BNS (added 2026-08-03) — supersedes the WebPKI assumption

Silent Mode's BCH Name Service (BNS) at D:\Dev\SilentMode\Argus provides the identity layer we were about to reinvent. The wallet's backend is a .dgb BNS name (product decision: rpc.dgb) whose on-chain records include ip (IPv4 to dial) and tls (SHA-256 fingerprint over DER of the server's cert).

Trust chain:

rpc.dgb BNS name
    ↓ resolveEndpoint via @dgb-wallet/bns
BCH chain (CashToken cert + OP_RETURN BNS1 records)
    ↓
{ ip, tls fingerprint }
    ↓ TLS handshake, fingerprint pinned via node:tls checkServerIdentity
VPS running DigiByte Core (disablewallet=1)

No ICANN, no CA/Browser Forum, no Let's Encrypt. Cert rotation is a single on-chain UPD tx — every wallet picks up the new fingerprint at next resolve, no client update.

.dgb TLD status: already activated in the 2026-07-30 bootstrap of tlds.bch. No TLD activation needed — just register individual names (e.g. rpc.dgb) via the existing silentmode.st/register.html flow.

Implementation:

• @dgb-wallet/bns wraps resolver-web.js from Argus. resolveEndpoint(name) returns { ip, tls } or throws if either record is missing.
• @dgb-wallet/rpc RpcClient({ bnsName, username, password }) does the lookup and pins the TLS handshake to the on-chain fingerprint. Direct-URL mode still exists as a dev escape hatch.
• ops/setup.sh provisions the VPS with a self-signed cert (no ACME), prints the fingerprint at the end, ready to paste into the BNS record.
• ops/Caddyfile.bns uses on-disk cert instead of Let's Encrypt.

Product name commitment: the wallet ships as "DigiByte.X Wallet" under the existing .X BNS TLD, distinct from other DigiByte wallets. Product-brand "Aegis" is reserved for a future multicoin wallet.

Distribution: NOT under dl.silentmode.st — Silent Mode is scoped to web infrastructure (browsers, resolvers, protocols). DigiByte.X Wallet is its own product using .dgb TLD for its own operational needs (rpc.dgb, wallet.dgb, docs.dgb, and later usd.dgb/digidollar.dgb for DigiDollar dApp surfaces).

10.8 Build order (revised, 2026-08-03)

Three tracks, each shippable in independent pieces.

Track A — Chain data (client-side privacy via BIP158)

#	Milestone	Status
A1	Peer connect + version handshake	✅ Done, 8/8 handshakes vs. real mainnet
A2	Peer discovery (DNS seeds + getaddr)
A3	Header sync (getheaders) — ~1.8 GB one-time
A4	BIP157 negotiation + BIP158 filter download	Confirmed available: several peers advertise NODE_COMPACT_FILTERS
A5	Filter probing (scripthash → hit → fetch block)
A6	Persistent header/filter cache

Track B — Broadcast

#	Milestone
B1	Broadcast via P2P (inv / tx)
B2	Dandelion++ stem/fluff

Track C — Transport privacy

#	Milestone
C1	Pluggable NetProvider transport abstraction
C2	SOCKS5 client (wallet becomes Tor-usable via external Tor)
C3	Embedded Tor on mobile (Tor by default)
C4	.onion peer discovery + onion-only mode
C5	Extension Tor story (Tor Browser detection, Firefox browser.proxy)

Track D — Persistence / UX

#	Milestone
D1	Encrypted keystore (WebCrypto)
D2	Recovery UX from §7a (mobile + extension shells)
D3	Privacy-mode toggle UI (§10.6)

Empirical facts confirmed during A1 (2026-08-03):

• DGB P2P network is alive; DNS seeds resolve to 100+ IPv4 peers.
• Chain tip observed: ~23.97M (well past DigiDollar / AlgoLock at 23,869,440 — DigiDollar has already activated on mainnet).
• Live peer versions: DGB Core 8.26.2, 9.26.4, 9.26.5.
• Protocol version 70019 accepted.
• NODE_COMPACT_FILTERS advertised by real peers — the BIP158 dependency for Maximum Privacy is real, not aspirational.
• chainparams.cpp magic bytes {0xFA, 0xC3, 0xB6, 0xDA} must be stored as integer 0xDAB6C3FA for writeUInt32LE. Common gotcha; comment left in network.ts.

10.9 Legacy build-order (superseded)

1. Now → shared @dgb-wallet/core TypeScript package. BIP39, BIP32 with DGB chainparams, BIP44/49/84/86 derivation, address encoders (D…, S…, dgb1q…, dgb1p…), WIF import/export, PSBT primitives. No node required to develop or test. Scaffolded 2026-08-03 at packages/core/.
2. Next → P2P + BIP158 client. Adapt from bcoin or write from scratch against the DGB P2P spec. Peer discovery via DNS seeds. Header sync, filter download, filter probing, block fetching.
3. Then → RPC adapter for a local pruned Core (optional bastion path).
4. Then → mobile shell (React Native) + extension shell (Chrome MV3), both depending on @dgb-wallet/core.
5. Later → Blockbook client as the Convenience-mode backend.

---

Sources

Full URLs are in the four raw research outputs (project status, hardfork, node/SPV, seed recovery). Key references:

• github.com/DigiByte-Core/digibyte (repo, releases, chainparams.cpp)
• github.com/DigiByte-Core/digibyte/releases/tag/v8.26.0 (Taproot)
• github.com/satoshilabs/slips/blob/master/slip-0044.md (coin type 20)
• github.com/trezor/blockbook/blob/master/configs/coins/digibyte.json
• iancoleman.io/bip39 (recovery cross-check)
• dgbwiki.com/index.php?title=Common_support_queries (Core non-portability)
• github.com/DigiByte-Core/digibytego (official mobile reference)