GRINSolo Mining

Click a nickname for its workers. Owed = its share of every matured coinbase (split by work done, per nickname) minus what the operator has already paid out-of-band — it drops to zero once settled. The period table shows work share within a rolling window. Blocks = blocks that nickname's winning shares found in the period — a leaderboard stat only; payouts still split by work share, never by who got lucky. No Grin address is stored or shown.

Payouts are settled manually. The operator sends GRIN by hand to each miner out-of-band (e.g. friends mining to this node) and records it here — this page is bookkeeping only and moves no funds.

Span follows this chart's period selector (Weekly = last 7 days · Monthly = this month · Yearly = this year, shown as weekly averages). The left axis counts blocks found; the right axis is GRIN mined (the two are the same scale — GRIN = blocks × block reward). Bars are the actual GRIN credited that day — lumpy, because solo blocks arrive irregularly. The estimate line removes that block-luck: the day's work share × the average block rate over the shown span. Pool avg / miner = that day's smoothed pool reward ÷ how many miners were active that day (the count changes day to day). The estimate is a projection, not a promise — attribution is by the block's found day. Days here are UTC days (this is a pre-aggregated series, so it can't be re-bucketed per visitor): if you flip the found-blocks table/heatmap to Local time with the 🕓 header clock, a block found late in the UTC day can appear on the next local calendar day there while it stays on the UTC day here.

At equal effective hashrate, solo and a pool earn the same on average (minus the pool fee) — solo just has higher variance. A persistent shortfall vs a pool usually means lost effective hashrate, and these are the two culprits. Orphaned = a block you found that lost the propagation race and was reorged out (earns nothing) — high orphan % points to poor peering / slow block propagation, so raise your node's peer count. Stale = a solution that arrived after the chain moved on (pure latency loss) — high stale % points to slow job refresh or miner↔node latency. Rejected = invalid/duplicate submissions. Stale/rejected counts depend on the node logging at INFO; verify the parser caught your node's wording with --dry-run. The By worker table lists only workers that currently have a problem (orphaned or stale/rejected > 0), ranked worst-first so you can spot which rig to fix — clean workers are hidden (the count is noted under the table) and a long problem list is capped at the worst 25. Orphans are attributed exactly (to the worker whose share found the block), while stale/rejected are attributed to the worker only when your node names the login on its reject lines — any that don't are counted as unattributed in the note under the table (not shown as a worker row, since they belong to no single rig). --dry-run reports how many of your reject lines carry a login. The Node binary line shows which node build is running and when the collector last saw it change (up to 5 minutes after the swap). If stale % rose in the windows marked ⚑ (the node binary changed there), measure how long the node takes to hand out a new job: in the toolkit menu, Admin & Maintenance → Diagnostics & Support → Mining / stratum latency (keys 8 → 6 → 8).

Why "found" here can be lower than the "All blocks we found" total: Solo Health only counts a block once its fate is chain-verified at 1440-block maturity (~24 h), so it can be classified as matured or orphaned. Your most recently found blocks are still immature — they show in the all-blocks list but aren't counted here yet, so a small gap (e.g. 33 found vs 31 matured+orphaned) just means those last blocks haven't matured. They'll roll in within ~a day. For the same reason, very recent windows can read 0 orphans.