Task
Add wallet_origin and wallet_ever_funded to StatusResult.
This blocks a shipped feature from being observable. dig-node v0.132.0 creates a mnemonic seed unattended on first start and records an origin (auto / auto-acknowledged / imported) plus a monotonic ever_funded latch. dig-app has the welcome notice built and merged (dig-app#229). Neither side can talk to the other, because the contract between them has no field for the answer.
Measured, not assumed
A lane checked the pinned 0.17.0 and also downloaded the 0.18.0 .crate from crates.io and grepped src/results.rs. Neither declares either field. So this is not a version-bump away; the latest published contract genuinely cannot carry it.
Why the shape matters
wallet_origin is a three-state, not a boolean. auto-acknowledged exists so the desktop welcome notice fires exactly once — collapsing it to is_auto loses the only thing that stops the notice reappearing every launch.- An unrecognised value must parse to unknown and show nothing. dig-app already parses defensively for exactly this reason, and that property is what lets a fourth origin be added later without breaking older clients. Keep it.
wallet_ever_funded is a monotonic latch that never clears. Once set, no surface may describe the wallet as disposable, whatever the current balance reads — a balance of zero is not evidence a wallet never mattered. That matters because the wallet was created without the user asking and its recovery phrase has never been shown to anyone.
Related
- dig-node #286 — nothing calls
latch_ever_funded yet, so the field will report false in the shipped build until a balance observer exists. Adding the field here is still correct and is the prerequisite.
- dig-node #277 and its decision comment carry the origin/latch design.
- This is a byte-identical cross-repo contract: it is defined in dig-node and parsed in dig-app, which is exactly the shape that drifts. It belongs here rather than as string literals in two repos.
Evidence
dig-app can read a node-created wallet's origin over the real wire, and an unrecognised origin value yields unknown rather than any of the known states.
Task
Add
wallet_originandwallet_ever_fundedtoStatusResult.This blocks a shipped feature from being observable. dig-node v0.132.0 creates a mnemonic seed unattended on first start and records an origin (
auto/auto-acknowledged/imported) plus a monotonicever_fundedlatch. dig-app has the welcome notice built and merged (dig-app#229). Neither side can talk to the other, because the contract between them has no field for the answer.Measured, not assumed
A lane checked the pinned 0.17.0 and also downloaded the 0.18.0
.cratefrom crates.io and greppedsrc/results.rs. Neither declares either field. So this is not a version-bump away; the latest published contract genuinely cannot carry it.Why the shape matters
wallet_originis a three-state, not a boolean.auto-acknowledgedexists so the desktop welcome notice fires exactly once — collapsing it tois_autoloses the only thing that stops the notice reappearing every launch.wallet_ever_fundedis a monotonic latch that never clears. Once set, no surface may describe the wallet as disposable, whatever the current balance reads — a balance of zero is not evidence a wallet never mattered. That matters because the wallet was created without the user asking and its recovery phrase has never been shown to anyone.Related
latch_ever_fundedyet, so the field will reportfalsein the shipped build until a balance observer exists. Adding the field here is still correct and is the prerequisite.Evidence
dig-app can read a node-created wallet's origin over the real wire, and an unrecognised origin value yields unknown rather than any of the known states.