Skip to content
How it works

The path from your hash to a block.

Network difficulty sets the odds that one of your rig's hashes finds a block, and those odds are the same at every pool. A pool controls what happens around that hash.

The pool decides how fast your rig moves to a new block and whether it reads a winning share as a block, and then what happens to a block your rig finds. The path has seven steps: the new block, the share's version bits, a late share, the block test, the found block, the payout and the proof. For each step we give what NexusPool does, the measurement behind it with its date and scope, and a check you can run without trusting us, or a plain note that no such check exists yet. We name each known gap next to its step. None of it changes your odds of finding a block.

Connecting your rig
Step 01 · The new block

How fast does my rig get work on a new block?

Header-first

We send your rig work on the new block before our node finishes checking it.

A new block on the network leaves a rig hashing on the old one, and those hashes can't win: a block built on a stale parent loses to the chain. NexusPool starts new work the moment its Bitcoin node logs the new header, before the node finishes validating the block. On our Frankfurt server that work was ready 0.49 ms after the header and 205 ms before validation finished, both medians across 162 mainnet blocks on 10 and 11 September 2026.

That first job carries no transactions, so a block your rig finds on it pays the subsidy without fees. Once the node validates the block, the pool derives the job with fees from its previous template, and it falls back to a fresh template when it can't derive one in time. The pool's delay is one part of your stale time. The rest is how fast the block reaches our node and how fast the job reaches your rig.

Frankfurt medians, 162 blocks, to scale
0 msHeader logged0.49 msWork ready205 ms laterValidation finished
0.49ms

Median from header to work, Frankfurt

Evidence
Medians across 162 mainnet blocks: work ready 0.49 ms after the header and 205 ms before our node finished validating the block.
Date
Measured 10 and 11 September 2026
Scope
Measured on our Frankfurt server.

How to check itThe Latency Check page publishes the dated Frankfurt panel and a probe you run from your own network. A Stratum V1 client that logs raw messages shows both jobs: the first with an empty merkle branch, the next with the branch of the template that carries fees. Block Pulse reads that branch after each new block from a machine outside the pool.

Step 02 · Version bits

Does the pool read my shares the way my firmware writes them?

Version rolling

Three ways to write version bits. The pool reads all three.

Rigs roll part of the block header's version field to get more hashes out of each job, and firmware reports those rolled bits in one of three ways: the BIP310 format, an XOR delta or an OR. A pool that reads one format can misread the other two. Today the misreading costs nothing, because the base version on mainnet leaves those bits empty. A future soft-fork signal in bits 13 to 28 would change that: a pool reading one format would misread every share from the other firmware, a winning one included.

Since 19 September 2026, NexusPool tries each reading of a share and lets proof of work decide, and a reading that makes a block wins over one that doesn't. We checked the three formats against regtest nodes and against the firmware sources we could read.

Three readings of one share
BIP310The format the BIP describes
XOR deltaThe change from the job's version
ORThe bits set on top of the job's version

Proof of work picks the reading. A reading that makes a block wins.

Evidence
We tested the three formats against regtest nodes and read them in the firmware sources available to us.
Date
Live since 19 September 2026
Scope
Stratum V1, in all four regions. Stratum V2 sends the full version field, so it has nothing to read this way.

How to check itA Stratum V1 client log shows the base version of each job and the version-rolling mask the pool granted. The three-way reading has no check on the miner's side yet.

Known gapWe have not tested any device on hardware.

Step 03 · A late share

What happens to a share that arrives after the pool moved on?

Job retention

A late share still gets its block test.

Your rig can finish a share on a job the pool already replaced, because a new job takes time to reach your rig. If the pool forgets that job, it can't rebuild the header, and a winning share comes back as "job not found".

Since 18 and 19 September 2026, NexusPool keeps the jobs it replaces within a memory budget, so the pool still tests a late Stratum V1 share against the network target. In the logs we read after that change, on 19 September 2026, no region showed a "job not found" rejection.

Release 0.10.26.5 gives Stratum V2 rigs the same test. It also lets a Stratum V1 rig that loses its connection after finding a block deliver that block once it reconnects and sends the winning share again.

A replaced job, kept
0 sJob replacedLate shareStill tested for a blockMemory budgetDropped when the budget runs out
Evidence
No region logged a "job not found" rejection in the logs we read on 19 September 2026.
Date
Live since 18 and 19 September 2026
Scope
Stratum V1 and, since release 0.10.26.5, Stratum V2. Jobs stay within a memory budget.

How to check itYour miner's log shows the reason for each rejected share. "job not found" is the reason this step removes.

Known gapA late share earns no credit: only the block test runs. Over Stratum V2 your rig still hears "stale-share" when the pool sends its block. Delivery after a reconnect works over Stratum V1 only and needs your firmware to send the share again.

Step 04 · The block test

Does the pool test for a block before its own rules?

Block test

We test each share against the network before our own rules.

A share that meets the network target is a block, whatever the pool's own rules say about it. Over Stratum V1, NexusPool tests each share against the network target before it applies its difficulty, credit and share-rate rules, so the pool still submits the block of a rig over its share-rate limit, without share credit. Three checks run first: a flood ceiling on each connection, set above that limit, a lookup of the job the share belongs to and a duplicate check. A block whose timestamp falls outside the template window still goes to the node, and the node decides whether it is valid.

Over Stratum V2 the pool follows the same order, a late share included since release 0.10.26.5. For each share it reads and rejects, the pool returns the reason to your rig, such as job not found, duplicate share, low difficulty share, ntime out of range or submit rate limit exceeded.

The order over Stratum V1
  1. 01
    Flood ceilingCaps submits on each connection. It runs first.
  2. 02
    Find the jobThe pool rebuilds the header from the job it sent.
  3. 03
    Duplicate checkA share the pool already saw goes no further.
  4. 04
    Block testYour share against the network target. A block goes out from here.
  5. 05
    Timestamp windowCredit only. A block outside it already went to the node.
  6. 06
    Share-rate limitCredit only.
  7. 07
    Difficulty and creditYour share against your rig's own target.
Reasons your rig can seejob not foundduplicate sharelow difficulty sharentime out of rangesubmit rate limit exceeded
Evidence
We read the order in the source of the build that runs in all four regions.
Date
Read on 23 September 2026
Scope
Stratum V1. Stratum V2 follows the same order.

How to check itNo check from your side yet. Your miner's log shows the reason for each rejected share, and the technical docs list what the pool does with each Stratum V1 message.

Step 05 · The found block

What does the pool do with a block my rig finds?

Submission

On disk first, then to three Bitcoin nodes.

The pool writes the block to its journal on disk before it sends it anywhere, so a crash between the find and the submission doesn't lose it. From Los Angeles, Chicago and Frankfurt, the pool then submits the block to three Bitcoin Core nodes in three regions, one local and two over a private network, and keeps retrying until a node answers. An answer, accept or reject, ends the retries. Singapore submits to its own node.

The pool submits a block when the winning share arrives, without waiting for the next job, and it sends to the three nodes in parallel, so a slow node doesn't hold up the other two. If the pool restarts before a node accepts the block, it reads the journal and submits the block again on startup. We test this path against regtest nodes, including a restart between the find and the submission.

From the winning share on
Your blockJournal on disk
  • Los Angeles
  • Chicago
  • Frankfurt

Retries until a node answers. Singapore submits to its own node.

3nodes

From Los Angeles, Chicago and Frankfurt, in parallel

Evidence
Each region logs its submit targets at startup: three in Los Angeles, Chicago and Frankfurt, one in Singapore.
Date
Startup logs read on 23 September 2026
Scope
Los Angeles, Chicago and Frankfurt submit to three nodes. Singapore submits to its own node.

How to check itAny block the pool submits is public on a block explorer, with its coinbase paying the finder's address. Payout Preflight shows the coinbase the pool would build for your address right now. The same step, told from the miner's side: The first five minutes of a found block.

Known gapSingapore submits to one node.

Step 06 · The payout

Where does the reward go?

Coinbase

The block pays your address. There is no balance for us to hold.

The coinbase transaction of a block your rig finds pays the full subsidy and fees to your address, inside the block itself. NexusPool charges a 0% pool fee in solo mode and holds no balance for you. At that fee, the only output in the coinbase that carries value pays your address; the others carry data such as the witness commitment. Your wallet can spend the reward after 100 further blocks, as with any coinbase.

Over Stratum V1 the pool checks your address when your rig connects and refuses one it can't pay, so a typo fails at connect time instead of at the block. Payout Preflight shows you that transaction before you find anything: enter your address, and the pool rebuilds the exact coinbase it would pay you on the current block, byte for byte, with the amount and the raw transaction you can decode yourself.

The coinbase of a block your rig finds
To your address
The subsidy plus the fees
Other outputs
Data such as the witness commitment, no value
Pool fee
0% in solo mode
Spendable
After 100 further blocks
0%pool fee

Solo mode. The coinbase pays your address.

Evidence
Payout Preflight rebuilds the coinbase from the live template for any address you enter, with the same construction the pool uses for a real block.
Date
Payout Preflight live since 7 July 2026
Scope
Solo mining at a 0% pool fee. The address check at connect runs over Stratum V1.

How to check itPayout Preflight with your own address.

Step 07 · The proof

How do I check what the pool counted?

Glass Ledger

Each hour, a signed receipt for the work we counted.

Each hour the pool signs, for each rig, a receipt with the shares it counted, the difficulty it served them at and the window they landed in. The signature is BIP340, and the manifest at /.well-known/nexuspool-custody.json documents the signed bytes and each authority key the pool has signed with, retired regional keys included, with their dates. Each receipt names the region that signed it inside the signed bytes, so a receipt from one region can't pass as another's.

The Los Angeles region also anchors its receipts in Bitcoin each hour through OpenTimestamps, which proves they existed by the time of that Bitcoin block. A receipt proves what the pool says it counted. It can't show a share the pool never recorded, so compare it with your miner's own counter. Our standalone verifier is still in development; the verifier on our home page and your own code can check a receipt today.

One receipt, for each rig, each hour
Shares
The shares the pool counted
Difficulty
The difficulty it served them at
Window
The hour they landed in
Region
Named inside the signed bytes
Signature
BIP340, against the published key
Anchor
OpenTimestamps, Los Angeles region
Evidence
The manifest has listed each retired key with its dates since 13 September 2026, and an anchored receipt reached Bitcoin in block 966871.
Date
Retired keys and Los Angeles anchors since 13 September 2026
Scope
Receipts in all four regions. OpenTimestamps anchors cover the Los Angeles region only.

How to check itThe receipt verifier on our home page and the audit procedure check the signature. Glass Ledger shows your receipts and the anchors.

Known gapAnchors cover the Los Angeles region only, and the standalone verifier is still in development.

Connecting your rig

What does my rig connect to?

Endpoint

One address and one port for both protocols.

Point your rig at solo.nexuspool.io:3350. Stratum V1 and encrypted Stratum V2 share that port, and the pool reads the first bytes of each connection to tell which one your rig speaks. The name resolves to the nearest of four regions whose mining port answers: Los Angeles, Chicago, Frankfurt and Singapore. Each region runs a complete pool with its own Bitcoin Core node.

Since 11 September 2026 all four regions sign Stratum V2 with one authority key, and the technical docs publish it for your rig to pin. The pool sets each rig's share difficulty on its own, and a short silence doesn't drag that difficulty down.

Connect
Address
solo.nexuspool.io:3350
Protocols
Stratum V1 and encrypted Stratum V2, one port
Regions
Los Angeles, Chicago, Frankfurt and Singapore
Authority key
One for all four regions since 11 September 2026
Evidence
The key the four regions sign with is the one the technical docs and the custody manifest publish.
Date
One authority key since 11 September 2026
Scope
Bitcoin on solo.nexuspool.io:3350.

How to check itThe technical docs publish the Stratum V2 address with the key to pin. A Stratum client log shows the difficulty the pool set and the reason for each rejected share.

Known gapWe have not yet run a full Stratum V2 handshake against each region, so we don't yet claim a rig pinned to that key connects to every region. The bare nexuspool.io:3350 address has no failover between regions.

Scope

What this page doesn't claim

  • Your odds

    Difficulty sets them on each hash, at every pool.

  • The stale time outside the pool

    How fast a block reaches our node and how fast a job reaches your rig.

  • The open gaps above

    No credit for a late share, Singapore's single node and anchors outside Los Angeles.

  • A finished verifier or a public core

    The standalone verifier is still in development, and the core's source isn't public.

Trust nothing. Verify the receipt.

The whole reward goes to your address. Check it before you mine.

See your payoutCheck a receipt
Hash to block: what the pool does at each step · NexusPool