Bitaxe Stratum Compatibility and Pool Settings

A Bitaxe does not need an account to solo mine. It needs a reachable Stratum server, a valid Bitcoin payout address, and firmware that speaks the server's protocol. Bitaxe Stratum compatibility is usually straightforward because most Bitaxe firmware uses Stratum V1, but the details still decide whether your miner receives work, submits shares, and knows when to switch jobs.

For Bitcoin solo mining at NexusPool (nexuspool.io), set the host to solo.nexuspool.io and the port to 3350. Enter the Bitcoin address where you want a found block to pay. The pool accepts Stratum V1 and encrypted Stratum V2 on that same port.

That is the connection path. The rest of this article explains what it means when a Bitaxe says it is connected, what compatibility does not mean, and what to check before leaving a miner unattended.

What Bitaxe Stratum compatibility means

Stratum is the conversation between a miner and a pool. The pool sends a job. The miner hashes it. The miner sends back shares that meet the assigned share target. If one of those hashes also meets Bitcoin's network target, it is a valid block candidate.

Most Bitaxe units in home use connect through Stratum V1. This is the older and widely supported protocol. A Bitaxe's web interface may call it a pool URL, a pool host, or a mining server. Different firmware builds label fields differently, but the underlying requirement is the same: the host and port must reach a Stratum V1 service.

Stratum V2 is a separate protocol. It can encrypt the mining connection with Noise and can use authority-key pinning. A Bitaxe only uses V2 if its installed firmware implements it. Selecting a V2 option in a menu does not add V2 support to firmware that lacks it.

NexusPool accepts both versions at solo.nexuspool.io:3350. A V1 Bitaxe and a V2-capable miner can therefore use the same host and port. The protocol handshake tells the server which language the miner is speaking.

Compatibility is not a claim that every firmware version exposes every feature. It means the miner and server can establish the same protocol session and exchange valid work messages. Check your firmware's release notes if you need a specific feature such as V2 encryption, version rolling, or a particular worker-name format.

Set the connection before you think about shares

Start in the Bitaxe configuration page. Add the server host as solo.nexuspool.io and use port 3350. Put your own valid Bitcoin address in the identity or username field required by the firmware. No account, email address, or KYC step is part of the connection.

Some firmware accepts an optional worker label after the address. That label helps distinguish machines in a dashboard. It does not create a separate payout destination. The Bitcoin address is the part that matters when a block is built.

Save the settings and restart the mining process if the firmware does not reconnect by itself. Then check the Bitaxe status page. You want to see an active pool connection and an advancing accepted-share count after the miner has had time to work.

A connected indicator alone is not enough. A miner can connect, receive a job, and still produce no shares for a while if its assigned share difficulty is high relative to its hashrate. That is normal. A repeating authorization error, connection loop, or only rejected shares is not.

Do not use an old copied pool address just because it worked somewhere else. A Stratum URL can include a scheme, a host, and a port. The critical values here are the host solo.nexuspool.io and port 3350. Follow the field format your installed Bitaxe firmware expects rather than pasting a format intended for different firmware.

The password field

Many Stratum V1 firmware interfaces require a password field even where the pool does not use a meaningful secret. That field is a firmware requirement, not a custody account. Use the value specified by the pool's current connection instructions if your firmware will not save a blank field.

Do not put a wallet seed, private key, exchange password, or email password in a mining password field. A pool needs a payout address to construct a coinbase payout. It never needs the private key that spends funds from that address.

Why a Bitaxe may reject work or show rejected shares

A rejected share has a reason. It is not automatically a lost chance at a block. Most shares do not meet Bitcoin's network target, and the pool only uses them to confirm that the miner is doing assigned work.

A stale share is the common case around a new block. Bitcoin's tip changes, and the old job stops being useful. A Bitaxe may have started a hash just before the new job reached it. That result can arrive after the old job has expired.

Distance affects this handoff. A miner far from the pool's regions has a longer round trip for new jobs and share responses. It does not change the probability that a given hash finds a Bitcoin block. Network difficulty sets that probability for every pool.

NexusPool prepares work when it sees a new block header. On the Frankfurt server, the median time from header to work was 0.49 ms across 162 mainnet blocks measured on September 10 and 11, 2026. That initial job has no transactions because the node has not finished validating the block. Transaction-bearing work follows validation.

That distinction matters if you watch a job change in the Bitaxe log. A fast first job reduces time spent hashing the prior block. It does not promise that every individual share submitted during a tip change will be accepted.

Other rejection causes are more local. A wrong system clock can complicate diagnostics. Unstable Wi-Fi can delay submits. Overclocking can produce invalid calculations or intermittent network behavior. Firmware with an outdated Stratum implementation can misunderstand a server message.

Start with the error text. If the Bitaxe exposes its miner log, read the rejection reason before changing frequency, voltage, or pool settings. Changing several things at once only removes the evidence.

Share difficulty is not Bitcoin difficulty

A pool assigns share difficulty so it can receive a manageable stream of proof that the miner is working. A low-hashrate Bitaxe may take minutes between accepted shares. That wait does not mean the device is idle, and it does not turn the device's block target into an easier target.

Bitcoin network difficulty decides the target for a valid block. The pool's share difficulty decides which non-block shares the pool records. These are different thresholds.

A quiet rig can also create confusion after it reconnects. NexusPool holds a rig's difficulty when the rig goes quiet for a few minutes. This avoids treating a brief Wi-Fi drop like a new miner that needs a fresh difficulty estimate. It is an operational setting, not a change to block odds.

Solo mining is a lottery. An average wait is not a schedule. Lower network difficulty means a shorter expected wait, not more value for a found block. A Bitaxe is still doing real Bitcoin work, but no server setting can schedule a winning hash.

What happens if the Bitaxe finds a block

If a submitted hash meets the Bitcoin network target, the pool validates it as a block candidate and submits it to its Bitcoin node. A found block through Los Angeles, Chicago, or Frankfurt is written to disk first and then sent to Bitcoin nodes in all three of those cities. Each submission is retried for up to five minutes. Singapore sends a found block to its own node.

After a restart, the pool submits a pending block again. That behavior protects a result that has already been found. It does not alter the odds before the hash exists.

The payout destination is set before that moment. Payout Preflight shows the payout built for your address on the current block before your rig finds anything. If your address is correct, the block subsidy and transaction fees pay to that address inside the block. Nothing waits in a pool balance.

Check Payout Preflight using the same address you entered in the Bitaxe. It is the useful check before mining because it tests the thing that matters: where a found block would pay.

Stratum V1 or V2 for a Bitaxe?

Use the protocol your firmware actually supports. For most existing Bitaxe setups, that is Stratum V1. It is not a lesser mining result. A valid hash is judged against the same Bitcoin network target regardless of whether the connection used V1 or V2.

Use Stratum V2 when your firmware supports it and you want its encrypted connection and authority-key model. Do not guess at a key pin. A bad pin can stop a connection, while an unverified pin defeats the point of checking one. Confirm the published authority key through the pool's own documentation before configuring it.

If V2 fails while V1 works, do not assume the Bitaxe hardware is defective. Confirm the installed firmware version, its V2 settings, and whether it expects a specific transport format. Then test one change at a time.

Your first check is simple: point the Bitaxe at solo.nexuspool.io:3350, use your own Bitcoin address, and confirm that it receives work. Your second check is more important: see your payout before you mine. Trust nothing. Verify the payout address and the transaction built for it.