Estimated XvB net band: probabilities everywhere, measured collection bound - #879
Merged
Conversation
The tier calculator's unmeasured state showed XvB's face value labeled as an
upper bound — honest, but unanswerable for the question the panel exists for
("is enabling worth it?"). Everything except one factor IS computable on any
box: cost (linear P2Pool model) and draw odds (winners feed) are pure math;
per-win collection is not derivable from outside XvB, but it is BOUNDED by
measurement. Ship that bound:
- XVB_REALIZATION_PRIOR = (0.24, 0.42), from baseline-subtracted 6h post-win
payout-stream measurements on a production wallet across two regimes: 24%
with the credited average riding the tier threshold (terminated rounds),
42% with comfortable margin.
- Unmeasured tiers emit assumed_reward_year_range; the panel's Net becomes a
range labeled (estimated) — red only when even the optimistic end loses,
green only when even the pessimistic end profits. Measured supersedes it.
- Accuracy fixes the stream measurement demanded: the local-measurement
attribution window widens 2h -> 6h (the stream is front-loaded but runs
~6h), and the box's own linear P2Pool baseline over the windowed hours is
subtracted so ordinary payouts can't inflate the factor.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The tier calculator's unmeasured state showed XvB's face value labeled as an upper bound — honest, but it dodged the question the panel exists to answer: is enabling worth it? Everything except one factor is computable on any box — cost is the linear P2Pool model, draw odds come from the winners feed — and the one factor that can't be derived (per-win collection, mechanics on XvB's side) is bounded by measurement. So ship the bound:
XVB_REALIZATION_PRIOR = (0.24, 0.42): baseline-subtracted 6h post-win payout-stream measurement on a production wallet across two regimes — 24% collected with the credited average riding the tier threshold (terminated rounds), 42% with comfortable margin.assumed_reward_year_range; the panel's Net becomes a range labeled (estimated) — red only when even the optimistic end loses, green only when even the pessimistic end profits. A local measurement supersedes the band; raw face value renders only when no band is computable.For Whale at today's figures the estimated band reads −1.35 … −0.20 XMR/yr — the answer the face value's +2.5 hid.
Testing
Server: prior-band emission/exclusivity/staleness, baseline-subtraction unit test. Frontend: range math + exclusivity in
xvbTierComparison, estimated-label render with both endpoints and range coloring. Full suite green, patch coverage 100%, lint + docs voice clean.🤖 Generated with Claude Code