Bitaxe Pools: Where Your Solo Block Pays

A Bitaxe can find a Bitcoin block. That fact does not make the wait predictable. Bitaxe pools decide where your rig receives work, how they read its shares, and where a winning block goes. Network difficulty sets the odds at every pool. Your hashrate sets your portion of those odds.

For a home miner, the useful question is not which pool has the loudest success story. It is whether you can inspect the path between your Bitaxe and your Bitcoin address before a block is found. Solo mining is a lottery. An average is not a schedule.

What Bitaxe pools actually do

Your Bitaxe does not mine a block by itself in isolation. It asks a pool for a candidate block template and hashes against that work. The pool sends new work when the network advances. Your miner sends back shares that show it is doing the assigned work.

A share is usually not a Bitcoin block. It is a result that meets the target the pool assigned to your rig. The pool uses shares to see that the connection is alive and that the miner is hashing. A real block is the rare result that also meets Bitcoin's network target.

This distinction matters when reading pool dashboards. A high share count does not mean a block is due. A quiet hour does not mean the next hour owes you anything. Difficulty changes over time, and the network target defines the result that matters.

A solo pool should not hold a balance for later payout. If your rig finds a valid Bitcoin block, the coinbase transaction should pay the subsidy and transaction fees to the Bitcoin address you supplied. That is the outcome worth checking.

Start with the connection path

For most Bitaxe owners, setup should begin with one concrete thing: the Stratum endpoint and the payout address. A pool that requires an account can place an account record between your miner and the address that receives a found block. That may be acceptable for some mining arrangements. It is not necessary for solo mining.

At NexusPool (nexuspool.io), Bitcoin miners connect to solo.nexuspool.io:3350 with a Bitcoin address and no account. The same port accepts Stratum V1 and encrypted Stratum V2. Most Bitaxe firmware uses Stratum V1, so that is the setting a home miner will usually select.

The address is not a username in the usual sense. It is the destination that matters if your miner finds a block. Use an address you control. Check every character before saving the configuration. A typo does not become harmless because the miner has been running for weeks.

Worker names can still help you identify a device. Name a Gamma in a way you will recognize later, such as its shelf position or serial number. The worker name helps you read status. It should not replace the payout address as the thing you verify.

Check the payout before you need it

The most direct question for a solo miner is simple: if this rig finds the current block, where does the reward land?

A useful pool can answer that before a win. NexusPool's Payout Preflight builds the payout for your address on the current block. It shows the coinbase output your rig would use if it found that block. The check covers the block subsidy and the transaction fees in that block at that moment.

That last condition has a limit. Transaction fees in the next block can differ because the mempool and selected transactions can differ. The block subsidy is set by Bitcoin's rules. The preflight is not a promise about a future block template. It is a checkable construction for the current one.

This is better evidence than a statement that a pool is non-custodial. Read the output address. Compare it with the address in your miner configuration. If you control that address, the block reward has no pool balance to wait in after the block is confirmed.

New work matters more than a pretty dashboard

When another miner finds a block, the previous block template becomes old work. Your Bitaxe needs new work quickly so it spends less time hashing a template that cannot become the next Bitcoin block.

There is a trade-off at the instant a new header arrives. A pool can prepare a first job before its Bitcoin node finishes validating the new block. That first job carries no transactions. It gets miners onto the new height sooner. Later work can include transactions after validation and template construction.

The mechanism should be measurable, not decorative. On NexusPool's Frankfurt server, the median time from a new header to work was 0.49 ms across 162 mainnet blocks on September 10 and 11, 2026. That work arrived 205 ms before node validation on median. The measurement describes that server, those dates, and that sample. It does not promise your home network will see the same time.

Distance still matters. A miner far from Los Angeles, Chicago, Frankfurt, and Singapore has a longer round trip to the pool. That can delay new work and status updates. It does not change the odds of finding a block. Network difficulty and your hashrate still set those.

Ask what happens to shares and a winning result

A small miner may only notice the pool when shares are rejected. Some rejected shares are ordinary. A share can arrive late after new work replaced the old job. A share can fail the assigned difficulty. A malformed message can fail before the pool can interpret it.

The useful standard is a reason you can inspect. A pool should read a share the way the firmware wrote it and tell the rig why it was rejected. Vague red numbers make troubleshooting slower. Specific reasons let you distinguish a Wi-Fi problem, stale work, an incorrect clock, or a configuration error.

Your Bitaxe may also go quiet while you change a fan, reboot firmware, or lose power. If the pool immediately changes its assigned difficulty after a short silence, the first shares after reconnecting can be less useful for reading the rig's behavior. Holding a rig's difficulty for a few minutes avoids that unnecessary reset.

A valid block needs a more careful path than an ordinary share. It should be written to disk before submission. It should be sent to nodes with retries if the first attempt fails. After a service restart, a pending block should be submitted again rather than treated as forgotten work.

For Bitcoin blocks found through NexusPool's Los Angeles, Chicago, or Frankfurt regions, the pool writes the block to disk and sends it to Bitcoin nodes in all three cities. Each submission is retried for up to five minutes. A block found through Singapore goes to its own node. Those are different paths, so they should not be described as one identical global behavior.

Do not confuse pool choice with luck

A lower network difficulty means a shorter expected wait for a given hashrate. It does not mean the block has more value. A higher hashrate means more attempts over time. It does not create a date when a Bitaxe will find a block.

No pool can change the odds set by network difficulty. What a pool can do is avoid wasting the luck your rig already has. It can send new work promptly, interpret submitted work correctly, and carry a valid block through submission without putting the payout in its custody.

That is why a clean setup screen is not enough. Before connecting, inspect the endpoint, confirm the address, and find out whether the pool can show the current block payout. After connecting, watch the reasons for rejects instead of treating them as a mysterious percentage.

Point one Bitaxe at solo.nexuspool.io:3350 only after you have checked the address that would receive the current block payout. Trust nothing. Verify your payout destination.