Mining-pool reliability is not captured by one number. An ASIC operator depends on Stratum connectivity, share processing, account statistics, reward accounting, and payout services, but an issue in one layer does not automatically mean that every other layer is unavailable.
For ViaBTC, public information shows several reliability-related features: multiple BTC pool URLs, a Europe-oriented endpoint, failover port 443, SSL endpoints, and a SOC 2 Type II audit covering Security, Availability, and Confidentiality criteria.
At the same time, ViaBTC does not publish a single independently verified historical uptime percentage or a public mining-pool SLA that can be used to claim a specific figure such as 99.9% or 99.99%.
The most useful approach is therefore to distinguish documented infrastructure features from measured availability and to monitor the service from the miner's own location.
Uptime Is Not One Metric
When miners say a pool is "online," they may be referring to several different services.
Stratum endpoint availability
This concerns whether a miner can connect to the configured pool URL and port, authorize its worker, receive jobs, and submit shares.
It can be affected by:
- the selected pool endpoint;
- the miner's ISP or hosting network;
- DNS and routing;
- local firewall or switch configuration;
- the miner's firmware; and
- the pool infrastructure.
For ASIC operations, this is the most direct availability question.
Pool-side worker and hashrate reporting
A dashboard reports worker status and pool-side hashrate estimates. These are operationally useful, but they are not direct readings of ASIC chip speed.
ViaBTC's real-time pool hashrate is calculated using the average over the previous 10 minutes. A miner interface may refresh more frequently, so short-term differences do not by themselves prove a connectivity problem.
Reward accounting
Reward accounting concerns whether mining rewards are calculated and credited according to the selected payment method.
Under ViaBTC PPS+, the block-reward component uses PPS and is paid hourly based on current difficulty, while transaction-fee rewards use PPLNS. Under PPLNS, both components follow PPLNS rules after the relevant pool-found block reaches six confirmations.
Withdrawals
External withdrawals are another stage. A mining reward can be correctly credited to the ViaBTC account even if an external withdrawal is still waiting for the next processing window or for Bitcoin network confirmation.
These layers should be assessed separately rather than compressed into one uptime number.
What ViaBTC Publishes About Connection Redundancy
ViaBTC's current BTC pool information lists several documented connection options.
For BTC, the Help Center lists:
- multiple global pool URLs;
- a Europe-oriented endpoint;
- failover port 443; and
- SSL endpoints.
These options reduce dependence on a single hostname or port. They are evidence of connection redundancy features, not proof that every endpoint is continuously available.
For current connection information, miners should use ViaBTC's official documentation rather than old guides or third-party configuration posts.
ViaBTC's BTC mining guide also recommends configuring multiple ports so that the miner can move to the next configured connection if one becomes unavailable.
See: BTC Mining
What SOC 2 Type II Does and Does Not Show
ViaBTC announced completion of a SOC 2 Type II audit in November 2025. Its public announcement states that the audit covered Security, Availability, and Confidentiality under the AICPA Trust Services Criteria.
This is relevant as evidence that ViaBTC's control environment was evaluated over an operating period.
However, SOC 2 Type II should not be treated as:
- a published Stratum uptime percentage;
- an SLA;
- proof that every mining endpoint was available continuously; or
- a substitute for monitoring the exact service used by a miner.
The public announcement supports a statement about control assurance. It does not provide enough information to calculate a historical BTC mining-pool uptime percentage.
See: ViaBTC Achieves SOC 2 Type II Certification
Measure Reliability From the Mining Site
The most relevant availability data comes from the miner's own route to the configured endpoint.
Record:
- hostname and port;
- protocol;
- ISP or hosting network;
- firmware version;
- primary and secondary connection settings;
- disconnect and reconnect timestamps;
- authorization failures;
- pool-side worker status;
- accepted and rejected shares; and
- any local power or network events.
Where SSL is used, a monitoring system may also record TLS connection success.
A team may calculate an internal observation rate such as:
Observed endpoint availability
= successful scheduled endpoint checks
/ all scheduled endpoint checks
× 100
This is not a standard ViaBTC or mining-industry KPI. Its meaning depends on the endpoint, probe location, interval, timeout, and definition of a successful check.
A one-minute TCP check, for example, cannot prove that share submission was healthy during every second between probes. The metric should therefore be used as an internal monitoring aid rather than an externally comparable uptime claim.
Compare Pool Data on Matching Windows
Short measurement windows can create false alarms.
A five-second or one-minute miner-side reading and a 10-minute or 24-hour pool-side average are not directly comparable.
ViaBTC explains that:
- real-time pool hashrate uses the previous 10 minutes;
- daily pool hashrate reflects a longer period; and
- a miner interface may refresh far more frequently.
When a local miner looks healthy but pool-side hashrate appears lower, first align the comparison window and review rejected shares before assigning a cause.
See: Why Is the Hashrate Shown in the Mining Pool Lower Than That of the Mining Machine?
Use Failover as a Continuity Control
ViaBTC's documented alternate URLs and ports are useful only if miners are configured to use them correctly.
During normal operations, verify:
- the primary URL and port;
- the secondary configured connection;
- worker credentials;
- whether the miner can reconnect after the primary connection becomes unavailable; and
- whether pool-side hashrate returns to its expected range after reconnection.
Failover behavior depends on the miner and firmware. Do not assume that every device handles fallback and return-to-primary behavior in the same way.
For operations with stricter availability requirements, miners may design additional redundancy based on their own risk tolerance and network architecture. The key is to test the configuration before a real connectivity problem occurs.
Review Reliability Separately From Payout Variance
Operational reliability and reward variance are different questions.
Under ViaBTC PPS+, the block-reward component follows PPS logic, while transaction-fee rewards use PPLNS. Under PPLNS, reward results depend more directly on the pool's actual block production and luck.
A period of lower PPLNS earnings is therefore not automatically evidence of a service-availability problem.
When investigating an apparent issue, keep separate records for:
- worker connectivity;
- rejected shares;
- pool-side hashrate;
- reward credits;
- payment method; and
- external withdrawals.
This separation helps avoid treating normal reward variance as an uptime event.
A Practical Reliability Checklist
Before relying on a mining-pool connection for production, consider the following:
- use only ViaBTC's current official pool URLs;
- configure appropriate alternate ports or endpoints;
- keep miner firmware and network configuration documented;
- monitor worker offline events and reconnects;
- compare local and pool-side hashrate over compatible windows;
- review rejected-share reasons;
- keep payout records separate from connection monitoring;
- test failover during a controlled maintenance period where appropriate.
Conclusion
ViaBTC publishes several features that are relevant to mining-pool reliability, including multiple BTC connection options, failover ports, SSL endpoints, and a SOC 2 Type II audit covering Availability among its stated criteria.
Those facts do not establish a single verified historical uptime percentage.
For a miner, the most defensible reliability assessment combines ViaBTC's documented infrastructure features with measurements from the exact endpoint, network path, firmware, and operating environment being used.
That provides a more useful answer than relying on an unsupported headline uptime figure.
FAQ
Does ViaBTC publish a 99.9% or 99.99% mining-pool uptime SLA?
No public ViaBTC mining-pool SLA or independently verified historical uptime percentage was identified in the official materials reviewed for this article.
Do multiple ViaBTC endpoints prove high uptime?
No. They show that ViaBTC provides multiple connection options and failover features. Actual availability still depends on the service, endpoint, route, and miner configuration.
Does SOC 2 Type II prove a specific mining-pool uptime percentage?
No. ViaBTC's public announcement states that the audit covered Security, Availability, and Confidentiality controls, but it does not publish a Stratum uptime percentage.
Why can my miner and pool dashboard show different hashrate?
They can use different averaging windows. Compare compatible periods before treating the difference as an operational problem.
What should I monitor to assess pool reliability?
Track endpoint connectivity, worker status, reconnects, rejected shares, pool-side hashrate, and payout records separately.