NexusPool
NexusPool 0.10.26.5: The Best Solo Bitcoin Pool We Have Ever Made
NexusPool 0.10.26.5, the best Solo Bitcoin Pool we have ever made: five places from rig to block, all changed since 0.9.26. 0% fee on the Bitcoin pool.
NexusPool 0.10.26.5 · non-custodial Bitcoin solo mining pool · changelog dated 2026-09-29 · Bitcoin pool read 2026-09-30 at 18:43 UTC
We set out to build the best solo mining pool on the market. NexusPool 0.10.26.5 is the best NexusPool we have ever made, and this is the release where we say it out loud. Rig to block. Five places. All changed since 0.9.26.
If your rig solves a block, the pool journals it, then sends it to each configured node until one answers. A reject counts as an answer. The fee is 0%, and the coinbase of a found block pays your address. The Bitcoin pool reports 0.10.26.5. We are not asking for faith: the fee and the coinbase take a minute to check, and the checks start below. The changelog lists all 21 public changes.
The Bitcoin pool reports 0.10.26.5 (read 2026-09-30 at 18:43 UTC)Stratum V1 and Stratum V2Nothing to install on your rig
Rig to block: five places changed since 0.9.26
The road from your rig to a block is where a pool does its work. NexusPool 0.10.26.5 changes five places on it, and several were already running in production before the changelog date.
- Work starts at the block headerYour rig gets work when the node logs a header, before the node finishes checking the block.
- Stratum V1 version bits, read three waysThe pool reads each share three ways and lets proof of work choose.
- Late winning shares still get a block testA winning share that arrives after the pool replaced its job gets tested as a block, on Stratum V1 and Stratum V2.
- A found block is retried until a node answersThe pool journals the block, sends it to each configured node and keeps going until one answers.
- The first bytes decide: Stratum V1 or Stratum V2One port, two protocols. The pool decides from a connection's opening bytes and reads on while it cannot tell.
One payout rule changes too, for rented rigs on Stratum V1. The rented-rig section has the rule.
Four checks you can run today
NexusPool 0.10.26.5 is pool-side software for the Bitcoin pool. You change nothing on your rig. Your old pool address still works, and so does a TLS address. New rigs can point at solo.nexuspool.io:3350.
- Your rig's own log shows the reason the pool gives for a refused share, such as
job not found, if the firmware logs it. - Payout Preflight rebuilds the coinbase the pool would build for the address you type.
- The version feed names the release the Bitcoin pool runs. The live section has the command.
- The Latency Check page lists the dated Frankfurt timings and offers a probe,
np-stratum-probe.py, that times the first notification on a new connection, from your network. The probe is 14,442 bytes. Read it before you run it.
The changelog lists the rest of the 21.
Work starts at the block header
With header-first on, the pool gives rigs a first job the moment the node logs a new block's header. The node is still validating the block. The work does not wait for it.
Header-first takes the node's validation time out of the wait for work. The first job holds no transactions, so a block solved on it pays the subsidy (the new bitcoin a block creates). Jobs with transactions follow; line 2 of the release map describes the fee-paying one.
Header-first, timed in Frankfurt: 162 of 162 blocks
A loud claim is cheap. Here is the stopwatch.
The clock ran inside one Frankfurt server, from the node logging the header to fresh work ready. Even the slowest of the 162 blocks had work ready before the node finished validating. We printed that one too.
How a block solved on early work is handled
A block solved on early work can sit on a parent the node has not finished checking. The pool holds it in memory until the node rules on that parent. A valid parent releases the block, and an invalid parent drops it. A full hold or a pool shutdown releases it without a ruling; at shutdown the block goes to the journal for the next start to send. If a different block takes the height, or a default wait runs out, the pool asks the node for the parent's status. An invalid answer drops the block, and any other answer, or none, releases it.
Without header-first
Rigs started on a new block after the node finished checking it.
With header-first on
Rigs start when the node logs the header. The first job holds no transactions.
What you can see
The Latency Check page lists the dated Frankfurt figures, and its probe times the first notification on a new connection from your network.
Stratum V1 version bits, read three ways
On Stratum V1, the pool reads a share's version bits three ways and lets proof of work choose. The reading whose header forms a block wins; with no block, the one that meets the credit target does.
Rigs roll version bits in different ways. The pool reads each Stratum V1 share with the BIP 310 layout, with an XOR delta and with an OR, and builds the header each reading gives. If the readings disagree, the pool uses the one whose header meets the credit target (the difficulty a share must meet to count), and a reading that forms a block wins over one that does not.
BIP 320 reserves version bits 13 to 28 for general use and asks soft forks not to signal there, so the three-way reading covers the case where a job version ever carries a bit in that range. The reading has run on the Bitcoin pool since 2026-09-19.
Late winning shares still get a block test
With the job archive on, a winning share that arrives after the pool replaced its job gets a block test before any stale answer, on Stratum V1 and Stratum V2.
We keep a replaced job's block contents for a bounded time. The pool rebuilds a late winning share against the header the rig mined and tests it against the network target. A block that passes goes to the journal and out to the nodes. Stratum V2 rigs get the same test on their own connection.
A late share gets no share credit: the test is for blocks, and a share that is not a block is refused as before, with job not found or job credit expired. On Stratum V2 the rig receives stale-share even when the pool sends the block.
A Stratum V1 rig that loses its connection after solving a block can deliver it after it reconnects, if it sends the winning share again. The pool searches its archived jobs for the one whose rebuilt header meets the block target and delivers the block when the match is unambiguous. That block goes to the journal and out to the nodes. The block pays the address its archived job was built for, and the returning rig gets no share credit.
Before (archive off)
A winning share for a replaced job met a refusal such as job not found, with no block test.
Now
With the archive on, the pool tests that share as a block before it answers stale.
What you can see
A refused late share shows job not found or job credit expired in your rig's log, if the firmware logs it.
A found block is retried until a node answers
Before the pool sends a block, it journals the block on disk. It then sends it to each configured node until one answers. A reject counts as an answer.
Journal first. Every configured node at once. Another round until one answers. The Los Angeles, Chicago and Frankfurt regions send the block to the three Bitcoin Core nodes in those cities in parallel; Singapore sends it to its own node. Any answer, accept or reject, stops the retrying. Without an answer, the block goes back in the queue for another round. The retry does not give up. It runs until a node answers. If the journal write fails, the pool raises an alarm and the block still goes out.
Before
A block found while a node was starting up could be recorded as rejected.
Now
The pool journals that block and retries it until a node answers.
What you can see
After a find, a block explorer shows the block. Payout Preflight shows the coinbase the pool would build for an address, which tells you where the reward would land.
The first bytes decide: Stratum V1 or Stratum V2
The pool decides Stratum V1 or Stratum V2 from a connection's opening bytes, so a Stratum V2 handshake that opens with a brace is no longer mistaken for Stratum V1.
One port. Two protocols. The first bytes decide. Stratum V1 and encrypted Stratum V2 share solo.nexuspool.io:3350 on the Bitcoin pool, so the pool tells them apart from what a connection sends first. An opening byte other than { means Stratum V2. A connection that opens with { gets a longer look: the pool reads on to see whether the first line is a JSON request, and keeps reading while it cannot decide.
A Stratum V2 handshake begins with a random-looking byte. When that byte happened to be the brace character, the pool read the connection as Stratum V1 and left it waiting until it timed out. Rigs retry, so the effect was an intermittent delay before a connection came up.
Before
The pool read any opening brace as Stratum V1.
Now
The pool reads a brace as a prompt to look further, and decides from the opening bytes.
Rented rigs: payout follows the last authorized address
Renting on Stratum V1? On the Bitcoin pool, the reward goes to the last address your rig authorizes, from the next job.
Check which address your rental authorizes last. If your rental sends one address on each connection, nothing changed for you. If it authorizes another address on the same connection, the reward now goes to the one authorized last, the one the pool displays. Before, the payout stayed on the first address a connection authorized. A job already handed out keeps the address the pool built it with. The fee stays at 0%.
What you can see
After a block exists, read its coinbase in a block explorer. The signed block receipt, listed on Glass Ledger, carries the coinbase transaction id, which an explorer resolves.
What stays the same in NexusPool 0.10.26.5
The Bitcoin pool reports 0.10.26.5. Ask it which release it runs.
On 2026-09-30 at 18:43 UTC we read version 0.10.26.5 from the Bitcoin pool's public feed, and the changelog page marks the entry Current.
Ask the pool yourself:
curl -s https://nexuspool.io/api/pool | grep -o '"version":"[^"]*"'At the time we read it, the output was "version":"0.10.26.5". The Bitcoin Cash and Litecoin/Dogecoin pools run their own releases (0.8.26.14).
Straight answers about NexusPool 0.10.26.5
What is NexusPool 0.10.26.5?
NexusPool is a non-custodial Bitcoin solo mining pool. NexusPool 0.10.26.5 is its Bitcoin pool release, with a changelog dated 2026-09-29 that lists 21 public changes. Five of them sit on the road from a rig to a block: where work starts, version bits, late winning shares, found-block delivery and the first bytes of a connection.
Is NexusPool the best solo mining pool?
We think so, and we say it plainly. Our bar is the whole road from your rig to a block. The checks are on the page: 0% fee, a coinbase you can read before you mine, five places changed, one changelog.
Why should I believe NexusPool 0.10.26.5?
Believe what you can check. Paste your address into Payout Preflight and read the coinbase. Run the version command and read 0.10.26.5. Count the 21 lines on the changelog. A loud claim with its proof beside it is the deal.
Did anything change for rented rigs?
Yes, for a Stratum V1 connection that authorizes a second address. The rented-rig section has the rule.
What happens to a block my rig finds while a node is down?
The pool journals the block before it sends it, then retries until a node answers, including a block found while a node starts up. Station 4 has the detail.
How soon does the pool have fresh work after a new block?
With header-first on, fresh work was ready a median 0.49 ms after the node logged the block header, timed inside one Frankfurt server (162 mainnet blocks observed, 10 to 11 September 2026). The first job holds no transactions. The Latency Check probe times a new connection to its first job from your network.
All 21 changes in NexusPool 0.10.26.5, line by line
Count them on the changelog. It prints its lines without numbers, so the numbers below follow its print order. Six lines link to their station, and one links to the rented-rig section.
| Line | Change in plain words | Who sees it |
|---|---|---|
| 1 | Header-first. With header-first on, rigs start on a new block the moment the node logs its header. Station 1 | Solo minerOperator |
| 2 | Fee-paying job. Where this rebuild is enabled, the pool publishes a fee-paying job from the previous template once the node has connected a block, while it builds the full template. The pool skips only the wait for a fresh template. | Solo minerOperator |
| 3 | Late solutions. With the job archive on, a late winning share gets a block test on Stratum V1 and Stratum V2. Station 3 | Solo miner |
| 4 | Reconnections. With the job archive on, a Stratum V1 rig can deliver a block after it reconnects, if it resends the winning share. Station 3 | Solo minerRented rig |
| 5 | Block delivery. The pool retries a found block until a node answers. Station 4 | Solo minerOperator |
| 6 | Queued once. The pool remembers the last 64 blocks it queued (a block released from the header-first hold is not counted) and answers a repeat solution for one of them as a duplicate share, with no second journal line or submission. | Operator |
| 7 | Share limit. A block, or a share at or above the difficulty the pool served the rig, no longer counts toward the default limit of 200 submissions per second per connection, so a very fast rig is not stopped before the pool tests its block. | Solo minerRented rig |
| 8 | Stratum V2 difficulty tuning. Stratum V2 shares count at the difficulty the rig mined them at, so a difficulty change no longer overshoots. | Stratum V2 developerOperator |
| 9 | First bytes. One port, two protocols: the pool tells Stratum V1 from Stratum V2 by the first bytes. Station 5 | Stratum V2 developerSolo miner |
| 10 | Stratum V2 error names. Three share-refusal names changed to duplicate-share, invalid-non-rollable-version-bit and bad-extranonce-size. | Stratum V2 developer |
| 11 | Version rolling. The pool reads Stratum V1 version bits three ways and keeps the reading whose header meets the credit target. Station 2 | Solo minerOperator |
| 12 | Long usernames. A 62-character taproot address plus a worker name now connects and mines: the pool accepts usernames up to 255 bytes. | Solo minerRented rig |
| 13 | Refused shares. Operator telemetry records refused shares under their cause (duplicate, timestamp, bad submit, or the pool lacking the capacity to check the share) instead of one generic reason. The pool's own capacity limits no longer count against a rig, and the share-rate ceiling keeps its own counter. | Operator |
| 14 | Rented-rig payouts. On the Bitcoin pool, for Stratum V1 connections, the reward goes to the address a rig authorized last, from the next job. Rented rigs | Rented rigSolo miner |
| 15 | Chain watch. The pool raises an alarm when its node's chain stops advancing: by default, after 30 minutes without a new block when the node reports no peers, or after 90 minutes whatever the peer count. | Operator |
| 16 | Restart and share-check fixes. Two fixes land on this line: one about work space in use across a restart, and one about a share check that could not run. | Operator |
| 17 | Declared job origin. A declared job is one where the miner picks its own transactions; Job Declaration is opt-in. The pool judges a declared job against the template the miner declared it on, so a template refresh can no longer make a valid job look stale. | Declared jobs |
| 18 | Declared transactions. The pool checks each transaction body a miner supplies against the miner's own declaration before it asks a node. | Declared jobs |
| 19 | Declaring connections. A declaring connection that closes frees the unfinished declarations it held. | Declared jobsOperator |
| 20 | First job after a block. Keeping recent jobs for late solutions does not hold up the first job on a new block: pruning runs after the notification. | Operator |
| 21 | Job lookup. On average, looking up a recent job by its job name takes constant time however many jobs the archive holds. | Operator |
Doubt us. Then run the command. Ours: the changelog and the checks. Yours: the verdict. Tell us what you see: write to support with the region, the UTC time and the log line.
Trust nothing. Verify the coinbase that Payout Preflight builds for your own address.