Binance Pool will close on November 10: what miners need to change
Source report: 2026-10-13 · Editorial analysis published: 2026-10-13
Binance’s October 13 notice sets a November 10, 07:00 UTC cutoff for pool connections and related services. Miners should migrate beforehand; historical pages are scheduled to close on November 24.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
The deadline is for connections, not just a website menu
Binance announced on October 13 that its pool and associated savings, cloud mining and transaction-acceleration services will end on November 10 at 07:00 UTC. Stratum endpoints, pool APIs and notifications are included. Shares arriving after the cutoff will not be credited. This is an announced future closure; the notice expects normal operation until the applicable deadline.
The deadline is 09:00 in Kyiv on November 10, after the autumn clock change. Binance requests relevant account-verification steps by 23:59 UTC that day. Historical pages are scheduled to remain available until November 24 at 07:00 UTC. Final eligible rewards and refunds depend on product terms and account status; the announcement promises no universal settlement amount or payment date.
Make an inventory before changing a fleet
For a farm operator, the first practical step is an inventory of active connections. Record each miner’s model, firmware, local management address, current pool URLs and worker identifier. Include devices that restart automatically after an outage: a forgotten old configuration can reappear when power returns. Preserve a dated copy securely before editing, rather than relying on memory or the current dashboard view.
Our suggested migration worksheet has separate columns for the device, physical location, intended destination and verification result. It should identify who changed a setting and when. This is an operational recommendation by ASIC.tools, not an extra Binance requirement. A small farm can use a spreadsheet; a larger installation needs a controlled process that avoids editing the same machine from two management tools at once.
Changing pools usually means changing configuration
BITMAIN’s S19/S19 Pro setup guide describes entering a pool URL and a worker identifier in the miner configuration, saving the settings and checking the dashboard. That is a model-specific example, not an instruction to install S19 firmware on other devices. Use the documentation for the actual miner and the destination pool’s current connection settings, including the required algorithm, hostname, port and worker format.
Pool migration should not be confused with a firmware upgrade or factory reset. A new pool does not by itself justify flashing a control board, replacing its software or erasing its network configuration. If the existing firmware supports the required connection, change the relevant fields first. Treat any separate compatibility problem as a separate maintenance task, with its own model-specific instructions and rollback plan.
Test one device and verify accepted work
Begin with a representative device during a period when somebody can inspect it. After saving the new connection, check both the miner and the receiving pool. A fan running or a normal local hashrate reading does not prove that the destination accepted work under the correct account. Look for the expected worker, accepted shares and a sensible trend over the pool’s stated reporting interval.
If the destination shows no worker, compare the exact hostname, port, algorithm and identifier before touching hardware. Preserve relevant logs and error messages. Do not repeatedly switch pools in response to every short dashboard delay: the time window matters. The goal of the test is to establish a known working configuration that can be reproduced on similar devices, while documenting any models that need different handling.
Audit backup slots and monitoring integrations
Where a miner supports several pool entries, inspect every configured slot. A successful primary connection can hide a stale backup until the first destination becomes unavailable. Replace retired Binance entries deliberately, according to the miner’s documented failover behavior. Do not assume all three URLs use independent infrastructure simply because their names differ; check how the selected pool describes its regional and backup endpoints.
Also review the systems outside the miner itself. A farm may use a pool API for dashboards, an email rule for offline alarms or a Telegram alert for hashrate changes. These can fail when the associated service ends even though the hardware has moved successfully. Reconnect monitoring to verified data from the new destination, then test an alert deliberately so a silent dashboard is not mistaken for a healthy farm.
Quantify downtime without pretending it is a forecast
Consider a purely illustrative migration test: a device has an assumed gross earning rate of $5 per day and is unavailable for two hours. The foregone gross amount in that simplified scenario is $5 × 2 / 24, or about $0.42. This is arithmetic, not a quoted Binance reward, measured miner profitability or promised future payment. Actual earnings fluctuate with network conditions, fees and the settlement scheme.
The same worksheet should distinguish lost gross revenue from net operating cost. An idle miner may still draw electricity; a fully powered-off device behaves differently. Compare the meter and the actual outage duration rather than substituting nameplate power automatically. For a fleet, multiply only after checking which machines were affected. This makes a staged migration review useful without presenting an unsupported single loss figure for every operator.
Keep payout records separate from equipment status
Export the records needed to reconcile completed work before historical access disappears. Save the period, credited rewards, transfers and any relevant account notices, and keep copies in a private location. A machine appearing online at another pool does not explain a remaining balance at Binance. Conversely, a final payment does not prove that every device has left an obsolete Stratum endpoint.
For Pool Savings or Cloud Mining, use the applicable product process rather than treating a balance as a hardware setting. The closure notice asks users to redeem active savings positions and make their accounts eligible for remaining settlements. If a particular account has restrictions or an unresolved discrepancy, obtain an account-specific answer through official support. Do not infer settlement rights from another user’s screenshot or a social-media deadline summary.
A practical completion check
A migration can be marked complete when the inventory is reconciled, intended workers submit accepted work, obsolete endpoints are removed from applicable backup slots and monitoring produces usable signals. Retain the date and evidence of those checks. If a device is deliberately offline, record that explicitly and ensure its next start will use the revised configuration, so it does not silently return to a retired destination.
Use the source notice again near the cutoff to check for amendments. This article preserves the October 13 announcement and explains an operator workflow; it does not announce that Binance has already stopped mining connections. The closure concerns one service provider. We have no verified basis here to claim a particular reduction in global Bitcoin hashrate, a change to block rules or a guaranteed improvement in profitability at a replacement pool.
Source: Binance ↗ · BITMAIN S19/S19 Pro setup guide ↗
Mining calculator ↗
