Bitcoin Pool Review: What Solo Miners Can Check

Your miner does not need a username, an account balance, or a promise about returns. It needs a Bitcoin address and a place to send work. This Bitcoin pool review looks at the parts that matter when you mine solo: where a winning block pays, how fresh work reaches the rig, and what evidence you can inspect before you point hardware at a server.

Solo mining is a lottery. Network difficulty sets the odds at every pool. Your hashrate sets your share of those odds. A pool cannot add luck, schedule a win, or turn a lower expected wait into a guaranteed result. It can only handle the path between your rig and the Bitcoin network without losing work or putting a reward under its control.

NexusPool (nexuspool.io) is a non-custodial Bitcoin solo mining pool operated by SweetHash. A miner connects to solo.nexuspool.io:3350 with a Bitcoin address. There is no account, sign-up gate, or KYC step. The same port accepts Stratum V1 and encrypted Stratum V2.

What a Bitcoin Pool Review Should Actually Test

A solo pool review should not start with a block count, a lucky story, or a projected payout. None tells you when your own rig will find a block. Start with a narrower question: if your rig finds one, can you see where the whole reward will go and how the pool carries that result to the network?

There are four useful checks: payout construction, new-work timing, share handling, and block submission. They answer different failure modes. A direct payout does not prove the pool reads a share correctly. Fast job creation does not prove a found block is submitted again after a restart.

Check the payout before a block exists

A non-custodial solo payout is not a balance displayed on a website. It is an output in the block coinbase transaction that pays the address your miner supplied. The subsidy and transaction fees belong in that transaction. If the address is right, the reward lands there when the block is accepted.

Payout Preflight shows the miner a payout built for that address on the current block before the rig finds anything. This is the useful kind of preview because it concerns the actual destination, not an estimate of future income. Transaction fees vary by block. The displayed amount can change when the next block template changes. The destination should not be ambiguous.

The pool states a 0% pool fee for Bitcoin solo mining. The check that matters is still the constructed payout. A fee claim written on a page is weaker than inspecting the transaction path the miner would use.

Check whether the rig receives new work promptly

Mining on an old block is not the same as mining on the current tip. Once another block arrives, old work has less value because a valid result may build on a stale chain. A pool cannot stop the rest of the network from finding blocks. It can prepare and send the next job quickly.

On the Frankfurt server, the median time from receiving a block header to making work available was 0.49 ms across 162 mainnet blocks on September 10 and 11, 2026. That work was ready 205 ms before the pool node completed validation. The first job carried no transactions because transaction selection waits for validation.

That limitation matters. A header-first job is about reducing time spent on old work, not about promising the final transaction set instantly. It also describes Frankfurt, those dates, that sample, and Bitcoin. It does not describe every region forever, Bitcoin Cash, or Litecoin.

For a home miner, the practical check is simpler. Connect the rig and watch whether its log receives clean job updates. If you live far from Los Angeles, Chicago, Frankfurt, or Singapore, network distance adds round-trip time. It changes how quickly jobs and statistics reach the rig. It does not change the odds of finding a Bitcoin block.

Check what the pool says about rejected shares

A share is evidence that a miner worked on a job. Most shares are not blocks. A useful pool tells the rig why it accepted or rejected a share instead of leaving an operator to interpret a generic failure.

The pool reads each share in the form the firmware sent and records a reason for each share it reads and rejects. That distinction is deliberate. A malformed encrypted Stratum V2 submission that cannot be read gets no reply. There is no meaningful share result to send back.

Difficulty changes can confuse small miners when a device pauses, reboots, or loses Wi-Fi. The pool holds a rig's assigned difficulty when it goes quiet for a few minutes. When the rig returns, it can resume at the prior difficulty rather than receiving a needless adjustment immediately. This does not alter block odds. It reduces avoidable churn in the connection behavior.

Small-farm operators should test the details their fleet exposes: rejected-share reason codes, reconnection behavior, and which region receives the connection when a local path fails. A claim about handling shares is only useful when the rig log gives an operator something to compare against it.

Bitcoin Pool Review: Follow a Found Block

The winning event is rare. It is also the event where a vague description is least acceptable. A review should ask what happens after a valid block candidate reaches the pool, not just whether the dashboard recognizes it.

A block found through Los Angeles, Chicago, or Frankfurt is written to disk first. It is then sent to Bitcoin nodes in all three cities. Each delivery is retried for up to five minutes. If the pool restarts with a pending block, it submits that block again.

Singapore has a different path. A block found through Singapore is sent to its own node only. That is not a defect hidden by a broad claim about global propagation. It is a boundary worth stating because a miner should know which mechanism applies to a connection.

Writing first and retrying after a restart address mundane risks. A found block should not depend on a value that exists only in memory during one process lifetime. Multi-city delivery in the three named regions gives more than one route toward the Bitcoin network. It does not guarantee acceptance. Bitcoin nodes still apply consensus rules, and another valid block can arrive first.

That last point is the part marketing usually skips. A pool can preserve and submit the block your rig found. It cannot make the network choose it over a competing valid block.

The Connection Test Comes Before the Story

For a Bitaxe, NerdQaxe, Avalon Nano, or a standard Stratum V1 ASIC, the first test is not complicated. Enter your own Bitcoin address as the worker identity. Set the server to solo.nexuspool.io:3350. Save the settings and read the device log until it shows an authorized connection and accepted work.

Use the address you control. A typo cannot be fixed after a block is mined into Bitcoin. If your firmware supports encrypted Stratum V2, the same port accepts it. Stratum V1 remains available for hardware that does not yet support V2.

Do not treat a clean connection as a forecast of income. It only confirms that the rig can receive work and submit shares through that path. The lottery remains a lottery after the green status light turns on.

Technical operators can inspect the additional evidence layer. The pool signs an hourly receipt for the work it counted from each rig with a published key. One receipt covers one rig for one hour. It does not represent a single share. Los Angeles also timestamps new receipts in Bitcoin. Any BIP340-capable library can verify a receipt against the published key.

Receipts are not the first thing a home miner needs to read. They are useful when an operator wants an independent record of what the pool counted during a particular hour. The scope matters as much as the signature.

What This Review Cannot Tell You

No Bitcoin pool review can tell you when a solo miner will hit. A lower network difficulty means a shorter expected wait. It does not mean more value, and an average is not a schedule. A rig can find a block early, late, or never during the period you choose to run it.

It also cannot turn a distant network path into a local one. Miners in Australia, South America, or Africa may see a longer round trip to the available regions. Test the connection from your own network instead of borrowing someone else's latency result.

The useful standard is modest. Know the address in the coinbase payout. Know what new-work measurement applies and where. Know what the pool says when it rejects work. Know how it stores and submits a found block. Then connect one rig and check the behavior you can see.

Trust nothing. Verify your payout before you mine.