Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3166
Task
Obtain a wallet fixture that holds one unspent $DIG CAT coin and one NFT, so the $DIG-balance
family's acceptance bar can be measured instead of argued.
Why — the current replica cannot falsify the thing it is used to check
The node's live wallet is at %LOCALAPPDATA%\DigNode\wallet.sqlite (dig-node 0.160.0, synced to height
9,212,691). Measured 2026-08-28:
|
|
| coins |
948 |
| distinct puzzle hashes |
1 |
coins with asset_id set |
0 — all NULL, i.e. all typed XCH |
| coins carrying a hint |
0 of 948 |
cats / nfts / dids rows |
0 / 0 / 0 |
derivations |
0 |
| unspent |
2 coins, 1.599 XCH |
Every table CAT/NFT/DID attribution populates is empty, and no coin has ever been hinted. CAT coins
live at cat_puzzle_hash(owner_p2, asset_id) — a different puzzle hash from the owner p2 — so a
node that has never run attribution has never subscribed to its own $DIG address and has never seen
those coins at all. That is #382 visible in production.
The consequence for testing is the point of this ticket. All 948 rows sit at the single owned p2
hash, so the point-read tier stages zero of them:
[REPLICA] nfts=0 dids=0
[ROUTE] point-read tier: believed=948 staged=0
A run against this replica proves no regression and corroborates nothing. nfts=0 dids=0 is
equally consistent with a defect having emptied them and with the wallet never having held an NFT — so
the measurement cannot distinguish the two, in either direction.
That has already cost real work. PR #393 reached eight review rounds; its round-7 gating finding
(the point-read narrowing terminally deleting nfts/dids rows) could only be demonstrated on a
simulator fixture, and its round-8 fix could only be verified there too. The earlier
{promoted: 8} → dig_balance 3856455 measurement came from capture files that are not on this machine,
and it predates findings it therefore cannot certify.
Without this fixture, every future round re-litigates the same unfalsifiable measurement.
What is needed
A wallet whose database, after a sync, contains at least:
- One unspent $DIG CAT coin — so a balance can be wrong in the direction the family cares about,
and so promotion has something real to promote.
- One NFT or DID owned by the wallet — so the point-read tier stages a singleton and the
nfts/dids path is exercised end to end rather than by fixture.
Either on the existing node wallet or a dedicated one. A dedicated test wallet is probably cleaner: it
can be minted deliberately, its expected contents are known exactly, and it does not entangle the
acceptance bar with whatever the main wallet happens to hold.
This is a mainnet spend and it is small. Note the current wallet holds 1.599 XCH unspent, so
funding is a real consideration rather than a formality.
Acceptance
A named wallet fixture, reachable by the dig-wallet harness (the DIG_REAL_WALLET /
DIG_REAL_COINS / DIG_REAL_PARENTS path), whose sync produces a non-zero cats row count and a
non-zero nfts or dids row count — so that a regression in either path makes the harness go red
rather than stay silently green.
Record the wallet's expected contents alongside it. A fixture whose correct output nobody wrote down
becomes unfalsifiable the moment its author stops working on it, which is how this ticket came to
exist.
Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3166
Task
Obtain a wallet fixture that holds one unspent $DIG CAT coin and one NFT, so the $DIG-balance
family's acceptance bar can be measured instead of argued.
Why — the current replica cannot falsify the thing it is used to check
The node's live wallet is at
%LOCALAPPDATA%\DigNode\wallet.sqlite(dig-node 0.160.0, synced to height9,212,691). Measured 2026-08-28:
asset_idsetcats/nfts/didsrowsderivationsEvery table CAT/NFT/DID attribution populates is empty, and no coin has ever been hinted. CAT coins
live at
cat_puzzle_hash(owner_p2, asset_id)— a different puzzle hash from the owner p2 — so anode that has never run attribution has never subscribed to its own $DIG address and has never seen
those coins at all. That is #382 visible in production.
The consequence for testing is the point of this ticket. All 948 rows sit at the single owned p2
hash, so the point-read tier stages zero of them:
A run against this replica proves no regression and corroborates nothing.
nfts=0 dids=0isequally consistent with a defect having emptied them and with the wallet never having held an NFT — so
the measurement cannot distinguish the two, in either direction.
That has already cost real work. PR #393 reached eight review rounds; its round-7 gating finding
(the point-read narrowing terminally deleting
nfts/didsrows) could only be demonstrated on asimulator fixture, and its round-8 fix could only be verified there too. The earlier
{promoted: 8} → dig_balance 3856455measurement came from capture files that are not on this machine,and it predates findings it therefore cannot certify.
Without this fixture, every future round re-litigates the same unfalsifiable measurement.
What is needed
A wallet whose database, after a sync, contains at least:
and so promotion has something real to promote.
nfts/didspath is exercised end to end rather than by fixture.Either on the existing node wallet or a dedicated one. A dedicated test wallet is probably cleaner: it
can be minted deliberately, its expected contents are known exactly, and it does not entangle the
acceptance bar with whatever the main wallet happens to hold.
This is a mainnet spend and it is small. Note the current wallet holds 1.599 XCH unspent, so
funding is a real consideration rather than a formality.
Acceptance
A named wallet fixture, reachable by the dig-wallet harness (the
DIG_REAL_WALLET/DIG_REAL_COINS/DIG_REAL_PARENTSpath), whose sync produces a non-zerocatsrow count and anon-zero
nftsordidsrow count — so that a regression in either path makes the harness go redrather than stay silently green.
Record the wallet's expected contents alongside it. A fixture whose correct output nobody wrote down
becomes unfalsifiable the moment its author stops working on it, which is how this ticket came to
exist.