Stratum is the communications layer that connects an ASIC to a mining pool. It carries job notifications, difficulty adjustments, and share submissions, but it does not alter how an ASIC hashes SHA-256 inputs. When operators compare Stratum V1 and Stratum V2, the relevant questions are about connectivity, security, and who controls block-template construction — not about raw hashing performance. This article separates what the Stratum V2 specification defines from what any individual pool, including ViaBTC, has actually deployed.

What Stratum carries

In a conventional pooled-mining session, the pool server sends the ASIC a job: a block header template, a target difficulty, and instructions for constructing the coinbase transaction. The ASIC searches for a nonce that satisfies the assigned share target and returns valid shares to the pool, which credits them toward the miner's payout under whatever method the pool uses (PPS+, PPLNS, or another documented model).

Stratum does not determine payout economics, pool fees, or settlement timing — those are pool policies layered on top of the protocol. What Stratum does govern is the format of the connection, how jobs are delivered, how authentication occurs, and, in more advanced deployments, whether the party submitting shares also controls which transactions go into the block template.

V1 and V2 comparison

Stratum V1 is typically implemented as a JSON-based, line-delimited protocol over a plain TCP socket. It did not originally define built-in transport encryption; transport encryption and server authentication depend on additional protections provided by the implementation or network setup.

Stratum V2 is a binary protocol with fixed message framing, published as an open specification. For ASIC operators, the main differences are:

Two distinctions deserve a closer look:

• Transport security. The Stratum V2 specification uses authenticated encryption for remote upstream connections, meaning traffic between a mining device (or proxy) and a remote pool endpoint is encrypted and the server is authenticated as part of the connection setup. Local device-to-local-proxy links can be treated differently under the specification (Stratum V2 Protocol Security).
• Separation of mining and template functions. The V2 specification defines distinct roles and sub-protocols: the Mining Protocol (job delivery and share submission, functionally similar to V1), and the optional Job Declaration Protocol (coordination of miner-selected templates). These are architecturally separate, and a pool can support the Mining Protocol without supporting Job Declaration (Stratum V2 protocol overview).

Switching protocols alone does not guarantee higher chip-level hashrate or better energy efficiency, measured in J/TH. Those hardware characteristics depend on the ASIC and its operating settings. Job delivery and connection behavior should be evaluated separately: protocol and implementation differences can affect how effectively mining work reaches devices and shares reach the pool, without changing the chip's underlying hashing capability (Stratum V2 Mining Protocol).

Security and job selection

Published research on Stratum V1 demonstrated that, in deployments without added transport protections, unencrypted Stratum traffic could expose information useful for inferring a miner's hashrate and could be subject to interference by a network-positioned adversary (Recabarren and Carbunar, Hardening Stratum, the Bitcoin Pool Mining Protocol, 2017) (arxiv.org/abs/1703.06545). This describes a structural limitation of the original V1 design in the absence of supplementary protections — it does not mean every V1 connection in production today is unprotected, since individual implementations and endpoints may add their own transport security.

Stratum V2's authenticated encryption protects message contents and integrity, while server authentication helps clients verify the upstream server. These protections reduce exposure to eavesdropping on message contents and message tampering. They should not be read as a guarantee against all traffic analysis: the cited research also examines earnings inference from packet timestamps, so encrypting message contents alone does not establish that all metadata-based inference is prevented.

A separate and frequently conflated topic is job, or transaction, selection. Under the standard pooled-mining model, the pool server constructs the block template and the ASIC simply searches for a valid nonce against it. Stratum V2's Job Declaration Protocol defines an optional path in which a mining operation — not the ASIC itself — obtains a candidate template from a Template Provider and uses a Job Declarator Client to coordinate custom work with a supporting pool (Stratum V2 Job Declaration Protocol).

The current specification describes two modes. In Full-Template mode, the client declares the template's transaction IDs, and the pool can request missing transaction data. In Coinbase-only mode, the transaction set is not disclosed to the pool through this process, and the DeclareMiningJob message is not used. Both modes describe optimistic mining: work can be sent to devices before the pool's acknowledgement, with shares cached pending that acknowledgement. Operators should check how their chosen implementation handles acknowledgements and cached shares.

For operators, enabling Stratum V2 on an ASIC, by itself, does not grant transaction-selection capability. Job Declaration requires additional infrastructure on the mining-operation side, and it requires the pool to support that specific sub-protocol, not just the base V2 Mining Protocol. An operation considering Job Declaration should expect to run or coordinate with a Bitcoin node and compatible template-building software, in addition to whatever ASIC or proxy configuration it already manages.

Device and proxy compatibility

An ASIC configured against a V1 endpoint does not automatically gain V2 capability. Native V2 support depends on the device's firmware implementing the binary protocol and its encryption handshake. Where firmware does not support V2 directly, a compatible V1-to-V2 translation proxy can bridge V1 ASIC connections to a compatible V2 pool endpoint, avoiding a firmware change on every unit. A generic V2 proxy is not sufficient unless it implements that translation. In this configuration, the ASIC-to-proxy link remains V1, while the proxy-to-pool link uses V2; V2 encryption on the upstream link does not automatically protect the local V1 link (SRI translation-proxy example).

For operators evaluating migration, a few practical compatibility points apply:

• Confirm whether current firmware exposes a V2 connection option, or whether a compatible V1-to-V2 translation proxy is required.
• Where V1 fallback is available during a transition, testing a subset of miners before converting an entire fleet reduces the risk of a fleet-wide connectivity issue.
• Monitoring should distinguish local device readings from pool-reported shares and worker status, since a protocol change can affect connection stability independently of underlying hash performance.
• Job Declaration infrastructure (node, Template Provider, Job Declarator Client) is a separate deployment decision from basic V2 connectivity and carries its own maintenance requirements.

At present, ViaBTC's documented BTC mining configuration uses standard stratum+tcp endpoints (for example, stratum+tcp://btc.viabtc.io:3333 and stratum+tcp://btc.viabtc.io:443) with the conventional userID.workerID worker format and multiple ports recommended for connection continuity (ViaBTC BTC Mining guide). This documentation describes the currently published connection method; it should not be read as a statement about Stratum V2 or Job Declaration availability, confirmed or otherwise, and operators should consult current official ViaBTC documentation directly for the latest supported connection options.

Questions to ask your pool

Because "supports Stratum V2" can describe meaningfully different capabilities, operators evaluating a pool should ask specific questions rather than accepting the label at face value:

1. Does the pool support the V2 Mining Protocol for standard pool-issued jobs, the Job Declaration Protocol, or both?
2. If Job Declaration is supported, does it operate in a mode where the pool still receives transaction data for validation, or one where it does not see transaction contents directly?
3. Is there published setup documentation covering firmware requirements, supported proxies, ports, and authentication for a V2 connection?
4. Does V1 remain available as a fallback during a migration period, and how does the pool handle a mixed fleet running both protocol versions simultaneously?
5. Independent of protocol version, what payout method, fee, settlement timing, and withdrawal terms apply, and are those terms documented the same way regardless of whether a worker connects via V1 or V2?

Treating protocol capability and payout terms as separate evaluation criteria avoids the common error of assuming that a pool's transport-layer improvements also improve its economics — they are independent aspects of pool selection.

FAQ

Does switching to Stratum V2 increase my ASIC's hashrate?

Not by itself. Stratum V2 changes mining communications, not the ASIC's chip design. Switching protocols alone does not guarantee higher chip-level hashrate or better J/TH. Assess job delivery, connection stability, and pool-accepted shares separately from the device's local hashrate.

Is Stratum V2 required to use a mining pool today?

No. The required protocol depends on the endpoint you use. A V1-compatible miner can use a compatible V1 endpoint; confirm the supported protocol and setup requirements for your specific firmware and pool connection.

Does enabling Stratum V2 let me choose my own transactions?

Not by itself. Basic Stratum V2 Mining Protocol support still relies on the pool to issue jobs. Transaction selection requires the separate, optional Job Declaration Protocol, which needs additional infrastructure on the mining-operation side and explicit pool support for that function.

Can I run Stratum V2 ASICs and V1 ASICs on the same pool account?

This depends on the specific pool's implementation. Operators should confirm with the pool whether mixed-protocol fleets are supported before migrating a subset of devices.

Is Stratum V1 unsafe to use?

Independent security research identified structural weaknesses in unencrypted V1 implementations, such as exposure of hashrate-related data to a network-positioned observer. This is a known limitation of the base design rather than evidence that every V1 deployment in production lacks any protection, since individual pools or network setups may add their own transport safeguards.

References

• Stratum V2 Protocol Overview
• Stratum V2 Mining Protocol
• Stratum V2 Protocol Security
• Stratum V2 Job Declaration Protocol
• Recabarren, R., and Carbunar, B. (2017). Hardening Stratum, the Bitcoin Pool Mining Protocol. arXiv:1703.06545.
• ViaBTC Support. BTC Mining.
• Stratum V2. New SRI update with Job Negotiator - allowing miners to select transactions. April 14, 2023.