Skip to content

chore(release): v0.260.0 -- the claim loop pays a peer - #622

Merged
MichaelTaylor3d merged 29 commits into
mainfrom
release/v0.260.0
Sep 23, 2026
Merged

MichaelTaylor3d merged 29 commits into
mainfrom
release/v0.260.0

Conversation

@MichaelTaylor3d

Copy link
Copy Markdown
Contributor

Summary

Stable cut v0.260.0 (minor bump over v0.259.0). Ships everything merged to develop since the v0.259.0 cut — the node side of the managed reward distributor's payment path.

Ships:

  • dig-node#620 — the real ClaimChainPort: production_claim_port(source, HintedLauncherIndex, broadcaster) wired from serve_with_shutdown -> spawn_claim_driver_from_config -> run_claim_driver; submit_initiate_payout builds a real spend via ChainEntrySlotSource on dig-rewards-coin 0.8.0 and broadcasts it. Closure artifact a_driven_cycle_over_a_funded_admitted_distributor_pays_this_peer passes (mint -> fund -> admit -> roll -> sync -> driven cycle -> claims_submitted == 1, payee coin amount == expected_accrued).
  • dig-node#618 — split the three conditions behind REWARD_CHAIN_UNAVAILABLE (no such distributor / chain unreachable / chain sync disabled).
  • dig-node#619 — reward-distributor reads are OPEN on POST / (the reward-read access tier), doc + pin.
  • dig-node#617 — derive both claim cadences from one raw config value and inject the clock (the driver.rs transposition hole).
  • dig-node#611 — clamp an out-of-range claim schedule to the max.
  • dig-node#614 — construct and install a real RewardsChainPort over dig-rewards-coin.
  • dig-node#591 — lock inbound dial+accept counted once.

Closes DIG-Network/dig_ecosystem#3347
Closes DIG-Network/dig_ecosystem#3342

Version bump

Workspace root Cargo.toml ([workspace.package].version, the value nightly-release.yml's stable channel and the version-increment gate read) 0.258.0 -> 0.260.0 (develop's root sat below main's 0.259.0 after the v0.259.0 cut), plus the matching dig-node-service entry in Cargo.lock via cargo update --workspace --offline so --locked builds stay satisfied. Library crates keep their independent versions.

Post-merge (orchestrator)

  • Dispatch nightly-release.yml channel=stable; confirm Stable — changelog + tag RAN.
  • Verify the artifact (14 assets, draft=false, prerelease=false, releases/latest).
  • -s ours reconcile main -> develop, then forward-port anything main holds newer.

Test plan

  • Lint commit messages
  • Check version increment
  • Rustfmt
  • Clippy
  • Test + coverage
  • Release-script tests

🤖 Generated with Claude Code

MichaelTaylor3d and others added 28 commits September 5, 2026 20:33
* chore: open lane for #574

* feat(mirror): persist mirror-bond coin ids so a restart cannot double-create

Bond identity was reconstructed from a live chain scan on every read
(`mirror/observe.rs`), with no persistence of its own. A restart, a cold
replica, or a lagging/flaky chain source all rendered a real, unspent,
confirmed bond as "no bonds" -- and because the in-flight suppression is
keyed on pending/submitted audit entries, a bond whose create had already
CONFIRMED was not suppressed either, so the same short scan that emptied
the read surface also cleared the one thing that would have stopped a
second coin being paid for collateral that already exists (dig-node#574).

Persist the (store, root, epoch) -> coin_id mapping in the EXISTING spend
audit record (spend-audit.jsonl) rather than a new store: a mirror-coin
create already writes store_id + AuditedBond{root, epoch} + amount there,
and the coin id itself becomes durable the moment resolve_landed_spends
confirms it. This adds the one missing piece -- the advertised URL a
create carries -- and a read-side query, confirmed_mirror_bond, that
returns the newest CONFIRMED record naming a triple.

Chain stays authoritative. mirror::local_bond::recheck_missing_bonds
never trusts the record: for a held bond the live scan did not cover, it
asks the record for a candidate coin id, then re-verifies that SPECIFIC
coin against chain via the same independent check (chain_bond_verdict)
that verifies an untrusted peer's claimed bond. Only a fresh `Bonded`
verdict is folded back in, as covered; `Unbonded`/`Unverified` fall
through to an ordinary create, exactly as if no record existed.

Version: 0.254.86 (patch -- per #522 the MSI ProductVersion minor field
is exhausted and the counter lives in patch).

Co-Authored-By: Claude <noreply@anthropic.com>

* test(mirror): prove the recovery wiring end to end through PassRunner::run

Adds two integration-level tests over the REAL pass pipeline, not just the
isolated recheck_missing_bonds unit tests: a bond missing from the live
scan with a chain-reverified durable record is recovered (no double
create, correct Bonded state reported), and the control -- the same
record but chain disproves it -- correctly falls through to an ordinary
create. Together these are the concrete regression test for the
cold-start/lagging-chain-source double-create scenario the ticket asked
to have measured.

Also refactors in_flight_creates to take the already-folded SpendLedger
instead of re-reading the log itself, so PassRunner::run reads the audit
file once per pass and shares it with the new recovery step, and fixes a
doc comment on in_flight_creates that the recovery step would otherwise
have made stale on landing ("a Confirmed create has a coin the chain
observation already sees" is no longer unconditionally true).

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(fmt): wrap long test signatures to satisfy rustfmt

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(clippy): use slice::from_ref instead of cloning for a single-element slice

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(release): bump to v0.254.89

Base branch moved to develop after PR #576 merged there at v0.254.88
(main and develop are currently identical), leaving this branch's
carried-forward .88 as a zero-increment against the new base. Bumped
to the next free integer after fetching and verifying both origin/main
and origin/develop tip at .88.

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>
serve_accepted_relay_conn served every accepted relayed circuit (full mTLS
auth, full L7 peer RPC) while registering it nowhere, so connected_peers
under-reported every relayed inbound peer -- the relay-leg twin of the
direct-inbound defect #402/#523 already fixed.

adopt_inbound_peer_in_pool now dispatches by TraversalKind: Relayed routes to
dig-gossip's already-published adopt_relayed_inbound_handle (v0.32.0, the rev
this repo already pins), every other tier keeps the unchanged
adopt_direct_inbound_handle path. serve_accepted_relay_conn adopts before
serving and releases after, mirroring the direct listener exactly.

Refs: DIG-Network/dig_ecosystem#3124
…isions (#582)

* chore: open lane for #3189

* fix(cli): guard the exit-code namespace shared with diga against collisions

dign and diga deliberately share one process exit-code numbering (dig-app's
outcome.rs says so in its own doc comment), so a number is free only if it
is unoccupied ecosystem-wide. dig-node#407 assigned exit 7 to
NODE_UNREACHABLE by checking only this repo's own table, where 7 genuinely
was free -- and collided with diga's NOT_CONNECTED. A reviewer caught it by
hand; nothing failed automatically.

Adds scripts/check-exit-code-collisions.sh: parses both enums' code()/name()
match arms straight from their own source -- this repo's ExitCode, and a
live fetch of dig-app's outcome.rs at its default branch -- and fails if a
number carries two different names, or if either side draws a number from
the reserved shell signal range (126, 127, 128+N). Ships with an 18-case
hermetic test harness (scripts/tests/check-exit-code-collisions.test.sh)
covering the actual #407 collision shape, arm-order independence, arm-count
mismatch, the reserved-range boundary from both sides, the live-fetch path
itself, and fail-closed behaviour on an empty/missing/unreachable table.

Wires a real (unstubbed) invocation into ci.yml's existing "Release-script
tests" job so a collision introduced by a future PR, on either side, is a
red required check on that PR -- not a note a reviewer has to catch. The
fetch retries twice (2s backoff) since this becomes a required, network-
dependent check; a fetch failure still fails closed after retrying, never
silently passing as "diga has no codes".

Updates SPEC.md 8.4 to point at the mechanical guard instead of leaving
"re-check both tables" as unenforced prose, and records that the
extension's WALLET_WS_ERR.NOT_CONNECTED = -33001 is a separate JSON-RPC
error-code space, not a rival of this one. Adds a doc-comment to the
existing transcribed collision test pointing future readers at the live
script as the authoritative check; the transcription remains as a narrower,
hermetic regression pin for the #407 shape specifically.

No renumbering: every currently-assigned code is unchanged.

Refs #3189

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>
…rrupted strings (#3190) (#583)

* chore: open lane for #3190

* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings

Replicates dig-node-service::continuation_guard (dig-node#526/#501) into dig-node-core,
dig-wallet, dig-runtime and dig-chat-protocol, line-for-line apart from crate-specific
constants -- ported rather than reinvented, per dig_ecosystem#3190.

Wiring the guard in surfaced 48 pre-existing lost-continuation defects the ticket's own
"no measured corruption in these four crates" note did not anticipate: 36 in dig-node-core,
12 in dig-wallet, mostly test-assertion prose where a multi-line message lost its `\`
continuation and shipped the source's own indentation as a mid-sentence space run (one
as the worse `\n`-plus-indentation variant). All 48 are collapsed to the single space the
sentence always meant, with surrounding indentation and wording otherwise untouched.

Two lines are real column-alignment, not defects, and get a targeted EXCLUDED_LINE_RANGES
entry on dig-node-core instead of a rewrite: download.rs's `claimed(...)` fixture-table
trailing comments, and net.rs's `label : value` debug-print alignment.

Refs DIG-Network/dig_ecosystem#3190
Refs DIG-Network/dig_ecosystem#3130

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>
… the current advertise URL

Automatic half (D1-D4) of the daily mirror-URL reconcile: derived personal-day offset, two-observation hysteresis, nine ordered gates with K sized as a self-funding prefix before any reclaim, `submitted` never `completed`, audit lines gain `reclaim_reason` + `trigger`.

Gates at b4c0986: loop-reviewer PASS (review 5129272285), loop-security PASS @ 175304e (tree byte-identical, `git diff 175304e b4c0986` empty), adversarial loop-decider PASS (comment 5567083644; SHOULD-FIX findings ticketed separately).

Refs #570
Refs DIG-Network/dig_ecosystem#3203
…tem#3212)

Nine commits from the #3212 serve-path lane, gated at 899cc68 (reviewer review 5130425808,
security comment 5568662836), plus the single semver bump to 0.255.0 for the develop -> main batch.

- store_id/root case normalised at the CapsuleKey boundary; cache delete targets the matched entry
- tier-0 occupancy reads the eviction-aware ledger
- profile-sync outbound budget in bytes; announcer asked first
- melt confirmation depth on the terminal spend, fail-closed
- EngineWarming (-32002) while the peer tier attaches, never -32004
- window completeness derived from the bytes read
- deps: dig-stun 0.2, chia-query 0.24.3, dig-nat 0.21.2, dig-logging 0.2.2

Refs DIG-Network/dig_ecosystem#3212
… squash

Content-neutral. main@5eac531a is the squash of develop@194a0163 (tree-identical, verified
with `git diff --quiet 194a016 origin/main`), so develop already carries every byte main has;
this merge only records the ancestry so PR #588 (develop -> main) stops reading as CONFLICTING
and GitHub can build its merge ref again (the Commitlint and Check Version Increment
pull_request-event checks never attached to e11434a for that reason).

Refs DIG-Network/dig_ecosystem#3212
…ash + changelog)

Content-neutral: develop already carried every byte of the #588 squash; this brings in the
chore(release): v0.255.0 changelog commit so develop == main in content for the next batch.
develop is branch-protected against force-push and deletion, so it is synced by merge, not
recreated from main.

Refs DIG-Network/dig_ecosystem#3212
* chore: untrack gitnexus-generated agent files

These files were generated by `gitnexus analyze` as a side effect of
indexing this repository. They are development-loop private tooling
output, not product code, and carry no secrets. They are removed from
tracking going forward via .gitignore; history is deliberately NOT
rewritten.

Refs #3177

* chore: drop private-repo reference from gitignore comment

The ignore comment named a private repository and an internal issue
number in a public file, which is the same disclosure class this
change set exists to remove; the reference is dropped and the
guidance kept.
…enforced self-exclusion, bounded spend (#593)

The always-on reward-prover engine: ~2,000 lines under
`crates/dig-node-core/src/rewards/`, built against the merged `dig-rewards-coin`
SPEC. Library only -- nothing spawns it, and the sole production
`RewardsChainPort` refuses every call, so it cannot spend. Wiring the composed
system is #3265, which carries its own gate.

The epic's premise -- "anytime the process isn't running, rewards are not being
distributed" -- is half wrong, and the false half is the dangerous one. `Sync`,
`NewEpoch` and `InitiatePayout` need no manager authority, so funder downtime does
not stop rewards: it FREEZES THE ENTRY SET while accrual and payouts continue.
Peers that stopped mirroring keep earning; peers that started cannot begin. That
shaped the whole design.

Liveness honesty (SPEC 2.4). The status record carries no `healthy`/`ok`/`up`
boolean and no precomputed staleness, because a wedged loop cannot report its own
wedging -- whatever it last wrote stays there, so a writer-set flag reads true
forever after the failure it exists to reveal. The reader derives staleness from
`last_cycle_completed_at` against `observed_at` and its own clock. A recursive
JSON-key test enforces the absence at every nesting depth; asserting on keys and
never substrings, since `ProverState::Running` legitimately serializes the VALUE
"running". The one legal staleness signal is chain-derived (SPEC 12.4: 48 hours
AND a non-zero reserve, from the singleton's own spend history) and lives on the
distributor read, where a wedged prover cannot fake it.

Self-exclusion is a compile error, not a habit. dig-node#261's lesson is that an
invariant enforced on some paths is not an invariant. `admit` is the single
admission point, checks both SPEC 5.2 coordinates (own peer_id OR a payout puzzle
hash this wallet controls), and mints an `AdmittedPeer` with private fields and no
public constructor -- so `EntryAction::Add` cannot be built by a path that skipped
admission.

A prover's own fault can never strike a peer. `GateError` is a distinct type from
`GateIneligibleReason` and `record_prover_fault` takes `&self`, so SPEC 3.6 clause
4 is enforced by the borrow checker rather than by comment. Without that, a
misconfigured operator -- one missing mirror-collateral epoch ordinal -- would
strike every peer at once and evict its entire 250-entry set in three hours, each
eviction a fee it pays plus a settlement out of its own reserve.

The money bounds are stated where a human reads them (`rewards/mod.rs`): 24
bundles/day, 192 entry actions/day, a fee ceiling of 24x the configured standard
fee, 192 removals/day worst case with 96/day sustained churn. Recorded honestly:
SPEC 6.3's rate bound and fee ceiling are ONE control, not two.

Three gate rounds, every leg fresh-context. Round 3 at this head: reviewer PASS,
adversarial decider RATIFY (leg closed), security CHANGES-REQUIRED on a finding
the decider ratified deliberately -- adjudicated in
#593 (comment) and
carried to #3265 with the remedy corrected, because the proposed fix would have
persisted a poison flag to the very store whose writes were failing.

Found and fixed under gate: a census ordinal off by one in both directions (SPEC
4.6 requires n-1 exactly); an unreachable grace window leaving a named constant
with no reader; a missing `NewEpoch` spend; an absent-ordinal path attributing a
prover fault to peers; and a daily fee ceiling 24x too high because a per-bundle
fee was consumed as a daily ceiling.

Refs DIG-Network/dig_ecosystem#3250

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* chore: open lane for #3269

Bump dig-rpc-protocol to 0.11.0 (adds dig.getRewardProverStatus and
the other reward RPC methods to the wire).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards): fail-closed Reward-tier guard + dig-rpc-protocol 0.11 line assertion

- dependency_tree.rs: assert the resolved dig-rpc-protocol line is 0.11 (was 0.10);
  documents the known-red two-version state pending the dig-peer 0.14.0 /
  dig-download 0.23.0 cascade (#3269).
- reward_methods_tier_guard.rs: fail-closed guard over the live Method::ALL
  catalogue -- every Reward-named method must be Tier::Control and not
  peer-reachable, so a fifth reward method added later is caught at the wrong
  tier automatically rather than inheriting a wrong default (binds #3261's rule
  node-side).
- peer.rs: sibling unit test exercising the real (pub(crate)) is_peer_reachable_method,
  since an external integration test cannot see it -- same guard, executed against
  this node's own allowlist rather than only the shared crate's.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* style: remove trailing blank line in reward_methods_tier_guard.rs

* feat(rpc): serve dig.getRewardProverStatus at Tier::Control

Adds the missing handler for PR#595: a new reward_prover_statuses
registry + accessors on Node (empty until #3265 spawns a prover loop,
so the registry read is real, not a stub), a dispatch.rs arm inside
the Method enum match (never the string pre-match), and a
field-for-field mapping from dig-node-core's internal
rewards::state::RewardProverStatus (camelCase-tagged) onto
dig-rpc-protocol 0.11's wire RewardProverStatus (snake_case-tagged
struct, camelCase-tagged ProverState value), widening entry_count
u32 -> u64 explicitly and hex-encoding the three [u8; 32] identity
fields.

An all-zero launcher_id (what an uninitialised registry slot
hex-encodes to) is omitted at this boundary rather than rendered as
a real distributor with a plausible-looking id -- the money-hole
class the dig-rewards-coin driver's adversarial gates found three
times.

Tests (in dig-node-core::lib.rs's existing test module, where the
pub(crate) registry accessors are visible) drive the real dispatch
entry point (handle_rpc -> RpcDispatch::dispatch -> the Method arm)
and assert field-for-field on the serialized JSON body: populated
registry, empty registry (-> {"statuses": []}), zero-id omission,
tier/peer-reachability, enum-match-not-string-prematch, and
launcher_id filtering. The no-health-boolean / no-staleness
assertion is by key set, not substring.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* style: rustfmt the reward-prover-status registry + tests

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* chore(deps): bump dig-download 0.23, dig-peer 0.14, dig-rpc-protocol 0.11

Closes the two-versions-of-dig-rpc-protocol split (#3269): dig-download 0.23.0
and dig-peer 0.14.0 both now resolve dig-rpc-protocol ^0.11, matching
dig-node-core's own dig-rpc-protocol = "0.11.0" line, and dig-node-service's
two 0.10 lines (main dep + dev-dependency restatement for
openrpc_drift_guard.rs) move to 0.11 to match.

Manifests only. cargo update / Cargo.lock intentionally NOT run yet: a fourth
capper, dig-peer-selector ("0.11" in dig-node-core/Cargo.toml), still requires
dig-peer = "^0.13" in every published version through 0.11.1, so the tree
cannot fully resolve until a dig-peer-selector release picks up dig-peer 0.14.
CI will stay red on this commit for that reason, which is expected.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(rpc): close dig-rpc-protocol 0.11 cascade + attribute payout figures

Bump dig-peer-selector 0.11 -> 0.12 (the release that moves onto dig-peer
^0.14) and run cargo update, closing the two-versions-of-dig-rpc-protocol
split: Cargo.lock now resolves exactly one dig-rpc-protocol, at 0.11.0,
alongside dig-peer 0.14.0, dig-download 0.23.0, dig-peer-selector 0.12.0.

Add a subject-attribution test and doc comments to
reward_prover_status_to_wire: total_paid_out_base_units and
reserve_base_units are per-distributor totals (this distributor's payout to
ALL its mirrors, and this distributor's own reserve), never the querying
node's own earnings and never summed/cross-attributed across distributors.
This is the defect class a sibling adversarial gate found in dig-app#403's
rewards pane, which rendered a distributor total as one mirror operator's
personal earnings and overstated by up to 250x.

Checked: rewards/state.rs, rewards/port.rs and rewards/mod.rs contain no
Eligible/verdict/payout_hash symbol, so nothing in this mapping surfaces a
persisted EligiblePayoutHash verdict.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): silence dead_code on register_reward_prover_status pending #3265

Clippy's non-test lib target has no production caller for
register_reward_prover_status yet, because #3265 (the always-on prover loop
that would call it from bring-up) has not landed -- only tests call it today.
cfg_attr(not(test), allow(dead_code)) stands in for that missing caller
until #3265 wires a real one.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): make the all-zero identity guard non-silent and cover all three fields

Security (blocking) and the adversarial leg both found the same defect in the
zero-launcher_id filter: it checked only launcher_id, so a registration bug
that zeroed store_id or root beside a valid launcher_id would pass through as
a plausible record, and dropping the bad record silently destroyed the
evidence a registration bug happened at all -- SPEC Sec2.4 clause 1's exact
prohibition.

zeroed_identity_fields() now checks launcher_id, store_id AND root. The
dispatch filter still excludes a record with any zeroed field (never renders
an uninitialised slot as a real distributor), but first fires a
tracing::warn! naming which field(s) were zero, so a bad registration is
observable rather than swallowed. Kept isolated in dispatch.rs rather than
woven into the wire mapping, since this belongs at #3265's writer once that
lands.

Replaced get_reward_prover_status_omits_an_all_zero_launcher_id (which
proved the omission but not the observability, and never exercised a zeroed
store_id/root beside a valid launcher_id) with
get_reward_prover_status_logs_and_excludes_a_zeroed_identity_field, covering
both a zeroed launcher_id and a zeroed store_id beside a valid launcher_id,
and asserting the tracing::warn! output via the crate's existing
capture_sync_logs test utility.

Fixed a now-false "Known-red" doc comment on
tests/dependency_tree.rs::the_workspace_carries_exactly_one_module_wire_crate:
the dig-peer 0.14.0 / dig-download 0.23.0 / dig-peer-selector 0.12.0 cascade
already landed in this PR's Cargo.toml/Cargo.lock, so the assertion is green,
not red. Assertion itself untouched -- still exact-version.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): correct a born-false "shipped dig-app 15.5.0" doc claim

dig-app's latest release is v15.4.0 -- there is no v15.5.0 tag -- and
dig-app#403 (the pane that would consume dig.getRewardProverStatus) is OPEN
and unmerged. Point the doc comment at the real, unmerged consumer instead
so a future reader doesn't take this as evidence a shipped consumer depends
on the guard, which would wrongly discourage relocating it to #3265's writer.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): correct doc placement, assert the zeroed field by name, treat root as an observation

Three findings from the correctness gate on PR#595 at 134864a.

1. The zeroed-identity helper's doc block was spliced onto the end of
   reward_prover_status_to_wire's block with no separator, so the wire-mapping
   rationale documented a boolean predicate and the mapping function was left
   with no doc at all. Each doc block now sits above the item it describes.

2. The log assertion `logs.contains("launcher_id")` was a tautology: the warn
   emits launcher_id as a structured field on every fire, so the property the
   guard exists to add -- naming which field was zeroed -- was unasserted.
   Deleting `zeroed_fields = ?zeroed` from the warn left every assertion green.
   The test now asserts the zeroed_fields value itself, which the fixture makes
   exact and disjoint across cases.

3. `root` is an observation, not an identity. A registered prover that has not
   completed its first cycle plausibly has no root, and a writer that zero-inits
   it would have made a healthy prover invisible. A zeroed launcher_id or
   store_id still excludes the record; a zeroed root alone warns and returns.

Refs #3269

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rpc): restore zeroed_fields structured field dropped from the pushed warn

The previous commit (080be3d) landed with `zeroed_fields = ?zeroed` missing
from the tracing::warn! call in the GetRewardProverStatus filter -- a
one-line regression introduced while proving the new log assertion goes red
without it, never restored before the commit was made. Without this field
the log line never names WHICH field was zero, so an operator sees only
that something was excluded, and the test asserting `zeroed_fields=[...]`
per case would fail. Restored; all 7 reward-prover-status tests green.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): split zeroed-field logging by level -- WARN for a missing
identity, DEBUG for a zeroed root

A zeroed launcher_id or store_id is a real registration bug: the record is
excluded and now logs at WARN, naming the exact field(s) via
`zeroed_fields=[...]`. A zeroed root alone is an ordinary pre-first-cycle
state, not a fault: the record is still returned, and now logs at DEBUG
instead of WARN, so an operator polling this endpoint sees warn-level
volume proportional to real registration bugs, not to every
not-yet-cycled prover on every poll.

Updated the doc comments on `zeroed_fields`, the dispatch filter and the
test to describe the level split, and extended the regression test to
assert on level (WARN vs DEBUG) as well as the `zeroed_fields` value.
Proved both directions: flipping the DEBUG branch back to WARN turns the
test red on the level assertion; flipping the field-name assertion back to
a bare `contains("launcher_id")` would have passed unconditionally (the
prior tautology) and is no longer possible since the assertions now pin
`zeroed_fields=[...]` plus the level string.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
…adence (#3251) (#594)

* feat(rewards): peer claim loop skeleton -- discovery, cadence, config, claim port

* test(rewards): write all twelve acceptance tests for the peer claim loop

* feat(rewards): wire the seven rewards_claim submodules into the crate

mod.rs declared no submodules, so types.rs/port.rs/config.rs/cadence.rs/
parser.rs/engine.rs/hints.rs (1,435 lines, 25 tests) were never part of the
crate and never compiled. Declare them and re-export the public surface.

* style(rewards): cargo fmt the rewards_claim submodules

* chore(deps): bump dig-node-control-interface 0.33->0.35, dig-rpc-protocol 0.10->0.11.0

dig-rpc-protocol 0.11.0 is merged and tagged upstream; the other dig-*/chia-*
deps of dig-node-service were already at the latest permitted-by-caret version
in Cargo.lock. crates/dig-node-core/Cargo.toml is untouched (#3250's file set).

* chore(deps): revert dig-node-control-interface and dig-rpc-protocol bumps

Both create a duplicate-version split in this PR's scope and neither can be
closed without editing a sibling crate's manifest this lane does not own:

- dig-rpc-protocol 0.11.0 duplicates against dig-node-core/Cargo.toml:194
  ("0.10.2"), which is #3250's live file set (dig-node#593).
- dig-node-control-interface 0.35.0 duplicates against
  dig-wallet/Cargo.toml:81 ("0.33"), a sibling crate this lane does not own;
  the observed Clippy break (BalanceAsset/Asset type-identity mismatch,
  missing url_reconcile/url_current/urls fields) came from THIS duplicate,
  not from dig-rpc-protocol.

Both belong to their own sequenced dep-bump unit of work, not this ticket.

* fix(rewards-claim): fault laundering, permanent no-entry blacklist, fee ceiling magnitude

Three independent gates on dig-node#594 (51516e6) found four logic defects; this
addresses A, B and C per the corrected fix brief (D is documented only, not fixed
here per the brief's own instruction).

Defect A -- the anti-silence surface laundered every real fault into `Nominal`:
- A1: `fault_reported` had no fault-bearing ClaimLoopState to fall through to, so a
  chain adapter erroring every cycle read `Nominal` forever. Added
  `ClaimLoopState::Faulted { cycles }`, outranking Nominal/ClaimableButNotClaiming,
  under ChainSourceUnavailable.
- A2: inverted the test that asserted A1's bug as correct behaviour.
- A3: `ClaimableButNotClaiming` compared a per-cycle snapshot
  (`distributors_claimable`) against a lifetime-cumulative counter
  (`claims_submitted`), so it latched healthy forever after one lifetime success.
  Added `claims_submitted_this_cycle` (per-cycle) as the correct comparand; kept
  `claims_submitted` as a cumulative counter.
- A4: `last_discovery_at`/`last_cycle_at` were stamped even on a failed discovery
  or an all-faulted cycle, destroying the staleness signal a reader depends on.
  Now only stamped on success; added `last_attempt_at` to prove liveness
  separately. `fault_reported` and `distributors_faulted` now reset per cycle
  instead of latching for the process's lifetime.

Defect B -- "terminal, stop retrying" was implemented as a process-lifetime
blacklist (`terminal_no_entry: HashSet<Bytes32>`, never cleared). That blocked
SPEC 12.5 clause 2's re-entry path (evicted, re-challenged, re-admitted never
claims again) and permanently punished a peer that discovered a distributor
before the funder's AddEntry landed. Removed the blacklist entirely -- `own_entry`
is a cheap chain read, re-issued every cycle for every candidate, matching clause
3's "never cache across cycles". `NoEntrySlot` is now a per-cycle observation, not
a lifetime sentence.

Defect C -- the fee ceiling didn't bind anything and there was no aggregate cap:
- C1: default `CLAIM_FEE_CEILING_MOJOS_DEFAULT` lowered from 1_000_000_000
  (transplanted from `MIRROR_SPEND_FEE_CEILING_MOJOS`, sized for a mirror-coin
  spend) to 200_000 -- 2x the observed routine Chia fee range (5,000-100,000
  mojos), so it actually binds instead of leaving 4-5 orders of magnitude of
  slack.
- C2: added a per-cycle aggregate fee budget
  (`max_cycle_fee_budget_mojos`, default 10x the per-claim ceiling) checked
  across all claims in a cycle, closing the attacker-cost gap where funding K
  distributors could force a victim to spend K x the per-claim ceiling per cycle.
  New `ClaimOutcome::SkippedCycleBudgetExhausted`.

Tests: rewards_claim test count 26 -> 37 (11 new: repeated_discovery_faults_never_
read_as_nominal, failed_discovery_leaves_last_discovery_at_unchanged, a_reported_
fault_surfaces_as_faulted_not_nominal, a_lifetime_submission_does_not_mask_a_
later_cycle_that_submits_nothing, no_entry_slot_then_re_admitted_produces_a_claim_
on_the_later_cycle, distributors_each_under_ceiling_do_not_collectively_exceed_
the_cycle_budget, the_default_per_claim_ceiling_actually_binds_a_routine_fee, plus
renamed/rewritten no_entry_slot_is_non_terminal_and_re_checked_every_cycle).

Refs #3251

* fix(rewards-claim): refuse a claim entry for the wrong payout puzzle hash

CI fix: cadence.rs's RewardsClaimConfig literal was missing the
max_cycle_fee_budget_mojos field added in the previous commit (E0063,
caught by CI's Clippy/Test jobs -- the local cargo check for this
workspace is too slow to use as the compiler here).

Defect E (security-gate finding, folded in before this pass closes):
submit_initiate_payout was called with entry.payout_puzzle_hash -- whatever
the chain port handed back -- with no check against this node's own
own_payout_puzzle_hash. UnavailableClaimChainPort is the only production
adapter today so nothing can exploit this yet, but the whole point of the
ClaimChainPort seam is that #3249 swaps in a real adapter with nothing
above it changing, so deferring this would ship the landmine live with no
review pass watching for it. Added an equality guard before the spend:
a mismatch refuses to submit, counts
(ClaimStatus::claims_refused_payout_mismatch), surfaces its own named
outcome (ClaimOutcome::PayoutPuzzleHashMismatch), and is reported as a
fault (a divergent entry means the port is confused or hostile, not that
there is nothing to claim) -- never corrected by substituting our own
hash and proceeding.

Defect D: documented, not wired, per instruction -- added the "not yet
wired into node startup" paragraph to mod.rs's module doc (the PR body
carries the same paragraph) so the next reader arrives at the caveat in
the code, not only in a merged PR description.

Refs #3251

* fix(rewards-claim): B1 -- ClaimableButNotClaiming is a magnitude comparison, not a zero-test

submitted_this_cycle < claimable_this_cycle now fires the anti-silence state, carrying
the shortfall as ClaimableButNotClaiming { claimable, submitted }. The previous
submitted_this_cycle == 0 zero-test let one submission mask any number of same-cycle
skips (claimable=10, submitted=1 read Nominal).

Also folds in B3's precedence fix (ChainSourceUnavailable > Faulted >
ClaimableButNotClaiming > Idle > Nominal) and the per-distributor
payout_hash_mismatches_this_cycle counter so a per-distributor fault can no longer
pin the cycle-wide Faulted state, plus R2's rename of terminal_no_entry_slot to
no_entry_slot_this_cycle now that it is no longer terminal.

* fix(rewards-claim): B2/B3 -- value-ordered budget with rotation, per-distributor fault isolation

B2: run_cycle now splits into a pre-budget phase (asset/entry/hash/threshold checks,
producing the claimable set) and a budget phase, ordering the claimable set by accrued
value descending before applying the fee ceiling and cycle budget. Dust distributors
(low accrued value regardless of attacker-controlled fee) now sort last and are the
ones the budget drops, closing the claim-suppression attack where ten high-fee dust
distributors could consume the whole cycle budget ahead of a victim's real earnings.
A rotation_cursor tie-breaks only WITHIN equal-accrued-value tiers so a genuinely
tied honest tail that exceeds one cycle's budget every cycle still rotates through
and is eventually served, rather than dropping the same tail forever.

B3: the payout-hash mismatch check in evaluate_pre_budget now increments the
per-distributor payout_hash_mismatches_this_cycle counter instead of setting
fault_reported, so one hostile or buggy entry can no longer pin the cycle-wide
Faulted state and bury ClaimableButNotClaiming for every other healthy distributor.

R2: terminal_no_entry_slot -> no_entry_slot_this_cycle throughout.

* fix(rewards-claim): R5 -- document not-yet-wired loop; persist B2 rotation cursor

An operator reading their own rewards-claim.json and seeing enabled: true has no way
to know from that file alone that no startup path constructs a ClaimEngine yet
(#3268) -- mod.rs said so, but a config file reader does not arrive at a module doc.

Also gives RewardsClaimConfig a rotation_cursor: Option<Bytes32> field so B2's
tie-break cursor survives a save/load round-trip -- an in-memory-only cursor resets
on every restart, which would starve a legitimately tied honest tail forever on any
node that restarts daily.

* fix(rewards-claim): clippy collapsible-match + SPEC v0.1.3 wording refresh

Collapses the nested if into the outer match arm in run_cycle (clippy::collapsible_match).
Also refreshes NoEntrySlot / no_entry_slot_this_cycle doc comments now that
dig-rewards-coin v0.1.3's SPEC §12.5 amendment is merged and tagged: absence is
terminal for one claim attempt only, never for the distributor, must not be cached,
and must not accumulate into a permanent exclusion set -- confirming rather than
diverging from the re-read-every-cycle behaviour already implemented.

* fix(rewards-claim): add missing rotation_cursor field in cadence.rs test literal

Struct literal in the cadence test module was not updated when RewardsClaimConfig
gained rotation_cursor (R5 commit) -- CI's Clippy/Test jobs caught the missing field
(E0063) that a local cargo check could not (killed by memory pressure before this
workspace-wide build completed).

* fix(rewards-claim): F1 -- ChainSourceUnavailable is per-cycle, never a latch

compute_state() compared against self.state -- last cycle's OWN computed
output -- so once any cycle took an Unavailable port path, every later
cycle re-asserted ChainSourceUnavailable forever, even after the chain
came back and real claims were submitting. A node still syncing, or one
dropped connection, was enough to trip this permanently.

Add ClaimStatus::chain_unavailable_this_cycle, reset to false at the top
of every run_cycle and set true only on a cycle that actually took the
Unavailable path; compute_state now reads that flag instead of
self.state, so the reading is live again.

Test: a_transient_unavailable_cycle_does_not_latch_state_for_the_rest_of_the_process
(engine.rs) drives cycle 1 unavailable, cycle 2 healthy with a
submission, and asserts cycle 2 reads Nominal. Plus a compute_state-level
regression in types.rs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F3/F4/F5 -- fix stale counters, dedup candidates, correct version doc

F3: reset EVERY per-cycle counter (distributors_known/with_own_entry/
claimable/faulted, claims_submitted_this_cycle, no_entry_slot_this_cycle)
at the TOP of run_cycle, before any early return. The three
ChainUnavailable early-return paths skip the end-of-function assignment
block entirely, so a cycle that hit one used to leave the PRIOR cycle's
counts sitting on self.status while last_attempt_at stamped fresh for
THIS cycle -- a stale count under a fresh timestamp, exactly what SPEC
§2.4's staleness reasoning forbids. types.rs's doc sentence for
no_entry_slot_this_cycle now correctly says it is dated by
last_attempt_at (the field stamped unconditionally every cycle), not
last_cycle_at.

F4: dedup `candidates` by launcher id before phase 2. A real adapter
scanning §1.3 launch comments across every (store_id, root) this node
mirrors can plausibly return the same launcher id twice; without dedup
phase 2 would evaluate it twice and submit InitiatePayout twice against
one entry slot in one cycle -- the second spend is invalid but the fee
is paid anyway.

F5: dig-rewards-coin is v0.1.3, published on crates.io -- correct the
stale "v0.1.1" module-doc claim.

Tests: a_chain_unavailable_cycle_does_not_leave_prior_cycles_counters_stale
(F3), a_duplicated_launcher_id_submits_exactly_once (F4).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards_claim): fold payout-hash mismatches into the shortfall predicate (F2)

A payout-hash mismatch never enters the eligible set, so it was counted in
NEITHER distributors_claimable NOR claims_submitted_this_cycle -- the
shortfall lived in neither term of compute_state's magnitude comparison.
All-K-distributors mismatching therefore read Nominal (falsely healthy).

Fold payout_hash_mismatches_this_cycle into the comparison's denominator:
submitted < claimable + mismatches. The result is ClaimableButNotClaiming
(a shortfall), never the cycle-wide Faulted -- Defect B3 stays fixed.

Inverts the assertion at what was engine.rs:1305
(a_payout_mismatch_never_sets_the_cycle_wide_fault_or_masks_other_distributors):
it previously asserted ClaimLoopState::Nominal across three cycles of an
ongoing mismatch, which pinned the defect as intended behaviour (an
A2-class test). It now asserts ClaimableButNotClaiming { claimable: 1,
submitted: 1 }.

Adds all_distributors_mismatching_is_a_shortfall_not_nominal, covering the
brief's exact "what if every distributor refuses for the same reason" case.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F1/F3 -- AtomicU32 in fake ports, not Mutex, keeps discovery Send

CI's Clippy job (the compiler for this crate, per brief) caught it: holding
a std::sync::MutexGuard across the .await in FlakyThenHealthyPort and
HealthyThenUnavailablePort's discover_distributors made the returned future
not Send, which #[async_trait]'s generated trait signature requires.

Neither fake needs a lock -- each holds one call counter, incremented once
per call, never read-modify-written across an await point. AtomicU32's
fetch_add removes the guard (and the Send bound violation) entirely.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F7 -- persist the fee window and cadence gate across restart

The per-cycle aggregate fee budget and the 24h cadence clock both lived only
in memory: `spent_this_cycle_mojos` was a `run_cycle` local and nothing on
disk recorded a completed cycle. Every fresh process got a full
`max_cycle_fee_budget_mojos` and an empty cadence clock, so a node stuck in
a crash-restart loop could spend unbounded XCH on fees, one full budget per
restart.

Adds three `#[serde(default)]` fields to `RewardsClaimConfig`
(`fee_window_start_unix`, `fee_spent_in_window_mojos`,
`last_cycle_completed_at`) and a new opt-in `ClaimEngine::with_persisted_fee_
window(dir, cadence_seconds)` that:
- restores the window/cadence state from `dir` at construction,
- refuses to start a cycle until the cadence has elapsed since the last
  completed one,
- rolls a fresh budget window only once the cadence has elapsed since it
  opened, otherwise keeps enforcing the budget against the persisted spend,
- persists the spend BEFORE every chain submission (write-then-spend), never
  batched to cycle end, and persists the completed-cycle timestamp when a
  cycle finishes.

Engines that never call `with_persisted_fee_window` (every pre-F7 test) are
unaffected -- this is additive, opt-in state beside the existing rotation
cursor, not a change to B2's value-ordering or rotation mechanism.

`ClaimStatus`'s own counters stay in-memory on purpose (observability, meant
to reset on restart); only the spend bound and the cadence gate persist.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F7 -- update cadence.rs test literal for new persisted fields

The three new persisted RewardsClaimConfig fields (fee_window_start_unix,
fee_spent_in_window_mojos, last_cycle_completed_at) broke this crate's only
remaining full struct literal outside config.rs/engine.rs's own test
modules -- E0063 missing fields, caught by CI's Clippy job. Switched to
..RewardsClaimConfig::default() so the next added field cannot break this
literal again, the same fix already applied once before for rotation_cursor.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F8/F14 -- atomic state write, fail closed on a corrupt window

Salvaged from a lane killed by a weekly cap before it could commit. Uncompiled at
commit time; CI is the compile signal.

Covers the fourth gate pass findings on the F7 persisted spend bound:

- F8: RewardsClaimConfig::save_to now writes atomically (temp file + rename in the
  same directory), reusing the pattern already used by mirror/reconcile_state.rs
  for the same class of state. load_from distinguishes an ABSENT file (clean first
  run, defaults are correct) from a PRESENT but unparsable one, which fails CLOSED:
  the window is treated as fully spent and nothing is submitted. Never Default, and
  never a silent clamp downward, which would hand back the budget the corruption
  was hiding.
- F14: the budget comparison uses saturating arithmetic so a corrupt disk-seeded
  fee_spent_in_window_mojos cannot panic under the release profile's
  overflow-checks.
- F9/F10/F12/F13 in progress in the same files.

Refs #3251

* fix(rewards-claim): negate with ! rather than the unimported Not trait

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* fix(rewards-claim): F13 -- correct stale test literals to the folded shortfall

compute_state (types.rs) already reported the folded shortfall
denominator (distributors_claimable + payout_hash_mismatches_this_cycle)
as `claimable` -- that part of F13 landed in f478516. The two engine.rs
tests asserting this state were written against the pre-fold, un-folded
numbers and never updated, so CI showed the implementation producing the
correct folded value (`claimable: 2`, `claimable: 1`) while the test
literals still expected the stale un-folded one (`claimable: 1`,
`claimable: 0`).

Update both literals -- and the comments describing them -- to the
folded values the F13 fix actually produces. No production code change;
compute_state's predicate and payload were already correct.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(rewards-claim): add ClaimOutcome::Faulted variant

Add the seventh ClaimOutcome variant: the type could only say a peer was
legitimately not paid, never that a chain call failed. Carries the launcher
id, a bounded (200 char) copy of the chain port's error text, and whether a
pre-committed fee was reversed, so a reader can tell no money moved.

Engine wiring at the two fault arms (engine.rs:332, :377) follows in the
next commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): both fault arms now push ClaimOutcome::Faulted

engine.rs:332 and :377 used to increment `faulted` and discard the
outcome, leaving a definitively-failed claim absent from the outcome
stream -- indistinguishable from a cycle that never touched that
distributor. Both PreBudgetResult::Fault and BudgetPhaseResult::Fault
now carry the chain port's (bounded) error text, and the
submit_initiate_payout failure path also carries the fee it reversed,
so a reader can tell no money moved. The counter stays; it is not a
substitute for the outcome.

7 call sites needed updating: 3 PreBudgetResult::Fault constructions
(reserve_asset_id, own_entry, payout_threshold), 2 BudgetPhaseResult::Fault
constructions (required_fee_mojos, submit_initiate_payout), and the 2
consuming match arms -- exactly the set that was silently discarding a
failure before this change.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards-claim): a failed submission produces a Faulted outcome

Regression for the rework: reuses F12's fixture (a submission that
definitely never broadcast) to prove both facts from one cycle -- the
outcome exists and carries the reversed fee, and the persisted window
still reflects zero net spend. Also fixes a rustfmt diff on the
PreBudgetResult::Fault variant Clippy's Rustfmt job flagged.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): delete fee_window_poisoned, stop latching self-healing state

Finding 1 (dig-node#594 pass 6): a future-dated clock is self-healing by
construction (`t > now` goes false the moment real time passes it), but the
engine ORed it into `self.fee_window_poisoned` and set that field `true`
permanently -- an RTC glitch or VM resume froze the claim loop forever instead
of until the skew passed. This is the third instance of one mechanism (pass 3
latched ChainSourceUnavailable, pass 4 left a stale cadence-gate `state`), so
the fix removes the FIELD, not just the bug: with no `fee_window_poisoned` on
`ClaimEngine`, `self.fee_window_poisoned = true` is a compile error, not a
convention to remember.

Per-cycle conditions (corrupt + future-dated-clock) now live in a
`CycleConditions` value built fresh at the top of every `run_cycle` from `now`
plus a freshly reloaded `RewardsClaimConfig`, used, and dropped -- never
stored on the engine. `corrupt` is now re-read from disk every cycle too (it
previously latched at construction only), matching what
`ClaimLoopState::PersistedStateCorrupt`'s doc already claimed but the code
never did.

Rewrites the single-cycle f10 regression into a two-cycle test: cycle 1 with a
future-dated clock refuses; cycle 2, after the clock catches up and the
cadence elapses, MUST claim. The old one-cycle version was green whether the
latch bug was present or not.

Refs #594

* fix(rewards-claim): satisfy clippy doc-list indent and rustfmt

Clippy failed with 3x doc_lazy_continuation on the PersistedStateCorrupt
doc comment (types.rs:165-167): continuation lines of a `-` bullet must
be indented under the marker, not left flush. Indent them.

Rustfmt failed on the new fail_reserve_asset_for early-return in
FakeChainPort::reserve_asset_id (engine.rs:888): the Err(...) call
exceeded the line-length limit unwrapped. Let rustfmt wrap it.

Refs #594

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards-claim): red proof for corrupt-then-repaired stale read

Cycle 1 refuses a corrupt fee-window file; the file is then repaired to
valid values with a fully-spent window and a recent completed-cycle
time. Cycle 2 must neither grant a fresh budget nor skip the cadence
gate. Fails against current `with_persisted_fee_window`, which loads
the three fee-window fields once at construction and never refreshes
them from the per-cycle `cfg` -- see engine.rs:149-157, #594.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): resync fee-window fields from disk every cycle

`with_persisted_fee_window` only loaded fee_window_start_unix,
fee_spent_in_window_mojos and last_cycle_completed_at once, at
construction. Once the now-deleted fee_window_poisoned latch stopped
masking it, a file corrupt at construction and repaired later left
those three fields stuck on poisoned()'s None/0/None placeholders --
a fresh budget and a skipped cadence gate, and persist_fee_window then
overwrote the repaired disk values with them.

CycleConditions now carries the three fields from the SAME freshly
reloaded cfg it already used for the corrupt/future-dated check, and
run_cycle copies them onto self before the cadence gate or window-roll
logic runs, but only on a read that is neither corrupt nor future-
dated. This also fixes Finding 2b: future_dated_clock now reads cfg's
own clocks instead of self's stale ones. Corrects the doc claim at the
old lines 236-238 to describe what the code now does for both halves.

Closes #594.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* refactor(rewards-claim): make disk the sole store for the fee window

Delete `fee_window_start_unix`, `fee_spent_in_window_mojos` and
`last_cycle_completed_at` from `ClaimEngine`. `run_cycle` already re-reads
`RewardsClaimConfig` fresh every cycle for the corrupt/future-dated check,
so caching a copy on the engine bought nothing and cost exactly the
stale-read defect class F16 just fixed. A local `FeeWindowState`, scoped to
one `run_cycle` call, now threads the in-flight values through
`evaluate_budget_phase`/`uncommit_fee`/`persist_fee_window` instead. With
no field left to cache into, a future `self.fee_window_start_unix = ...`
outside this file is an E0609 compile error, the same enforcement
`fee_window_poisoned`'s removal already has.

No behaviour change: every early return, the corrupt/future-dated fail-
closed path, the cadence gate, the window roll, write-then-spend
pre-commit/uncommit and the per-claim ceiling are unchanged -- only where
the three values live changed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* chore: open lane for #3269 (unit 2 -- rewards chain port + listRewardDistributors)

* chore(rewards): add dig-rewards-coin 0.2 dep; record blocked-reader finding

dig-rewards-coin 0.2.0 is published but ships no chain reader (its own
state.rs module doc: SPEC 12.1's read_distributor is withheld pending
DIG-Network/dig_ecosystem#3267). Separately, no registry in this codebase
records which distributors this node funds. A "real" RewardsChainPort
adapter over 0.2.0 therefore has no honest way to answer any of the four
trait methods with live data yet -- reimplementing read_distributor or
inventing a funded-distributor registry would be exactly the unreviewed
money-shape guess kernel invariant 6 says to escalate instead of build.
UnavailableChainPort remains the only production adapter; port.rs records
the finding for the next unit.

Refs #3269

* docs(rewards): revert dep add, name both blockers with evidence in port.rs

Per L1 direction: an unused dig-rewards-coin dep with no consumer is inert
weight and would want whichever version ships the reader (0.3.0+, PR#6 open
against DIG-Network/dig-rewards-coin), not 0.2 -- so it's reverted here and
belongs in the unit that actually consumes it.

Expanded the port.rs module doc to name both blockers explicitly with what
was read (state.rs:1-31, #3267, the open reader PR) and the negative grep
that found no funder-ownership registry anywhere in the tree, plus why
serving dig.listRewardDistributors through UnavailableChainPort was
considered and rejected (false capability signal; the exact "dispatch
surface with no function behind it" pattern dig-node#593 was the last PR
allowed to land on).

No RewardsChainPort adapter, no Node wiring, no dispatch arm -- all three
reward methods stay -32601 pending #3267 and a funder-ownership registry
(parallel tickets, both required).

Refs #3269
* feat(rewards): durable funder-ownership registry (identity only)

Records WHICH reward distributors this node funds -- launcher id plus the
store id when the funding act knew it -- and nothing else. No amount can
be recorded: every money figure here is chain-derived and goes stale, and
dig_ecosystem#3286's wrapping u64 share multiply means a figure crossing
this boundary can already be wrong. Durable storage would make it
permanent.

Persistence mirrors rewards_claim::engine::ClaimEngine: an optional state
directory (absent = inert, so tests and default builds need no disk),
atomic write, and a corrupt record is never overwritten. The set is never
cached on the registry -- every read re-reads the file -- so no transient
state lives on the struct across calls (the engine's F16/F18 discipline).

The read outcome is closed and distinguishes funds-nothing from every
unknown: NotConfigured (no state dir / dir missing / nothing written yet),
PersistedStateCorrupt and IoFailed. A corrupt record is quarantined by
COPY and left in place, so the next read is corrupt too rather than
decaying into an empty list -- SPEC 2.4 clause 1 in the place it costs
most, since an empty dig.listRewardDistributors tells an operator it funds
no distributors.

Node carries it in a OnceLock slot with pub(crate) accessors, mirroring
mirror_pointers and reward_prover_statuses. Nothing installs it in
production yet: no dig-node code funds a distributor, and the startup
wiring belongs to dig_ecosystem#3268, so the slot is marked the same way
register_reward_prover_status is.

Refs #3285

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rewards): drop a duplicated funded_distributors initializer

Two test-only `Node` literals got the slot twice (E0062), because the
inserted line's own indentation made the wider-indented site match twice.

Refs #3285

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…al startup (#3268) (#605)

* feat(rewards): wire the peer claim loop onto a cadence driver from real startup (#3268)

The peer reward-claim engine shipped complete and tested in #594 but INERT:
nothing constructed it, so the 86400s cadence never fired while
`rewards_claim.enabled` defaulted to `true` -- a config asserting a subsystem
is on while nothing runs.

`rewards_claim/driver.rs` is a SCHEDULER, not a chain adapter: it derives this
node's own payout puzzle hash, loads `RewardsClaimConfig`, builds a
`ClaimEngine` against the only production port that exists
(`UnavailableClaimChainPort`, until #3249 lands a real one) and drives
`run_cycle` every `cadence_seconds + jitter`, jitter drawn from the OS CSPRNG.
`server.rs`'s `serve_with_shutdown` makes exactly one call into it, beside
`self_heal::spawn_driver_if_service()`.

`enabled = true` now means: a background task exists, drives a counted cycle
per interval, and its outcome is readable in-process as a NAMED state. With
`UnavailableClaimChainPort` every cycle honestly reports
`ChainSourceUnavailable` -- the gap is loud instead of silent.

Anti-silence: `ClaimLoopHandle` carries a monotonic `cycles_driven` counter
alongside the status, because `Idle` before the first cycle is correct and
honest, so status alone cannot tell "scheduler never fired" from "nothing was
claimable". The gate takes an INJECTED handle rather than reading the
process-wide singleton, so `ClaimDriverRefusal::{Disabled, ChainSyncDisabled,
NoOperatorWallet}` and "spawned but never ticked" are four pairwise-distinct
readings a test asserts in-process.

Nothing goes on the wire: no RPC method, dispatch row, handler or OpenRPC
entry. `ClaimStatus` stays off the wire until #3249's real adapter lets the
status surface be re-derived against it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rewards): silence the deliberately-ignored fake-port argument (#3268)

`OneDistributorPort::own_entry` ignores the puzzle hash the engine passes in
on purpose -- the fake always returns the entry keyed to `entry_keyed_to` so
the ENGINE's own comparison is what decides claimable vs. refused. Named it
`_payout_puzzle_hash` (clippy `-D unused-variables`) and moved the rationale
onto the parameter, where the next reader meets it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(rewards): close the untested joint between the claim gate and the drive loop (#3268)

`decide_claim_driver` was tested and `drive` was tested, but the production
body joining them -- load the config from the state dir, derive the engine,
reach `drive` -- was exercised by nothing. That is the exact shape of #594,
which shipped a complete, fully-tested and entirely inert claim engine: had
this body returned early, built the engine wrong, or never reached `drive`,
every test on this change would still have passed and a real node would still
never claim.

Split `run_claim_driver` on the same `load` / `load_from` pattern the config
itself uses: `run_claim_driver_in(state_dir, own_payout_puzzle_hash, port,
handle)` holds the whole body and is generic over the port, and
`run_claim_driver` is reduced to the wallet-derivation adapter that cannot be
reached from a test. Adds two tests through the real body: counted cycles from
a written config (zero before the interval, exactly one per interval after),
and `UnavailableClaimChainPort` reporting `ChainSourceUnavailable` by name on a
driven cycle -- proving the production adapter path is reached, not only a fake.

No behaviour change: same config, same engine construction, same port.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rewards): settle before advancing, and keep the wrapped assertion out of rustfmt's reach (#3268)

Two repairs to the new composition tests:

- The `ChainSourceUnavailable` test advanced the paused clock before the
  spawned body had reached its first `sleep`, so the timer was not yet
  registered and the advance bought no cycle at all -- it read zero cycles, not
  a driven one. A `settle()` first, mirroring the counted-cycles test.
- rustfmt rejoined a `\`-continued assertion message into one line, leaving 14
  literal spaces mid-sentence and tripping the repo's own
  `continuation_guard`. `concat!` states the wrap explicitly, so no formatter
  pass can reintroduce the run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* feat(rewards): emit a per-cycle event so the claim loop has a reader (#3268)

The adversarial gate blocked #605 on this: the PR justified itself by making
an inert subsystem loud, but nothing in the shipped binary could hear it.
ClaimLoopHandle had no caller outside driver.rs tests, drive() emitted no
event, and all three tracing calls fired only on paths where the loop does
NOT run -- so on the default path (enabled=true, chain sync on) the
observable output was identical to before the PR: silence. Today that
silence covers a permanent ChainSourceUnavailable; after #3249 it would also
cover Faulted, PersistedStateCorrupt and ClaimableButNotClaiming.

log_cycle() now names the state and the cycle count after every cycle --
info for Nominal, warn for everything else, because "this peer is earning
nothing and here is why" is a warning, not routine chatter. Tested by
capturing the subscriber output rather than asserting the call site exists,
since this ticket exists because a guarantee that cannot be observed in a
running node is not a guarantee.

Refs DIG-Network/dig_ecosystem#3268

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rewards): stop a u64::MAX jitter bound panicking the claim driver

`OsJitter::jitter_seconds` computed `bound + 1` for its modulus. `jitter_seconds`
comes from the node's persisted `rewards_claim` config and is not clamped, so a
config carrying `u64::MAX` overflow-panicked inside the detached claim-driver
task -- which has no restart and emits no further log output, so the claim loop
would die silently for the rest of the process lifetime.

`saturating_add(1)` keeps the draw within `0..=bound` for every input; the
composed `next_interval_seconds` range is unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rewards): sanitize the claim schedule so no config value silently disables the loop

`next_interval_seconds` saturates instead of panicking, so a persisted
`jitter_seconds = u64::MAX` no longer crashes the driver -- it schedules the
next cycle ~585 billion years out. The claim loop then never fires again: no
cycle, no `log_cycle` line, and a permanent, reassuring `0` cycle count. That is
#594's inert-but-green shape reopened one level up, in the config file.

`run_claim_driver_in` now sanitizes both schedule fields where it reads them,
before either reaches the engine's fee window or `drive`:

- `CLAIM_SCHEDULE_SECONDS_MAX = 31 * 24 * 60 * 60` (31 days) -- above every
  documented default (86,400s cadence, 3,600s jitter) and above "claim
  monthly", while excluding everything that means never.
- out of range (or a zero cadence, which would busy-loop) substitutes the
  published default and emits `tracing::warn!` naming the field, the rejected
  value and the substituted one. Nothing is accepted silently.

`config.rs` is untouched: it keeps reporting what is on disk.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* chore(release): v0.256.0 -- reward distributor prover, peer claim loop, prover-status RPC (#602)

* feat(mirror): persist mirror-bond coin ids (#575)

* chore: open lane for #574

* feat(mirror): persist mirror-bond coin ids so a restart cannot double-create

Bond identity was reconstructed from a live chain scan on every read
(`mirror/observe.rs`), with no persistence of its own. A restart, a cold
replica, or a lagging/flaky chain source all rendered a real, unspent,
confirmed bond as "no bonds" -- and because the in-flight suppression is
keyed on pending/submitted audit entries, a bond whose create had already
CONFIRMED was not suppressed either, so the same short scan that emptied
the read surface also cleared the one thing that would have stopped a
second coin being paid for collateral that already exists (dig-node#574).

Persist the (store, root, epoch) -> coin_id mapping in the EXISTING spend
audit record (spend-audit.jsonl) rather than a new store: a mirror-coin
create already writes store_id + AuditedBond{root, epoch} + amount there,
and the coin id itself becomes durable the moment resolve_landed_spends
confirms it. This adds the one missing piece -- the advertised URL a
create carries -- and a read-side query, confirmed_mirror_bond, that
returns the newest CONFIRMED record naming a triple.

Chain stays authoritative. mirror::local_bond::recheck_missing_bonds
never trusts the record: for a held bond the live scan did not cover, it
asks the record for a candidate coin id, then re-verifies that SPECIFIC
coin against chain via the same independent check (chain_bond_verdict)
that verifies an untrusted peer's claimed bond. Only a fresh `Bonded`
verdict is folded back in, as covered; `Unbonded`/`Unverified` fall
through to an ordinary create, exactly as if no record existed.

Version: 0.254.86 (patch -- per #522 the MSI ProductVersion minor field
is exhausted and the counter lives in patch).

Co-Authored-By: Claude <noreply@anthropic.com>

* test(mirror): prove the recovery wiring end to end through PassRunner::run

Adds two integration-level tests over the REAL pass pipeline, not just the
isolated recheck_missing_bonds unit tests: a bond missing from the live
scan with a chain-reverified durable record is recovered (no double
create, correct Bonded state reported), and the control -- the same
record but chain disproves it -- correctly falls through to an ordinary
create. Together these are the concrete regression test for the
cold-start/lagging-chain-source double-create scenario the ticket asked
to have measured.

Also refactors in_flight_creates to take the already-folded SpendLedger
instead of re-reading the log itself, so PassRunner::run reads the audit
file once per pass and shares it with the new recovery step, and fixes a
doc comment on in_flight_creates that the recovery step would otherwise
have made stale on landing ("a Confirmed create has a coin the chain
observation already sees" is no longer unconditionally true).

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(fmt): wrap long test signatures to satisfy rustfmt

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(clippy): use slice::from_ref instead of cloning for a single-element slice

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(release): bump to v0.254.89

Base branch moved to develop after PR #576 merged there at v0.254.88
(main and develop are currently identical), leaving this branch's
carried-forward .88 as a zero-increment against the new base. Bumped
to the next free integer after fetching and verifying both origin/main
and origin/develop tip at .88.

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

* fix(peer): count accepted relayed circuits in the connected pool (#579)

serve_accepted_relay_conn served every accepted relayed circuit (full mTLS
auth, full L7 peer RPC) while registering it nowhere, so connected_peers
under-reported every relayed inbound peer -- the relay-leg twin of the
direct-inbound defect #402/#523 already fixed.

adopt_inbound_peer_in_pool now dispatches by TraversalKind: Relayed routes to
dig-gossip's already-published adopt_relayed_inbound_handle (v0.32.0, the rev
this repo already pins), every other tier keeps the unchanged
adopt_direct_inbound_handle path. serve_accepted_relay_conn adopts before
serving and releases after, mirroring the direct listener exactly.

Refs: https://github.com/DIG-Network/dig_ecosystem/issues/3124

* fix(cli): guard the exit-code namespace shared with diga against collisions (#582)

* chore: open lane for #3189

* fix(cli): guard the exit-code namespace shared with diga against collisions

dign and diga deliberately share one process exit-code numbering (dig-app's
outcome.rs says so in its own doc comment), so a number is free only if it
is unoccupied ecosystem-wide. dig-node#407 assigned exit 7 to
NODE_UNREACHABLE by checking only this repo's own table, where 7 genuinely
was free -- and collided with diga's NOT_CONNECTED. A reviewer caught it by
hand; nothing failed automatically.

Adds scripts/check-exit-code-collisions.sh: parses both enums' code()/name()
match arms straight from their own source -- this repo's ExitCode, and a
live fetch of dig-app's outcome.rs at its default branch -- and fails if a
number carries two different names, or if either side draws a number from
the reserved shell signal range (126, 127, 128+N). Ships with an 18-case
hermetic test harness (scripts/tests/check-exit-code-collisions.test.sh)
covering the actual #407 collision shape, arm-order independence, arm-count
mismatch, the reserved-range boundary from both sides, the live-fetch path
itself, and fail-closed behaviour on an empty/missing/unreachable table.

Wires a real (unstubbed) invocation into ci.yml's existing "Release-script
tests" job so a collision introduced by a future PR, on either side, is a
red required check on that PR -- not a note a reviewer has to catch. The
fetch retries twice (2s backoff) since this becomes a required, network-
dependent check; a fetch failure still fails closed after retrying, never
silently passing as "diga has no codes".

Updates SPEC.md 8.4 to point at the mechanical guard instead of leaving
"re-check both tables" as unenforced prose, and records that the
extension's WALLET_WS_ERR.NOT_CONNECTED = -33001 is a separate JSON-RPC
error-code space, not a rival of this one. Adds a doc-comment to the
existing transcribed collision test pointing future readers at the live
script as the authoritative check; the transcription remains as a narrower,
hermetic regression pin for the #407 shape specifically.

No renumbering: every currently-assigned code is unchanged.

Refs #3189

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings (#3190) (#583)

* chore: open lane for #3190

* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings

Replicates dig-node-service::continuation_guard (dig-node#526/#501) into dig-node-core,
dig-wallet, dig-runtime and dig-chat-protocol, line-for-line apart from crate-specific
constants -- ported rather than reinvented, per dig_ecosystem#3190.

Wiring the guard in surfaced 48 pre-existing lost-continuation defects the ticket's own
"no measured corruption in these four crates" note did not anticipate: 36 in dig-node-core,
12 in dig-wallet, mostly test-assertion prose where a multi-line message lost its `\`
continuation and shipped the source's own indentation as a mid-sentence space run (one
as the worse `\n`-plus-indentation variant). All 48 are collapsed to the single space the
sentence always meant, with surrounding indentation and wording otherwise untouched.

Two lines are real column-alignment, not defects, and get a targeted EXCLUDED_LINE_RANGES
entry on dig-node-core instead of a rewrite: download.rs's `claimed(...)` fixture-table
trailing comments, and net.rs's `label : value` debug-print alignment.

Refs https://github.com/DIG-Network/dig_ecosystem/issues/3190
Refs https://github.com/DIG-Network/dig_ecosystem/issues/3130

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

* feat(mirror): detect an IP change daily and reconcile mirror coins to the current advertise URL

Automatic half (D1-D4) of the daily mirror-URL reconcile: derived personal-day offset, two-observation hysteresis, nine ordered gates with K sized as a self-funding prefix before any reclaim, `submitted` never `completed`, audit lines gain `reclaim_reason` + `trigger`.

Gates at b4c09866: loop-reviewer PASS (review 5129272285), loop-security PASS @ 175304e1 (tree byte-identical, `git diff 175304e1 b4c09866` empty), adversarial loop-decider PASS (comment 5567083644; SHOULD-FIX findings ticketed separately).

Refs DIG-Network/dig-node#570
Refs DIG-Network/dig_ecosystem#3203

* feat(serve): content hosting + serve path batch, v0.255.0 (dig_ecosystem#3212)

Nine commits from the #3212 serve-path lane, gated at 899cc68f (reviewer review 5130425808,
security comment 5568662836), plus the single semver bump to 0.255.0 for the develop -> main batch.

- store_id/root case normalised at the CapsuleKey boundary; cache delete targets the matched entry
- tier-0 occupancy reads the eviction-aware ledger
- profile-sync outbound budget in bytes; announcer asked first
- melt confirmation depth on the terminal spend, fail-closed
- EngineWarming (-32002) while the peer tier attaches, never -32004
- window completeness derived from the bytes read
- deps: dig-stun 0.2, chia-query 0.24.3, dig-nat 0.21.2, dig-logging 0.2.2

Refs DIG-Network/dig_ecosystem#3212

* chore: untrack gitnexus-generated agent files (#590)

* chore: untrack gitnexus-generated agent files

These files were generated by `gitnexus analyze` as a side effect of
indexing this repository. They are development-loop private tooling
output, not product code, and carry no secrets. They are removed from
tracking going forward via .gitignore; history is deliberately NOT
rewritten.

Refs #3177

* chore: drop private-repo reference from gitignore comment

The ignore comment named a private repository and an internal issue
number in a public file, which is the same disclosure class this
change set exists to remove; the reference is dropped and the
guidance kept.

* feat(rewards): always-on prover loop engine -- honest liveness, type-enforced self-exclusion, bounded spend (#593)

The always-on reward-prover engine: ~2,000 lines under
`crates/dig-node-core/src/rewards/`, built against the merged `dig-rewards-coin`
SPEC. Library only -- nothing spawns it, and the sole production
`RewardsChainPort` refuses every call, so it cannot spend. Wiring the composed
system is #3265, which carries its own gate.

The epic's premise -- "anytime the process isn't running, rewards are not being
distributed" -- is half wrong, and the false half is the dangerous one. `Sync`,
`NewEpoch` and `InitiatePayout` need no manager authority, so funder downtime does
not stop rewards: it FREEZES THE ENTRY SET while accrual and payouts continue.
Peers that stopped mirroring keep earning; peers that started cannot begin. That
shaped the whole design.

Liveness honesty (SPEC 2.4). The status record carries no `healthy`/`ok`/`up`
boolean and no precomputed staleness, because a wedged loop cannot report its own
wedging -- whatever it last wrote stays there, so a writer-set flag reads true
forever after the failure it exists to reveal. The reader derives staleness from
`last_cycle_completed_at` against `observed_at` and its own clock. A recursive
JSON-key test enforces the absence at every nesting depth; asserting on keys and
never substrings, since `ProverState::Running` legitimately serializes the VALUE
"running". The one legal staleness signal is chain-derived (SPEC 12.4: 48 hours
AND a non-zero reserve, from the singleton's own spend history) and lives on the
distributor read, where a wedged prover cannot fake it.

Self-exclusion is a compile error, not a habit. dig-node#261's lesson is that an
invariant enforced on some paths is not an invariant. `admit` is the single
admission point, checks both SPEC 5.2 coordinates (own peer_id OR a payout puzzle
hash this wallet controls), and mints an `AdmittedPeer` with private fields and no
public constructor -- so `EntryAction::Add` cannot be built by a path that skipped
admission.

A prover's own fault can never strike a peer. `GateError` is a distinct type from
`GateIneligibleReason` and `record_prover_fault` takes `&self`, so SPEC 3.6 clause
4 is enforced by the borrow checker rather than by comment. Without that, a
misconfigured operator -- one missing mirror-collateral epoch ordinal -- would
strike every peer at once and evict its entire 250-entry set in three hours, each
eviction a fee it pays plus a settlement out of its own reserve.

The money bounds are stated where a human reads them (`rewards/mod.rs`): 24
bundles/day, 192 entry actions/day, a fee ceiling of 24x the configured standard
fee, 192 removals/day worst case with 96/day sustained churn. Recorded honestly:
SPEC 6.3's rate bound and fee ceiling are ONE control, not two.

Three gate rounds, every leg fresh-context. Round 3 at this head: reviewer PASS,
adversarial decider RATIFY (leg closed), security CHANGES-REQUIRED on a finding
the decider ratified deliberately -- adjudicated in
https://github.com/DIG-Network/dig-node/pull/593#issuecomment-5601784815 and
carried to #3265 with the remedy corrected, because the proposed fix would have
persisted a poison flag to the very store whose writes were failing.

Found and fixed under gate: a census ordinal off by one in both directions (SPEC
4.6 requires n-1 exactly); an unreachable grace window leaving a named constant
with no reader; a missing `NewEpoch` spend; an absent-ordinal path attributing a
prover fault to peers; and a daily fee ceiling 24x too high because a per-bundle
fee was consumed as a daily ceiling.

Refs DIG-Network/dig_ecosystem#3250

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* feat: serve dig.getRewardProverStatus at Tier::Control (#595)

* chore: open lane for #3269

Bump dig-rpc-protocol to 0.11.0 (adds dig.getRewardProverStatus and
the other reward RPC methods to the wire).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards): fail-closed Reward-tier guard + dig-rpc-protocol 0.11 line assertion

- dependency_tree.rs: assert the resolved dig-rpc-protocol line is 0.11 (was 0.10);
  documents the known-red two-version state pending the dig-peer 0.14.0 /
  dig-download 0.23.0 cascade (#3269).
- reward_methods_tier_guard.rs: fail-closed guard over the live Method::ALL
  catalogue -- every Reward-named method must be Tier::Control and not
  peer-reachable, so a fifth reward method added later is caught at the wrong
  tier automatically rather than inheriting a wrong default (binds #3261's rule
  node-side).
- peer.rs: sibling unit test exercising the real (pub(crate)) is_peer_reachable_method,
  since an external integration test cannot see it -- same guard, executed against
  this node's own allowlist rather than only the shared crate's.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* style: remove trailing blank line in reward_methods_tier_guard.rs

* feat(rpc): serve dig.getRewardProverStatus at Tier::Control

Adds the missing handler for PR#595: a new reward_prover_statuses
registry + accessors on Node (empty until #3265 spawns a prover loop,
so the registry read is real, not a stub), a dispatch.rs arm inside
the Method enum match (never the string pre-match), and a
field-for-field mapping from dig-node-core's internal
rewards::state::RewardProverStatus (camelCase-tagged) onto
dig-rpc-protocol 0.11's wire RewardProverStatus (snake_case-tagged
struct, camelCase-tagged ProverState value), widening entry_count
u32 -> u64 explicitly and hex-encoding the three [u8; 32] identity
fields.

An all-zero launcher_id (what an uninitialised registry slot
hex-encodes to) is omitted at this boundary rather than rendered as
a real distributor with a plausible-looking id -- the money-hole
class the dig-rewards-coin driver's adversarial gates found three
times.

Tests (in dig-node-core::lib.rs's existing test module, where the
pub(crate) registry accessors are visible) drive the real dispatch
entry point (handle_rpc -> RpcDispatch::dispatch -> the Method arm)
and assert field-for-field on the serialized JSON body: populated
registry, empty registry (-> {"statuses": []}), zero-id omission,
tier/peer-reachability, enum-match-not-string-prematch, and
launcher_id filtering. The no-health-boolean / no-staleness
assertion is by key set, not substring.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* style: rustfmt the reward-prover-status registry + tests

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* chore(deps): bump dig-download 0.23, dig-peer 0.14, dig-rpc-protocol 0.11

Closes the two-versions-of-dig-rpc-protocol split (#3269): dig-download 0.23.0
and dig-peer 0.14.0 both now resolve dig-rpc-protocol ^0.11, matching
dig-node-core's own dig-rpc-protocol = "0.11.0" line, and dig-node-service's
two 0.10 lines (main dep + dev-dependency restatement for
openrpc_drift_guard.rs) move to 0.11 to match.

Manifests only. cargo update / Cargo.lock intentionally NOT run yet: a fourth
capper, dig-peer-selector ("0.11" in dig-node-core/Cargo.toml), still requires
dig-peer = "^0.13" in every published version through 0.11.1, so the tree
cannot fully resolve until a dig-peer-selector release picks up dig-peer 0.14.
CI will stay red on this commit for that reason, which is expected.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(rpc): close dig-rpc-protocol 0.11 cascade + attribute payout figures

Bump dig-peer-selector 0.11 -> 0.12 (the release that moves onto dig-peer
^0.14) and run cargo update, closing the two-versions-of-dig-rpc-protocol
split: Cargo.lock now resolves exactly one dig-rpc-protocol, at 0.11.0,
alongside dig-peer 0.14.0, dig-download 0.23.0, dig-peer-selector 0.12.0.

Add a subject-attribution test and doc comments to
reward_prover_status_to_wire: total_paid_out_base_units and
reserve_base_units are per-distributor totals (this distributor's payout to
ALL its mirrors, and this distributor's own reserve), never the querying
node's own earnings and never summed/cross-attributed across distributors.
This is the defect class a sibling adversarial gate found in dig-app#403's
rewards pane, which rendered a distributor total as one mirror operator's
personal earnings and overstated by up to 250x.

Checked: rewards/state.rs, rewards/port.rs and rewards/mod.rs contain no
Eligible/verdict/payout_hash symbol, so nothing in this mapping surfaces a
persisted EligiblePayoutHash verdict.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): silence dead_code on register_reward_prover_status pending #3265

Clippy's non-test lib target has no production caller for
register_reward_prover_status yet, because #3265 (the always-on prover loop
that would call it from bring-up) has not landed -- only tests call it today.
cfg_attr(not(test), allow(dead_code)) stands in for that missing caller
until #3265 wires a real one.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): make the all-zero identity guard non-silent and cover all three fields

Security (blocking) and the adversarial leg both found the same defect in the
zero-launcher_id filter: it checked only launcher_id, so a registration bug
that zeroed store_id or root beside a valid launcher_id would pass through as
a plausible record, and dropping the bad record silently destroyed the
evidence a registration bug happened at all -- SPEC Sec2.4 clause 1's exact
prohibition.

zeroed_identity_fields() now checks launcher_id, store_id AND root. The
dispatch filter still excludes a record with any zeroed field (never renders
an uninitialised slot as a real distributor), but first fires a
tracing::warn! naming which field(s) were zero, so a bad registration is
observable rather than swallowed. Kept isolated in dispatch.rs rather than
woven into the wire mapping, since this belongs at #3265's writer once that
lands.

Replaced get_reward_prover_status_omits_an_all_zero_launcher_id (which
proved the omission but not the observability, and never exercised a zeroed
store_id/root beside a valid launcher_id) with
get_reward_prover_status_logs_and_excludes_a_zeroed_identity_field, covering
both a zeroed launcher_id and a zeroed store_id beside a valid launcher_id,
and asserting the tracing::warn! output via the crate's existing
capture_sync_logs test utility.

Fixed a now-false "Known-red" doc comment on
tests/dependency_tree.rs::the_workspace_carries_exactly_one_module_wire_crate:
the dig-peer 0.14.0 / dig-download 0.23.0 / dig-peer-selector 0.12.0 cascade
already landed in this PR's Cargo.toml/Cargo.lock, so the assertion is green,
not red. Assertion itself untouched -- still exact-version.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): correct a born-false "shipped dig-app 15.5.0" doc claim

dig-app's latest release is v15.4.0 -- there is no v15.5.0 tag -- and
dig-app#403 (the pane that would consume dig.getRewardProverStatus) is OPEN
and unmerged. Point the doc comment at the real, unmerged consumer instead
so a future reader doesn't take this as evidence a shipped consumer depends
on the guard, which would wrongly discourage relocating it to #3265's writer.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): correct doc placement, assert the zeroed field by name, treat root as an observation

Three findings from the correctness gate on PR#595 at 134864a9.

1. The zeroed-identity helper's doc block was spliced onto the end of
   reward_prover_status_to_wire's block with no separator, so the wire-mapping
   rationale documented a boolean predicate and the mapping function was left
   with no doc at all. Each doc block now sits above the item it describes.

2. The log assertion `logs.contains("launcher_id")` was a tautology: the warn
   emits launcher_id as a structured field on every fire, so the property the
   guard exists to add -- naming which field was zeroed -- was unasserted.
   Deleting `zeroed_fields = ?zeroed` from the warn left every assertion green.
   The test now asserts the zeroed_fields value itself, which the fixture makes
   exact and disjoint across cases.

3. `root` is an observation, not an identity. A registered prover that has not
   completed its first cycle plausibly has no root, and a writer that zero-inits
   it would have made a healthy prover invisible. A zeroed launcher_id or
   store_id still excludes the record; a zeroed root alone warns and returns.

Refs #3269

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rpc): restore zeroed_fields structured field dropped from the pushed warn

The previous commit (080be3df) landed with `zeroed_fields = ?zeroed` missing
from the tracing::warn! call in the GetRewardProverStatus filter -- a
one-line regression introduced while proving the new log assertion goes red
without it, never restored before the commit was made. Without this field
the log line never names WHICH field was zero, so an operator sees only
that something was excluded, and the test asserting `zeroed_fields=[...]`
per case would fail. Restored; all 7 reward-prover-status tests green.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rpc): split zeroed-field logging by level -- WARN for a missing
identity, DEBUG for a zeroed root

A zeroed launcher_id or store_id is a real registration bug: the record is
excluded and now logs at WARN, naming the exact field(s) via
`zeroed_fields=[...]`. A zeroed root alone is an ordinary pre-first-cycle
state, not a fault: the record is still returned, and now logs at DEBUG
instead of WARN, so an operator polling this endpoint sees warn-level
volume proportional to real registration bugs, not to every
not-yet-cycled prover on every poll.

Updated the doc comments on `zeroed_fields`, the dispatch filter and the
test to describe the level split, and extended the regression test to
assert on level (WARN vs DEBUG) as well as the `zeroed_fields` value.
Proved both directions: flipping the DEBUG branch back to WARN turns the
test red on the level assertion; flipping the field-name assertion back to
a bare `contains("launcher_id")` would have passed unconditionally (the
prior tautology) and is no longer possible since the assertions now pin
`zeroed_fields=[...]` plus the level string.

Refs #3269

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

* feat(rewards): peer-side claim loop -- watch distributors, claim on cadence (#3251) (#594)

* feat(rewards): peer claim loop skeleton -- discovery, cadence, config, claim port

* test(rewards): write all twelve acceptance tests for the peer claim loop

* feat(rewards): wire the seven rewards_claim submodules into the crate

mod.rs declared no submodules, so types.rs/port.rs/config.rs/cadence.rs/
parser.rs/engine.rs/hints.rs (1,435 lines, 25 tests) were never part of the
crate and never compiled. Declare them and re-export the public surface.

* style(rewards): cargo fmt the rewards_claim submodules

* chore(deps): bump dig-node-control-interface 0.33->0.35, dig-rpc-protocol 0.10->0.11.0

dig-rpc-protocol 0.11.0 is merged and tagged upstream; the other dig-*/chia-*
deps of dig-node-service were already at the latest permitted-by-caret version
in Cargo.lock. crates/dig-node-core/Cargo.toml is untouched (#3250's file set).

* chore(deps): revert dig-node-control-interface and dig-rpc-protocol bumps

Both create a duplicate-version split in this PR's scope and neither can be
closed without editing a sibling crate's manifest this lane does not own:

- dig-rpc-protocol 0.11.0 duplicates against dig-node-core/Cargo.toml:194
  ("0.10.2"), which is #3250's live file set (dig-node#593).
- dig-node-control-interface 0.35.0 duplicates against
  dig-wallet/Cargo.toml:81 ("0.33"), a sibling crate this lane does not own;
  the observed Clippy break (BalanceAsset/Asset type-identity mismatch,
  missing url_reconcile/url_current/urls fields) came from THIS duplicate,
  not from dig-rpc-protocol.

Both belong to their own sequenced dep-bump unit of work, not this ticket.

* fix(rewards-claim): fault laundering, permanent no-entry blacklist, fee ceiling magnitude

Three independent gates on dig-node#594 (51516e62) found four logic defects; this
addresses A, B and C per the corrected fix brief (D is documented only, not fixed
here per the brief's own instruction).

Defect A -- the anti-silence surface laundered every real fault into `Nominal`:
- A1: `fault_reported` had no fault-bearing ClaimLoopState to fall through to, so a
  chain adapter erroring every cycle read `Nominal` forever. Added
  `ClaimLoopState::Faulted { cycles }`, outranking Nominal/ClaimableButNotClaiming,
  under ChainSourceUnavailable.
- A2: inverted the test that asserted A1's bug as correct behaviour.
- A3: `ClaimableButNotClaiming` compared a per-cycle snapshot
  (`distributors_claimable`) against a lifetime-cumulative counter
  (`claims_submitted`), so it latched healthy forever after one lifetime success.
  Added `claims_submitted_this_cycle` (per-cycle) as the correct comparand; kept
  `claims_submitted` as a cumulative counter.
- A4: `last_discovery_at`/`last_cycle_at` were stamped even on a failed discovery
  or an all-faulted cycle, destroying the staleness signal a reader depends on.
  Now only stamped on success; added `last_attempt_at` to prove liveness
  separately. `fault_reported` and `distributors_faulted` now reset per cycle
  instead of latching for the process's lifetime.

Defect B -- "terminal, stop retrying" was implemented as a process-lifetime
blacklist (`terminal_no_entry: HashSet<Bytes32>`, never cleared). That blocked
SPEC 12.5 clause 2's re-entry path (evicted, re-challenged, re-admitted never
claims again) and permanently punished a peer that discovered a distributor
before the funder's AddEntry landed. Removed the blacklist entirely -- `own_entry`
is a cheap chain read, re-issued every cycle for every candidate, matching clause
3's "never cache across cycles". `NoEntrySlot` is now a per-cycle observation, not
a lifetime sentence.

Defect C -- the fee ceiling didn't bind anything and there was no aggregate cap:
- C1: default `CLAIM_FEE_CEILING_MOJOS_DEFAULT` lowered from 1_000_000_000
  (transplanted from `MIRROR_SPEND_FEE_CEILING_MOJOS`, sized for a mirror-coin
  spend) to 200_000 -- 2x the observed routine Chia fee range (5,000-100,000
  mojos), so it actually binds instead of leaving 4-5 orders of magnitude of
  slack.
- C2: added a per-cycle aggregate fee budget
  (`max_cycle_fee_budget_mojos`, default 10x the per-claim ceiling) checked
  across all claims in a cycle, closing the attacker-cost gap where funding K
  distributors could force a victim to spend K x the per-claim ceiling per cycle.
  New `ClaimOutcome::SkippedCycleBudgetExhausted`.

Tests: rewards_claim test count 26 -> 37 (11 new: repeated_discovery_faults_never_
read_as_nominal, failed_discovery_leaves_last_discovery_at_unchanged, a_reported_
fault_surfaces_as_faulted_not_nominal, a_lifetime_submission_does_not_mask_a_
later_cycle_that_submits_nothing, no_entry_slot_then_re_admitted_produces_a_claim_
on_the_later_cycle, distributors_each_under_ceiling_do_not_collectively_exceed_
the_cycle_budget, the_default_per_claim_ceiling_actually_binds_a_routine_fee, plus
renamed/rewritten no_entry_slot_is_non_terminal_and_re_checked_every_cycle).

Refs #3251

* fix(rewards-claim): refuse a claim entry for the wrong payout puzzle hash

CI fix: cadence.rs's RewardsClaimConfig literal was missing the
max_cycle_fee_budget_mojos field added in the previous commit (E0063,
caught by CI's Clippy/Test jobs -- the local cargo check for this
workspace is too slow to use as the compiler here).

Defect E (security-gate finding, folded in before this pass closes):
submit_initiate_payout was called with entry.payout_puzzle_hash -- whatever
the chain port handed back -- with no check against this node's own
own_payout_puzzle_hash. UnavailableClaimChainPort is the only production
adapter today so nothing can exploit this yet, but the whole point of the
ClaimChainPort seam is that #3249 swaps in a real adapter with nothing
above it changing, so deferring this would ship the landmine live with no
review pass watching for it. Added an equality guard before the spend:
a mismatch refuses to submit, counts
(ClaimStatus::claims_refused_payout_mismatch), surfaces its own named
outcome (ClaimOutcome::PayoutPuzzleHashMismatch), and is reported as a
fault (a divergent entry means the port is confused or hostile, not that
there is nothing to claim) -- never corrected by substituting our own
hash and proceeding.

Defect D: documented, not wired, per instruction -- added the "not yet
wired into node startup" paragraph to mod.rs's module doc (the PR body
carries the same paragraph) so the next reader arrives at the caveat in
the code, not only in a merged PR description.

Refs #3251

* fix(rewards-claim): B1 -- ClaimableButNotClaiming is a magnitude comparison, not a zero-test

submitted_this_cycle < claimable_this_cycle now fires the anti-silence state, carrying
the shortfall as ClaimableButNotClaiming { claimable, submitted }. The previous
submitted_this_cycle == 0 zero-test let one submission mask any number of same-cycle
skips (claimable=10, submitted=1 read Nominal).

Also folds in B3's precedence fix (ChainSourceUnavailable > Faulted >
ClaimableButNotClaiming > Idle > Nominal) and the per-distributor
payout_hash_mismatches_this_cycle counter so a per-distributor fault can no longer
pin the cycle-wide Faulted state, plus R2's rename of terminal_no_entry_slot to
no_entry_slot_this_cycle now that it is no longer terminal.

* fix(rewards-claim): B2/B3 -- value-ordered budget with rotation, per-distributor fault isolation

B2: run_cycle now splits into a pre-budget phase (asset/entry/hash/threshold checks,
producing the claimable set) and a budget phase, ordering the claimable set by accrued
value descending before applying the fee ceiling and cycle budget. Dust distributors
(low accrued value regardless of attacker-controlled fee) now sort last and are the
ones the budget drops, closing the claim-suppression attack where ten high-fee dust
distributors could consume the whole cycle budget ahead of a victim's real earnings.
A rotation_cursor tie-breaks only WITHIN equal-accrued-value tiers so a genuinely
tied honest tail that exceeds one cycle's budget every cycle still rotates through
and is eventually served, rather than dropping the same tail forever.

B3: the payout-hash mismatch check in evaluate_pre_budget now increments the
per-distributor payout_hash_mismatches_this_cycle counter instead of setting
fault_reported, so one hostile or buggy entry can no longer pin the cycle-wide
Faulted state and bury ClaimableButNotClaiming for every other healthy distributor.

R2: terminal_no_entry_slot -> no_entry_slot_this_cycle throughout.

* fix(rewards-claim): R5 -- document not-yet-wired loop; persist B2 rotation cursor

An operator reading their own rewards-claim.json and seeing enabled: true has no way
to know from that file alone that no startup path constructs a ClaimEngine yet
(#3268) -- mod.rs said so, but a config file reader does not arrive at a module doc.

Also gives RewardsClaimConfig a rotation_cursor: Option<Bytes32> field so B2's
tie-break cursor survives a save/load round-trip -- an in-memory-only cursor resets
on every restart, which would starve a legitimately tied honest tail forever on any
node that restarts daily.

* fix(rewards-claim): clippy collapsible-match + SPEC v0.1.3 wording refresh

Collapses the nested if into the outer match arm in run_cycle (clippy::collapsible_match).
Also refreshes NoEntrySlot / no_entry_slot_this_cycle doc comments now that
dig-rewards-coin v0.1.3's SPEC §12.5 amendment is merged and tagged: absence is
terminal for one claim attempt only, never for the distributor, must not be cached,
and must not accumulate into a permanent exclusion set -- confirming rather than
diverging from the re-read-every-cycle behaviour already implemented.

* fix(rewards-claim): add missing rotation_cursor field in cadence.rs test literal

Struct literal in the cadence test module was not updated when RewardsClaimConfig
gained rotation_cursor (R5 commit) -- CI's Clippy/Test jobs caught the missing field
(E0063) that a local cargo check could not (killed by memory pressure before this
workspace-wide build completed).

* fix(rewards-claim): F1 -- ChainSourceUnavailable is per-cycle, never a latch

compute_state() compared against self.state -- last cycle's OWN computed
output -- so once any cycle took an Unavailable port path, every later
cycle re-asserted ChainSourceUnavailable forever, even after the chain
came back and real claims were submitting. A node still syncing, or one
dropped connection, was enough to trip this permanently.

Add ClaimStatus::chain_unavailable_this_cycle, reset to false at the top
of every run_cycle and set true only on a cycle that actually took the
Unavailable path; compute_state now reads that flag instead of
self.state, so the reading is live again.

Test: a_transient_unavailable_cycle_does_not_latch_state_for_the_rest_of_the_process
(engine.rs) drives cycle 1 unavailable, cycle 2 healthy with a
submission, and asserts cycle 2 reads Nominal. Plus a compute_state-level
regression in types.rs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F3/F4/F5 -- fix stale counters, dedup candidates, correct version doc

F3: reset EVERY per-cycle counter (distributors_known/with_own_entry/
claimable/faulted, claims_submitted_this_cycle, no_entry_slot_this_cycle)
at the TOP of run_cycle, before any early return. The three
ChainUnavailable early-return paths skip the end-of-function assignment
block entirely, so a cycle that hit one used to leave the PRIOR cycle's
counts sitting on self.status while last_attempt_at stamped fresh for
THIS cycle -- a stale count under a fresh timestamp, exactly what SPEC
§2.4's staleness reasoning forbids. types.rs's doc sentence for
no_entry_slot_this_cycle now correctly says it is dated by
last_attempt_at (the field stamped unconditionally every cycle), not
last_cycle_at.

F4: dedup `candidates` by launcher id before phase 2. A real adapter
scanning §1.3 launch comments across every (store_id, root) this node
mirrors can plausibly return the same launcher id twice; without dedup
phase 2 would evaluate it twice and submit InitiatePayout twice against
one entry slot in one cycle -- the second spend is invalid but the fee
is paid anyway.

F5: dig-rewards-coin is v0.1.3, published on crates.io -- correct the
stale "v0.1.1" module-doc claim.

Tests: a_chain_unavailable_cycle_does_not_leave_prior_cycles_counters_stale
(F3), a_duplicated_launcher_id_submits_exactly_once (F4).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards_claim): fold payout-hash mismatches into the shortfall predicate (F2)

A payout-hash mismatch never enters the eligible set, so it was counted in
NEITHER distributors_claimable NOR claims_submitted_this_cycle -- the
shortfall lived in neither term of compute_state's magnitude comparison.
All-K-distributors mismatching therefore read Nominal (falsely healthy).

Fold payout_hash_mismatches_this_cycle into the comparison's denominator:
submitted < claimable + mismatches. The result is ClaimableButNotClaiming
(a shortfall), never the cycle-wide Faulted -- Defect B3 stays fixed.

Inverts the assertion at what was engine.rs:1305
(a_payout_mismatch_never_sets_the_cycle_wide_fault_or_masks_other_distributors):
it previously asserted ClaimLoopState::Nominal across three cycles of an
ongoing mismatch, which pinned the defect as intended behaviour (an
A2-class test). It now asserts ClaimableButNotClaiming { claimable: 1,
submitted: 1 }.

Adds all_distributors_mismatching_is_a_shortfall_not_nominal, covering the
brief's exact "what if every distributor refuses for the same reason" case.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F1/F3 -- AtomicU32 in fake ports, not Mutex, keeps discovery Send

CI's Clippy job (the compiler for this crate, per brief) caught it: holding
a std::sync::MutexGuard across the .await in FlakyThenHealthyPort and
HealthyThenUnavailablePort's discover_distributors made the returned future
not Send, which #[async_trait]'s generated trait signature requires.

Neither fake needs a lock -- each holds one call counter, incremented once
per call, never read-modify-written across an await point. AtomicU32's
fetch_add removes the guard (and the Send bound violation) entirely.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F7 -- persist the fee window and cadence gate across restart

The per-cycle aggregate fee budget and the 24h cadence clock both lived only
in memory: `spent_this_cycle_mojos` was a `run_cycle` local and nothing on
disk recorded a completed cycle. Every fresh process got a full
`max_cycle_fee_budget_mojos` and an empty cadence clock, so a node stuck in
a crash-restart loop could spend unbounded XCH on fees, one full budget per
restart.

Adds three `#[serde(default)]` fields to `RewardsClaimConfig`
(`fee_window_start_unix`, `fee_spent_in_window_mojos`,
`last_cycle_completed_at`) and a new opt-in `ClaimEngine::with_persisted_fee_
window(dir, cadence_seconds)` that:
- restores the window/cadence state from `dir` at construction,
- refuses to start a cycle until the cadence has elapsed since the last
  completed one,
- rolls a fresh budget window only once the cadence has elapsed since it
  opened, otherwise keeps enforcing the budget against the persisted spend,
- persists the spend BEFORE every chain submission (write-then-spend), never
  batched to cycle end, and persists the completed-cycle timestamp when a
  cycle finishes.

Engines that never call `with_persisted_fee_window` (every pre-F7 test) are
unaffected -- this is additive, opt-in state beside the existing rotation
cursor, not a change to B2's value-ordering or rotation mechanism.

`ClaimStatus`'s own counters stay in-memory on purpose (observability, meant
to reset on restart); only the spend bound and the cadence gate persist.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F7 -- update cadence.rs test literal for new persisted fields

The three new persisted RewardsClaimConfig fields (fee_window_start_unix,
fee_spent_in_window_mojos, last_cycle_completed_at) broke this crate's only
remaining full struct literal outside config.rs/engine.rs's own test
modules -- E0063 missing fields, caught by CI's Clippy job. Switched to
..RewardsClaimConfig::default() so the next added field cannot break this
literal again, the same fix already applied once before for rotation_cursor.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): F8/F14 -- atomic state write, fail closed on a corrupt window

Salvaged from a lane killed by a weekly cap before it could commit. Uncompiled at
commit time; CI is the compile signal.

Covers the fourth gate pass findings on the F7 persisted spend bound:

- F8: RewardsClaimConfig::save_to now writes atomically (temp file + rename in the
  same directory), reusing the pattern already used by mirror/reconcile_state.rs
  for the same class of state. load_from distinguishes an ABSENT file (clean first
  run, defaults are correct) from a PRESENT but unparsable one, which fails CLOSED:
  the window is treated as fully spent and nothing is submitted. Never Default, and
  never a silent clamp downward, which would hand back the budget the corruption
  was hiding.
- F14: the budget comparison uses saturating arithmetic so a corrupt disk-seeded
  fee_spent_in_window_mojos cannot panic under the release profile's
  overflow-checks.
- F9/F10/F12/F13 in progress in the same files.

Refs #3251

* fix(rewards-claim): negate with ! rather than the unimported Not trait

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* fix(rewards-claim): F13 -- correct stale test literals to the folded shortfall

compute_state (types.rs) already reported the folded shortfall
denominator (distributors_claimable + payout_hash_mismatches_this_cycle)
as `claimable` -- that part of F13 landed in f478516a. The two engine.rs
tests asserting this state were written against the pre-fold, un-folded
numbers and never updated, so CI showed the implementation producing the
correct folded value (`claimable: 2`, `claimable: 1`) while the test
literals still expected the stale un-folded one (`claimable: 1`,
`claimable: 0`).

Update both literals -- and the comments describing them -- to the
folded values the F13 fix actually produces. No production code change;
compute_state's predicate and payload were already correct.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(rewards-claim): add ClaimOutcome::Faulted variant

Add the seventh ClaimOutcome variant: the type could only say a peer was
legitimately not paid, never that a chain call failed. Carries the launcher
id, a bounded (200 char) copy of the chain port's error text, and whether a
pre-committed fee was reversed, so a reader can tell no money moved.

Engine wiring at the two fault arms (engine.rs:332, :377) follows in the
next commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): both fault arms now push ClaimOutcome::Faulted

engine.rs:332 and :377 used to increment `faulted` and discard the
outcome, leaving a definitively-failed claim absent from the outcome
stream -- indistinguishable from a cycle that never touched that
distributor. Both PreBudgetResult::Fault and BudgetPhaseResult::Fault
now carry the chain port's (bounded) error text, and the
submit_initiate_payout failure path also carries the fee it reversed,
so a reader can tell no money moved. The counter stays; it is not a
substitute for the outcome.

7 call sites needed updating: 3 PreBudgetResult::Fault constructions
(reserve_asset_id, own_entry, payout_threshold), 2 BudgetPhaseResult::Fault
constructions (required_fee_mojos, submit_initiate_payout), and the 2
consuming match arms -- exactly the set that was silently discarding a
failure before this change.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards-claim): a failed submission produces a Faulted outcome

Regression for the rework: reuses F12's fixture (a submission that
definitely never broadcast) to prove both facts from one cycle -- the
outcome exists and carries the reversed fee, and the persisted window
still reflects zero net spend. Also fixes a rustfmt diff on the
PreBudgetResult::Fault variant Clippy's Rustfmt job flagged.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): delete fee_window_poisoned, stop latching self-healing state

Finding 1 (dig-node#594 pass 6): a future-dated clock is self-healing by
construction (`t > now` goes false the moment real time passes it), but the
engine ORed it into `self.fee_window_poisoned` and set that field `true`
permanently -- an RTC glitch or VM resume froze the claim loop forever instead
of until the skew passed. This is the third instance of one mechanism (pass 3
latched ChainSourceUnavailable, pass 4 left a stale cadence-gate `state`), so
the fix removes the FIELD, not just the bug: with no `fee_window_poisoned` on
`ClaimEngine`, `self.fee_window_poisoned = true` is a compile error, not a
convention to remember.

Per-cycle conditions (corrupt + future-dated-clock) now live in a
`CycleConditions` value built fresh at the top of every `run_cycle` from `now`
plus a freshly reloaded `RewardsClaimConfig`, used, and dropped -- never
stored on the engine. `corrupt` is now re-read from disk every cycle too (it
previously latched at construction only), matching what
`ClaimLoopState::PersistedStateCorrupt`'s doc already claimed but the code
never did.

Rewrites the single-cycle f10 regression into a two-cycle test: cycle 1 with a
future-dated clock refuses; cycle 2, after the clock catches up and the
cadence elapses, MUST claim. The old one-cycle version was green whether the
latch bug was present or not.

Refs #594

* fix(rewards-claim): satisfy clippy doc-list indent and rustfmt

Clippy failed with 3x doc_lazy_continuation on the PersistedStateCorrupt
doc comment (types.rs:165-167): continuation lines of a `-` bullet must
be indented under the marker, not left flush. Indent them.

Rustfmt failed on the new fail_reserve_asset_for early-return in
FakeChainPort::reserve_asset_id (engine.rs:888): the Err(...) call
exceeded the line-length limit unwrapped. Let rustfmt wrap it.

Refs #594

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards-claim): red proof for corrupt-then-repaired stale read

Cycle 1 refuses a corrupt fee-window file; the file is then repaired to
valid values with a fully-spent window and a recent completed-cycle
time. Cycle 2 must neither grant a fresh budget nor skip the cadence
gate. Fails against current `with_persisted_fee_window`, which loads
the three fee-window fields once at construction and never refreshes
them from the per-cycle `cfg` -- see engine.rs:149-157, #594.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): resync fee-window fields from disk every cycle

`with_persisted_fee_window` only loaded fee_window_start_unix,
fee_spent_in_window_mojos and last_cycle_completed_at once, at
construction. Once the now-deleted fee_window_poisoned latch stopped
masking it, a file corrupt at construction and repaired later left
those three fields stuck on poisoned()'s None/0/None placeholders --
a fresh budget and a skipped cadence gate, and persist_fee_window then
overwrote the repaired disk values with them.

CycleConditions now carries the three fields from the SAME freshly
reloaded cfg it already used for the corrupt/future-dated check, and
run_cycle copies them onto self before the cadence gate or window-roll
logic runs, but only on a read that is neither corrupt nor future-
dated. This also fixes Finding 2b: future_dated_clock now reads cfg's
own clocks instead of self's stale ones. Corrects the doc claim at the
old lines 236-238 to describe what the code now does for both halves.

Closes #594.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* refactor(rewards-claim): make disk the sole store for the fee window

Delete `fee_window_start_unix`, `fee_spent_in_window_mojos` and
`last_cycle_completed_at` from `ClaimEngine`. `run_cycle` already re-reads
`RewardsClaimConfig` fresh every cycle for the corrupt/future-dated check,
so caching a copy on the engine bought nothing and cost exactly the
stale-read defect class F16 just fixed. A local `FeeWindowState`, scoped to
one `run_cycle` call, now threads the in-flight values through
`evaluate_budget_phase`/`uncommit_fee`/`persist_fee_window` instead. With
no field left to cache into, a future `self.fee_window_start_unix = ...`
outside this file is an E0609 compile error, the same enforcement
`fee_window_poisoned`'s removal already has.

No behaviour change: every early return, the corrupt/future-dated fail-
closed path, the cadence gate, the window roll, write-then-spend
pre-commit/uncommit and the per-claim ceiling are unchanged -- only where
the three values live changed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

* chore(release): v0.256.0

Bump dig-node-service to v0.256.0 for release.

This release includes:
- Reward distributor prover loop (#593)
- Peer reward claim loop (#594)
- Reward prover status RPC (#595)

* ci: scope commitlint to PR-introduced commits, fix title suffix check

A develop -> main release-cut PR was linting main..develop, the full
inherited commit range, instead of just the commits it introduces.
Every commit in that range was already linted at its own PR while it
was still mutable; re-linting it at cut time adds no information and
cannot be satisfied once merged (gitlinks and rev-pinned deps make
history immutable). Use commitDepth: 1 on a main-base PR; keep the
full-range lint unchanged for develop-base PRs, where authors can
still fix the commits.

Also fix the PR-title lint's blind spot: GitHub's squash merge lands
"$PR_TITLE (#$PR_NUMBER)" as the commit subject, about eight
characters longer than the title alone, so a title that passes
header-max-length can still produce an over-limit commit subject that
nothing checks. Lint the exact string that will land.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

* chore(release): v0.257.0 -- the reward distributor lifecycle starts running (#607)

* feat(mirror): persist mirror-bond coin ids (#575)

* chore: open lane for #574

* feat(mirror): persist mirror-bond coin ids so a restart cannot double-create

Bond identity was reconstructed from a live chain scan on every read
(`mirror/observe.rs`), with no persistence of its own. A restart, a cold
replica, or a lagging/flaky chain source all rendered a real, unspent,
confirmed bond as "no bonds" -- and because the in-flight suppression is
keyed on pending/submitted audit entries, a bond whose create had already
CONFIRMED was not suppressed either, so the same short scan that emptied
the read surface also cleared the one thing that would have stopped a
second coin being paid for collateral that already exists (dig-node#574).

Persist the (store, root, epoch) -> coin_id mapping in the EXISTING spend
audit record (spend-audit.jsonl) rather than a new store: a mirror-coin
create already writes store_id + AuditedBond{root, epoch} + amount there,
and the coin id itself becomes durable the moment resolve_landed_spends
confirms it. This adds the one missing piece -- the advertised URL a
create carries -- and a read-side query, confirmed_mirror_bond, that
returns the newest CONFIRMED record naming a triple.

Chain stays authoritative. mirror::local_bond::recheck_missing_bonds
never trusts the record: for a held bond the live scan did not cover, it
asks the record for a candidate coin id, then re-verifies that SPECIFIC
coin against chain via the same independent check (chain_bond_verdict)
that verifies an untrusted peer's claimed bond. Only a fresh `Bonded`
verdict is folded back in, as covered; `Unbonded`/`Unverified` fall
through to an ordinary create, exactly as if no record existed.

Version: 0.254.86 (patch -- per #522 the MSI ProductVersion minor field
is exhausted and the counter lives in patch).

Co-Authored-By: Claude <noreply@anthropic.com>

* test(mirror): prove the recovery wiring end to end through PassRunner::run

Adds two integration-level tests over the REAL pass pipeline, not just the
isolated recheck_missing_bonds unit tests: a bond missing from the live
scan with a chain-reverified durable record is recovered (no double
create, correct Bonded state reported), and the control -- the same
record but chain disproves it -- correctly falls through to an ordinary
create. Together these are the concrete regression test for the
cold-start/lagging-chain-source double-create scenario the ticket asked
to have measured.

Also refactors in_flight_creates to take the already-folded SpendLedger
instead of re-reading the log itself, so PassRunner::run reads the audit
file once per pass and shares it with the new recovery step, and fixes a
doc comment on in_flight_creates that the recovery step would otherwise
have made stale on landing ("a Confirmed create has a coin the chain
observation already sees" is no longer unconditionally true).

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(fmt): wrap long test signatures to satisfy rustfmt

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(clippy): use slice::from_ref instead of cloning for a single-element slice

Co-Authored-By: Claude <noreply@anthropic.com>

* chore(release): bump to v0.254.89

Base branch moved to develop after PR #576 merged there at v0.254.88
(main and develop are currently identical), leaving this branch's
carried-forward .88 as a zero-increment against the new base. Bumped
to the next free integer after fetching and verifying both origin/main
and origin/develop tip at .88.

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

* fix(peer): count accepted relayed circuits in the connected pool (#579)

serve_accepted_relay_conn served every accepted relayed circuit (full mTLS
auth, full L7 peer RPC) while registering it nowhere, so connected_peers
under-reported every relayed inbound peer -- the relay-leg twin of the
direct-inbound defect #402/#523 already fixed.

adopt_inbound_peer_in_pool now dispatches by TraversalKind: Relayed routes to
dig-gossip's already-published adopt_relayed_inbound_handle (v0.32.0, the rev
this repo already pins), every other tier keeps the unchanged
adopt_direct_inbound_handle path. serve_accepted_relay_conn adopts before
serving and releases after, mirroring the direct listener exactly.

Refs: https://github.com/DIG-Network/dig_ecosystem/issues/3124

* fix(cli): guard the exit-code namespace shared with diga against collisions (#582)

* chore: open lane for #3189

* fix(cli): guard the exit-code namespace shared with diga against collisions

dign and diga deliberately share one process exit-code numbering (dig-app's
outcome.rs says so in its own doc comment), so a number is free only if it
is unoccupied ecosystem-wide. dig-node#407 assigned exit 7 to
NODE_UNREACHABLE by checking only this repo's own table, where 7 genuinely
was free -- and collided with diga's NOT_CONNECTED. A reviewer caught it by
hand; nothing failed automatically.

Adds scripts/check-exit-code-collisions.sh: parses both enums' code()/name()
match arms straight from their own source -- this repo's ExitCode, and a
live fetch of dig-app's outcome.rs at its default branch -- and fails if a
number carries two different names, or if either side draws a number from
the reserved shell signal range (126, 127, 128+N). Ships with an 18-case
hermetic test harness (scripts/tests/check-exit-code-collisions.test.sh)
covering the actual #407 collision shape, arm-order independence, arm-count
mismatch, the reserved-range boundary from both sides, the live-fetch path
itself, and fail-closed behaviour on an empty/missing/unreachable table.

Wires a real (unstubbed) invocation into ci.yml's existing "Release-script
tests" job so a collision introduced by a future PR, on either side, is a
red required check on that PR -- not a note a reviewer has to catch. The
fetch retries twice (2s backoff) since this becomes a required, network-
dependent check; a fetch failure still fails closed after retrying, never
silently passing as "diga has no codes".

Updates SPEC.md 8.4 to point at the mechanical guard instead of leaving
"re-check both tables" as unenforced prose, and records that the
extension's WALLET_WS_ERR.NOT_CONNECTED = -33001 is a separate JSON-RPC
error-code space, not a rival of this one. Adds a doc-comment to the
existing transcribed collision test pointing future readers at the live
script as the authoritative check; the transcription remains as a narrower,
hermetic regression pin for the #407 shape specifically.

No renumbering: every currently-assigned code is unchanged.

Refs #3189

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings (#3190) (#583)

* chore: open lane for #3190

* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings

Replicates dig-node-service::continuation_guard (dig-node#526/#501) into dig-node-core,
dig-wallet, dig-runtime and dig-chat-protocol, line-for-line apart from crate-specific
constants -- ported rather than reinvented, per dig_ecosystem#3190.

Wiring the guard in surfaced 48 pre-existing lost-continuation defects the ticket's own
"no measured corruption in these four crates" note did not anticipate: 36 in dig-node-core,
12 in dig-wallet, mostly test-assertion prose where a multi-line message lost its `\`
continuation and shipped the source's own indentation as a mid-sentence space run (one
as the worse `\n`-plus-indentation variant). All 48 are collapsed to the single space the
sentence always meant, with surrounding indentation and wording otherwise untouched.

Two lines are real column-alignment, not defects, and get a targeted EXCLUDED_LINE_RANGES
entry on dig-node-core instead of a rewrite: download.rs's `claimed(...)` fixture-table
trailing comments, and net.rs's `label : value` debug-print alignment.

Refs https://github.com/DIG-Network/dig_ecosystem/issues/3190
Refs https://github.com/DIG-Network/dig_ecosystem/issues/3130

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

* feat(mirror): detect an IP change daily and reconcile mirror coins to the current advertise URL

Automatic half (D1-D4) of the daily mirror-URL reconcile: derived personal-day offset, two-observation hysteresis, nine ordered gates with K sized as a self-funding prefix before any reclaim, `submitted` never `completed`, audit lines gain `reclaim_reason` + `trigger`.

Gates at b4c09866: loop-reviewer PASS (review 5129272285), loop-security PASS @ 175304e1 (tree byte-identical, `git diff 175304e1 b4c09866` empty), adversarial loop-decider PASS (comment 5567083644; SHOULD-FIX findings ticketed separately).

Refs DIG-Network/dig-node#570
Refs DIG-Network/dig_ecosystem#3203

* feat(serve): content hosting + serve path batch, v0.255.0 (dig_ecosystem#3212)

Nine commits from the #3212 serve-path lane, gated at 899cc68f (reviewer review 5130425808,
security comment 5568662836), plus the single semver bump to 0.255.0 for the develop -> main batch.

- store_id/root case normalised at the CapsuleKey boundary; cache delete targets the matched entry
- tier-0 occupancy reads the eviction-aware ledger
- profile-sync outbound budget in bytes; announcer asked first
- melt confirmation depth on the terminal spend, fail-closed
- EngineWarming (-32002) while the peer tier attaches, never -32004
- window completeness derived from the bytes read
- deps: dig-stun 0.2, chia-query 0.24.3, dig-nat 0.21.2, dig-logging 0.2.2

Refs DIG-Network/dig_ecosystem#3212

* chore: untrack gitnexus-generated agent files (#590)

* chore: untrack gitnexus-generated agent files

These files were generated by `gitnexus analyze` as a side effect of
indexing this repository. They are development-loop private tooling
output, not product code, and carry no secrets. They are removed from
tracking going forward via .gitignore; history is deliberately NOT
rewritten.

Refs #3177

* chore: drop private-repo reference from gitignore comment

The ignore comment named a private repository and an internal issue
number in a public file, which is the same disclosure class this
change set exists to remove; the reference is dropped and the
guidance kept.

* feat(rewards): always-on prover loop engine -- honest liveness, type-enforced self-exclusion, bounded spend (#593)

The always-on reward-prover engine: ~2,000 lines under
`crates/dig-node-core/src/rewards/`, built against the merged `dig-rewards-coin`
SPEC. Library only -- nothing spawns it, and the sole production
`RewardsChainPort` refuses every call, so it cannot spend. Wiring the composed
system is #3265, which carries its own gate.

The epic's premise -- "anytime the process isn't running, rewards are not being
distributed" -- is half wrong, and the false half is the dangerous one. `Sync`,
`NewEpoch` and `InitiatePayout` need no manager authority, so funder downtime does
not stop rewards: it FREEZES THE ENTRY SET while accrual and payouts continue.
Peers that stopped mirroring keep earning; peers that started cannot begin. That
shaped the whole design.

Liveness honesty (SPEC 2.4). The status record carries no `healthy`/`ok`/`up`
boolean and no precomputed staleness, because a wedged loop cannot report its own
wedging -- whatever it last wrote stays there, so a writer-set flag reads true
forever after the failure it exists to reveal. The reader derives staleness from
`last_cycle_completed_at` against `observed_at` and its own clock. A recursive
JSON-key test enforces the absence at every nesting depth; asserting on keys and
never substrings, since `ProverState::Running` legitimately serializes the VALUE
"running". The one legal staleness signal is chain-derived (SPEC 12.4: 48 hours
AND a non-zero reserve, from the singleton's own spend history) and lives on the
distributor read, where a wedged prover cannot fake it.

Self-exclusion is a compile error, not a habit. dig-node#261's lesson is that an
invariant enforced on some paths is not an invariant. `admit` is the single
admission point, checks both SPEC 5.2 coordinates (own peer_id OR a payout puzzle
hash this wallet controls), and mints an `AdmittedPeer` with private fields and no
public constructor -- so `EntryAction::Add` cannot be built by a path that skipped
admission.

A prover's own fault can never strike a peer. `GateError` is a distinct type from
`GateIneligibleReason` and `record_prover_fault` takes `&self`, so SPEC 3.6 clause
4 is enforced by the borrow checker rather than by comment. Without that, a
misconfigured operator -- one missing mirror-collateral epoch ordinal -- would
strike every peer at once and evict its entire 250-entry set in three hours, each
eviction a fee it pays plus a settlement out of its own reserve.

The money bounds are stated where a human reads them (`rewards/mod.rs`): 24
bundles/day, 192 entry actions/day, a fee ceiling of 24x the configured standard
fee, 192 removals/day worst case with 96/day sustained churn. Recorded honestly:
SPEC 6.3's rate bound and fee ceiling are ONE control, not two.

Three gate rounds, every leg fresh-context. Round 3 at this head: reviewer PASS,
adversarial decider RATIFY (leg closed), security CHANGES-REQUIRED on a finding
the decider ratified deliberately -- adjudicated in
https://github.com/DIG-Network/dig-node/pull/593#issuecomment-5601784815 and
carried to #3265 with the remedy corrected, because the proposed fix would have
persisted a poison flag to the very store whose writes were failing.

Found and fixed under gate: a census ordinal off by one in both directions (SPEC
4.6 requires n-1 exactly); an unreachable grace window leaving a named constant
with no reader; a missing `NewEpoch` spend; an absent-ordinal path attributing a
prover fault to peers; and a daily fee ceiling 24x too high because a per-bundle
fee was consumed as a daily ceiling.

Refs DIG-Network/dig_ecosystem#3250

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* feat: serve dig.getRewardProverStatus at Tier::Control (#5…
PR #608 was squash-merged, which discarded the second parent and left main
still not an ancestor of develop -- the -s ours remedy is itself defeated by
squash-only merging. This commit carries both parents so the link actually
exists.

Content is byte-identical to develop: verified git diff 49ae2c6..develop is
empty before and after. The only thing this adds is the ancestry edge that
stops the next cut PR being DIRTY.

See DIG-Network/dig_ecosystem#3298 -- the durable fix is allow_merge_commit
on this repo; this is the only remedy available without it.

Refs DIG-Network/dig_ecosystem#3268

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Serves all five reward-distributor RPC methods, all Tier::Control and none
peer-reachable: dig.listRewardDistributors, dig.getRewardDistributor,
dig.listRewardDistributorCommitments, dig.getRewardProverStatus and
dig.getPayeeRewardClaimStatus. Migrates the partial-knowledge results to
Half<T>/ClaimLogObservation so an unread half is NotConsulted rather than a
reassuring zero, and refuses getRewardProverStatus on a zeroed identity instead
of silently dropping the record.

The chain ADAPTER remains dig_ecosystem#3310's: install_reward_chain_port has no
non-test caller, so port-backed methods answer REWARD_CHAIN_UNAVAILABLE in
production and the claimable half is always NotConsulted.

Bumps dig-rpc-protocol 0.11 -> 0.12 across dig-node-core and dig-node-service.

Gates at head 95ca5f9: 5/5 required checks SUCCESS by name, 3414 tests passed,
coverage 90.17%, security PASS, 0 unresolved review threads.
Follow-ups: #3327 (mutation probe), #3328 (range-check comment).

Refs #3268
Refs #3269
Refs #3246

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Develop sat at 0.255.0 while main was at 0.257.0, so the develop -> main release PR could not satisfy the required Check Version Increment gate. Cargo.lock synced so --locked is satisfied.

Refs #3269

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
On pull_request GitHub runs the workflow from the PR's HEAD branch, so a develop -> main release PR runs develop's copy of commitlint.yml. main's commitDepth: 1 release-cut branch was therefore never consulted at a cut. The file never reached develop because the -s ours reconciliation at cd8ce7b records ancestry without bringing content across.

Refs #3298
Refs #3269

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(rewards): clamp an out-of-range claim schedule to the max instead of substituting the default

sanitized_schedule() previously replaced any above-maximum cadence/jitter with the
documented 1-day/1-hour default, so a 60-day configured cadence ran every 1 day --
31x more often than the operator asked. Above-max values now clamp to
CLAIM_SCHEDULE_SECONDS_MAX (31 days) instead. A zero cadence still substitutes the
default (it has no clamp direction and would busy-loop the engine) -- that branch
is unchanged and its WARN reads "substituted", distinct from the clamp branches'
"clamped".

The adjustment (configured vs effective) is now threaded call-scoped (ScheduleAdjustment,
never an engine field) from sanitized_schedule() into drive() and onto the per-cycle
log line, so an operator reading any single cycle can see the schedule actually in
force -- previously only a once-per-process WARN said so.

Refs #3306

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(test): assert for CLAMPED warning in uppercase, not lowercase

Production tracing::warn! at sanitized_schedule emits "CLAMPED" in uppercase
in both cadence and jitter clamping cases; test assertions must match.

Fixes test: a_sixty_day_cadence_is_clamped_to_thirty_one_days_not_replaced_by_the_default
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* fix(clippy): remove unused import CLAIM_JITTER_SECONDS_DEFAULT

The jitter branch no longer substitutes the default, so the constant is
not used at module level. Test module accesses it through use super::*.

Fixes clippy error at crates/dig-node-service/src/rewards_claim/driver.rs:39
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* style(fmt): rustfmt formatting of driver.rs

Applied cargo fmt to maintain code style consistency across new and
modified test code.

Fixes rustfmt check on PR #611
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* fix(test): add CLAIM_JITTER_SECONDS_DEFAULT import to test module

The constant is used by the test at line 1446 but was removed from
module-level imports. Add it to the test module's own use statements
to fix the compilation error.

Fixes clippy and test compilation errors on PR #611
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* fix(import): correct CLAIM_JITTER_SECONDS_DEFAULT import path in tests

Changed from super::cadence to super::super::cadence to match the module
nesting level. mod tests is inside driver, so super references driver.
Requires super::super to reach cadence. Also applied rustfmt formatting.

Verified with: cargo check -p dig-node-service --lib --tests
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* fix(rewards): assert per-cycle field names, size fee window from raw cadence

Gate F1: the per-cycle log test asserted bare numbers against the whole
captured log buffer, which the once-per-spawn clamp WARN already contains --
deleting every per-cycle field from log_cycle would still pass it. Filter to
"claim cycle complete" lines, require at least two, and assert the actual
field names (configured_cadence_seconds / effective_cadence_seconds).

Gate F2: with_persisted_fee_window was sized from the CLAMPED cadence,
doubling the fee-budget windows a long-cadence operator sized (60-day
config -> ~12 windows/year instead of ~6). Pass the raw cfg.cadence_seconds
instead; the scheduler still uses the clamped value. Added a regression
test showing the two configurations roll the persisted fee window at
different ticks.

Gate F3/F4: corrected the "unclamped at rest" and "would busy-loop" doc
claims -- config.rs already floors cadence_seconds to
CLAIM_CADENCE_FLOOR_SECONDS before the driver ever sees it, so the
zero-cadence branch is defence in depth, not the primary guard. Removed
the vacuous `!rendered.contains("clamped")` assertion (every clamp string
is uppercase CLAMPED) and replaced it with a real one.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* style(fmt): rustfmt driver.rs

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards): split the overloaded cadence field so the clamp governs the gate

`ClaimEngine::cadence_seconds` was a single field feeding two policies: the
restart-safety cadence gate (`run_cycle`'s `CadenceNotElapsed` check) and the
persisted aggregate fee-budget window length. Passing the raw, unclamped
configured cadence into `with_persisted_fee_window` set the GATE to the raw
60-day value while the driver's scheduler kept ticking on the clamped 31-day
interval -- the loop woke every 31 days and was refused every time, turning
the previous clamp fix into a complete no-op with every test green.

Split the field into `gate_cadence_seconds` (CLAMPED -- the schedule the
driver's background loop actually sleeps on; used by the `CadenceNotElapsed`
gate at `run_cycle`) and `fee_window_seconds` (RAW -- the operator's
configured cadence; sizes how long the persisted fee-budget window stays
open before rolling). Reusing the clamped value for the window would double
the number of fee-budget windows a long-cadence operator sized; reusing the
raw value for the gate reproduces the exact silent-non-claiming defect this
split exists to close.

Updated `with_persisted_fee_window`'s and both fields' doc comments to
describe the two-value split (the prior doc described the single field as a
deliberate overload, which is now false); added an explicit mutation-tested
proof (`the_gate_tracks_the_clamped_cadence_while_the_fee_window_tracks_the_raw_one`)
that drives the real `drive()` loop with an injected clock and asserts the
gate opens on the clamped interval while the window rolls only on the raw
one; and documented, on the existing `run_claim_driver_in` composition test,
why that test cannot make the same state assertion (that body hardcodes
`unix_now_seconds`, real wall-clock, which `tokio::time::advance` cannot
drive).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
…-rewards-coin (#614)

* chore(deps): pin chia-sdk-driver/chia-sdk-types/chia-puzzle-types, add dig-rewards-coin

Money-bug containment for dig_ecosystem#3303/#3286: exact `=` pins on
dig-node-service's direct edge stop the resolved chia-sdk-driver/chia-sdk-types/
chia-puzzle-types versions moving under us. This constrains OUR compile target
only -- Cargo.lock still carries a second, transitive chia-sdk-driver 0.30.0 and
chia-puzzle-types 0.26.0 line via other crates, and this pin does not evict
those. Containment, not correction.

chia-protocol/chia-bls/chia-sha2 stay caret: an `=` on a wire type poisons every
crate that depends on chia-protocol directly.

dig-rewards-coin = "0.5" (not the ticket's stale "0.4"): 0.5.0 is the release
that already refuses `epoch_seconds == 0` inside `read_distributor` itself.

Refs #3310

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(rewards): construct and install a real RewardsChainPort over dig-rewards-coin

Adds RealRewardsChainPort (crates/dig-node-service/src/rewards/): distributor_report
served for real over dig-wallet's CorroboratedChainSource and
dig_rewards_coin::state::read_distributor, via a guarded read
(read_distributor_guarded) that refuses launch constants carrying
epoch_seconds == 0 BEFORE calling into dig-rewards-coin at all -- defense in
depth over that crate's own identical refusal (state.rs:1015), since
chia-sdk-driver-0.36.0's commit_incentives backfill loop never terminates on
that value and has no await point a timeout could interrupt.

store_id/root are recovered from the launcher's creating spend's CREATE_COIN
memo (chain_source.rs), following dig-mirror-coin's read_parent_outputs
pattern: authenticate the puzzle reveal against the coin's puzzle hash before
running it, never trust an unauthenticated memo alone.

The other four RewardsChainPort methods (funded_distributors,
distributor_state, submit_entry_writes, spend_new_epoch) answer Unavailable --
out of this ticket's scope (funder-registry and prover-cycle work tracked
separately).

Installed once from server.rs's enable_chain_sync-gated block, logging a
false (already-installed) return at WARN.

Refs #3310

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards): satisfy rustfmt and regenerate the workspace lockfile

CI's `cargo fmt --all -- --check` and `--locked` builds both failed on
the prior commit: rustfmt wanted several closures/return-types
reformatted, and Cargo.lock was missing the `chia-sdk-test`,
`clvm-traits` and `clvmr` entries the new adapter's Cargo.toml lines
require, which `--locked` refuses to backfill.

Refs #3310

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards): read LaunchCommentError payloads, scope containment test, fix constants fixture

- LaunchCommentError::ChainSource/Malformed tuple payloads were flagged
  dead_code by clippy: a derived Debug impl does not count as reading a
  private field. Add a manual Display impl that formats each variant's
  payload, and switch chain_port.rs's build_report call site from {error:?}
  to {error} so the reason reaches a log reader.

- adapter_source_never_imports_withdraw_committed_incentives was
  self-defeating: it include_str!s its own file and the test's own name
  and assertion messages contain the literal string it searches for, so
  it could never pass. Scope the scan to production_region(), everything
  before the file's own #[cfg(test)] marker.

- launcher_spend_with's RewardDistributorConstants fixture set
  reserve_inner_puzzle_hash/reserve_full_puzzle_hash to Bytes32::default()
  without calling .with_launcher_id(launcher_id), which recomputes both
  fields from curried tree hashes. chia-sdk-driver's
  RewardDistributor::from_launcher_solution requires constants ==
  constants.with_launcher_id(launcher_id), so this fixture deterministically
  failed to decode on every invocation (not flaky/timing-dependent).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards): finish A3 -- real-simulator distributor_report + install-path evidence

Drives RealRewardsChainPort::distributor_report end to end against a
distributor launched by dig_rewards_coin::launch_dig_distributor in
chia-sdk-test's peer simulator, over a MockChainSource loaded from the
simulator's real coin records/spends. store_id/root are asserted
against the values launched with -- recoverable only by actually
running the launcher's parent spend and decoding its CLVM memo, so no
fixture shortcut can pass this test.

Also covers install_reward_chain_port's single-install refusal (true
then false, with the WARN server.rs's own call site logs).

Node exposes no lighter test constructor to an external integration
test crate, so the install-path test uses Node::from_env(), the same
constructor openrpc_drift_guard.rs's own test uses. launch_fixture
returns Box<dyn std::error::Error> rather than pulling in anyhow for
one test file.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards): stop reporting a missing parent spend as a distributor-identity verdict

ChainSource::parent_spend returning Ok(None) is a chain-source gap (the
source does not yet hold the launcher's creating spend), not a genuine
"this is not a DIG distributor" classification. Give it its own
LaunchCommentError::ParentSpendUnavailable variant so chain_port.rs can
map it to ChainPortError::Unavailable, agreeing with the other absence
path (read_distributor_guarded's own Ok(None)), instead of rendering a
transport lag as a definitive negative identity claim.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(rewards): observable degradation and a testable epoch computation

- Add one bounded tracing::warn! on distributor_report's error path,
  firing once per failure->success transition (not per call, via an
  AtomicBool), so an installed-but-degraded chain source is no longer
  indistinguishable from "no port installed."
- Extract current_distributor_epoch's arithmetic into a pure
  epoch_ordinal fn and unit-test it directly (non-zero multi-epoch case,
  the saturating_sub clock-skew branch, and the bare-launch zero case) --
  the only non-trivial computed field in the report mapping, previously
  unexercised by anything but a zero-valued default.
- Add launch_comment_error_to_port_error, wiring chain_source.rs's new
  ParentSpendUnavailable variant to ChainPortError::Unavailable, with a
  regression test, and a companion test confirming
  GuardedReadError::NonTerminatingEpochSeconds still maps to the named
  refusal (Other), never to Unavailable.
- Add a unit test proving a failing chain source surfaces as a named
  ChainPortError::Unavailable, never Ok(_) with a default-valued report.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards): de-circularize the install-refusal warn evidence

install_reward_chain_port_refuses_a_second_install_with_a_warn
previously captured and asserted against a warn it emitted itself
inside the test's own closure -- deleting server.rs's real warn line
would have left it green. Replace the self-emission with a source-text
check against server.rs's own production region (the same shape
adapter_source_never_imports_withdraw_committed_incentives already uses),
so the assertion can only be satisfied by what server.rs actually ships.

Also softens the A3 module doc's overstated "no fixture value can
produce the right store_id/root" claim: true of this file today, not a
structural guarantee.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* style(rewards): rustfmt, and note the install-warn test asserts source text not runtime behaviour

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Characterization test locking the #870 refusal rule: a peer identity holding both a dialled (outbound) pool slot and an accepted (inbound) mTLS connection is counted exactly once, the dialled slot survives, and the refused inbound peer is still served.

Refs DIG-Network/dig_ecosystem#3124

Gates at 2d46d9a: loop-reviewer verdict APPROVED (review 5228183672), loop-security PASS (issuecomment-5704107401), 14/14 checks green, 0 unresolved threads.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…BLE (#618)

* chore: open lane for #3342

Refs #3342

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(rewards): red test -- an answering chain with no distributor is an absence

`build_report` maps `read_distributor_guarded`'s `Ok(None)` -- the chain
answering "no distributor at this launcher" -- onto the same
`ChainPortError::Unavailable` an unreachable chain produces. A funder
deciding whether to claw back cannot tell "you have nothing there" from
"we cannot see the chain", and one wire shape for both makes that call a
guess on a money surface.

This test is RED at this commit, deliberately: it is the acceptance
evidence for the split that follows, written before the fix so the fix
has something to turn green.

Refs #3342

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rewards): split absence from outage behind REWARD_CHAIN_UNAVAILABLE

`ChainPortError::Unavailable` stood for three conditions a caller must
tell apart:

1. no chain-read adapter installed on this Node at all;
2. an installed adapter could not reach the chain -- a real outage;
3. the chain ANSWERED and holds no distributor at that launcher id
   (`read_distributor_guarded` -> `Ok(None)`).

Case 3 is the money-surface defect: an absence rendered as an outage. A
funder deciding whether to claw back cannot distinguish "you have
nothing there" from "we cannot see the chain", and one wire shape for
both makes that call a guess.

`Ok(None)` now gets its own `ChainPortError::NotADistributor` and its
own machine code, so the two can never share a shape again.

The message "no chain-read adapter is wired yet" was also false at the
site that emitted it -- on a default install an adapter IS wired and IS
answering. It is not reworded; it is confined to
`reward_chain_port_absent_response`, the one case where it is true, and
the `Unavailable` arm now names its real cause. A diagnostic that
misnames its own cause sends the next reader to the wrong subsystem.

Turns green the red test added in the previous commit.

Refs #3342
Refs #3246

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(rewards): pin the wire split and keep an absence off the degraded latch

Two pre-merge gate findings, both proven by mutation.

H1 -- the wire-level distinction was unpinned. No test asserted any
REWARD_* string on a JSON-RPC response body, so pointing the
`NotADistributor` arm's `data.code` at `REWARD_CHAIN_UNAVAILABLE_MACHINE`
re-collapsed the split, compiled clean (the match stays exhaustive) and
left all 3431 tests green. The port-level test was also too loose:
`assert_ne!(.., Unavailable)` passes if the variant is later re-mapped to
`Other`. Now a dispatch test installs a port answering
`Err(NotADistributor)` and asserts `data.code` by value for both methods,
and the port test asserts the variant by name.

H2 -- an absence armed the degradation latch. Every `Err`, including
`NotADistributor`, set the adapter-wide `report_degraded` latch and
warned that reads "stay refused until the chain source recovers". The
warn fires only on a false->true transition, so one probe for a launcher
id that simply is not a distributor silenced the warning for the next
GENUINE outage. That is worse than the defect this branch set out to fix:
it trades a misleading error for missing telemetry on a money surface.
`NotADistributor` is now excluded from both the latch and the warn; `Ok`
still clears it, matching a real recovery.

Refs #3342
Refs #3246

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* style(rewards): rustfmt the H1 dispatch test

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…(dig_ecosystem#3351) (#619)

dig_ecosystem#3351: dig.getRewardDistributor / dig.listRewardDistributorCommitments were documented
"CONTROL plane: loopback admin / in-process FFI ONLY" and answer on anonymous POST /. Decision (option 2,
posted on the ticket): Tier::Control is a transport-path class (local dispatch, never the mTLS peer
surface), not a token gate; both reads disclose only public on-chain state keyed by the caller's
launcher_id; zero live RPC callers exist; SPEC §5.5 L1080 requires every non-control.* method to be
requires_auth: false. The doc now says what the code does, and two tests pin it: POST / with no token
reaches the reward handler (not -32030); /ws does not route the reads (ok:false, not Unauthorized in
either numeric or string form). Mutation proofs M1/M2 run and RED (PR comment 5724073551). Node-local
reward reads -> #3352; rewards-coin SPEC §2.6 tier sentence -> #3354; rate bound on the open chain
reads -> #3355.

Gates on head 262551c: reviewer PASS (5243744057), security PASS (5243754264), adversarial PASS
(5724353432). Zero production code-path change.

Refs DIG-Network/dig_ecosystem#3351

🤖 Generated with [Claude Code](https://claude.com/claude-code)
…d inject the clock (#617)

* chore: open lane for #3336

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): newtype the fee-window cadence args + injectable-clock seam

- GateCadenceSeconds / FeeWindowCadenceSeconds newtypes on
  ClaimEngine::with_persisted_fee_window so transposing the two cadence
  values at the driver.rs call site is a compile error, not a silent
  money defect (#3336).
- run_claim_driver_in_with_clock: the production body with the clock
  parameterized instead of hardcoded to unix_now_seconds, so the timing
  behaviour is testable under tokio::time::advance. run_claim_driver_in
  stays a thin wrapper over it passing the real clock.

Refs #3336

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(rewards-claim): drive gate/window split through run_claim_driver_in_with_clock

Adds the_production_body_tracks_the_clamped_gate_and_the_raw_fee_window,
proving the F2 gate-vs-fee-window distinction through the actual
production body (run_claim_driver_in_with_clock) rather than a
hand-assembled drive() call, so a transposition of the two cadence
arguments at with_persisted_fee_window's call site (#3336) is caught
end-to-end.

Refs #3336

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* style: cargo fmt rewards-claim fee-window call sites

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* refactor(rewards-claim): collapse two cadence newtypes into one ClaimCadences value

The positional-newtype shape (GateCadenceSeconds/FeeWindowCadenceSeconds as two
adjacent with_persisted_fee_window arguments) closed the positional swap but left
the value swap open -- GateCadenceSeconds(raw)/FeeWindowCadenceSeconds(clamped)
still compiled and still passed the existing test (dig_ecosystem#3336 rework).

Bundle both cadences into one ClaimCadences { gate_clamped, fee_window_raw }
value instead: there is no longer a pair of adjacent arguments for a swap to
target at the call site. Every production and test call site updated.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(rewards-claim): make the clamped gate cadence unconstructible except by its clamp

DIG-Network/dig_ecosystem#3336: `ClaimCadences { gate_clamped: u64, fee_window_raw: u64 }`
closed the positional swap between the two cadence values but left the value swap open --
both fields were plain u64, so nothing stopped a caller writing the RAW configured cadence
into `gate_clamped` and the CLAMPED one into `fee_window_raw`. `ClampedGateCadence`'s inner
field is now private with `ClampedGateCadence::clamp(FeeWindowCadenceSeconds) -> Self` as its
only constructor, so a raw value has no path into the gate slot without going through the
clamp. `FeeWindowCadenceSeconds` wraps the raw side so the two are no longer interchangeable
plain integers.

* style(rewards-claim): cargo fmt

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* refactor(rewards-claim): derive the gate cadence from one raw config value

Closes the remaining half of the #3336 transposition hole structurally rather
than by test. `ClaimCadences` now has private fields and a single constructor,
`ClaimCadences::from_raw`, which derives `gate_clamped` from the same raw value
it stores as `fee_window_raw`. The production call site passes ONE value, so
there is no longer a pair to transpose or a `pub` field to write the wrong
local into.

Behaviour-identical: `CLAIM_CADENCE_FLOOR_SECONDS` is 60 and `config.rs` floors
any smaller configured cadence at load, so `sanitized_schedule`'s zero branch is
unreachable from this path and its output equals `min(cadence, MAX)` -- exactly
what the clamp computes.

Also renames `FeeWindowCadenceSeconds` to `RawConfiguredCadence` (it is the
clamp's input type, not only the window's), and replaces the tick-1/tick-2
`assert_ne!(state, CadenceNotElapsed)` exclusions with exact-state assertions --
the exclusion was equally satisfied by PersistedStateCorrupt and
ChainSourceUnavailable, whose early returns also sit above the window-roll
block, so it would have gone vacuous the moment either fired.

Refs DIG-Network/dig_ecosystem#3336

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* style(rewards-claim): restore string line continuations in claim-driver assertions

Convert literal backslash-n escapes with trailing spaces back to proper Rust string
line continuations (trailing backslash at end of line). The strings render as single
sentences without artificial newlines or multi-space runs. Fixes continuation_guard.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* docs(rewards-claim): separate the type-enforced half from the test-guarded half

The #3336 doc comments asserted a type-level guarantee the code does not
deliver. `ClaimCadences::from_raw` does close the pairing mutation -- the gate
and the fee window cannot disagree with each other, because `from_raw` derives
`gate_clamped` from the same `RawConfiguredCadence` it stores as
`fee_window_raw`, and it is the only constructor. It does NOT close the value
mutation: `from_raw(RawConfiguredCadence(cadence_seconds))`, the already-clamped
local instead of `cfg.cadence_seconds`, has the same type and compiles. Measured
consequence: the fee window halves -- the tick-2 assertion fails with
left Some(5356800), right Some(2678400).

That mutation is caught by exactly one test,
`the_production_body_tracks_the_clamped_gate_and_the_raw_fee_window`. The other
money test stays green under it, because it hand-assembles `drive` and never
traverses the production call site. The old docs told the next reader the value
swap was type-closed -- the exact sentence that would be cited to delete the one
guarding test.

Also corrects the stale "transposing the two arguments" description: the call
takes ONE argument, so that mutation cannot be written at all; and drops the
claim that the surviving mutation also breaks the gate (clamping an
already-clamped value is the identity, so it does not).

Docs only -- no behaviour, no type, and no assertion changed.

Refs DIG-Network/dig_ecosystem#3336

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(rewards-claim): remove the two-argument F2 doc block and name the clamp precondition

Doc comments only; no code, assertion, type or visibility changed. The test
count is unchanged (92 passed, 0 failed).

- engine.rs: delete the `with_persisted_fee_window` "F2 (money): takes TWO
  cadence values, deliberately not one" block. The method takes ONE
  `ClaimCadences`; those two names are private fields, not parameters, and
  "deliberately not one" instructed the next author to restore the two-`u64`
  signature this PR makes unwritable -- twenty lines above the #3336 section
  that contradicts it.
- engine.rs: `ClampedGateCadence::clamp` no longer claims flat equivalence with
  `sanitized_schedule`. It reproduces only that function's clamp arm, not its
  zero-substitution arm; they agree because a zero cannot reach it, and that
  precondition is now named.
- driver.rs: the surviving production-call-site comment describes the
  one-argument call it sits above, and names the single test that catches
  passing the clamped local instead of the raw config value.
- driver.rs: the sibling money test now records that it stays GREEN under that
  mutation, so its doc cannot be cited to delete the test that does catch it.

Refs DIG-Network/dig_ecosystem#3336

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(rewards-claim): correct the clock-seam fn name and the load_from exit count

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
…-- the claim loop pays a peer (#620)

Refs DIG-Network/dig_ecosystem#3347. Refs DIG-Network/dig_ecosystem#3246.

RealClaimChainPort installed from serve_with_shutdown via the corroborated chain source + a hint-index enumerator; own_entry and submit_initiate_payout are real over dig-rewards-coin 0.8.0 (ChainEntrySlotSource, finish_spend signature, Broadcaster); closure artifact drives run_claim_driver_in to a simulator-accepted payout coin. Triple gate PASS @ 9648236; five mutation proofs posted.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Workspace root version 0.258.0 -> 0.260.0 (develop's root sat below main's 0.259.0 after the
v0.259.0 cut; 0.260.0 is the next minor above main). Matching dig-node-service entry in Cargo.lock
so --locked builds stay satisfied.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
@MichaelTaylor3d

Copy link
Copy Markdown
Contributor Author

Close/reopen to re-fire the pull_request workflows: only the CodeQL dynamic run attached to 713b2ae on open; CI, Commitlint, Check Version Increment and Native install packages never triggered. Head unchanged.

@MichaelTaylor3d

Copy link
Copy Markdown
Contributor Author

loop-security verdict: CHANGES-REQUIRED — head 713b2ae

Pre-merge adversarial audit of release/v0.260.0 -> main (dig-node#622), diff b1dde19f..713b2aea (+3337/-405, 19 files). Ticket: DIG-Network/dig_ecosystem#3347.

S1 — Custody/spend: CLEAR

crates/dig-node-service/src/rewards_claim/chain_port.rs:306-327 — required_fee_mojos always returns 0, and submit_initiate_payout refuses any non-zero fee_mojos by name (chain_port.rs:322-327) before building anything. submit_initiate_payout (chain_port.rs:329-378) attaches no fee coin, holds no signing key, and calls distributor.finish_spend(&mut ctx, vec![]) with an empty coin list (chain_port.rs:366-368) — the only coin in the resulting SpendBundle is the distributor's own reserve/entry-slot coin from dig-rewards-coin. There is no path by which this node's own wallet coins, collateral, or fee balance enter the bundle. An attacker minting an arbitrary distributor cannot make this node spend its own funds — there is nothing of the node's in the spend to begin with.

S2 — Payee destination: CLEAR

crates/dig-node-service/src/rewards_claim/driver.rs:300 (own_payout_puzzle_hash) derives the payout puzzle hash from owner_inner_puzzle_hash — this node's own identity — never from attacker/chain-supplied data. engine.rs:694,710,858 use self.own_payout_puzzle_hash unconditionally for both the entry-match check and the actual submit_initiate_payout call; engine.rs:710 refuses (does not pay) an entry whose payout_puzzle_hash differs from the node's own (regression-tested at engine.rs:2642 "entry_for_a_different_payout_puzzle_hash_is_refused_not_paid"). No caller-suppliable destination exists on this path.

S3 — DoS via distributor set: CLEAR on the named hazard, un-bounded-enumeration is defense-in-depth

crates/dig-node-service/src/rewards/chain_source.rs:101-110 refuses epoch_seconds == 0 (NonTerminatingEpochSeconds) BEFORE read_distributor_guarded returns, and chain_port.rs:236,254,284,333 route every read (reserve_asset_id, payout_threshold, own_entry, submit_initiate_payout) through this same guarded read — so the commit_incentives infinite-loop hazard (module doc, chain_source.rs:5-17) cannot reach dig-rewards-coin/chia-sdk-driver from this adapter. The out-of-range schedule clamp is applied at ClaimCadences::from_raw (engine.rs:67-79) before the cadence reaches the driver. NOT bounded: discover_distributors (chain_port.rs:193-218) iterates every candidate id from HintedLauncherIndex sequentially inside one spawn_blocking, with no cap on candidate count — an attacker who gets N distributor-launch hints into this node's peer view makes one claim cycle perform N sequential guarded chain reads. Each read is individually bounded (the epoch guard, no unbounded loop), so this is a scaling/cost concern rather than a hang — defense-in-depth, recommend a ticket capping candidates per cycle, not a blocker.

S4 — Open reads on POST / (#619 without #621): BLOCKING

crates/dig-node-core/src/seams/dig_rpc/dispatch.rs:1017-1096 (dig.getRewardDistributor, dig.listRewardDistributorCommitments) are dispatched on the ordinary Method::from_name match with no auth and no rate limit — confirmed at crates/dig-node-service/src/server.rs:1150, where the ONLY ingress rate limiter (control_ingress_admits, server.rs:971-974, backed by MissRateLimiter) is entered only inside if control::is_control_method(&method) (server.rs:1132), and is_control_method (crates/dig-node-service/src/control.rs:99-101) matches ONLY the control. prefix — verified by the existing test is_control_method_only_matches_control_namespace asserting !is_control_method("dig.getContent"). Both new methods are dig.*, so they never pass through control_ingress_admits at all; no other per-method or per-IP limiter exists on this path.

Each call drives a real RewardsChainPort::distributor_report chain read (dispatch.rs:1026,1069), keyed by a caller-supplied launcher_id, disclosing no node-local state (public on-chain distributor data only) — so this is NOT an S1-class custody or S5-class honesty issue, and NOT a node-local info leak. It IS exactly the amplification vector dig_ecosystem#3051 was written to close for control.* open reads, but that fix was never extended to these two new dig.* methods.

Exploit: operator sets DIG_NODE_ALLOW_REMOTE=1 (an explicit, documented opt-in the codebase already supports and gates other surfaces against, e.g. server.rs:201-205) to run a public-facing node. A remote, unauthenticated caller then sends dig.getRewardDistributor/dig.listRewardDistributorCommitments at line rate — no token, no backoff, no per-source limiter — each one forcing a real chain read via RewardsChainPort. Under the DEFAULT loopback-only bind this is not reachable remotely, so it is not exploitable out of the box, but it ships the exact gap the ticket calls out: #619's open reads land in this cut WITHOUT #621's rate bound.

Ruling: BLOCKING for a node that runs with DIG_NODE_ALLOW_REMOTE=1 (an already-supported, documented configuration this same codebase treats as the live threat model for every other open read on this surface — see the control_ingress_admits doc's own rationale, server.rs:942-968). ACCEPTABLE under the default loopback-only bind. Recommend either (a) fast-follow #621 lands before this cut goes out, or (b) the minimal fix — route dig.getRewardDistributor/dig.listRewardDistributorCommitments through the SAME control_ingress_admits-style ingress check (widen the rate-limit scope beyond is_control_method, or add an equivalent guard at these two arms) — before merge. Parent decides which.

S5 — Honesty of money-adjacent reports: CLEAR

chain_port.rs:24-25 and the module doc explicitly call out that a silent no-op would be the exact defect this ticket exists to prevent — a refused method reports a NAMED ClaimPortError, never a fabricated success. dispatch.rs:930-956 REFUSES the whole dig.getRewardProverStatus call when a record's identity field is zeroed rather than silently excluding it (the earlier, correctly-identified defect). REWARD_CHAIN_UNAVAILABLE is split (dispatch.rs:38-56) so "chain unreachable" is never conflated with "chain answered, nothing there." No path found that reports a payment or chain condition that did not occur.

S6 — Supply chain: CLEAR

Cargo.lock diff is exactly two hunks: dig-node-service 0.259.0->0.260.0 (this crate's own version) and dig-rewards-coin 0.5.0->0.8.0 (registry, checksum pinned and changed). No other third-party crate moved.

S7 — Forgeable guards: CLEAR

No pub struct Marker/unit-type admission token found in the new code. The one "trust-but-verify" pattern (LauncherIndex, chain_port.rs:58-69) is explicitly documented and enforced as non-authoritative: every id it proposes is re-verified through dig_rewards_coin::discover_distributor's real memo decode (resolve_via_chain, chain_port.rs:160-178) before being trusted, so a forged or stale index entry yields nothing rather than a bypass.

CI at judgement time

gh pr checks 622 shows only CodeQL: Analyze (actions) pass, Analyze (javascript-typescript) pass, Analyze (rust) PENDING, CodeQL skipping. No build/test workflow is attached to this PR at judgement time — an unrun leg is not a PASS; the correctness/build gate is not evidenced here.

Scope audited

19 changed files in the diff b1dde19f..713b2aea; read via git show/git diff in the read-only worktree C:/worktrees/dig-node-cut (untouched, no writes made). Focused reading on chain_port.rs, driver.rs, engine.rs, port.rs, server.rs, dispatch.rs, chain_source.rs, control.rs. Did not build or run tests (per brief — shared cold-build worktree). Did not audit dig-rewards-coin 0.8.0's own internals (out of repo scope) beyond confirming the lock pin and this adapter's documented non-use of created_slot_value_to_slot (mutation-tested, chain_port.rs:576-587).

…r the cut)

The develop -> main cut cannot preserve ancestry under squash-only merging, and no -s ours
reconciliation was recorded on develop after the v0.259.0 cut, so this branch reads CONFLICTING
against main (Cargo.toml/Cargo.lock/lib.rs) and GitHub fires no pull_request workflows on a
conflicting PR. -s ours records main's history and keeps this tree byte-identical to 713b2ae.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

@MichaelTaylor3d MichaelTaylor3d left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

loop-decider ADVERSARIAL verdict: PASS — head 713b2ae (now ea370d6, same tree)

Head read: 713b2aeadf4703635d096b581dc87fabab6ab9f3 (worktree C:/worktrees/dig-node-cut, git rev-parse HEAD). The PR head then moved to ea370d64e0922b8fed5258dea7e299c9f8d2122c by a -s ours merge of origin/main (parents 713b2aea + b1dde19f); verified git diff --quiet 713b2aea ea370d64 exit 0, tree d973eb15 byte-identical — this verdict covers both SHAs. Diff base b1dde19f (v0.259.0). Read-only; no files modified.

Claim under attack: v0.260.0 pays an admitted peer from the real startup path, and the composite cannot (a) spend the node's own money, (b) report a phantom payment, (c) hang on attacker-minted chain state, (d) sweep unfinished work. All four legs survive. One advisory (A4, non-blocking) recorded.

A1 — Own-money spend: REFUTED

  • crates/dig-node-service/src/rewards_claim/chain_port.rs:322 — fee_mojos != 0 is Err(ClaimPortError::Other) before any chain read. required_fee_mojos (:306) is a constant Ok(0), so the engine's fee is always 0 on this adapter.
  • Bundle contents: SpendContext::new() (:341) is fresh; the only spends added are initiate_payout(...) on the distributor (:344) and distributor.finish_spend(&mut ctx, vec![]) (:366). finish_spend (chia-sdk-driver 0.36.0 primitives/action_layer/reward_distributor.rs:699-757) spends the distributor singleton and the distributor's OWN reserve CAT (cat_spend_for_reserve_finalizer_controller); other_cat_spends is the empty vec![]. No wallet coin, no change, no fee coin can enter the bundle. Signature is pending_spend.signature (the distributor's; no node key is consulted) — production_claim_port (driver.rs:320) takes no signer.
  • Broadcaster is submit-only: crates/dig-wallet/src/sage/spend.rs:361-370 (ChiaQueryBroadcaster::broadcast = push_tx + accepted_by_mempool); it neither signs nor adds a fee.

A2 — Phantom payment: REFUTED

  • engine.rs:856-863 — ClaimOutcome::Submitted is produced ONLY on Ok(()) from submit_initiate_payout; claims_submitted increments only from Submitted (engine.rs:607, :642).
  • chain_port.rs:383 — broadcaster.broadcast(&bundle).await.map_err(...)? returns Err before the Ok(()) at :399. ChiaQueryBroadcaster::broadcast maps a non-accepted mempool status to Err (spend.rs:370, accepted_by_mempool :305-316).
  • PayoutOutcome::EntrySlotAbsent at submission time is Err (chain_port.rs:357), not Ok.
  • Closure artifact asserts on the PAYEE COIN, not just the counter: tests/rewards_claim_chain_port_3347.rs:507-513 — payee_coins.len() == 1 at CatArgs::curry_tree_hash(reserve_asset_id, payout_puzzle_hash) and payee_coins[0].coin.amount == expected_accrued, after sim.spend_coins(bundle.coin_spends) accepts the exact bundle the production driver handed the broadcaster (:496-499).
  • Residual (not a hole): the artifact's broadcaster is MockBroadcaster, so ChiaQueryBroadcaster's Ok/Err mapping is covered by read, not by this test.

A3 — Hang on attacker-minted state: REFUTED

  • Refusal site: crates/dig-node-service/src/rewards/chain_source.rs:89 — read_distributor_guarded calls refuse_non_terminating_epoch_seconds (:102-113) BEFORE dig_rewards_coin::state::read_distributor. The guard reads only the launcher spend's key_value_list — no generation walk — so it cannot itself hit the hazard.
  • Reachable from the real path: every RealClaimChainPort method that touches distributor state goes through read_distributor_guarded — reserve_asset_id (rewards_claim/chain_port.rs:237), payout_threshold (:255), own_entry (:284), submit_initiate_payout (:337). run_claim_driver (driver.rs:332) builds exactly this port via production_claim_port (:383); the return type is pinned by const _: ProductionClaimPortFactory = production_claim_port (:980). Discovery (resolve_via_chain, :160) uses discover_distributor, which decodes the launch memo only (dig-rewards-coin-0.8.0/src/discovery.rs:274-288), no state replay.
  • Mapped to a named refusal, never Unavailable (chain_port.rs:135), so an attacker-minted epoch_seconds == 0 distributor is one Faulted outcome, not a hang and not a chain-unavailable state flip.
  • Schedule out of range: sanitized_schedule (driver.rs:459-509) clamps both fields to CLAIM_SCHEDULE_SECONDS_MAX and substitutes the default for cadence == 0; config.rs:229-250 floors cadence and fails closed on an over-budget persisted spend.

A4 — Transposition regression (#3336): REFUTED, with one advisory

  • Single derivation site: driver.rs:604-607 — .with_persisted_fee_window(state_dir, ClaimCadences::from_raw(RawConfiguredCadence(cfg.cadence_seconds))); both the clamped gate and the raw fee window are derived inside ClaimCadences::from_raw (engine.rs:47-70) from ONE newtype argument. The historic two-u64 transposition is no longer expressible.
  • Test ABOVE the site that goes RED under the surviving mutation (passing the clamped local instead of cfg.cadence_seconds): driver.rs:1658 the_production_body_tracks_the_clamped_gate_and_the_raw_fee_window — drives the production body and asserts the window does not roll at tick 2 (left Some(5356800), right Some(2678400) under the mutation, documented in the test).
  • Advisory (non-blocking, not the #3336 class): driver.rs:595-596 destructures (cadence_seconds, jitter_seconds, adjustment) and driver.rs:610-612 passes them positionally to drive(engine, cadence_seconds, jitter_seconds, ...) (:167-171, both u64). A swap here compiles and no test deterministically catches it (write_config uses jitter_seconds: 0, so the production-body test would go red only probabilistically). Failure direction is BENIGN for money: the engine's own cadence gate (engine.rs:446, driven by ClaimCadences) is independent of the sleep interval, so a shortened sleep yields CadenceNotElapsed, not extra spend. Recommend a CadenceSeconds/JitterSeconds newtype pair as a follow-up tweak; not a reason to hold the cut.

A5 — Forgeable admission: REFUTED

  • The claim side has no admission marker at all: "admitted" is a fresh chain read of the entry slot on EVERY call (engine.rs:691-699 -> own_entry -> snapshot.entry_slot(payout_puzzle_hash) at chain_port.rs:290), and "ours" is reserve_asset_id == DIG_ASSET_ID (engine.rs:686-689).
  • Unit types in scope (hints.rs:26 NoHintSource, rewards_claim/port.rs:81 UnavailableClaimChainPort, core/rewards/port.rs:305 UnavailableChainPort, core/rewards/state.rs:102 SystemClock, core/rewards/writes.rs:247 NoPersistence) prove nothing; none gates a spend.
  • Funder side AdmittedPeer (dig-node-core/src/rewards/admission.rs:57) has private fields and a #[cfg(test)]-only constructor — not constructible from production code.

A6 — Sweep: REFUTED

  • git diff --name-only b1dde19f..HEAD vs b1dde19f..origin/develop: identical (diff exit 0), 19 files, +3337/-405. Root Cargo.toml/Cargo.lock 0.258.0 -> 0.260.0 appear only in the cut commit 713b2aea. Every file in the fileset is attributable to #620/#617/#619/#618/#591/#614/#611 by git log b1dde19f..HEAD -- <file>; dig-node-core/src/lib.rs (+119) is #618 + #591. Nothing from open #621 is present.

A7 — Release honesty: SHIP NOW; #3352/#3355 stay open as follow-ups

  • git show 7c9f46b0 -- dispatch.rs (#619) changes comments only (28 lines, all doc); the five reward-read methods were already served OPEN on main at v0.259.0 (the only main...HEAD change to those handlers is #618's error split). This cut does not widen exposure; it documents and pins what already ships.
  • loop-security's S4 (dig.getRewardDistributor / dig.listRewardDistributorCommitments, dispatch.rs ~1017-1096, bypass the control.*-scoped ingress rate limiter under DIG_NODE_ALLOW_REMOTE=1) is REAL but PRE-EXISTING: both methods are dispatched at Tier::Control, un-token-gated, on origin/main at v0.259.0 (dispatch.rs:971, :1014 on main). Holding this cut fixes nothing for the shipped v0.259.0 binaries; it only delays the payout path the release exists to ship.
  • The reads are chain-read only (no wallet, no spend path). Exposure class is DoS/cost on peer reads behind an opt-in env var, not money/custody. Rule applied: WAIT only for money/custody exposure INTRODUCED by the cut; a pre-existing DoS bound is a follow-up. Decision: SHIP. #621 (token-gate + rate-bound, #3352/#3355) lands in the next cut; S4 stays open as CHANGES-REQUIRED on #621's scope, not on #622.

Test: NOT RUN

Every question settled by read; the one permitted test was not spent. No cargo processes started.

Required checks (by name, gh pr checks 622)

At read time only CodeQL jobs had attached (Analyze (actions) pass, Analyze (javascript-typescript) pass, Analyze (rust) pending). Lint commit messages, Check version increment, Rustfmt, Clippy, Test + coverage, Release-script tests: NOT ATTACHED — unrun is not a pass. This PASS is on the diff content; the orchestrator must see all six green on 713b2aea before merging.

@MichaelTaylor3d MichaelTaylor3d left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

loop-reviewer verdict: PASS — head 713b2ae (now ea370d6, tree byte-identical, see note)

SHA note: I judged the diff at head 713b2aeadf4703635d096b581dc87fabab6ab9f3. Mid-review the PR head advanced to ea370d64e0922b8fed5258dea7e299c9f8d2122c via a -s ours merge of origin/main (ancestry-only, resolving the CONFLICTING mergeability GitHub had reported and letting pull_request workflows attach). I independently verified git diff --quiet 713b2aea ea370d64 exits 0 and both commits share tree d973eb15b7576a2f01bdf61248c6e5dec0204bdb — the diff judged below is unchanged at the new head. Verdict applies to both SHAs.

H1 — startup wiring: PASS

crates/dig-node-service/src/server.rs (the state.wallet_chain.corroborated_chain_source(..) block right before the L7 sync comment, and the spawn_claim_driver_from_config(config.enable_chain_sync, state.wallet_chain.clone()) call replacing the old single-arg call) wires the real chain source into both the funder-side RewardsChainPort (via install_reward_chain_port) and the claim-loop path. crates/dig-node-service/src/rewards_claim/driver.rs::run_claim_driver now builds production_claim_port(source, HintedLauncherIndex::new(wallet_chain), broadcaster) — a RealClaimChainPort, not UnavailableClaimChainPort. UnavailableClaimChainPort's only remaining production-code reference is gated #[cfg(test)] (driver.rs, use super::port::UnavailableClaimChainPort; under #[cfg(test)]) — unreachable from production, confirmed by reading the import gate, not just the doc comment. production_claim_port's return type is pinned so a retype to the unavailable adapter is a compile error, per its own doc comment.

H2 — submit_initiate_payout honesty: PASS

rewards_claim/chain_port.rs::submit_initiate_payout: fee_mojos != 0 returns Err before any chain work (~line 322). The bundle is built inside spawn_blocking, then self.broadcaster.broadcast(&bundle).await.map_err(..)? — a broadcaster Err propagates via ? and the function returns before the tracing::info!("InitiatePayout submitted") line or the trailing Ok(()); there is no path that logs/returns success without broadcast() having returned Ok. Caller side, engine.rs's evaluate_budget_phase: Ok(()) from the port increments spent_this_cycle_mojos and yields ClaimOutcome::Submitted; Err(Unavailable) / Err(Other) both call uncommit_fee (reversing the pre-committed persisted spend) and never produce Submitted — claims_submitted only increments from Submitted-derived counts.

H3 — epoch_seconds==0 refused before the non-terminating call: PASS

chain_port.rs's guarded_read_error_to_claim_port_error maps GuardedReadError::NonTerminatingEpochSeconds (raised by rewards::chain_source::read_distributor_guarded, called from every read site including inside submit_initiate_payout's spawn_blocking) to a named ClaimPortError::Other BEFORE initiate_payout/ChainEntrySlotSource ever run — the guard sits ahead of the dig-rewards-coin call in the same function body, not after it.

H4 — cadence transposition: PASS, single named test

rewards_claim/engine.rs introduces ClaimCadences::from_raw(RawConfiguredCadence) as the ONLY constructor (private fields, no struct-literal escape) deriving gate_clamped (via ClampedGateCadence::clamp) and fee_window_raw from the SAME RawConfiguredCadence value — the gate and the fee window can no longer disagree with each other. The module's own doc names the residual gap (which raw u64 a call site labels RawConfiguredCadence(..) is not type-checked) and the ONE test that pins the real call site against it: driver::tests::the_production_body_tracks_the_clamped_gate_and_the_raw_fee_window (driver.rs:1658), which drives spawn_claim_driver_from_config's real body, not a fake harness. Confirmed the production call site (driver.rs:603) passes RawConfiguredCadence(cfg.cadence_seconds), matching what the test asserts against.

H5 — REWARD_CHAIN_UNAVAILABLE / three-way split: PASS

crates/dig-node-core/src/seams/dig_rpc/dispatch.rs: REWARD_CHAIN_UNAVAILABLE_MACHINE fires from exactly two sites — reward_chain_port_error_response's ChainPortError::Unavailable arm (an installed adapter's chain source could not answer) and reward_chain_port_absent_response (no adapter installed at all) — both messages are true to their condition ("no chain-read adapter is wired yet" vs. "the chain source could not answer"). ChainPortError::NotADistributor gets its own REWARD_NOT_A_DISTRIBUTOR_MACHINE with message "no reward distributor exists... on chain" (chain answered, genuinely empty) — distinct wire code, distinct message, never collapsed into the unavailable code. REWARD_INVALID_WITHDRAWAL_SHARE_MACHINE is the third, separate condition. All three are wire-distinguishable via data.code.

H6 — ClaimOutcome honesty / fault variant: PASS

rewards_claim/types.rs::ClaimOutcome has a 7th variant (following Submitted/SkippedBelowThreshold/SkippedFeeAboveCeiling/NoEntrySlot/NotOurs/SkippedCycleBudgetExhausted/PayoutPuzzleHashMismatch) explicitly for "something went wrong" — a ClaimPortError::Other(_) this cycle — distinct from the six legitimate-non-payment variants and from cycle-wide ChainSourceUnavailable. No counter increments under this variant (claims_submitted is fed only by Submitted, per H2).

H7 — version bump: PASS

Root Cargo.toml [workspace.package].version: 0.257.0 -> 0.260.0, above main's 0.259.0. Cargo.lock diff (b1dde19f...713b2aea) shows version bumps confined to dig-node-service (0.257.0->0.260.0) plus the dependency bumps already reflected from develop (dig-rewards-coin at 0.8.0, etc.) — no unrelated lock churn beyond what the workspace bump and the merged feature PRs already account for.

H8 — debug/unfinished artefacts: PASS

git diff of the whole range grepped for todo!/unimplemented!/dbg!/MUTATION-TEST/#[ignore] on added lines only — zero hits across the whole diff.

Required checks (branch protection on main names exactly: Lint commit messages, Check version increment, Rustfmt, Clippy, Test + coverage, Release-script tests — confirmed via the branch-protection API)

At the ORIGINAL head 713b2aea: none of the six had attached — only CodeQL/Analyze (*) ran, and a paginated search of workflow runs for head_branch=release/v0.260.0 returned zero runs besides that CodeQL run. Consistent with the PR having read CONFLICTING before the ancestry-merge described above — pull_request-triggered workflows do not fire on an unmergeable PR.

At the CURRENT head ea370d64 (same tree), at time of this verdict:

  • Lint commit messages — COMPLETED / SUCCESS
  • Check version increment — COMPLETED / SUCCESS
  • Rustfmt — COMPLETED / SUCCESS
  • Clippy — COMPLETED / SUCCESS
  • Release-script tests — COMPLETED / SUCCESS
  • Test + coverage — still IN_PROGRESS at judgement time, not yet a pass or a fail

I did not run cargo build/cargo test myself (per brief: cold build in a shared worktree, three gate legs sharing it). The correctness verdict above is from static reading of the diff, not from running the suite; Test + coverage's own result is the missing empirical leg, and branch protection will not permit this merge until it reports. If Test + coverage comes back red, this verdict is void and the PR needs a fresh gate pass against whatever it reports.

Not run

  • cargo build / cargo test (shared worktree, cold-build risk per brief).
  • No independent adversarial/security leg re-derived here — this diff touches money paths (submit_initiate_payout, own_entry) but is composed of already-gated constituent PRs (#620 reviewer+adversarial PASS per ticket #3347's own facts); I re-derived the composite wiring (H1–H6) rather than re-deriving #620's own proofs from scratch.

Inline threads

None opened — no blocking defect found. Zero open threads.

@MichaelTaylor3d

Copy link
Copy Markdown
Contributor Author

loop-security re-ruling — head 713b2ae/ea370d64: PASS

Verified independently against git diff b1dde19f 713b2aea -- crates/dig-node-core/src/seams/dig_rpc/dispatch.rs and git show b1dde19f:...dispatch.rs: on main (v0.259.0, already released) the Some(Method::GetRewardDistributor) and Some(Method::ListRewardDistributorCommitments) arms already exist, already call port.distributor_report(..) unconditionally, and are already reachable on POST / with no token and no ingress rate limit — the only change in #622's hunk there is doc comments plus swapping reward_chain_port_error_response(&id, &ChainPortError::Unavailable) for the new reward_chain_port_absent_response(&id) (a message-text correction, #3342). No auth, tier, or rate-limit code changed. server.rs's control_ingress_admits gate (scoped to control.* only) is untouched by this diff on either side.

So S4 is a pre-existing exposure on main, not something #622 introduces or widens — my original CHANGES-REQUIRED conflated "ships this cut" with "this diff creates this," which is the wrong test for a gate scoped to the diff. Withdrawing the BLOCKING ruling on #622.

Verdict on #622's diff: PASS. S4 is carried forward as a pre-existing finding, correctly scoped to #621/#3352/#3355's remit (the rate-bound fix), not to this release cut. loop-decider's SHIP ruling stands; no objection from this leg.

S1/S2/S3(named)/S5/S6/S7 findings from the original review are unaffected and still apply as-is (all CLEAR, S3's unbounded-candidate-count note still recorded as defense-in-depth).

Remaining non-blocking note carried from the original review: no build/test CI was attached at judgement time (only CodeQL) — that's an evidence gap for the correctness gate, not a security finding, and doesn't change this PASS.

@MichaelTaylor3d
MichaelTaylor3d marked this pull request as ready for review September 23, 2026 20:02
@MichaelTaylor3d
MichaelTaylor3d merged commit 27cf18d into main Sep 23, 2026
15 checks passed
@MichaelTaylor3d
MichaelTaylor3d deleted the release/v0.260.0 branch September 23, 2026 20:02
MichaelTaylor3d added a commit that referenced this pull request Sep 23, 2026
…ink)

-s ours records main's history so the next develop -> main cut opens MERGEABLE instead of
CONFLICTING (GitHub fires no pull_request workflows on a conflicting PR). It brings NO content;
the forward-port of main's newer files follows in the next commit.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant