Task
Make dig-node's two chain-tip measurements one measurement, without merging the two peer connections. This is the cheap step that removes the user-visible symptom of #2761 while #2610/#2227 (the version-line migration) remain blockers on the real unification.
The symptom
dign wallet peak reads chia-query's ChainTransport. dign wallet sync-status reads the replica's sync_state. They are two independent measurements from two different TLS connections to two different randomly-chosen peers, and they agree today only by luck — both reported 9136641 on a live node, with nothing enforcing that they must.
Scope (CORRECTED)
Measured on origin/main @ 0c98ce5 (v0.114.1): dign wallet peak does NOT read the replica or a registered provider. At crates/dig-wallet/src/sage/chain.rs:104-108 it constructs its own chia_query::ChainQuery with default config, spinning up a private five-peer pool (max_peers: 5) plus standalone coinset (coinset_fallback_enabled: true) under a freshly-generated TLS identity. This is a third, unregistered measurement invisible to the node's provider registry.
Do this: Inject the node's provider registry into ChainTransport at chain.rs:104-108 so the wallet reads the same source as everything else. This yields one peak measurement by construction and deletes the undocumented third-fabric private connection.
Do not merge the connections. That is #2761 and it is blocked on the version-line collapse; attempting it against the current chia-protocol 0.26 / SDK 0.30 line produces types that will not unify.
The distinction that must survive this change
The replica's persisted sync_state.peak_height is legitimately a different and lower number — it is what has been durably applied, not where the chain is. Do not collapse the two concepts into one field to make them match. Expose the chain tip as the single measurement, keep the applied height as its own clearly-labelled value, and make sure no surface presents the applied height as the chain's tip.
This is the same honesty rule as #2666 and #2764: a surface must never imply a fact it has not established. Two numbers that mean different things is correct; two numbers that claim to mean the same thing and can silently disagree is the defect.
Evidence
Prove it by construction, not by observation: a test that forces the two sources apart and shows the surfaces still agree, because they now read the same one. Observing them equal on a running node proves nothing — they were already equal when the defect was found.
Context
Decided on #2761. Order: #2648 → #213 (reshaped) → #2666 → this → #2610/#2227 → #2761.
Re-measured 2026-08-19 at sweep time — STILL LIVE, and the cited line has moved twice
Recorded in the body because a move to this repo does not carry comment history, and this ticket's
line numbers have now drifted twice.
dig-node origin/main @ b92de34 (v0.126.2), crates/dig-wallet/src/sage/chain.rs:
:81 — client: Mutex<Option<Arc<chia_query::ChiaQuery>>>:131 — let built = chia_query::ChiaQuery::new(chia_query::ChiaQueryConfig::default()).await
So the private fabric is intact: its own pool under ChiaQueryConfig::default() (max_peers: 5,
coinset_fallback_enabled: true, tls_identity: Generated), invisible to the provider registry and
unreachable by operator provider config. Line history: 104-108 (v0.114.1) → ~107 (v0.119.0) →
131 (v0.126.2). Locate it by the ChiaQuery::new(ChiaQueryConfig::default()) call, not by line.
Note :115-116 now also constructs PeerCorroboratedReads::new(DialedPeerSample::mainnet()) inside the
same transport — read that before injecting, so the registry injection and the corroborated-read sample
do not end up as two more rival sources.
Parent
dig_ecosystem#2790 (NC-12) names this ticket as gap 2 of three — "no path constructs its own
peer fabric outside the registry" is one of its three acceptance clauses, and this is the path that
falsifies it. Gaps 1 and 3 have since closed (dig-node#213, chia-query#19), leaving this the last open
one.
Do not merge the connections — that is dig_ecosystem#2761, still blocked on the
chia-protocol 0.26 / SDK 0.30 version-line collapse (#2610 / #2227).
Orchestrator ticket: https://github.com/DIG-Network/dig_ecosystem/issues/2790
Moved from DIG-Network/dig_ecosystem#2768 so this repo's own PR can close it with Closes (CLAUDE.md §1.3).
GitHub refuses a private-to-public issue transfer, so the body was copied and comment history
stayed on the original.
Task
Make dig-node's two chain-tip measurements one measurement, without merging the two peer connections. This is the cheap step that removes the user-visible symptom of #2761 while #2610/#2227 (the version-line migration) remain blockers on the real unification.
The symptom
dign wallet peakreads chia-query'sChainTransport.dign wallet sync-statusreads the replica'ssync_state. They are two independent measurements from two different TLS connections to two different randomly-chosen peers, and they agree today only by luck — both reported9136641on a live node, with nothing enforcing that they must.Scope (CORRECTED)
Measured on
origin/main@0c98ce5(v0.114.1):dign wallet peakdoes NOT read the replica or a registered provider. Atcrates/dig-wallet/src/sage/chain.rs:104-108it constructs its ownchia_query::ChainQuerywith default config, spinning up a private five-peer pool (max_peers: 5) plus standalone coinset (coinset_fallback_enabled: true) under a freshly-generated TLS identity. This is a third, unregistered measurement invisible to the node's provider registry.Do this: Inject the node's provider registry into
ChainTransportatchain.rs:104-108so the wallet reads the same source as everything else. This yields one peak measurement by construction and deletes the undocumented third-fabric private connection.Do not merge the connections. That is #2761 and it is blocked on the version-line collapse; attempting it against the current
chia-protocol 0.26/ SDK0.30line produces types that will not unify.The distinction that must survive this change
The replica's persisted
sync_state.peak_heightis legitimately a different and lower number — it is what has been durably applied, not where the chain is. Do not collapse the two concepts into one field to make them match. Expose the chain tip as the single measurement, keep the applied height as its own clearly-labelled value, and make sure no surface presents the applied height as the chain's tip.This is the same honesty rule as #2666 and #2764: a surface must never imply a fact it has not established. Two numbers that mean different things is correct; two numbers that claim to mean the same thing and can silently disagree is the defect.
Evidence
Prove it by construction, not by observation: a test that forces the two sources apart and shows the surfaces still agree, because they now read the same one. Observing them equal on a running node proves nothing — they were already equal when the defect was found.
Context
Decided on #2761. Order: #2648 → #213 (reshaped) → #2666 → this → #2610/#2227 → #2761.
Re-measured 2026-08-19 at sweep time — STILL LIVE, and the cited line has moved twice
Recorded in the body because a move to this repo does not carry comment history, and this ticket's
line numbers have now drifted twice.
dig-node
origin/main@b92de34(v0.126.2),crates/dig-wallet/src/sage/chain.rs::81—client: Mutex<Option<Arc<chia_query::ChiaQuery>>>:131—let built = chia_query::ChiaQuery::new(chia_query::ChiaQueryConfig::default()).awaitSo the private fabric is intact: its own pool under
ChiaQueryConfig::default()(max_peers: 5,coinset_fallback_enabled: true,tls_identity: Generated), invisible to the provider registry andunreachable by operator provider config. Line history:
104-108(v0.114.1) →~107(v0.119.0) →131(v0.126.2). Locate it by theChiaQuery::new(ChiaQueryConfig::default())call, not by line.Note
:115-116now also constructsPeerCorroboratedReads::new(DialedPeerSample::mainnet())inside thesame transport — read that before injecting, so the registry injection and the corroborated-read sample
do not end up as two more rival sources.
Parent
dig_ecosystem#2790 (NC-12) names this ticket as gap 2 of three — "no path constructs its own
peer fabric outside the registry" is one of its three acceptance clauses, and this is the path that
falsifies it. Gaps 1 and 3 have since closed (dig-node#213, chia-query#19), leaving this the last open
one.
Do not merge the connections — that is dig_ecosystem#2761, still blocked on the
chia-protocol 0.26/ SDK0.30version-line collapse (#2610 / #2227).Orchestrator ticket: https://github.com/DIG-Network/dig_ecosystem/issues/2790
Moved from DIG-Network/dig_ecosystem#2768 so this repo's own PR can close it with
Closes(CLAUDE.md §1.3).GitHub refuses a private-to-public issue transfer, so the body was copied and comment history
stayed on the original.