Choose an XBT mining pool by checking how it accepts work, calculates rewards and handles failures. A low advertised fee is useful only when the connection method, payout rules and operational requirements fit your setup.

Use the BlakeStack pool comparison to find the current published terms and their source links. This guide explains the questions behind that comparison. It does not rank a universal best pool or promise a return from mining.

Confirm the network and your mining setup

Check that the operator explicitly mines the Bitcoin BLAKE2b chain. A BTC or XBT label alone is ambiguous. You also need compatible BLAKE2b hardware or software; an ordinary SHA256d miner cannot produce valid work for this network.

Read the operator's instructions for your exact device, firmware and gateway. The network mining documentation explains why the node and mining stack must understand the BLAKE2b rules. Confirm that a test connection produces accepted work before committing a larger setup.

Decide between shared and solo mining

In a shared pool, eligible work contributes to a reward-sharing scheme. With solo mining through an operator, your reward depends on finding a block yourself, subject to that service's terms. A pool connection does not make solo rewards arrive regularly.

Ask what a submitted share means for that pool's payout method. Names such as TIDES or PPLNS need an accompanying description of the work window, weighting and treatment of earlier shares. You want to understand what happens when the pool finds a block, when you disconnect and when you change payout addresses.

B2Pool's explanation illustrates a shared rolling work window alongside a separate solo offering. Use that operator's description for its own products; do not assume another pool uses an identical window because its payout label sounds similar.

Compare the complete fee arrangement

Record the fee for the connection mode you will actually use. DATUM, ordinary Stratum and fallback modes may have different terms. Also check whether a zero fee is permanent, a launch offer or subject to an announced change.

For example, a 1% fee on a hypothetical 0.01 XBT allocation is 0.0001 XBT. That calculation compares the fee alone. It does not account for whether your work qualifies, when the pool finds blocks or when the allocation becomes spendable.

If published terms conflict or a fee is missing, treat it as a question for the operator. BlakeStack preserves unknown and provisional values instead of turning them into a zero.

Separate payout thresholds from coinbase maturity

A minimum payout determines whether the operator creates a payment or includes an output. Coinbase maturity determines when coins created in a block reward can be spent. Direct payment in the coinbase can therefore reach your address before it is spendable.

Ask whether amounts below the threshold carry forward, remain eligible only within a work window, or are handled another way. Ask what happens to a small allocation when you stop mining. Those details matter more than a threshold number without its surrounding rules.

As checked on 8 October 2026, Knots 29.4.2 distinguishes block consensus from wallet and mempool policy. While the long-maturity deployment is active, coinbases created at or after height 973,440 require 6,480 confirmations for block consensus; older coinbases retain the 100-block rule there. That node version's wallet and mempool apply 6,480 to every coinbase. The deployment has a stated height window, so check the current rules rather than extrapolating a permanent waiting period. See the developer documentation and versioned consensus implementation.

Block counts do not guarantee an exact number of days. Ask the operator how its payout process interacts with these rules and the wallet you intend to use.

Check what DATUM support actually gives you

DATUM lets a miner's node participate in constructing the block template, including transaction selection. A pool's DATUM support and your own use of a gateway are separate questions: determine who runs the node, who builds the template and what happens when that node is unavailable.

The CONVOY gateway repository describes the gateway architecture. Omega's connection instructions provide an operator-specific example of running your own node and gateway. Confirm the supported build and configuration for the pool you choose.

Plan failover and check transparency

Before connecting, write down the answers to these questions:

  • Which endpoint and connection mode will receive my work?
  • Who constructs the template during normal operation and during failover?
  • Does failover change the fee or reward arrangement?
  • How can I check accepted and rejected shares, payout outputs and found blocks?
  • Where does the operator announce changes and answer support questions?

A published block record and a clear payout explanation help you check an operator's claims. Neither removes the need to monitor your own gateway and miner. A single accepted share proves connectivity at that moment, not sustained performance.

Make a shortlist you can recheck

Start with your requirements, then use the pool comparison to compare the sourced terms. Its listings are a limited editorial selection, not live measurements of every pool's hashrate, uptime or results. The methodology page explains how sources and uncertainty are presented.

Keep the operator's current instructions and your chosen connection mode with your notes. Recheck them after a node upgrade, fee announcement or payout-address change. Choose a setup you can operate and verify consistently, then judge it from accepted work and actual payout records.