Demo build. This is a software product for sale — not an investment, token sale, or financial service. Coins shown run on testnet and have no monetary value. Buyers are responsible for their own licensing, compliance and any mainnet launch.

Demo pool testnet only no real mining revenue
BTC testnet XMR testnet ETC testnet RVN testnet KAS testnet GCC testnet

Worker names, sub-workers, and stats.

The fastest path from "I have a GPU or ASIC" to "shares are landing" on the testnet demo. Five steps.

01 The address.worker scheme

A miner identifies itself to the pool with a single username made of two parts joined by a dot:

text
<wallet-address>.<workername>
e.g. bc1q9z4f…h2vp.rig-01

The part before the dot is your wallet address — the non-custodial destination every share is attributed to. The part after the dot is a free-text label for the machine. The pool groups all attribution by the address, then breaks the statistics out by worker name so you can tell your machines apart. The worker label is optional; omit it and the pool treats the whole connection as a single unnamed worker under that address.

02 Many rigs as sub-workers

To run a fleet, keep the same address on every machine and give each one a different worker name. Each distinct name becomes a sub-worker the dashboard tracks on its own, while all their shares still flow to the one address.

bash
same address everywhere, one name per machine
# machine 1
-u bc1q9z4f...h2vp.rig-01 -p x
# machine 2
-u bc1q9z4f...h2vp.rig-02 -p x
# machine 3
-u bc1q9z4f...h2vp.gpu-loft-01 -p x

There is no need to register sub-workers in advance — a name appears in the dashboard the first time a machine connects with it. That also means a typo creates a new phantom worker rather than an error, so it is worth keeping the names tidy from the start.

03 What the dashboard surfaces

For each worker name the pool has seen, the dashboard shows the operational signals you need to spot a sick machine:

  • Accepted shares — valid shares the pool counted from that worker.
  • Rejected shares — shares the worker submitted that the pool discarded (stale, low-difficulty, or invalid). A small number is normal; a rising proportion is a tuning or connectivity signal.
  • Last seen — when the worker most recently submitted a share. A worker that has gone quiet has stopped, lost its link, or crashed.
  • Hash rate — the rate the worker reports, surfaced as-is. It is the miner’s own figure rather than an independent measurement, so treat it as indicative.
output
worker accepted rejected last-seen hashrate*
rig-01 4,812 3 2s ago 38.2 MH/s
rig-02 4,790 2 4s ago 37.9 MH/s
gpu-loft-01 1,204 61 9m ago 0.0 MH/s
* hashrate as reported by the miner

In that example gpu-loft-01 is worth a look: a high reject count, a last-seen nine minutes old and a zero hash rate together say the machine has fallen over.

04 Naming conventions that scale

With two machines any names work. With twenty, a convention saves you. A few that hold up:

  • Encode location and hardware, for example loft-3070-01 or garage-asic-02, so a problem worker tells you where to walk and what to check.
  • Zero-pad the numbers (rig-01, not rig-1) so the dashboard sorts them in the order you expect.
  • Keep it to letters, digits and hyphens. Avoid spaces and punctuation, which some miners mangle before sending.
  • Make every name unique. Two machines sharing a name collapse into one row, and you lose the ability to tell which one is misbehaving.