How to Connect an ASIC to a Mining Pool
Pointing an ASIC at a pool means giving it a Stratum URL, a worker identifier, and usually a conventional password. Firmware opens a session, receives jobs, submits shares. The operation takes five minutes; what takes time is the class of mistakes that leaves the machine running while no share is ever counted.
What you need first
- The ASIC reachable on the local network, or through the host's VPN, with access to the vendor interface or a documented alternative firmware.
- An account at the pool or, in some cases, simply a Bitcoin address used as the identifier. The
address.workerandaccount.workerconventions are not universal, and the pool's documentation settles it. - At least two URLs, a primary and a failover, ideally in different regions or at two separate operators.
- The payout address you control, configured in the pool account if the pool pays outside the Stratum identifier.
That last line deserves a pause: confusing the worker name with the payout address is the most common error, and depending on the pool it sends your earnings to an address that is not yours. Verify it before starting the machine, not after the first payout.
The firmware fields, one by one
- Pool 1, 2, and 3. Most firmwares accept three servers and fail over when the first stops answering. Check above all how that failover triggers, by failure count or timeout: a slow failover leaves you hashing into the void for minutes on every incident.
- The URL. Copy it from the pool's official page, choosing the closest region by measured latency rather than apparent distance. A wrong port, or
sslswapped withtcp, produces immediate rejects. - The worker. Usually in the form
identifier.name. Avoid spaces and any character the pool forbids. One name per machine makes diagnosis far easier when a unit drops off. - The password. Many pools accept
xor ignore the field entirely. Others use it to carry options such as a static difficulty. Never paste your web account password there without reading the documentation. - Share difficulty. Let the pool negotiate it automatically in the large majority of cases. Forcing an unsuitable value raises rejects or floods your statistics with trivial shares.
- Applying the settings. After saving, confirm in the logs and in the pool interface that accepted shares appear. The machine running proves nothing.
On a hosted site, the host often locks the interface and applies its own profile. In that case ask for the real worker name and the URL actually in use, rather than trusting what a marketing screenshot shows.
What "connected" means
An ASIC can display 100 % of its local hashrate without a single accepted share: wrong URL, missing account, drifted clock, blocking egress firewall. Conversely, the pool can display hashrate with a lag, since its estimators are moving averages rather than instantaneous measurements.
Three indicators to watch in the first days:
- The ratio of accepted, stale, and rejected shares. A high stale rate points at latency, short jobs, or a misunderstood failover, never at network difficulty.
- Temperature and throttling. A machine reducing its frequency has a thermal problem, not a pool problem.
- The first payout. It depends on the threshold and scheme in force, not on the first hour of shares. Check that threshold before worrying.
Stratum V1 or V2
Most retail ASICs still speak Stratum V1. V2, with its bridges and proxies, exists at some pools and firmwares, and brings session encryption plus, depending on deployment, template delegation.
Only enable V2 if both sides document it for your specific model. A V2 URL pasted into firmware that speaks V1 only fails silently: the machine runs, no session opens, and nothing in the interface flags it clearly.
Minimum security
Four measures that take ten minutes and prevent hashrate theft:
- Change the ASIC admin password, and never expose its interface to the internet.
- Restrict the firewall to egress traffic toward the pool's Stratum ports, with no admin access open from outside.
- Enable payout address whitelisting if the pool offers it.
- Document who is allowed to change the pool URL. A silent URL change is the classic method for diverting hashrate, and it only shows up if someone regularly compares the configuration against a reference.
Commissioning checklist
- Official URL taken from the pool's own site, with a failover configured
- Unique worker name per machine, with no forbidden characters
- Payout address verified in the pool account
- Accepted shares visible on both sides within a reasonable window
- Alert configured if pool-side hashrate falls to zero for longer than the pool's stats window
- Admin password changed and interface not exposed
Once those six points are validated, you can discuss payout scheme and fees. Until they are, no yield optimization has any effect: if shares are not accepted, nothing else counts.
Buy or compare through The Bitcoin Bay
The Bitcoin Bay is an independent business introducer: we list new ASICs sourced directly from manufacturers (Bitmain, MicroBT, Bitdeer, Canaan) and refurbished machines via verified reseller partners. Each model is paired with professional hosting options at our partner sites in Northern Europe and Paraguay.
No yield promises, no payment handled on our side — the transaction is signed directly with the chosen partner. CIF/AMF status not solicited.
Related reading
Monitoring a Miner: Tools and Metrics
Monitoring a miner means comparing what the machine reports to what the pool counts. The six families of signals to track, and how to read them without blaming the wrong cause.
ReadBitmain Logs and Kernel Panic: Diagnostics
Read a Bitmain controller's logs in time order, sort the motif into five families, and treat a kernel panic as a controller halt rather than a mining problem.
ReadStratum Jobs and clean_jobs
A Stratum job is a work contract, and the clean_jobs flag revokes it. The five causes of invalidation and what you can actually fix.
Read