fix(custody)!: a second node-side USER custody + signing surface survives in dig-wallet's self-origin UI

[MichaelTaylor3d]

Task

A SECOND node-side USER custody + signing surface survives in crates/dig-wallet/src/lib.rs — the
self-origin wallet UI (SPEC §16.3). It is a rival implementation of exactly the capability removed by
#325, and it was never covered by the #1701 freeze.

Evidence

• lib.rs:369 POST /api/import — validates a mnemonic, seed_store::encrypt_seed(&m, &req.password),
  writes it to seed_path(), opens a signing session.
• lib.rs:409 POST /api/unlock — seed_store::decrypt_seed(&bytes, &req.password) → session.
• lib.rs:510 POST /api/send — builds and BLS-signs a standard XCH payment; broadcast:true pushes
  it to mainnet.
• lib.rs:1049 onward — the CHIP-0002 dapp signer: chip0002_signMessage, chip0002_signCoinSpends,
  chia_signMessageByAddress.

The freeze commit 2ce8002c touched sage/auth.rs, sage/custody.rs, sage/rpc.rs, seed_store.rs,
wallet_authz.rs and meta.rs — none of this.

Why it was NOT removed alongside the Sage plane

The zero-population measurement does not cover it. Step 2 of dig_ecosystem#1701 counted custody
manifest blobs (<config_dir>/wallets/), not seed_path(). Deleting this surface without its own count
carries the exact funds-loss risk the parent ticket's freeze-then-count sequence exists to prevent.

Deliverable

1. COUNT first, over seed_path(), on the same machines. Report the number.
2. If zero, remove the surface and its CHIP-0002 signer, mirroring dig-node#325.
3. If non-zero, an offline export path before removal, per the parent ticket's step 3.

Either way §908 — the node signs NOTHING on the user's behalf — is not whole until this closes.
SPEC.md §18.20 currently names this gap explicitly rather than claiming §908 is satisfied.

Parent

https://github.com/DIG-Network/dig_ecosystem/issues/1701

Sibling

#325

[MichaelTaylor3d]

Step 1 — the count, over seed_path()

USER-CUSTODY POPULATION = 1. Not zero. The ticket's branch 3 applies, not branch 2.

Six blobs exist at a seed_path() location across the four machines. Five are the node's own
autoseed operator identity. One is a user-password-sealed wallet, on the Windows workstation.

machine	blobs	autoseed operator	USER custody	how established
Windows workstation — %LOCALAPPDATA% (TDS1\micha)	1	1	0	measured (meta read, device key matched)
Windows workstation — %LOCALAPPDATA% (LocalSystem service profile)	1	1	0	metadata-settled; file contents UNREADABLE — see below
Windows workstation — C:\Users\micha\DigWallet	1	0	1	measured
us-east-1 i-05b64ca6d66419cc1	1	1	0	measured
eu-west-1 i-0bd47ab60b7153cb4	1	1	0	measured
ap-southeast-1 i-0f3506c9c99145e83	1	1	0	measured
total	6	5	1

No machine returned an unreadable directory. Every zero above is a measured zero. The one partial
is a file-content read, and it is argued out below rather than assumed away.

---

The resolved seed_path()

crates/dig-wallet/src/lib.rs:199-205, verbatim:

/// Path to the encrypted seed file (per-user, off the profile dir).
fn seed_path() -> PathBuf {
    let base = std::env::var("LOCALAPPDATA")
        .or_else(|_| std::env::var("HOME"))
        .unwrap_or_else(|_| ".".to_string());
    PathBuf::from(base).join("DigWallet").join("seed.bin")
}

Byte-identical since the #209 import (a0b54e7, 2026-07-02) — checked across every revision of the
file, so no historical blob can sit at a different spelling of this path.

It does not match custody.rs's layout at all. No <config_dir>, no wallets/, no <id>.seed.
Four resolutions:

platform / context	resolves to
Windows, interactive user	%LOCALAPPDATA%\DigWallet\seed.bin
Windows, service as LocalSystem	C:\Windows\System32\config\systemprofile\AppData\Local\DigWallet\seed.bin
Unix with HOME	$HOME/DigWallet/seed.bin
neither var set	./DigWallet/seed.bin — cwd-relative

On the whole standing fleet it takes the fourth branch. The packaged unit sets ProtectHome=true
and exports neither HOME nor LOCALAPPDATA — read from /proc/<MainPID>/environ on each box, which
carries only USER=root — and cwd=/. So the wallet lands at /DigWallet/seed.bin, at the root of
the filesystem, with /DigNode/device/device.key beside it. Identical on all three boxes. That is
worth its own ticket independently of this one.

---

How the three categories were told apart

Test fixtures — excluded, 0 blobs. seed_path() always ends in DigWallet/seed.bin, so the
complete predicate is a directory named DigWallet, not a file named seed.bin. A whole-C: sweep
found 4 such directories. Exactly one is under %TEMP% — ...\Temp\.tmpJnh979\DigWallet, a
tempfile crate dir matching the shape dig-node-service/tests/never_log.rs:129-132 creates — and
it is empty; it holds no seed.bin. So this store's fixture contribution is zero by enumeration
rather than by exclusion rule. The 4014 PID-suffixed files the earlier sweep found belong to the
custody.rs store and appear at no DigWallet path. (949 .tmp* dirs exist in %TEMP%; one has a
DigWallet child.)

autoseed operator identity — excluded, 5 blobs. Discriminated on three independent signals, all
present on all five:

• a wallet.meta.json sidecar reading {"origin":"auto", ..., "ever_funded":false};
• a 32-byte device.key at the sibling <base>/DigNode/device/, which WalletPaths::resolve only
  ever creates on the mint path;
• seed.bin mtime equal to — or 2s after — device.key mtime, the documented mint ordering with the
  key written first and the Argon2id seal in between.

The ever_funded: false latch on all five is autoseed's own monotonic record that a non-zero
balance was never once observed on any of them.

The LocalSystem blob — settled by metadata, NOT by a content read. Its seed.bin and
wallet.meta.json are ACL'd owner-only (write_new_owner_only), so as TDS1\micha I can enumerate
the directory and stat both files but cannot read either; Get-Acl on the file is refused too.
I am not reporting a content read I did not perform. What the metadata does settle:

• seed.bin, wallet.meta.json and the sibling DigNode\device\device.key all carry
  CreationTime == LastWriteTime == 2026-08-21 03:57:19, to the second.
• POST /api/import writes seed.bin via std::fs::write and never touches device.key. Any
  import over this blob would therefore leave seed.bin strictly newer than device.key. It does
  not. The blob has not been rewritten since it was minted — which is the property that matters,
  and it is the one thing an import could not hide.
• wallet.meta.json is 94 bytes, byte-for-byte the length of the micha-profile sidecar that
  reads origin: "auto" with a 7-fractional-digit timestamp. "imported" is +4 bytes,
  "auto-acknowledged" +13. 94 pins it to "auto".

Treat that as high-confidence, not proven. One elevated read settles it outright — Get-Content
on that wallet.meta.json plus the first 6 bytes of that seed.bin. I did not attempt elevation.
This one is worth settling rather than waving through: the node runs as LocalSystem, so its
%LOCALAPPDATA% is the SYSTEM profile, and a user typing a password into the loopback UI at
127.0.0.1:9777 would land their wallet in exactly this directory. It is the one place on a Windows
install where real user custody is structurally reachable. If it turns out to be user custody the
population is 2 and the recommendation below does not change.

---

The one user-custody blob

C:\Users\micha\DigWallet\seed.bin
  size      248 bytes
  created   2026-06-26 20:09:00
  modified  2026-06-26 22:00:19    <- written at least twice, 1h51m apart
  1st byte  0x01                   <- legacy digstore_chain::seed::EncryptedSeed
  siblings  none (no wallet.meta.json, no connections.json, no wallet-source.json)
  no DigNode\device\ exists anywhere under C:\Users\micha

Every signal points the same way:

• Legacy format. First byte 0x01 is the EncryptedSeed version constant, not one of
  DIGVK1/DIGLW1/DIGOP1. autoseed only ever writes DIGOP1, so this cannot be a minted blob.
• No device key exists for that base, so nothing machine-held can open it. It is sealed under a
  user password.
• No wallet.meta.json. The crate's own rule (read_meta) is that an absent sidecar reads as
  Imported, not Auto, "because the dangerous direction of this question is the one that discards
  funds". Its funded state is therefore unknown — the ever_funded: false evidence covering the
  other five does not exist for this one, and cannot be reconstructed without the password.
• Written twice, nearly two hours apart — not a single-shot artifact.

It predates the dig-keystore migration and the #209 import, i.e. the dig-companion era. It sits at
the HOME/cwd branch, so a current build on that machine never looks at it — seed_path()
resolves to %LOCALAPPDATA%\DigWallet there. It is already orphaned from the product.

---

Sweep completeness — stated honestly

• Per-account enumeration is complete. Every profile under C:\Users, plus all four service
  profiles (systemprofile x2, LocalService, NetworkService), was checked directly at its
  LOCALAPPDATA\DigWallet. That is where seed_path() actually resolves, and none was unreadable.
• The whole-disk C: sweep is a floor, not exhaustive. It hit 364 access-denied directories
  ($Recycle.Bin, Config.Msi, PerfLogs, WindowsApps, Dell service stores, docker
  windowsfilter layers, C:\ProgramData\DIG, C:\ProgramData\DigNetwork). None is a plausible
  LOCALAPPDATA/HOME/cwd for a wallet process, but I will not call zero what I could not read.
• The K: volume sweep is still running and is not included above. It is a secondary data
  volume; a blob could only land there if a process ran with cwd or HOME on it.
• Fleet sweeps are complete for the root filesystem. find / -xdev returned zero permission
  errors on all three boxes; /root, /var/lib/dig-node and /home/ubuntu were each confirmed
  readable-and-absent rather than silently skipped. /boot and /boot/efi are separate mounts and
  were not traversed.
• C:\ProgramData\DIG is the updater status dir, not custody — confirmed again, and its DACL
  denial is again a red herring here.

Nothing was disturbed. net.dignetwork.dig-node read ActiveState=active SubState=running NRestarts=0 with an unchanged MainPID before and after on all three fleet boxes. Read-only
throughout: no blob was read into memory beyond its first 6 bytes, and none was moved, zeroized or
deleted anywhere.

---

Can the surface be removed safely?

Not as-is. Step 3's recovery path is required first — the count is non-zero, which is exactly the
condition the parent ticket wrote step 3 for.

The risk is narrower than "deleting the code deletes a key", and worth stating precisely:

1. Removal destroys no bytes. The blob survives on disk either way.
2. Removal destroys the only reader. POST /api/export (lib.rs:1026, routed at :3846) is the
   sole mnemonic-recovery path in the entire repo — there is no CLI equivalent anywhere in
   dig-node-service or dig-node-core. Take it out and the blob becomes bytes that nothing shipped
   can ever open again.

Two traps a step-3 CLI written today would fall into, both caused by the specific blob that is
actually in the population:

• It must decrypt the LEGACY format. The one blob is 0x01-prefixed, not DIGOP1. A CLI built on
  opaque::open fails on 100% of the real population. It has to go through
  seed_store::decrypt_seed, which dispatches on magic and keeps the legacy path alive.
• It must accept an explicit --path. The blob is at C:\Users\micha\DigWallet\seed.bin, which
  is not where seed_path() resolves on that machine. A CLI that reads only seed_path() cannot
  see the one thing it exists to rescue.

Also binding on the removal — all of it already implied by seed_store.rs's own module doc:

• Keep seed_path(), seed_store and autoseed. Five of the six blobs are the node's own live
  operator identity, minted and opened on every start by dig-node-service
  (entrypoint.rs:965, win_service.rs:126 → wallet_bootstrap::ensure_wallet_seed()).
• The 9777 HTTP plane is not served by the node service. dig_wallet::run() is spawned by
  dig-runtime (crates/dig-runtime/src/lib.rs:86) and by the standalone dig-wallet binary;
  dig-node-service links the crate only for sage::* chain reads and mTLS. On this workstation
  9777 is not listening — dig-node holds 9776/9778/9444/9445 only. The surface's blast radius is
  dig-runtime and the standalone binary, not the node service.
• Whatever replaces /api/export must be an offline CLI, not a served RPC. The parent ticket
  rejected a served wallet.export_seed because a permanent exfiltration capability is the wrong
  price for a one-time rescue — and /api/export is precisely that served shape, which is one more
  reason it should not survive removal.

Recommendation

Run step 3, scoped to what the count actually found: an offline dig-node wallet export-seed [--path <file>] that goes through seed_store::decrypt_seed, prints to console, adds no network
surface, and is deleted in the same PR as the surface it rescues. Prove it once against the real blob
— export, re-import into dig-app, derived address matches — and only then remove.

Do not zeroize or delete that file as part of this work. It is the only copy of whatever it holds,
nothing on that machine reads it today, and it costs nothing where it sits.

_{Measured 2026-08-23. Parent: https://github.com/DIG-Network/dig_ecosystem/issues/1701 · sibling: #325}

[MichaelTaylor3d]

Closing the one gap left open above: the K: volume

K: holds zero DigWallet directories. The sweep completed and returned none.

Same caveat as the whole-disk C: pass: that sweep suppressed access errors without counting them,
so it is a floor rather than a proof. It does not move the number either way — K: is a secondary
data volume, and seed_path() could only land there via an unusual cwd or a HOME pointed at it,
neither of which any DIG process is configured to do.

The count stands at USER-CUSTODY POPULATION = 1, and the per-account enumeration that produces
it — every C:\Users profile plus all four service profiles, at their LOCALAPPDATA\DigWallet —
was complete and had no unreadable directory.

One supporting check for the removal recommendation, now verified repo-wide rather than just across
dig-node-service/dig-node-core: grepping the whole dig-node workspace (dig-node-core,
dig-chat-protocol, dig-node-service, dig-runtime, dig-wallet) for any seed-export or
phrase-reveal path returns exactly two, and no CLI:

• POST /api/export — dig-wallet/src/lib.rs:1026, this surface;
• WalletCustody::reveal_mnemonic — dig-wallet/src/sage/custody.rs:502, the first store, already
  being removed by feat(custody)!: carve node-side USER custody out of dig-node (step 4 of dig_ecosystem#1701) #325.

So both node-side custody stores are on track to lose their only reader in the same programme, and
this one still has a blob behind it.

[MichaelTaylor3d]

Parent link + shape decision (2026-08-23)

Parent orchestrator ticket: https://github.com/DIG-Network/dig_ecosystem/issues/1701 (retire node-side USER
custody — freeze, COUNT, remove). This issue is that ticket last remaining child, and it is the work
unit WU-1 of the decision at
https://github.com/DIG-Network/dig_ecosystem/issues/1007#issuecomment-5390359868.

Related: https://github.com/DIG-Network/dig_ecosystem/issues/908 (the boundary) ·
https://github.com/DIG-Network/dig_ecosystem/issues/1007 (closing as superseded; it does NOT move custody
here or anywhere).

What the decision changes for this issue: nothing is extracted or relocated. The surface is DELETED.
An earlier plan proposed moving custody.rs into the published dig-wallet-backend crate; that is
rejected, because the #908 destination already exists and is already adopted — dig-wallet-backend 0.29.0
splits engine (never links a secret-key crate, pinned by tests/key_isolation.rs) from client (the
sole compilation unit holding SecretKey/mnemonic, with zeroize), and dig-app + dig-account consume it
today.

Reference of good: PR #326 is the worked example of this exact carve on plane 1 — same shape, same gate
tier, and it documents the removal in the surviving module doc rather than leaving a silent hole.

Before deleting, re-take the population count on the current tip. #1701 measured plane 2 at 2 blobs,
both origin: auto device-keyed OPERATOR wallets, neither ever funded, verified against chain state with
positive and negative controls. That count has been wrong twice on this family. Operator identity
(autoseed.rs, DIGOP1/DIGVK1) is NOT retired and MUST survive; only the USER path goes.

Gate: full triple gate (custody/crypto tier, §1.10). Evidence to produce: the import/unlock/send/
export routes and the three mnemonic/secret-key wallet-connect methods absent from the router; no
Mnemonic/SecretKey in lib.rs outside operator-facing code; the operator flow still green; dig-node
SPEC.md §7.12/§18.24 swept; and an explicit statement that no new network-reachable surface was added.

Single-writer: dig-node currently has PRs #334 and #336 in gate. This is one serialized lane on
crates/dig-wallet, never a concurrent second writer.

[MichaelTaylor3d]

Step 1 — custody population re-measured over seed_path(), on this host

Branch loop/327-remove-second-custody-plane, draft PR #338. Machine: Windows 11, micha,
the loop's primary dev host. Ranged over both bases seed_path() can resolve —
%LOCALAPPDATA% (what Windows actually uses) and $HOME (what a headless Linux install
uses) — not just the one this platform resolves. That widening is what found blob 2.

Harness: a throwaway integration test in crates/dig-wallet/tests/ (deleted before commit)
calling dig_wallet::autoseed::open_sealed_with_device_key and
digstore_chain::keys::derive_indexed_keys(.., 0..25). It prints puzzle hashes only; no seed,
mnemonic or secret key is printed anywhere.

cargo test -p dig-wallet --test zz_population_measurement -- --nocapture

The two blobs

#	path	container	wallet.meta.json	device key	origin verdict
1	%LOCALAPPDATA%\DigWallet\seed.bin (225 B)	dig-keystore/DIGOP1	present, origin:"auto"	present	auto — device-keyed operator wallet
2	C:\Users\micha\DigWallet\seed.bin (248 B)	legacy/EncryptedSeed(v1)	absent	absent	USER-ORIGIN

Blob 2 is the one a count keyed on origin misses, and it is missed in the unsafe
direction. It has no sidecar to read an origin from, and it cannot be an auto-minted wallet:
autoseed has only ever sealed DIGOP1 under a device key, and there is no device key under
$HOME. The legacy EncryptedSeed layout was written exclusively by the user
import/create path. So the honest classification is user-origin, and this host's
user-origin population is 1, not 0.

Funding — from chain state, with both controls

No argument here cites ever_funded. latch_ever_funded still has zero production
callers (dig-node#286), so the "ever_funded": false sitting in blob 1's sidecar is not
evidence of anything.

Controls, POST https://api.coinset.org/get_coin_records_by_puzzle_hash,
include_spent_coins: true:

• positive — burn ph 0x00..00 -> success: true, 6527 records
• negative — well-formed bogus ph 0xdeadbeef.. -> success: true, 0 records

Blob 1, all 25 HD indices 0..24 (HD-scan rule, not index 0 alone): success: true, 0
coin records ever, 0 unspent mojos, on every index. Never funded, not funded now.

Blob 2: undeterminable. It is password-sealed and I do not hold the password. I did not
attempt to open it and no cracking was performed.

Verdict, and why this is not a STOP

Literally read, the gate does not clear: user-origin count is 1 and its funding is unknown
rather than zero. But the gate's stated reason is "the offline export path (#1701 step 3)
comes first" — and step 3 has already shipped:

• dig_wallet::seed_export::export_mnemonic (crates/dig-wallet/src/seed_export.rs:93) —
  no network surface, reads both on-disk formats via seed_store::decrypt_seed, and
  takes an explicit path precisely so a file written under a base this build no longer
  resolves stays reachable. That is exactly blob 2's situation.
• Reachable as a real verb: dign wallet export-seed --path <p>, routed at
  crates/dig-node-service/src/entrypoint.rs:678 -> seed_export_cli::run. Not a
  library function with no caller.

So the precondition this gate exists to protect is satisfied by shipped, reachable code, and
removing the HTTP custody plane strands nothing. Proceeding, with a regression test that
pins the legacy EncryptedSeed blob-2 shape exporting through that CLI path — because
that is the case the removal actually puts weight on.