A Bitcoin mining pool switch is safest when treated as an operational migration, not just a URL change. Before redirecting ASICs, preserve old-pool records, verify the destination’s Stratum settings, and confirm both shares and payout details after the move. This is especially relevant for miners responding to the reported SBI Crypto pool closure.

Reports stated that SBI Crypto’s mining-pool service would close on July 31, 2026, and stop accepting mining shares at 07:00 JST on July 31, or 22:00 UTC on July 30. The difference matters: the service date is July 31 in Japan, while the UTC cutoff falls on July 30. Schedule configuration changes using the time zone shown on your devices and at your facility.

What happened to the SBI Crypto mining pool

The SBI Crypto pool closure creates a practical task for miners: redirect active hashrate, preserve account records, and establish a working connection elsewhere with minimal downtime.

Blockspace Media, citing Hashrate Index data, reported a seven-day average of 20.9 EH/s and roughly 2.2% of Bitcoin network hashrate as of June 30, 2026. That is dated context, not a current network-share figure, but it helps explain why a coordinated migration could affect pool dashboards and support queues.

Reporting did not provide a public reason for the closure. Avoid assigning a motive without direct evidence. Focus instead on configuration, settlement, and recordkeeping.

Closure time: July 31 JST and July 30 UTC

For your migration plan, record both reported times:

• Reported service closure date: July 31, 2026, JST.
• Reported share-acceptance cutoff: 07:00 JST on July 31, 2026.
• Equivalent reported UTC cutoff: 22:00 UTC on July 30, 2026.

Do not assume that a miner, firmware panel, farm-management system, and pool dashboard use the same time zone. Label the cutover time in the local time used by site operators. For distributed fleets, maintain a shared UTC runbook alongside each site’s local schedule.

Make the change before the cutoff where possible. That gives you time to find incorrect worker formatting, unreachable ports, or unexpected rejection rates while the prior configuration is still available for reference.

Preserve records before changing anything

Save the current state before editing a miner or farm-management template. A copy of the old setup speeds up troubleshooting and can help reconcile a Bitcoin mining pool payout after cutover.

At minimum, preserve:

• Worker names and worker-to-machine mappings.
• Wallet addresses and configured payout destinations.
• Payout history, balance screenshots, transaction identifiers, and available exports.
• Pool-side hashrate and worker-status screenshots.
• Miner IP addresses, firmware versions, pool URLs, ports, usernames, passwords, and failover order.
• Farm-management templates, custom settings, and monitoring thresholds.

Before changing settings, check the former pool’s official notice, account dashboard, and support channel for final-payment timing, minimum payout thresholds, treatment of unpaid balances, remaining account access, and tax or export records. Do not assume a final-payment policy unless it is confirmed through an official SBI source or your authenticated account.

Keep these records in access-controlled storage. Wallet addresses and account exports can create financial and security exposure if shared casually.

How to change mining pool settings safely

A controlled migration reduces the risk of a fleet-wide typo, incorrect payout address, or unsupported endpoint. Start with a small representative group of miners when feasible, then expand once the test group is stable.

Verify the Stratum mining configuration

Obtain the new pool’s Stratum endpoint, port, worker format, and password requirements from official documentation or an authenticated dashboard. Do not rely on an endpoint copied from a chat message, search snippet, or unofficial mirror.

Then follow this sequence:

1. Save or export the current configuration from each miner or management platform.
2. Record the old primary and backup pool entries for rollback.
3. Enter the verified new Stratum URL, port, worker name, and password.
4. Confirm the worker format exactly. A pool may require an account identifier plus a worker suffix, while another may use a wallet address or a different convention.
5. Enter or confirm the intended payout address in the new pool account before directing meaningful hashrate.
6. Configure backup endpoints only when they are verified and supported by the pool.
7. Save the configuration, then restart or reload the miner if required by the firmware.
8. Watch the miner log and pool dashboard for connection status, accepted shares, rejected shares, and reported hashrate.

For a pool-specific example of the details to verify, ViaBTC’s mining setup guidance covers the mining URL, username, password, payment method, and monitoring workflow. Reconfirm endpoints and payout settings at the time of migration.

Keep a rollback path

Do not overwrite the old configuration without saving it. If the new dashboard does not report accepted shares after a reasonable stabilization period, compare the miner log with the new pool’s official setup instructions. Rollback can limit downtime while you isolate a URL, port, DNS, firewall, worker-format, or firmware issue.

Verify the new pool connection and payout destination

A worker shown as online is not enough to confirm a successful migration. It may only show that the miner connected; it does not prove that the correct account and payout destination are receiving valid work.

Validate all of the following:

• The configured payout address matches the intended address character for character.
• Active hashrate on the miner is consistent with normal operation.
• The dashboard shows accepted shares, not only submitted or attempted shares.
• Material increases in rejected shares are investigated.
• Pool-side reported hashrate stabilizes after the pool’s stated reporting interval.
• Worker names match the machines you expect to see.
• A Hashrate Alert or rejection-rate alert is enabled where available.

ViaBTC supports dashboard-based hashrate and rejection-rate notifications by email or Telegram. Alerts help turn an unnoticed worker outage or elevated rejection rate into an actionable event, shortening the time between a configuration problem and a response.

PPS, PPS+, and PPLNS: the payout-method differences that matter

PPS versus PPLNS is not simply a choice between “better” and “worse.” These methods allocate payout timing, pool risk, transaction-fee treatment, and variance differently. Compare current terms for the specific coin and pool before estimating returns.

PPS

Pay Per Share (PPS) generally pays a defined value for valid shares based on network difficulty and the pool’s rules. The pool typically takes on more block-discovery variance. This can make payout patterns more predictable, but fees and transaction-fee treatment vary by pool.

PPS+

PPS+ generally combines PPS-style treatment for the block subsidy with a separate method for transaction fees. The calculation, timing, and fees are pool-specific. For example, a pool may distribute transaction-fee revenue using a PPLNS-style calculation, but miners should verify the current policy rather than infer it from the label.

PPLNS

Pay Per Last N Shares (PPLNS) allocates rewards based on shares in a recent window. Results can be more variable because they depend on block timing, pool luck, participation through the window, and the pool’s implementation. A miner that switches away quickly may have a different outcome from one that remains active through the relevant share window.

When comparing methods, verify the current fee schedule, minimum payout, payment frequency, transaction-fee policy, and any participation or reward-window rules. No pool migration guarantees higher income. Net results depend on pool fees, payout method, applicable luck or variance, downtime, rejected shares, latency, BTC price, network difficulty, transaction fees, and electricity cost.

Common pool-switch mistakes to avoid

The most expensive errors are usually operational. Avoid these common mistakes during a Bitcoin mining pool switch:

• Changing all machines at once without testing a representative miner first.
• Copying an unverified Stratum endpoint or using the wrong port.
• Reusing a worker format that the new pool does not accept.
• Failing to save the previous machine settings and backup-pool order.
• Treating “online” as proof of valid shares and correct payout routing.
• Ignoring rejected-share increases caused by latency, configuration, or connectivity issues.
• Assuming that an old pool will automatically pay every remaining balance without checking official instructions.
• Comparing advertised revenue without accounting for fees, payout terms, downtime, and electricity cost.

Final cutover checklist

Before completing the migration, confirm that:

• The new pool endpoint, port, worker format, and payout address were verified from an official source.
• A representative group is submitting accepted shares at expected levels.
• Pool-side hashrate has stabilized after the stated reporting interval.
• Hashrate Alert and rejection-rate notifications are enabled where available.
• The former pool’s records, payout details, and available exports are safely stored.
• Final settlement terms and account-access deadlines are confirmed through official SBI channels.

After the switch, review the new dashboard at the pool’s stated reporting interval, confirm the payout address again, and retain old records until former-pool settlement and accounting needs are resolved.