Mining Academy
- Home
- Academy
- Setup and Launch
Worker Names and Subaccounts in a Mining Pool Explained
Worker Names and Subaccounts in a Mining Pool Explained
A worker in mining is a single device (usually one ASIC) that connects to the pool under its own name. At RuPool the login is written as subaccount_name.worker_name: the part before the dot says which subaccount receives the hashrate, and the part after it names the specific machine in your statistics. A subaccount is a separate "folder" inside your account with its own wallets and its own statistics.
What a worker is and why it needs a name
When an ASIC connects to a stratum, the pool must know two things: who to credit the work to and which device it came from. The subaccount answers the first, the worker name the second. The pool counts accepted shares per worker and shows them in your dashboard: hashrate over different periods, online or offline status, time of the last share.
That lets you see not just the farm's total hashrate but the condition of each machine. With one ASIC the worker name is a formality. With ten or a hundred it becomes the main diagnostic tool: one row in the list tells you which machine dropped, where it stands and what to do about it. Without meaningful names you end up hunting for a dead ASIC by IP addresses and stickers.
The login format: subaccount, dot, worker
In the Worker field of the ASIC web interface (sometimes called User or Username) you enter a string like:
myfarm.rack1_s21_03
Here myfarm is the subaccount created in your dashboard and rack1_s21_03 is the worker name. The password can be anything, such as x, since the pool does not use it for authorization. The rules for a RuPool worker name: Latin letters, digits and underscores. Avoid Cyrillic, spaces, hyphens and above all extra dots, because the dot is reserved as the separator between subaccount and worker. Keep names in one letter case, preferably lowercase, so that Rig01 and rig01 do not become two different entries in your own tracking sheets.
Use the same login in all three pool blocks on the ASIC (primary and two backups), otherwise after a failover your statistics split across different workers. The other fields, addresses and ports are covered in how to connect an ASIC to a pool.
What a subaccount is and how it differs from a worker
A worker is a device; a subaccount is a logical container for a group of workers. Subaccounts are created in your dashboard under settings (/my/settings/subaccounts/). Each subaccount has:
- its own payout wallets per coin;
- its own statistics: total hashrate, list of workers, earnings history;
- its own name, which forms part of the ASIC login.
In other words, everything connected to one subaccount is treated as one "operation": payouts go to that subaccount's wallets and its report is separate from the rest. Your main account stays the single entry point from which you manage all subaccounts, including the watcher link, which gives read-only statistics without a password.
When you need separate subaccounts
One subaccount suits a private miner with a few machines. Separate subaccounts are for splitting flows:
- Different wallets. One part of the fleet pays out to a personal wallet, another to a partner's or a company's. Wallets are attached to the subaccount, so the split happens at that level.
- Clients and partners. If you host other people's ASICs or mine in a profit-sharing partnership, a subaccount per client gives transparent statistics you can show the owner through a watcher link without revealing anything else.
- Hosting. A hosting operator with a subaccount per client gets clean accounting: each client has their own hardware and their own earnings. More on this in the section on hosting.
- Different sites. Home, garage, a rented hall: a subaccount per site makes comparisons and troubleshooting easier.
- Tax and management accounting. If part of your mining is registered under a sole proprietorship or company and part under an individual, splitting by subaccount simplifies reporting. Discuss taxation with an accountant.
Do not create a subaccount per device: worker names are enough to separate machines inside one operation. Excessive splitting complicates wallet management, since each subaccount needs its own wallets.
Naming schemes for farms
A good worker name answers "what machine is this and where is it" without a lookup table. Any consistent scheme works; what matters is sticking to it. A few proven options:
| Scheme | Example | Best for |
|---|---|---|
| Sequential number | rig01, rig02 | a small farm in one place |
| Model and number | s21_01, l9_02 | a mixed fleet of different models |
| Rack, row, position | r2_p5_s19 | several racks where you need to find a machine by hand |
| Site and number | garage_03, hall_12 | several locations |
| Last IP octet | ip_137 | fixed addressing, easy to map to the web interface |
Practical recommendations:
- Leading zeros. Write
01, not1, so the list in your dashboard sorts predictably:rig02comes beforerig10. - Short and not overloaded. Long names get truncated in tables. Five to twelve characters is usually enough.
- Tie the name to the place rather than the model if machines get swapped often. After a repair or replacement the position's statistics stay in one row.
- Tie to the IP. Reserve addresses by MAC in the router and include the number in the name, so you can jump from a dashboard row to the machine's web interface.
- Uniqueness. Two devices with one name get their statistics mixed, and you will not notice that one of them has gone silent.
If you would rather not invent names by hand, use the name generator, which suggests options suitable for workers and subaccounts.
Example: three sites and two clients
Suppose you have two ASICs at home, twelve more in a rented space, and you host equipment for two acquaintances. A sensible layout: a subaccount own for your hardware with workers home_01, home_02, hall_01 and so on. Subaccounts client_ivanov and client_petrov, one per owner, with workers like s19_01. Each subaccount has its own wallets, so client earnings do not mix with yours, and each client can be given a watcher link to their own subaccount.
A month later you open the dashboard and see at once that hall_07 sagged while all of Petrov's machines are in place. Without this split you would be matching IP addresses to notes and manually working out who earned what. The choice of scheme is a matter of order, not technology, but the sooner you set that order up the less renaming you do later.
How to rename a worker and what happens to statistics
The worker name is set on the ASIC side, not in the dashboard: the pool learns it from the login at connection time. To rename, change the Worker field in the device's web interface for all three pools and save. After the restart the ASIC works under the new name, which the pool treats as a new worker: statistics for the old name stop updating. Earnings already credited are not lost, because payouts are tied to the subaccount's wallets, not to the worker name, so renaming does not move money anywhere; if in doubt, rename one machine first and check the statistics before editing the whole fleet.
This is exactly why names are worth planning in advance. Mass renaming across fifty machines is routine but slow work; many vendors and third-party tools let you change settings in bulk, but always verify the result in the dashboard.
Common mistakes in names and logins
- A dot inside the worker name:
myfarm.rig.01. There is one separator; use an underscore after it. - Cyrillic, spaces or special characters in the worker name.
- Different logins in the primary and backup pools.
- A typo in the subaccount name: the worker lands on the wrong subaccount or never appears.
- Identical names on different machines.
- Names like
testorasic, which tell you nothing about the device a month later.
FAQ
Can I use the same worker name in different subaccounts?
Yes. Subaccounts are independent, so identical worker names in different subaccounts do not conflict. Within one subaccount, keep names unique.
Do I need to create a worker in the dashboard first?
No. As a rule a worker appears in the statistics by itself once the ASIC connects with a subaccount.worker login and the pool receives the first shares. Only the subaccount has to exist beforehand.
What password should I use?
Any, for example x. The pool does not check it when authorizing a worker.
How do I let a client view their equipment without access to settings?
Create a separate subaccount for the client and give them a watcher link. It shows statistics without a password and does not let them change settings.
How many subaccounts do I need?
As many as you have independent operations: different wallets, clients or sites. For one owner's single farm, one subaccount is usually enough.