IceRiver Mining But Kaspa Rewards Not Showing in Wallet

Screenshot everything before you touch anything. IceRiver Web UI block notification, pool dashboard's block-found row, your wallet's no-transaction state, the timestamp. Lock the evidence in case the dashboard rolls over and overwrites the notification log. Do this before refreshing, before power-cycling, before any troubleshooting that could discard volatile evidence you will need to walk the chain. Note the exact timestamp, pool URL, worker name, and your wallet address character-by-character.

Verify on the Kaspa explorer at explorer.kaspa.org. Search for a block at your event timestamp. Read the coinbase output. Match it character-by-character to the wallet address you pasted into the IceRiver Pool Setting field. If it matches: the funds are confirmed on-chain — your job is to wait for wallet sync. If the explorer shows the block in red GHOSTDAG status: you got reorged out, no payout coming, DIY ends here.

Wait for wallet sync. Light wallets (Kasware, KDX) typically catch up within 5-15 minutes. Custodial wallets and exchanges typically credit within 12-24 hours, some require 100+ confirmations. If your event was within the last 30 minutes and the explorer confirms the coinbase is yours, the right move is patience, not panic. Refresh after 10 minutes; if still no balance update, force a re-sync (Kasware: lock then unlock; KDX: restart app; CLI: re-query the daemon).

Check your pool's payout schedule documentation. Most Kaspa solo pools pay you via a follow-up transaction, not directly to the coinbase. WoolyPooly, F2Pool, Kryptex, Acc-Pool, Hash-Pool all publish a payout schedule (every N minutes, or when threshold is met). Read it. If elapsed time since your block is shorter than the documented schedule, the answer is wait. If elapsed time is 2x the documented schedule with no movement, escalate to Tier 3.

Verify the wallet address you typed into the IceRiver Web UI. Web UI > Pool Setting > read the wallet address back. Compare character-by-character to your wallet's Receive tab. Look specifically for: missing kaspa: prefix, transposed characters, OCR substitution errors (0 vs O, l vs 1 vs I). If the address does not match your wallet, the coins were credited to some other Kaspa address that you do not control — likely lost unless that address is one you also own.

Trace the coinbase address on the explorer. Click the coinbase recipient on the block's explorer page. Open its transaction history. Filter by direction (outgoing). Look for an outgoing transaction to your wallet address in the minutes-to-hours after the block. If found, you will see the tx hash, the amount (typically the block subsidy minus the pool fee), and the confirmation count. Forward this tx hash to the pool support if needed for evidence.

Identify the coinbase address ownership. If the coinbase address is not yours, look it up on the pool's documentation page (most reputable pools publish their payout aggregator address) or on a Kaspa explorer that shows known address labels. WoolyPooly, F2Pool, Kryptex publish theirs. If the address has no public attribution, that is a serious flag — escalate to Tier 3.

Open a public-record support ticket. Discord channel, Telegram group, the pool's GitHub issues, or the pool's status-page comments. Quote: block height, block timestamp, your wallet address, your worker name, the suspected coinbase address. The public record matters — Kaspa pools that have lost reputation over missed payouts have done so via leaked Discord screenshots. Make support care.

Check the GHOSTDAG block status explicitly. Some Kaspa explorers (kgi.kaspad.net, kasplex.org) show GHOSTDAG metadata: blue (canonical, coinbase spendable), red (orphaned, no payout). If the explorer does not surface this, run a CLI query against a Kaspa node: kaspactl getBlock --hash=<block-hash> and inspect the verboseData.isInVirtualSelectedParentChain field. False = orphaned.

Check the IceRiver Web UI stratum log if exposed. Some firmware builds expose a stratum log via /cgi-bin/get_stratum_log.cgi or /log. Look for the share that triggered your block-found notification. The log line will show the difficulty target it cleared and whether the pool acknowledged it. A BLOCK FOUND followed by a stratum-side share rejected ack means false-positive UI — the UI fires before pool confirmation. Save the log for evidence.

Escalate publicly with documented evidence. If the pool stayed silent or denied the block beyond 24-48 hours, post on the Kaspa community forums, Twitter/X, and the pool's social channels. Include block height, block hash, coinbase address, your wallet address, timestamp screenshots, pool dashboard screenshots, your worker name. The Kaspa community is small and reputational damage is the main enforcement mechanism — this works more often than people expect.

Migrate to a stronger pool. If your current pool either lost the block, reorged on you above community norms, or paid out late: switch to a pool with proven payout reliability. WoolyPooly, F2Pool, Kryptex are the largest and have a public history of paying solo blocks promptly. Acc-Pool and Hash-Pool are smaller but well-regarded. Smaller solo pools with sketchy fee structures and no public payout history are the highest-risk choice for IceRiver operators going for the lottery.

Run your own Kaspa node and stratum bridge for true solo. If you are committed to solo mining and want to eliminate pool-routing risk entirely: run kaspad on a server, run a stratum bridge that constructs block templates with your wallet address as the coinbase recipient, point your IceRiver at that bridge. You eat your own block reward 100% — but you eat your own orphan rate too, and global broadcast latency depends on your node's connectivity. Reputable bridges: katpool, kStratum, kaspoold.

Configure failover correctly. Multi-pool failover on the IceRiver Web UI is two pool slots, primary and backup. Set primary to your preferred Kaspa pool and backup to a different well-reputed pool — never two pools from the same operator (they share broadcast infrastructure, so a primary failure usually takes the backup with it). Different operators give you independent broadcast paths. Especially important on Canadian residential ISPs with unreliable peering to certain regions.

Set up explorer-driven balance alerts. Tools like kaspascan.io and the Kasware extension can ping you when your wallet address sees an incoming transaction. Configure this so you do not have to refresh the wallet manually for hours after a block-found notification. A 5-second push alert beats a 30-minute panic. Also helps with future block events — you find out from the chain, not the dashboard.

When to ask D-Central. Hardware-side: per-board hashrate stable, Web UI clean, Temp1/Temp2 in band, but you have taken three reorg or false-positive losses in a month — book a bench check. We test the hashboards under load, verify chip count matches nameplate, confirm the firmware is shipping correct stratum job acknowledgments. Pool/wallet-side: if you are stuck on a missing-payout dispute, open a D-Central support ticket — we have walked dozens of Kaspa-payout cases and can usually identify the failure stage faster than the pool's own support.

What D-Central does on the bench. Test fixture with programmable load, per-chip enumeration on the hashboard, kHeavyHash burn-in for 6 hours against a controlled stratum bridge with known wallet routing. We confirm the miner is producing valid, broadcast-ready shares — and that the IceRiver Web UI's block-found logic is not drifting on a particular firmware build. Canadian bench, no shipping-to-China customs lottery, bilingual EN/FR support.

Ship safely. Pack the hashboards in anti-static bags, double-box with at least 5 cm of foam on every side. Include a note with: observed block-found-but-not-credited timeline, firmware version, pool URL, wallet address, and your contact info. Saves us diagnostic time, which saves you money. Book at https://d-central.tech/services/asic-repair/ — typical turnaround 5-10 business days, ships back from anywhere in Canada or the US.