Stratum Proxy for the mining pool — How to choose a mining architecture

content

If you are building a mining pool — your own, white-label, or for a data center — sooner or later you will run into a question that looks like a detail at first glance. How the proxy will manage connections between your miners and the upstream.
In practice, this is one of the key architectural decisions. It affects how many resources the infrastructure will need as it scales, how hard diagnostics will be, and exactly where the hardware management logic ends up.
In this article we break down the two basic approaches — and when each one is justified.

What a Stratum proxy is and why you need it

Before we get to architecture, some basic context for those who are only starting to design a pool.

Stratum is the protocol ASIC miners use to talk to the pool. A miner connects to the pool, receives a job, computes hashes, and sends the shares it finds back. The pool validates the shares, credits the reward, and periodically updates jobs when the block changes on the network.

A Stratum proxy appears in this scheme as an intermediate layer between the miners and the main pool. It accepts incoming connections from the hardware, relays jobs in both directions, and passes shares upward — to the upstream pool.

Why do you need it? Several reasons:

1. Regional distribution. If your miners are physically located across several sites, a proxy in each region reduces the latency (RTT) between the hardware and the pool. Instead of every ASIC reaching all the way to a server in another country, it connects to the nearest proxy node.
2. Buffering and resilience. The proxy can cache the current job locally and serve it to miners without going to the upstream on every request. If the connection to the upstream is temporarily interrupted, the hardware keeps working.
3. Load management. The proxy is the point where decisions about routing, difficulty, and connection balancing are made. It is not just a “pipe” — it is a full-fledged service with its own logic.
   And this is where the architectural choice begins.

Two approaches to organizing connections

Approach 1: 1:1 proxy

Principle: every miner that connects gets its own separate connection to the upstream. 100 ASICs — 100 connections to the main pool.
What this gives you:
Minimal logic at the proxy level. Difficulty for each device is set by the upstream itself — the proxy calculates nothing on its own. Less state to store and synchronize.
From a diagnostics standpoint, every worker is visible as a separate unit. If a particular ASIC behaves oddly, it shows up immediately at the connection level. Billing and payout auditing are simpler: the data for each device is isolated.
Limitations:
The number of connections to the upstream grows linearly with the number of devices. With tens of thousands of ASICs, this creates a load on the upstream that it may cap. In a regional deployment, each regional proxy carries as many connections as it has devices — which directly affects the choice and the cost of the infrastructure.

Approach 2: Aggregating proxy

Principle: many ASICs are multiplexed into one (or several) connections to the upstream. 100 miners — 1 connection upward.
What this gives you:
A sharp reduction in load on the upstream. For operators who connect to someone else’s pool (white-label, relaying), this makes it possible to avoid the connection limits imposed on their side. Horizontal scaling costs less — a new proxy node adds one connection to the upstream, not thousands.
Limitations:
The proxy takes on responsibility for calculating difficulty for each worker. This is not trivial: you need to track the hashrate of every device, adapt difficulty so that the share rate stays reasonable, and correctly aggregate shares before sending them upward.
Diagnostics are harder: if a single worker degrades, it has to be detected at the proxy level — the upstream only sees the aggregate flow.
More state — and, accordingly, more requirements for persistence and synchronization between instances.

When to choose what

1:1 is a reasonable choice if:

You control the upstream (your own pool) and can manage connection limits on your side.
Transparency is the priority: every worker is visible as an independent unit, which simplifies troubleshooting and billing.
The team wants to keep its own logic in the proxy to a minimum and offload as much as possible onto the upstream’s proven mechanisms.

Aggregation is a reasonable choice if:

You are connecting to a third-party upstream that has connection limits.
You need multi-region infrastructure with a minimal number of outgoing connections.
You are ready to implement and maintain difficulty management on your side — and it is justified by the operational savings.

Hybrids and additional logic

In practice, the line between the approaches blurs.
An aggregating proxy can support DevFee — a mechanism where a small percentage of hashrate (0.1%, for example) is redirected to a separate address. This is used for referral programs, partner platforms, and white-label operators. Technically it is “skimming off” a portion of the shares before aggregation — implemented at the proxy level and completely transparent to the upstream.
Another option is regional proxies as a job cache. The proxy keeps the current job locally and serves it to the connected ASICs without going to the upstream on every request. This reduces RTT for devices in remote regions and improves resilience during network flaps.

The bottom line

Proxy architecture is not a question of “which one is better”. It is a question of the control model: where you want decisions to be made, how much state you are prepared to maintain, and what your actual upstream scenario is.

1:1 is more transparent and simpler to operate. Aggregation gives you more room to maneuver — but shifts onto you the complexity the upstream used to handle.

Both models work in production. The choice is driven not by technical preference but by the specific infrastructure task.

If you are designing a mining pool or evaluating an existing architecture, we are ready to go through your situation. Write to us and we will run a technical review with no obligations.