BTC updated

ViaBTC Stratum Config: Multi-Coin Pool Setup Guide

ViaBTC is one of the few large pools that runs SHA-256, Scrypt, Etchash, X11, and several other algorithms under a single account umbrella. That has two practical implications for any operator approaching a viabtc stratum config. First, the stratum endpoint is algorithm-specific — pasting a Litecoin URL into a Bitcoin Antminer produces a flood of rejected shares and zero revenue. Second, the same ViaBTC account can host workers across multiple coins simultaneously, which simplifies multi-fleet accounting for operators running mixed hardware. This guide walks through ViaBTC account setup, per-coin endpoint selection, worker naming, FPPS payout, and verification across the dashboard and the rig.

What a ViaBTC stratum config looks like across coins

The Antminer-side configuration is the standard three-slot pool table with URL, worker name, and password per slot. ViaBTC publishes a separate set of stratum endpoints for each algorithm it supports, with regional clustering inside each algorithm’s set. The URLs differ both by hostname (often algorithm-specific subdomains) and by TCP port, which means a SHA-256 endpoint is functionally a different service from a Scrypt endpoint even though both live under viabtc.com infrastructure.

Account-side, ViaBTC issues a single login that exposes per-coin sub-accounts in the dashboard. Each coin gets its own payout address, fee mode, payout threshold, and worker list. The worker-name format is sub-account.worker, the same convention used by most major pools. Operators should consult ViaBTC’s live help centre for the current endpoint table per algorithm rather than reusing values from older third-party posts that may not reflect the current infrastructure.

Step 1 — create the ViaBTC account and per-coin sub-accounts

Register through ViaBTC’s signup flow, complete the two-factor enrolment, and inside the dashboard create a sub-account for each coin to be mined. The sub-account name becomes the worker-string prefix on every connected rig, so pick names that are short and unambiguous — a customer-id, location, or function tag works well. Set the payout address for each sub-account immediately and review the per-coin minimum payout, which differs between BTC, LTC, and the smaller-cap coins for fee-economics reasons.

Operators who plan to operate multiple algorithms should treat each sub-account as its own pool relationship for diagnostic purposes — accepted shares, hashrate, and payouts for Litecoin live entirely separately from the equivalents for Bitcoin even though both sit under the same ViaBTC login. Cross-reference the ViaBTC review for context on the pool’s history, fee structure, and counterparty profile before committing material hashrate.

Step 2 — pick the right endpoint for the algorithm

This is the step most likely to be mis-handled by a first-time multi-algorithm operator. A Bitmain S21 mining SHA-256 needs the SHA-256 ViaBTC endpoint; a Fluminer L3 or Bitmain L9 mining Scrypt needs the Scrypt endpoint; an Antminer D9 mining X11 needs the X11 endpoint. The hostnames typically encode the algorithm in the subdomain and the TCP port further distinguishes the service. A mismatch produces accepted-at-zero behaviour: the stratum handshake succeeds, jobs are sent, but every submitted share is rejected because the proof-of-work algorithm does not match the pool’s expected one.

Within the correct algorithm endpoint set, regional selection follows the standard rule: pick the cluster closest to the rig’s physical location. ViaBTC operates regional infrastructure with at least Asia, Europe, and Americas presence on the major coins. The latency principle in the stale-share explainer applies identically across algorithms; a 200 ms round-trip costs a measurable fraction of effective hashrate on any algorithm.

Step 3 — populate the Antminer pool fields

Open the Antminer web UI, navigate to Miner Configuration, and fill the three slots. A typical BTC-mining deployment on ViaBTC uses:

  • Pool 1: Primary SHA-256 ViaBTC regional endpoint, worker subaccount.uniqueworker.
  • Pool 2: Backup SHA-256 ViaBTC endpoint (same region preferred, adjacent region as fallback).
  • Pool 3: Tertiary slot — either a third ViaBTC endpoint or a different pool for cross-pool outage protection.

The worker label should encode physical location at scale. For mixed-coin farms, some operators include the coin and algorithm in the worker name (e.g. subaccount.btc-rack4-u22) so dashboard scanning is unambiguous even when staring at multiple sub-account screens at once. The ASIC mechanism explainer covers what the worker label is actually decorating in the underlying stratum protocol.

Step 4 — switching coins on the same ViaBTC account

ViaBTC’s multi-coin model makes intra-account coin switching straightforward. To move an Antminer from BTC to a different SHA-256 coin, the operator changes the pool URL to the target-coin endpoint and the sub-account prefix in the worker name to the corresponding sub-account; the rig itself does not need to know what coin it is mining as long as the algorithm matches.

For genuine algorithm changes — say, swapping a Scrypt rig from Litecoin endpoint to Dogecoin endpoint — the same principle applies but the algorithm-endpoint pair must remain coherent. The pool dashboard makes the switch trivially auditable: the source sub-account’s worker goes offline as expected, the destination sub-account’s worker comes online within minutes. Operators planning frequent inter-coin switching should also read the dedicated guide on switching mining pools mid-month for the payout-mechanics implications.

Step 5 — ViaBTC’s payout schemes and what to expect

ViaBTC offers PPS+, PPLNS, and FPPS payout modes depending on the coin. The default for major coins is typically PPS+ or FPPS; the active mode and fee rate are published in ViaBTC’s help centre and dashboard. Operators should read the current rate card rather than assume a historical figure.

The headline trade-off mirrors every other multi-mode pool: PPS+ and FPPS smooth variance at a slightly higher fee, PPLNS pushes variance to the miner at a lower fee. Operators with steady cash-flow obligations typically choose the variance-smoothed modes; operators running long-horizon and willing to absorb day-to-day variance sometimes prefer PPLNS to capture the fee saving. The dedicated FPPS-versus-PPLNS decision guide breaks down the math.

Verification across the ViaBTC dashboard and the rig

Three surfaces matter post-deployment:

  • Antminer status page: Shows the active pool URL, accepted/rejected share counts, hardware-error counter, and current hashrate. Reject rates above ~1% are a flag worth investigating.
  • ViaBTC worker dashboard: Live and rolling-window hashrate per worker per coin, online/offline state, last-accepted-share timestamp.
  • On-chain payout: Each coin’s payout history can be cross-referenced against a public block explorer such as mempool.space for Bitcoin to verify that ViaBTC’s records match the on-chain reality.

Where ViaBTC sits in the wider pool landscape

ViaBTC has historically been a top-five Bitcoin pool by share of network hashrate and a top-tier pool on several altcoins simultaneously. Hashrate Index’s pool distribution dashboard tracks the pool’s share on BTC over time. The multi-coin breadth is the key differentiator versus single-coin specialists like Foundry on BTC or Litecoinpool on LTC — operators running mixed hardware get unified accounting from one pool relationship.

For broader Bitcoin mining context including network economics, halving math, and the supporting infrastructure stack, the BTC mining hub at Coin Web Mining consolidates the related explainers.

Reading a multi-coin ViaBTC dashboard correctly

ViaBTC’s per-coin sub-account model is its biggest convenience and its most common source of confusion. Each coin’s dashboard is a separate view; a Litecoin worker will never appear on the Bitcoin sub-account screen, and an operator scanning the wrong coin’s worker list can spend ten minutes convinced a healthy rig has died. The first diagnostic step for any “missing worker” report on ViaBTC is to confirm which coin’s dashboard is open.

Within the right view, the numbers behave as they do at any pool. The real-time hashrate is a noisy short-window estimate; the 24-hour rolling average is the figure to compare against the rig’s nameplate. The accepted-versus-rejected ratio is the health signal — under 1% rejected is normal, a climb past 2% points to latency or a firmware fault. Because ViaBTC runs multiple algorithms, the reject pattern itself is diagnostic: a near-100% reject rate that begins the instant a worker connects almost always means the rig is pointed at the wrong-algorithm endpoint, not that the rig is faulty. A reject rate that starts low and creeps upward over days points instead to a degrading latency path or a thermal problem on the rig.

Payout addresses and thresholds across multiple coins

Every coin sub-account on ViaBTC carries its own payout address and its own threshold, and the minimums differ between coins for fee-economics reasons — a Bitcoin threshold and a Litecoin threshold are not interchangeable numbers. An operator mining both must set both addresses; a sub-account left without a destination address accrues a balance it cannot settle. Verify each coin’s first payout on the relevant block explorer against the dashboard record, because a working Bitcoin payout pipeline tells you nothing about whether the Litecoin one is configured correctly.

Operators consolidating mixed hardware under one ViaBTC login should treat each coin’s payout pipeline as an independent system for monitoring purposes. A single alert that fires on “ViaBTC payout received” is not enough if the farm mines three coins on three settlement schedules; the reconciliation has to be per coin. The upside of the model is that accounting stays clean — Bitcoin revenue, Litecoin revenue, and any altcoin revenue arrive at separate addresses on separate schedules, which simplifies bookkeeping even though it multiplies the number of pipelines to watch.

Keep the rigs off the public internet

As with any pool, the stratum connection to ViaBTC is outbound, so mining needs no inbound open port regardless of how many coins or algorithms the farm runs. Exposing a rig’s management web UI or SSH to the public internet adds attack surface with no operational benefit. A compromised rig can have its pool configuration silently rewritten to an attacker’s ViaBTC sub-account while still appearing healthy on the operator’s own dashboard.

The defensible setup keeps all miner management interfaces on a non-internet-routable management LAN, with remote access gated behind a VPN, and default credentials rotated on first boot. This is doubly worth doing on a multi-coin farm, where the larger device count and varied firmware mix widen the surface an attacker can probe. The lockdown does not affect the outbound stratum sessions to ViaBTC’s per-algorithm endpoints, which continue to work normally behind a fully firewalled management plane.

References

Can one ViaBTC account hold workers across BTC, LTC, and ETC simultaneously?
Yes. ViaBTC’s account model exposes per-coin sub-accounts under a single parent login. Each coin gets its own payout address and worker list; hashrate, payouts, and accepted-share telemetry are tracked separately per coin while still sitting under one set of login credentials.
What happens if a SHA-256 rig is pointed at the Scrypt endpoint by mistake?
The stratum connection succeeds because both endpoints speak the stratum protocol, but every submitted share is rejected because the proof-of-work algorithm does not match the pool’s expectation. The fix is to swap the URL for the correct algorithm endpoint; no account-side change is needed.
Does ViaBTC support PPLNS in addition to FPPS?
ViaBTC has historically offered multiple payout modes per coin, including PPS+, FPPS, and PPLNS depending on the coin. The active modes and current fees are published in ViaBTC’s help centre and visible in the per-coin dashboard. Operators should consult the live documentation for the present configuration.
How quickly does a switched-coin worker show up under the new sub-account?
Usually within a few minutes of the first accepted share against the new endpoint. The previous sub-account’s worker simultaneously goes offline as no further shares arrive at the old URL. Payouts for unpaid balance on the previous coin remain owed and pay out per that coin’s threshold rules.