Bellga is an XMRig fork with native VerusHash 2.2 (VRSC) and RandomX (ZEPH and XMR), optimized from PCs and servers all the way down to 32-bit ARM phones — and the pool for all three coins runs right next to it, on this same server. See the optimizations and supported processors →
Pieces already tested live against real pools and on real hardware, plus what is still in progress.
Step by step for the two supported platforms: x86-64 desktop/server and mobile via Termux or UserLAnd. Either way you end up with the same bellga executable — only the way it is compiled changes.
VerusHash needs AES-NI + PCLMUL + SSE4.1 — practically any general-purpose Intel/AMD CPU made after ~2011-2012. RandomX (ZEPH/XMR) runs on any x86-64.
The build uses CMake, just like the original XMRig — the VerusHash module is already enabled. The executable ends up in build/bellga.
Cuts down memory page swapping while hashing — a real hashrate gain at no cost.
How many huge pages you need depends on how many threads you run — 1280 pages (~2.5GB) covers most home setups; raise it if you have many cores.
Has to be reserved at kernel boot, through GRUB — unlike 2MB huge pages, it cannot be enabled at runtime.
Native build right on the device, no cross-compiling. It detects the CPU core on its own and picks the right optimization — see the processor list.
Works the same on Termux and UserLAnd — the script detects which one you are using. Already had the old xmrig-vrsc? Running the script again updates the same folder and leaves an xmrig shortcut pointing to bellga.
Without root, Android never gives write access to vm.nr_hugepages nor lets you lock memory out of paging — the miner works fine without it, just with slightly lower hashrate. To really enable it:
Rooting the device just for this is only worth it if the extra hashrate matters to you — it is optional, the miner runs without root too.
config.json is not tied to this pool — you can point it at any pool, for any coin Bellga mines.
This is the full reference — every field the miner accepts, pre-filled with sensible values (including dashboard and automatic benchmark submission, exclusive to this fork). The example is for VRSC: replace YOUR_VRSC_ADDRESS.worker_name with your real address before using it. For ZEPH or XMR, change algo to rx/0, the port to 3961 (ZEPH) or 3962 (XMR), and use that coin's address — or let the builder do it for you.
Same as above, with algo-perf pre-filled to skip the automatic calibration — on this build (32-bit, no hardware AES-NI/crypto extension) it crashes the miner with Bus error during the argon2/chukwav2 test, unrelated to VerusHash itself. Since rebench-algo stays false, the values here are just placeholders to satisfy the check — they do not need to be real hashrates.
url is the pool's host:port — switch freely between ours and any other (the builder already knows the addresses and ports of the main ones). user is always your address for the coin (VRSC, ZEPH or XMR) followed by . and a worker name of your choice, to tell each machine apart in the pool stats.
They do not exist in the original XMRig — only in Bellga:
| Field | Default | What it does |
|---|---|---|
| dashboard | true | Fixed, redrawn panel (hashrate 10s/30s/60s/avg, latest jobs/shares) instead of the scrolling log. |
| submit-benchmark | false | Turns on automatic benchmark submission — measures 90s of real mining, submits, then turns itself off. |
| submit-benchmark-duration | 90 | Seconds of measurement before submitting. |
| submit-benchmark-host | bellga.tech | Where it submits to. |
| submit-benchmark-port | 443 | Port of the host above. |
| submit-benchmark-path | /api/benchmarks/submit | Path of the submit route. |
| submit-benchmark-tls | true | Uses HTTPS to submit. |
| user-token | "" | Secret token of your account (in my account) — links this miner to your public profile. Empty = off. |
| user-machine-id | "" | Generated and saved automatically the first time — no need to fill it in. |
| user-report-interval | 60 | Seconds between heartbeats while mining. |
api/http: optional local HTTP API of the miner itself (not the pool API) — off by default.
autosave: if true, changes made through the API are saved back to config.json automatically — that is the mechanism submit-benchmark uses to turn itself off after submitting.
randomx: RandomX settings (ZEPH/XMR) — 1gb-pages: false by default, numa: true (important on multi-socket CPUs).
cpu: huge-pages: true, asm: true (assembly optimizations auto-detected for your CPU).
"verushash2.2": [-1, -1, -1, -1] is already set to 4 threads (adjust the number of -1 entries to how many cores/threads you want to dedicate — nproc on Linux shows the total). yield: false and priority: 5 make the miner fight for CPU without yielding to the rest of the system — a real hashrate gain, but the machine gets less responsive for anything else running on it. For an extra gain, replace each -1 with the number of the physical core you want to pin it to (e.g. [0, 1, 2, 3]) — this stops the OS from moving the thread between cores.opencl/cuda: GPU mining — off, Bellga is CPU-focused (VerusHash does not run on GPU in this port).
donate-level: % of time donated to the project (separate from the pool fee) — 1 is the minimum. When mining VRSC, ZEPH or XMR, the donation goes to pool.bellga.tech in the same coin.
pools: list of pools, with automatic failover if the first one goes down.
watch: reloads config.json automatically if the file changes on disk, no restart needed.
rebench-algo/bench-algo-time: automatic profit-based algorithm switching (MoneroOcean) — off on purpose, irrelevant for VerusHash.
pause-on-battery/pause-on-active: pauses mining on battery or while the user is active — relevant on a personal laptop/desktop, not on a VPS.
Same scheme for all three coins, the same one most pools use today — nothing exotic, so you know what to expect.
Follow your pending balance, past payouts and live hashrate on the stats page — sign in and save your addresses (VRSC, ZEPH or XMR) there to keep track.
No account needed — the "user" in config.json is your own address (VRSC, ZEPH or XMR, depending on the port) followed by a worker name of your choice. Payouts go straight to that address. Or use the config.json builder.