Why Is My Mining Pool Not Paying? Balance, Payout, and Wallet Checks

A mining pool can record rewards before it sends a payment to your wallet. When an ASIC appears to be earning but no payout arrives, identify the last completed stage: accepted work, credited balance, payout eligibility, payment sent, or wallet receipt. Check the account and coin first, then the payout record. That sequence tells you whether to investigate mining configuration, wait for a documented condition, or contact the pool or wallet provider.

Locate the missing stage before changing anything

Open the pool account that actually receives your miner's work. Match the coin, mining account, worker name, and active endpoint. A backup pool may hold part of the revenue after failover; looking only at the primary account leaves that work out of your investigation. If the worker is absent from the intended account, use the pool URL, worker name, and failover setup guide to audit where it is submitting shares.

Once the correct account shows work and rewards, use the table below as a triage worksheet. The actions are an investigation sequence, not a promise that every pool uses these exact status names.

What you can verify	What remains unproven	Next check
Miner reports accepted work	Credit to the intended account	Match worker and active pool with account records
Pool shows estimated revenue	Settled, withdrawable balance	Read the account's settlement definitions
Available balance exists	Eligibility for this payout cycle	Inspect threshold, schedule, destination, and holds
Pool shows processing	Broadcast or successful payment	Read the payout detail and reference
On-chain transaction exists	Confirmation and wallet credit	Match the destination output and transaction state
Transaction is confirmed	Provider has credited your account	Check receiving-service requirements and contact it

Save the status text and the time you observed it before editing settings. A screenshot taken after several changes is much less useful for explaining the original failure.

Separate earned rewards from withdrawal conditions

An estimated daily reward, a settled balance, and a paid total describe different events. Do not compare an estimated earnings tile directly with your wallet balance. If the confusion begins with how rewards are calculated, the FPPS, PPS+, and PPLNS comparison explains the accounting and variance differences; your chosen pool still defines when those rewards become withdrawable.

For example, Braiins' payout documentation distinguishes financial accounts, reward splits, and payout rules. A split can leave money in a different financial account from the one you are checking. A payout rule can depend on a threshold or a schedule, and rules are evaluated in a payment cycle. Crossing your selected balance threshold therefore does not establish that a payment has already been sent.

Copy the following details from your own account rather than another miner's screenshot:

• Coin and receiving network.
• Available balance in that coin, excluding estimates unless the pool explicitly includes them.
• Selected threshold, minimum allowed withdrawal, and any payout fee.
• Next eligible payout cycle, expressed in the pool's stated timezone.
• Destination activation status and any pause or security hold.

Keep the minimum withdrawal and the fee-free threshold in separate fields. They answer different questions. Read the current account terms before lowering a threshold, especially if a fixed fee would consume a material part of a small payment.

Check holds and address changes without restarting the clock

f2pool's unpaid-reward troubleshooting page lists insufficient balance, payout pauses, inactive addresses, and restrictions after an address change among the reasons for a missing payment. It directs users to the exact date shown in Payout Settings. Treat that account-specific release time as the starting point for an inquiry; avoid borrowing a generic delay from an older guide.

Record the last authorized destination change and compare the full saved address with the receiving wallet's instructions. Repeatedly replacing an already correct destination can complicate diagnosis and may trigger another security restriction. If the destination is unfamiliar, preserve the evidence and use the pool's official account-security and support process promptly.

Separate two questions in your notes: “When may this account pay?” and “When should this particular payment arrive?” A hold answers the first. A payment reference lets you investigate the second.

Follow the payment reference to the receiving side

For an on-chain Bitcoin payout, open the transaction ID from the pool's payout record. Check that the transaction exists, contains an output to your expected address, and shows the expected amount after the stated payout fee. If the transaction contains several recipients, compare your output rather than the entire transaction value.

Broadcast and confirmation are separate events. The Bitcoin payment FAQ explains why confirmation takes time and why receipt notifications do not provide the same assurance as confirmed payments. Do not turn an average block interval into a deadline for your payout. A transaction can remain unconfirmed while the wallet or receiving service applies its own acceptance policy.

If the right output is confirmed but a custodial service has not credited it, collect the transaction ID and its deposit requirements before contacting that service. With a self-hosted full-node wallet, check synchronization through the wallet's normal interface. Avoid deleting wallet data as an initial troubleshooting step.

A Lightning payout follows a different path: use its payment status and the receiving wallet's Lightning instructions. An invoice or Lightning address is not an on-chain Bitcoin address, and searching for an ordinary blockchain transaction ID will not diagnose a Lightning payment. Check invoice validity, receiver availability, and whether the pool recorded success, failure, or a return to the balance.

Build a support packet that answers the next question

Use this original worksheet to make the handoff specific. Leave unknown fields blank rather than guessing. Keep account identifiers and payment details private; send them only through the relevant provider's verified support channel.

Field	Evidence to attach	Question it resolves
Account, worker, coin, active pool	Relevant account record	Are we investigating the right earnings?
Observation time and timezone	Timestamped status capture	Which settlement or payout cycle applies?
Available balance and threshold	Current payout settings	Was the account eligible?
Hold or destination activation	Exact notice and release time	Is a documented restriction still active?
Payment record	Status, amount, reference, destination	Did the pool initiate this payment?
Receiving-side result	Confirmation or Lightning status	Which provider can resolve the remaining step?

Ask the pool to explain a missing payout record or an unresolved eligibility restriction. Ask the receiving provider about a correctly addressed payment that meets its acceptance rules but remains uncredited. If no one can establish that a payment was sent, keep that uncertainty explicit instead of describing it as a wallet failure. Never include a seed phrase, private key, login password, or authentication code in this packet.

Next step: complete one row for the last stage you can prove, then collect the evidence needed for the very next stage. Change a setting only when that evidence identifies a specific mismatch.

How frequently should a small miner withdraw?

After resolving the incident, consider whether the current payout arrangement still fits your operation. More frequent withdrawals can reduce the balance left with a pool, while fixed withdrawal fees can make small payments expensive. Lightning adds a receiving setup whose availability and compatibility need attention. A higher threshold can reduce payment frequency but leave more rewards waiting in the account.

There is no universal best interval. Compare your actual credited rewards, the fees shown by your provider, and how much unpaid balance you are comfortable leaving there. Revisit that choice when your hashrate allocation or receiving wallet changes, and retain a dated private record of the rules you relied on.

Frequently asked questions

Why does my ASIC show accepted shares but my wallet is empty?

Accepted work is earlier in the process than a wallet payment. Confirm that the intended pool account sees the worker, then check credited rewards, available balance, and payout eligibility. An account may still be waiting for settlement or a payout condition. Record the last stage you can verify before changing miner settings; those settings cannot explain every later payment or wallet-crediting issue.

Should I lower my payout threshold to get paid sooner?

Read the minimum withdrawal, selected threshold, payout schedule, and fee rules first. A lower threshold may change eligibility, but it does not establish when a payment will be processed or remove an account hold. Check whether a fixed withdrawal fee makes the smaller payment unattractive. Save the original settings and change them only after identifying the specific condition that is blocking your payout.

Can changing my payout address delay payment?

Some pools apply a security restriction after a destination change. Look for the exact notice and release time in your account instead of assuming a universal waiting period. Confirm that the saved destination is correct and activated, then avoid repeated edits merely to test whether payment resumes. If you did not authorize the change, preserve the record and use the provider's official security process.

The pool says paid. Why has the wallet not credited it?

Open the payment record and identify the receiving network. For an on-chain payout, verify the transaction, your destination output, and confirmation state. A custodial wallet may apply additional crediting requirements; a full-node wallet also needs current synchronization. Gather that evidence before contacting the receiving provider. If the pool cannot supply a usable payment reference, ask it to clarify what its paid status means.

Does restarting the miner fix a missing payout?

A restart does not resolve a balance threshold, account hold, or receiving-service crediting rule. Use miner troubleshooting when evidence shows the worker is submitting to the wrong account or not delivering accepted work. When rewards already appear in the correct account, follow the payout record instead. Unnecessary configuration changes can obscure the evidence without answering why the existing balance has not reached your wallet.

What information should I send to support?

Provide the account or worker identifier through the official support channel, the coin, observation time and timezone, relevant balance and payout settings, exact status notice, and payment reference if available. State the last stage you verified and the next stage that remains unknown. Include receiving-side evidence where useful, but keep seed phrases, private keys, passwords, and authentication codes out of every screenshot and message.