Payout Preflight Versus a Block Explorer

A block explorer is excellent at showing a Bitcoin block after it exists. That is too late to check where its reward was meant to go. Payout Preflight versus a block explorer is a question of timing: one shows the payout built for your address on current work, and the other records the block after a valid hash has already won.

For a solo miner, this difference is not cosmetic. A found block is rare. You should be able to inspect the reward path before the rare event, not reconstruct it from a transaction after the fact.

NexusPool (nexuspool.io) uses Payout Preflight to show the Bitcoin payout built for a miner's address on the current block. If that work finds a block, the block subsidy and transaction fees go to that address inside the block. The pool fee is 0%.

Payout Preflight versus a block explorer

A block explorer is a historical record. It reads data that has propagated through the Bitcoin network and presents it in a form people can inspect. Once a block has been found and accepted, an explorer can show the coinbase transaction, its outputs, the subsidy, the transaction fees, and the address that received them.

That is useful evidence. It can answer a direct question: where did this block's reward land?

It cannot answer a question from ten minutes earlier: if my rig finds the current work, where will its reward land? The block did not exist then. There was no block hash, no confirmed transaction, and nothing for an explorer to index.

Payout Preflight operates before that point. It takes the payout address your miner uses to connect and shows the payout constructed for the current Bitcoin block template. It lets you inspect the destination before your machine submits a winning share.

The distinction is simple. A preflight is a check of intended construction. An explorer is a check of the final on-chain result.

Both checks matter because they cover different parts of the path. Preflight checks the destination before a find. The explorer checks the published block after a find.

The current block is not a promise about the next hour

A preflight is tied to current work. Bitcoin work changes when the network finds a new block. It can also change as the pool updates the transactions it is preparing to include.

That means a preflight is not a standing promise that one fixed transaction will remain unchanged until your rig finds something. It is a view of the payout for the work being sent now.

The fee amount can change with the block template. The subsidy does not change within a subsidy era, but transaction fees depend on which transactions are in the current work. A fresh job issued immediately after the network advances may carry no transactions at all. At that point, there are no transaction fees in that first job to show.

This limit is useful, not inconvenient. A display that showed a full fee total while the miner was working on a transaction-free job would describe a different block from the one your rig was actually hashing.

When the pool updates work, check the current preflight again if you want to inspect the new construction. The address should remain your address. The total may move as the template changes.

What each tool can and cannot prove

Payout Preflight can show that the active payout construction directs the reward to your Bitcoin address. It gives you something concrete to inspect before luck enters the picture.

A block explorer can show that a particular found block contains an output to an address. It gives you public evidence after the block has been broadcast and accepted.

Neither tool changes the odds of finding a block. Network difficulty sets those odds at every pool. Your hashrate changes your share of the network's attempts. The pool cannot add luck.

Solo mining is a lottery. An expected wait is not a schedule. A lower network difficulty means a shorter expected wait, not more value in a block.

The useful question is therefore not which screen makes a find more likely. It is which screen lets you check a different claim without taking the operator's word for it.

A preflight does not prove that a block will be found. It does not prove that the Bitcoin network will accept a future block. It does not replace the on-chain record after a find.

An explorer does not prove what payout was prepared before a find. It does not show whether the work sent to your rig was built for your address before your hash met the network target.

Put together, the two checks form a clean sequence. Inspect the active payout before mining. If your rig later finds a block, inspect the block transaction afterward.

Why the timing matters for a home miner

Most home miners do not need a lecture on coinbase transactions before they can mine. They need to know where to point the machine and what they can verify.

For Bitcoin, connect a miner with its own valid payout address to solo.nexuspool.io:3350. There is no account and no payout balance held for later withdrawal. The address is part of the connection identity.

That arrangement changes the question after a find. You are not asking when a pool will calculate a balance, approve a withdrawal, or send a payout transaction. You are checking whether the reward output in the found block names your address.

Payout Preflight makes that address check available before the block exists. The explorer lets you repeat it afterward with network-visible data.

This is especially relevant for small machines that may run for a long time without a result. A Bitaxe or another home miner does not become less random because its screen is easy to read. It should still have a clear destination for the result if it does hit.

The same principle applies to a farm running standard ASICs. More machines change the hashrate you contribute. They do not make a payment path held inside the pool more desirable when the block reward can be constructed directly for the operator's address.

What to check before you point a rig

Start with the payout address. It should be an address you control, not an exchange deposit address or an address copied from an old configuration without checking it. If you do not control the keys, you are adding a separate dependency after the mining part is done.

Then read Payout Preflight as a statement about the current work. Confirm that the destination is the address configured in your miner. Confirm that the reward is built as a direct block payout, rather than as a credit to an internal account.

Finally, understand the scope. The preflight reflects a current template. New network work replaces old work. Fee totals can change with the template. None of this changes the payout address you should be checking.

If a block is found, use a block explorer as the second check. Find the block's coinbase transaction and inspect its outputs. The output should match the address used in the preflight for the work that won.

The reward is a coinbase output, so it is not immediately spendable. Bitcoin requires coinbase outputs to mature for 100 blocks before they can be spent. That maturity rule is part of Bitcoin consensus. It is not a pool withdrawal delay.

The check is better than a reassuring sentence

A pool can say that miners keep their rewards. That sentence is cheap because it describes an event that may not happen for a long time.

A preflight gives the claim a present-tense form. It says: here is the address in the current payout construction. You can inspect it now.

A block explorer gives the claim an after-the-fact form. It says: here is the output in the block. Anyone can inspect it after publication.

There are limits to both forms of evidence, and those limits are the point. Preflight is not a found block. An explorer is not a preview. They are not substitutes.

Use Payout Preflight before your rig begins work. Use a block explorer if it finds a block. Trust nothing. Verify your payout address.