A mining pool payout address change is complete only when the intended destination is active and a subsequent payout is reconciled—not when a new wallet appears in an address book. First identify whether rewards belong to a pool account or to the address used for mining. Then check the applicable payout rule, any security hold, and the receiving service’s current deposit requirements.
This guide is a change-control checklist for an existing operation. It is not a pool recommendation, a wallet recovery service or a promise of uninterrupted payments. No customer account was changed to prepare it. Pool documentation was checked on November 4, 2026; account-specific notices should be checked again when a change is made.
Separate the machine from the payment destination
Keep three records separate: the physical miner, its pool connection identity, and the destination for its rewards. An equipment record such as Antminer S21 XP identifies hardware, not ownership of a pool balance. Replacing a machine, changing a worker label or handing equipment to a hosting operator should not silently become a payment-routing change.
For account-based mining, review the selected account or subaccount before editing its payout settings. For address-based mining, the address may also identify the mining record. f2pool distinguishes those two modes in its support guide. Do not assume that an account-wallet editing procedure also transfers an address-mining balance.
Write down the intended scope before touching settings: which account, which asset, which destination, and which operator is responsible. For a fleet, explicitly name the accounts that must remain unchanged. This prevents a correct address from being installed on the wrong customer’s account.
| Record | What to identify | What it does not prove |
|---|---|---|
| Equipment | Model, inventory ID and assigned worker | Who controls accrued rewards |
| Mining account | Pool, account or subaccount, asset | Which saved wallet is the active destination |
| Payout rule | Destination, network and trigger | That the receiver has credited a payment |
| Payment receipt | Amount, time, transaction or settlement reference | That future payments will follow the same rule |
Save a useful before-change record
Create a restricted change note with the current destination, pending balance, last payment reference and the reason for the change. Record the time zone. A screenshot with no account context or timestamp is difficult to compare later, especially when different operators work across shifts.
Use a fresh receiving address supplied inside the intended wallet or deposit account. Independently check the complete destination after pasting it. Keep the asset and network visible in the note; a familiar ticker alone is insufficient. For the separate XBT naming problem, use our BTCB2, XBT and deposit-network guide, rather than applying Bitcoin assumptions to another chain.
For team operations, have a second person compare the intended receiver with the proposed change. This is an operational recommendation, not a claim that every pool offers dual approval. Keep seed phrases, private keys, recovery codes and session tokens out of tickets, screenshots and handover documents. A support request should explain the discrepancy without giving away control of the wallet.
Check the active rule, not just the saved wallet
Braiins documents a distinction between saved wallets and a Financial Account’s payout rule. That rule selects the destination, network and trigger. Its payout lock restricts destination changes; unlocking uses a wallet signature handled through support. See the Braiins payout FAQ.
The practical check is to reopen the active configuration after any confirmed change. Compare it with the approved note. Verify that unrelated thresholds, schedules and account selections were not altered accidentally. Do not remove account protections just to complete a checklist faster. If a lock or confirmation requirement prevents the intended change, stop and use the provider’s documented process.
A hardware maintenance contractor does not automatically need permission to redirect payments. For a hosted mining arrangement, agree on who can change connection settings, who controls payout settings and who checks receipts. These are separate responsibilities, even if one person currently performs all three.
Treat conflicting hold periods as an unresolved detail
A fixed “wait one day” instruction would be misleading here. At this review, f2pool’s general support page stated a three-day pause after address changes. Its dated October 2023 adjustment notice instead described a shorter hold and directed users to the wallet-settings resumption time. The public documents conflict; this article does not resolve that conflict by choosing the more convenient number.
Before scheduling a cash-dependent operation, record the actual resumption notice displayed for the affected account. If it is absent or inconsistent, ask support to confirm the applicable rule and retain the response. Distinguish a payout hold from loss of mining connectivity: a delayed payment alone does not identify a hardware fault.
Do not edit an address repeatedly while investigating a delay. Additional changes can make the sequence harder to reconstruct. Record the current state, the last confirmed action and the next check instead of experimenting with live payment settings.
Reconcile the first payment after the change
A practical acceptance record connects the pool’s payment entry to the receiving side. For an on-chain payout, compare the asset, destination, amount and transaction reference on the appropriate network. For another payout method, use its corresponding settlement record rather than expecting an on-chain transaction ID.
| Checkpoint | Evidence to retain | If evidence is missing |
|---|---|---|
| Intended rule active | Account identity and saved active configuration | Recheck scope before making further edits |
| Security hold understood | Applicable notice and resumption time | Ask the pool for clarification |
| Payment released | Pool payment record and reference | Check balance, trigger and payment status |
| Receipt reconciled | Receiver’s matching credited entry | Trace the reference with the receiving service |
| Change closed | Reviewer, timestamp and unresolved exceptions | Keep the change open; do not mark receipt verified |
An exchange deposit marked pending is not the same as a credited balance. Conversely, a pool balance below its payment trigger is not evidence that a sent transaction vanished. Name the actual stage when reporting a problem. For worker-side evidence, our miner versus pool hashrate guide explains a different measurement problem; hashrate should not be used as proof of payout receipt.
Close the record without losing the history
Keep the old destination as a historical reference, not as an instruction to reuse it. Retain the approval, effective change time and first reconciled receipt together. If the first payout has not arrived, leave the status as awaiting verification and assign a next check. That is more useful than a generic “done” message.
For equipment deployment questions, contact LeedMiner with the model, worker assignment and a redacted description of the issue. Keep wallet custody and payment approval with the account owner. This checklist reduces ambiguity; it does not guarantee recovery of funds sent to an incorrect destination or guarantee that a provider will approve a particular change.
