Secure ASIC Connections: What Your Rig Can Check

A miner can see the first part of a connection: the pool address, the worker name, and whether the rig reports accepted shares. The parts that matter most happen after that. Secure ASIC connections should protect the route from your rig's submitted work to a block that pays your address, while giving you enough evidence to check what the pool did.

For Bitcoin solo mining, NexusPool (nexuspool.io) accepts Stratum V1 and encrypted Stratum V2 at solo.nexuspool.io:3350. You connect with a Bitcoin address. There is no account, password, custody balance, or payout request waiting after a find.

That removes one category of risk. It does not turn solo mining into income. Network difficulty sets the odds at every pool. Solo mining is a lottery, and an average expected wait is not a schedule.

What secure ASIC connections need to protect

A mining connection has several separate jobs. Your rig needs current work. The pool needs to read your shares correctly. If your rig finds a valid block, the pool needs to submit it to the Bitcoin network. The coinbase transaction in that block needs to pay the address you chose.

These jobs have different failure modes. Encryption can stop someone on the network from reading or changing a connection. It cannot fix a payout address entered incorrectly in your miner. A signed receipt can show what a pool counted for an hour. It cannot make a disconnected rig hash useful work.

Start with the boundary that affects the reward. In non-custodial solo mining, the block itself pays your Bitcoin address. The block subsidy and transaction fees go there in the coinbase transaction. The pool does not receive a balance that it later sends to you.

That is a useful distinction when a pool says it supports self-custody. Ask where the reward is created. If it is created directly in a found block for your address, there is no pool-held payout balance between the block and your wallet.

Check the address before you mine

The address configured in your rig is not a display label. It is the destination for a block reward if your rig finds one. Copy it carefully. Do not use an address from an exchange account unless that service explicitly supports receiving a mined block reward and you accept its rules.

Payout Preflight lets a miner inspect a payout built for their address on the current block before the rig finds anything. The current template can change when the network finds a new block, so this is a check of the present work, not a promise about a future template.

A useful habit is simple: configure the address, inspect the projected payout, and save the address in your own records. A pool cannot repair a typo in an address after a block has been mined.

Stratum V1 and Stratum V2 are different security choices

Many home miners and older ASICs speak Stratum V1. It is widely supported, but the traditional connection is not encrypted. The miner sends and receives job and share messages in a format that a person on the same network path may be able to inspect.

That does not mean every Stratum V1 connection is unsafe. The practical risk depends on where the rig is connected. A miner on a private wired LAN has a different exposure from a rig connected through an untrusted shared network. Still, plaintext is plaintext.

Stratum V2 can encrypt the connection. It uses a Noise handshake, then protects the messages exchanged between the miner and the pool. It also supports authority-key pinning. A pinned authority key lets a rig reject a server that cannot prove it holds the expected authority.

NexusPool publishes one Stratum V2 authority key for all four Bitcoin regions. A miner with compatible firmware can use encrypted Stratum V2 on the same solo.nexuspool.io:3350 port used by Stratum V1.

The limit matters. A rig should not assume that a pin survives a regional failure without testing the handshake behavior it will use. A published key is something you can inspect. Failover behavior is something you should test from your own setup.

For a home miner whose firmware only supports Stratum V1, the practical connection path is still short. Point the rig at the Bitcoin endpoint, use your Bitcoin address as the account name, and use a worker name if your firmware requires one. Keep the miner and its local network under your control.

For an operator with several ASICs, separate worker names make troubleshooting easier. They help identify which rig submitted a rejected share or went quiet. They do not create accounts or change where a found block pays.

New work matters as much as encryption

A connection can be encrypted and still deliver old work too slowly. When Bitcoin finds a new block, miners need a new job built on the new tip. Hashing the old block after the network has moved on cannot produce the next valid block.

On the Frankfurt server, NexusPool measured a 0.49 ms median from receiving a new block header to sending work, across 162 mainnet blocks on September 10 and 11, 2026. That first job carries no transactions. It was ready 205 ms before the pool's node finished validating the block.

The qualification is part of the result. Early work is a header-first job. Transaction selection follows validation. This is not a claim that work can safely include transactions before a node has validated the new block.

Distance still exists. A miner far from Los Angeles, Chicago, Frankfurt, and Singapore will see a longer round trip. That can delay new jobs and dashboard-like status information. It does not change the odds of finding a block, which depend on hashrate and network difficulty.

Read share results, not just green status lights

Your rig reports a share because it believes it found a hash that meets the assigned target. The pool has to read the submitted bytes and test them. A share can be accepted, rejected for a stated reason, or arrive too late to count for the job that issued it.

A useful pool response tells you why a share was rejected. “Rejected” by itself is not enough to diagnose a bad network path, a stale job, a firmware problem, or malformed data. NexusPool reads each share the way the rig's firmware wrote it and provides a reason for each share it reads and rejects.

Quiet rigs create another edge case. Some miners pause during a network interruption, a thermal event, or a local restart. If the pool immediately changes difficulty when a rig goes quiet for a few minutes, the next shares can make diagnosis harder. The pool holds a rig's difficulty during that short quiet period.

This does not mean a disconnected rig is mining useful work. It means the rig can return without an unnecessary difficulty change after a brief interruption.

What happens if your ASIC finds a block

A valid block is rare. The path after a find is therefore worth understanding before the day it matters.

For a block found through Los Angeles, Chicago, or Frankfurt, NexusPool writes the block to disk first. It then sends the block to Bitcoin nodes in all three of those cities. Each submission is retried for up to five minutes. If the pool restarts with a pending block, it submits that block again.

Singapore has a narrower path. A block found through Singapore is sent to its own node only. That difference should shape your expectations. Four regions do not mean that every region follows the same broadcast procedure.

The test after a find is public. Look at the coinbase output in the found block. It should pay the address you configured. You can also see whether the block reached the chain. Neither check requires trusting a pool balance page.

Use receipts for an operational record

Connection security is not only about preventing interference. It is also about having evidence when a rig's history is disputed.

Each hour, the pool signs a receipt for the work it counted from each rig. The receipt is for one rig and one hour. It is not a receipt for every individual share. The signature can be checked with the published key using a BIP340-capable library.

For a small farm, receipts can help separate two questions that often get mixed together: what the rig says it sent, and what the pool says it counted. They are most useful when compared with the miner's own logs, timestamps, hashrate readings, and rejection reasons.

No receipt proves that a rig will find a block. It records counted work. That limit is the point of keeping the record precise.

Before you point a rig at a solo endpoint, check the payout address with Payout Preflight, confirm which protocol your firmware actually supports, and watch the first share results. Trust nothing. Verify the payout your current work would create.