Start mining with FearMiner

One line installs FearMiner, checks it against the release key and keeps it running as a service. It mines what your cockpit gives it, or your wallet on the pool you choose. The manual way, download, check, run, is right below it.

The one line #

$ curl -fsSL https://get.fearminer.com | sh

PS> irm https://get.fearminer.com/win | iex

$ curl -fsSL https://get.fearminer.com | sh

Extra config arguments: --enroll fm1_...

Prefer to download? #

The same files on both hosts:

Then check, unpack and run by hand:

The warning at the first run

$ curl -LO https://github.com/fearminer/fearminer/releases/latest/download/fearminer-linux-x86_64.tar.gz
$ curl -LO https://github.com/fearminer/fearminer/releases/latest/download/SHA256SUMS
$ grep ' fearminer-linux-x86_64.tar.gz$' SHA256SUMS | sha256sum -c -
$ tar xzf fearminer-linux-x86_64.tar.gz && cd fearminer-*-linux-x86_64
$ ./fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET -w rig1

PS> Invoke-WebRequest https://github.com/fearminer/fearminer/releases/latest/download/fearminer-windows-x86_64.zip -OutFile fearminer-windows-x86_64.zip
PS> Invoke-WebRequest https://github.com/fearminer/fearminer/releases/latest/download/SHA256SUMS -OutFile SHA256SUMS
PS> (Get-FileHash .\fearminer-windows-x86_64.zip -Algorithm SHA256).Hash.ToLower()
PS> Select-String windows-x86_64 SHA256SUMS
PS> Expand-Archive fearminer-windows-x86_64.zip -DestinationPath . ; cd fearminer-*-windows-x86_64
PS> .\fearminer.exe -o stratum+ssl://POOL:PORT -u YOUR_WALLET -w rig1

$ curl -LO https://github.com/fearminer/fearminer/releases/latest/download/fearminer-macos-arm64.tar.gz
$ curl -LO https://github.com/fearminer/fearminer/releases/latest/download/SHA256SUMS
$ grep ' fearminer-macos-arm64.tar.gz$' SHA256SUMS | shasum -a 256 -c -
$ tar xzf fearminer-macos-arm64.tar.gz && cd fearminer-*-macos-arm64
$ xattr -dr com.apple.quarantine .
$ ./fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET -w rig1

Flight sheet: miner custom
Installation URL: the fearminer_custom-<version>.tar.gz asset of the latest release, https://github.com/fearminer/fearminer/releases/download/v1.15.2/fearminer_custom-1.15.2.tar.gz
Hash algorithm: qpow · Wallet template: %WAL%.%WORKER_NAME%
Pool URL: stratum+ssl://POOL:PORT · Pass: x
Extra config arguments: any option, for example -d 0,2 --tls-fingerprint SHA256

It works when you see this #

job 9dd830e6 diff 18.25G
✔ 1/1 · GPU0 · 18.25G · 24 ms
hashrate 618.4 MH/s (10m 611.9, session 609.8, eff 598.2 / 97.8 %)

job 4b1c77a2 diff 40.0K
✔ 1/1 · CPU · 40.0K · 31 ms
hashrate 7.1 kH/s (10m -, session -, eff -)

A job, an accepted share, a hashrate: it is mining. The first block is a GPU rig, the second a CPU one.

eff and the averages read - until ten shares are accepted in the window. Read the terminal panel and logs reads the whole start-up block line by line.

To stop: q in the terminal panel, or Ctrl+C. Either one stops cleanly, exit code 0.

Where the money goes #

An accepted share is not a payment. The pool credits it and pays you later.

The payout threshold, the schedule and the pool's fee are the pool's, not FearMiner's. FearMiner's own fee is separate and is shown in the terminal panel header (Algorithms, fees and requirements).

The cockpit at app.fearminer.com is free, needs no account and is end-to-end encrypted: the relay between it and your rigs passes sealed messages it cannot read. It shows the fleet's hashrate and history, sets what each rig mines, and pauses, resumes or restarts a rig.

Add a rig #

FearMiner already installed: fearminer enroll fm1_... on the rig, no restart. It prints the rig's name (XXXX-XXXX-XXXX-XXXX) and the fleet's; the cockpit shows the same names: compare them.

$ fearminer enroll fm1_...
$ fearminer remote status

Mining sheets #

With a notice, someone who got into your cockpit cannot move your hash in silence: you have that long to see it and stop it.

Enrolment and the remote channel #

Everything else has a working default.

The fearminer_custom-<version>.tar.gz asset of a release is a HiveOS custom miner: the binary and the four h-*.sh scripts in a fearminer_custom folder. HiveOS shows it as fearminer_custom. The stats come from the miner's own /hive-stats, forwarded as is.

The package builds the command line from those fields:

h-run.sh passes --allow-root, since HiveOS runs every miner as root and the binary otherwise refuses to start as root.

Nothing to add to the flight sheet.

A crash or a hung card restarts the mining process after a backoff.

/hive-stats comes back on the same port, with crashes per card and restarts on it.

The HiveOS watchdog covers the supervisor giving up (exit code 12).

--no-supervisor in the extra arguments runs one process and leaves every restart to HiveOS.

Stats contract:

The overclock stays with the flight sheet: without an OC option the miner touches no clock, power limit or fan register.

--no-oc in the extra arguments makes it explicit.

HiveOS runs the miner as root, so the OC options work there without the helper.

Beta, from 1.5.3: built to mmpOS's published custom-miner guide and checked against it, not yet run on a real mmpOS rig. Say what does not work, on the Telegram channel or in an issue. The fearminer_mmpos-<version>.tar.gz asset of a release is an mmpOS custom miner; in the mmpOS dashboard:

The same list is what fearminer --list-algorithms prints, one line per algorithm with a one-line description; with --json, one array of {name, coin, class, fee_bps, aliases, unit, hive, requirements, refused}.

The list is the signed engine index: a new algorithm is a new row here at the next build of this page, and a new engine on the rigs without a miner release (Engines, below).

The rate in the table is per algorithm, mined in one-minute rounds on a separate connection, never on your session, and shown in the terminal panel header.

It is a ceiling from the signed engine index, never above 5 %: the signed terms from cfg.fearminer.com may lower it, never raise it. An algorithm with no fee pool in the terms is mined free, said once at start.

fee window gives when the first round is due; each round logs fee round started (1 min) and fee round ended with its share count.

Engine downloads, updates and rollback #

The miner hashes nothing itself: each algorithm is an engine of its own, fearminer-engine-<algo>, a signed program the miner downloads, starts and keeps up to date. The pool session, the fee, the supervisor, the sensors, the API and the terminal panel stay in the miner.

A new algorithm of a login family the miner speaks is mined without a miner release.

The wallet of each chain #

The chain is read off the wallet, so the address alone picks the algorithm. Each is checksum-verified at start; --ignore-wallet-check sends what you typed.

The CPU engine: threads and placement #

The same rules under every algorithm.

RandomX: huge pages #

RandomX is 20 to 30 % faster with the dataset, the cache and the scratchpads in 2 MiB pages, up to 50 % on some machines.

Before allocating the dataset the miner counts what it needs:

So 1184 pages for 16 threads.

It reads the kernel's free pool and, when short, asks the helper below to grow it, per NUMA node where there are several.

At start: huge pages 100 % (1184/1184 x 2 MiB), or E609 with the number to reserve and the command.

Without the helper, reserve by hand right after boot, while memory is unfragmented, and keep the setting across reboots.

transparent_hugepage set to always backs what did not fit.

$ sudo sysctl -w vm.nr_hugepages=1184
$ echo 'vm.nr_hugepages = 1184' | sudo tee /etc/sysctl.d/90-fearminer.conf

1 GiB pages: --1gb-pages (huge_pages_1g in the file, off by default as in XMRig).

It reserves three 1 GiB pages per NUMA node for the dataset when the CPU has them (pdpe1gb), 1 to 3 % over 2 MiB pages.

Used only where the kernel's default huge page size is 1 GiB: default_hugepagesz=1G hugepagesz=1G hugepages=3 on the kernel command line, which also reserves them before memory fragments.

Otherwise E610 says so and 2 MiB pages are used.

RandomX: the MSR tweaks #

XMRig's prefetcher settings on Ryzen and Intel are worth up to 30 % on an Intel, up to 6 % on a Zen. Its public values:

• Zen 1 and Zen 2
• Zen 3
• Zen 4 and Zen 5
• Intel Core

They need root: the miner asks the helper before its first network connection and never runs as root.

--msr auto, the default, picks the preset from the CPU's family and model.

With the helper there it is applied. Otherwise the miner names the loss and starts anyway:

Each line carries the estimated loss and the one-line fix.

Original values are read first and kept in a root-owned file.

They are written back at every end of the mining process, clean stop or crash (E614, or E608 when it cannot).

One block at start gives the engine's setup:

• JIT or interpreter
• hardware or software AES
• the MSR line
• the huge-page line
• the threads and their placement

It ends with the share of the ideal configuration reached (performance: about 52 % of the ideal configuration when both are missing).

--list-devices --json -a randomx gives the same under cpu.performance, applying nothing (null under another algorithm).

$ fearminer -a randomx -o stratum+ssl://pool.example.com:3335 -u YOUR_WALLET.rig1 -t 50% --cpu-affinity 0-7 --msr zen4
randomx  MSR zen4 preset applied on 16 CPU(s) via /usr/local/bin/fearminer-helper (sudo)
randomx  huge pages 100 % (1184/1184 x 2 MiB)
randomx  8 thread(s) on CPU 0-7 (--cpu-affinity)
randomx  performance: the ideal configuration (JIT, hardware AES, huge pages, MSR)

The helper: fearminer-helper #

fearminer-helper ships next to fearminer in the Linux archive and is the one privileged piece.

• A separate binary: no network, no configuration file, no dependency on the miner.
• It writes the MSR registers and grows the huge-page pools on request.
• It logs every step to stderr and answers one JSON line.
• The miner runs it as sudo -n fearminer-helper ... (never through a shell) before its first network connection, and holds no privilege afterwards.
• The miner never runs as root.
• A miner that is itself root (--allow-root, HiveOS) does the same in-process and never calls it.

Install:

• Copy it to /usr/local/bin.
• fearminer-helper install then prints the sudoers line for your user and this path, plus the systemd drop-in wiring it into fearminer.service; it writes nothing itself.
• Put the line in /etc/sudoers.d and load the msr module.

Check with status: one JSON line, no privilege needed, giving what the machine allows.

• the msr module and its allow_writes
• kernel lockdown, Secure Boot, a hypervisor
• huge pages free and total by size and node
• the preset auto would pick

Search order:

• /usr/local/bin/fearminer-helper
• the path the sudoers line names
• the archive's copy next to the binary, which no sudoers rule covers

A sudo that refuses one is followed by the next.

--helper PATH replaces both and is the only path tried.

When sudo refuses it, or nothing is there, E601 says so and names both paths.

$ sudo install -m 0755 fearminer-helper /usr/local/bin/fearminer-helper
$ fearminer-helper install
$ echo 'USER ALL=(root) NOPASSWD: /usr/local/bin/fearminer-helper' | sudo tee /etc/sudoers.d/fearminer-helper
$ sudo chmod 0440 /etc/sudoers.d/fearminer-helper
$ sudo modprobe msr && echo msr | sudo tee /etc/modules-load.d/msr.conf
$ sudo -n /usr/local/bin/fearminer-helper status

Original MSR values: /run/fearminer-helper/msr.json, root-owned, until msr restore or the next boot.

Pages a run reserved are returned when it stops, never below what another process uses (E615 if not).

The supervisor restores after every end of the mining process, clean stop or crash.

Under systemd the drop-in adds ExecStopPost=fearminer-helper msr restore and ExecStopPost=fearminer-helper hugepages release, the backstop if the supervisor dies.

Miner commands:

Exits:

Not done yet: RandomX v2 (rx/2, the next Monero fork), and a dataset copy per NUMA node (one copy for all of them today; the start line says how many nodes the threads are spread over).

Pearl #

• A noised int8 matrix product whose 8 x 8 tiles are hashed against the share target; the Merkle proof of a winning tile is the share.
• sm_86, sm_89 and sm_120 (RTX 30, 40 and 50 series), with 4.7 GB free; another card is left out with the reason (E310 for the memory). The NVIDIA driver is all it needs. Not on macOS.
• No CPU engine: -t is refused (E202).
• The rate is in T (10^12 multiply-accumulates a second), the unit its pools credit; the API gives MAC/s, HiveOS TH/s, the efficiency GMAC/W.
• Every proof is verified by the chain's verifier inside the engine, then again by the miner before it is sent (section 10).
• The pool must speak Pearl's "type": "v2" stratum, and is your choice: fearminer -o stratum+ssl://POOL:PORT -u prl1... -w rig1.
• Fee 1 %, a ceiling: nothing is charged until the signed terms name a Pearl endpoint, and the start says so.

Quantus #

• NVIDIA needs a driver of the 550 series or newer, 570 for RTX 50; the preflight prints the one installed.
• A card with no native engine runs on Vulkan, at about a third of the rate.
• On a rig with a GPU the CPU engine is off and -t N turns it on; on a rig without one it is on, with every thread but two.
• The first start tunes the kernel on your card and caches the result; --retune measures again.

RandomX #

• The RandomX library of tevador, v1.2.3, built into its engine.
• Allocated once: dataset 2080 MiB, cache 256 MiB, scratchpad 2 MiB per thread. A machine that cannot hold the dataset mines on the cache alone, many times slower, and says so at start.
• The dataset is rebuilt on every new seed hash, every 2048 blocks, about every three days: a few seconds on every core.
• Threads are capped by the L3 cache at 2 MiB each, and a sibling hyperthread adds nothing.
• Huge pages are worth 20 to 30 %, up to 50 % on some machines, and the MSR tweaks up to 30 % on an Intel, 6 % on a Zen. Both below.
• Pools speak the CryptoNote stratum: any pool XMRig connects to.

TensorCash #

• A proof of inference: windows of the registered model, Qwen3-8B, run on the card, and a share is a proof of 166 to 200 KB. The rate is in PoI/s, proofs of inference a second, and compares with no hashrate.
• NVIDIA only, with 11.1 GB of GPU memory free; a card short of it (another model loaded on it, say) is left out with E310. No CPU engine.
• The pools are WebSocket brokers: -o wss://host/v1/ws -u tc1q....rig1 -p token-file=<path>. The engine holds the pool session and reads the pool's token from that file (mode 600); the miner never reads it or shows it. Only the first pool is used for now.
• From the cockpit, a TensorCash sheet needs FearMiner 1.7.1 or later on the rig; the token stays on the rig, as above.
• The engine's own settings (its backend, the model's weights pinned by their SHA-256, the host the token goes to) are a file named by TSC_POOL_CONFIG.
• No offline benchmark: --benchmark says so and ends with code 3, and -a all skips it with the reason. Its rate is measured on a pool.
• A rejected share, or a pool that refuses the login, ends the session (E114): the miner stays up without mining until it is restarted.
• Fee: 2 %, mined by the engine itself on the same pool, on FearMiner's own tc1q... account, not in one-minute rounds.

• -o can be repeated, or given once with the URLs comma separated; FEARMINER_URL=A,B does the same.
• The order is the priority: first pool primary, the rest its backups.
• The wallet, the password and the TLS pins (--tls-fingerprint, --tls-spki) are given once for all pools, or once per pool in the same order.
• Any other count is E203.
• Every connection, probes and fee rounds included, goes through the same dialer: the proxy, the resolver and the address family policy below.

--job-timeout #

After --job-timeout seconds without a new job the workers stop. The miner reconnects under the same rules as a lost connection (E105).

Unless set, the figure is the chain's own:

The line says which; 0 turns the guard off.

TLS: the public roots, a pin, or trust on first use #

stratum+ssl:// is TLS 1.2 or 1.3 (1.3 preferred), host name as SNI. --tls adds it to a bare host:port.

The negotiated protocol and cipher print once per connection.

A certificate the roots do not sign (a node, a P2Pool, a private pool) must be pinned.

A failed handshake never falls back to plain TCP.

Either pin: one value for all pools, or one per pool in pool order, - for a pool without one.

A mismatch (E103) prints the pin and what the pool presented, same notation.

$ fearminer -o stratum+ssl://pool.example.com:3335 -u YOUR_WALLET.rig1 --tls-fingerprint 3a3524b6...c8307
$ openssl s_client -connect pool.example.com:3335 </dev/null 2>/dev/null | openssl x509 -fingerprint -sha256 -noout
$ fearminer -o stratum+ssl://node.lan:3335 -u YOUR_WALLET.rig1 --tls-spki sha256/BASE64
$ openssl s_client -connect node.lan:3335 </dev/null 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
$ fearminer -o stratum+ssl://node.lan:3335 -u YOUR_WALLET.rig1 --tls-tofu
TLS: first contact with node.lan:3335: certificate 3a3524b6...c8307 remembered
$ fearminer -o stratum+ssl://node.lan:3335 -u YOUR_WALLET.rig1 --tls-tofu --tls-tofu-reset node.lan:3335
$ fearminer -o stratum+ssl://10.0.0.2:3335 -u YOUR_WALLET.rig1 --tls-insecure
TLS: 10.0.0.2:3335 TLS 1.3 TLS13_AES_256_GCM_SHA384, certificate not verified (--tls-insecure), SHA-256 3a3524b6...c8307

--tls-tofu trusts the certificate on first use.

• The first handshake prints the pool's certificate fingerprint and keeps it in tls-pins.json in the state directory, keyed by host:port.
• A later handshake with another certificate is refused with E118, which prints both fingerprints, and the pool is left for the next.
• To accept the new certificate: start once with --tls-tofu-reset host:port (repeatable), or delete the entry from the file.
• A pool with its own --tls-fingerprint or --tls-spki is checked against its pin, not the file.
• A tls-pins.json that exists and cannot be read is E119: the miner does not start.

--tls-insecure checks nothing: whatever certificate the pool presents is accepted, with no chain, name or expiry check.

• It is for a TLS port forward or a proxy, where the name dialled is not the pool's and the roots refuse a path that works. The E102 line of such a refusal names it, beside a pin.
• The session stays encrypted, but anyone on the path can impersonate the pool and take the rig's work: every start says so (E120), and the TLS line prints the SHA-256 of the certificate presented, which --tls-fingerprint takes. A pin is the safer choice when the certificate is known.
• A pool with its own pin keeps it. Refused with --tls-tofu, and when no stratum+ssl:// pool without a pin is left.
• The fee rounds go the way the pools go. The terms, the engines, the telemetry and the cockpit's relay are always checked against the public roots.
• It needs a restart. A cockpit's mining sheet can carry it for its pools, and a sheet that changes it restarts the miner.

The connection's TLS line gives what held.

Proxy and DNS #

--proxy socks5://[user:pass@]host:port routes every pool connection through a SOCKS5 proxy:

• the mining session
• the probes on the primary
• the fee rounds

The pool is never tried directly while a proxy is set.

A password in the URL is masked in the log and in --dry-run, but shows in the process list: set it in the configuration file or the environment.

The proxy carries the pool connections, the engines' downloads, the cockpit's relay link and the telemetry. These go direct, over HTTPS, and show the rig's own address to their endpoints:

• the fetch of the signed fee terms (cfg.fearminer.com)
• the notifications
• the heartbeat of --heartbeat-url

A rig that must reach the network through the proxy alone keeps the proxy for the pools: the terms fetch then fails harmlessly (E111: the miner mines with the last terms it verified, or with the built-in ones).

$ fearminer -o stratum+ssl://pool.example.com:3335 -u YOUR_WALLET.rig1 --proxy socks5://127.0.0.1:9050
network  proxy socks5://127.0.0.1:9050 (the proxy resolves) · ip any
dns      pool.example.com: resolved by the proxy socks5://127.0.0.1:9050, no local lookup
$ fearminer -o stratum+ssl://pool.example.com:3335 -u YOUR_WALLET.rig1 --dns doh --doh-url https://1.1.1.1/dns-query
network  dns doh (https://1.1.1.1/dns-query) · ip any
dns      pool.example.com → 203.0.113.10 (doh https://1.1.1.1/dns-query)
$ fearminer -o stratum+ssl://pool.example.com:3335 -u YOUR_WALLET.rig1 --ipv4-only

DoH hides the names from the local resolver, not the pool from the network.

The TLS SNI and the pool's address stay visible on the wire; a proxy hides those.

With --proxy the proxy resolves.

--ip 4|6|any picks the address family.

A URL takes a bracketed IPv6 literal (stratum+tcp://[2001:db8::1]:3333).

Before the first connection the preflight's network and dns lines give how the pools will be reached and what each name resolves to.

They also give who answered: the system resolver, the DoH resolver, or the proxy with no local lookup.

Every pool socket carries TCP keepalive (60 s idle, a probe every 10 s, three probes), so a peer gone without a FIN is noticed in about a minute.

When the pool misbehaves #

A pool can also stall, stutter or lie; each case has a rule, a line with a code, and a counter on the pool's record (/api/v1/pools).

• A share with no reply: a submit waits --submit-timeout seconds (10) for its verdict; past that it is unanswered, not credited, said once (E125), counted under shares.unanswered. Any reply to a share, on time or late, starts the row over (a keepalive's does not). --max-no-submit-responses (10) in a row end the session (E113): reconnected at once, left for the next pool when the next session goes the same way.
• A refusal: every rejected share is one line with the pool's words and their class. Classes: low difficulty, stale, duplicate, unknown job, unauthorized, other, read off the Stratum v1 code when the pool sends one, off its wording otherwise. They are the pool record's rejected_by_reason counters; the last refusal's class rides the shares_rejected_high and gpu_unstable events.
• No job: no new job for --job-timeout seconds on a live socket ends the session (E105), the workers stopped first; the figure is the chain's own unless set, and the start's pool line gives which is in force.
• The same job again: a job whose id and work were already seen on the connection is ignored with a debug line (jobs_duplicate). A job carrying an older job's work under any id is a replay: ignored, said once per session (E128), counted (jobs_replayed); the workers stay on the current job. Judged on the content, never on the id alone.
• A job searched out: the rig has done as many hashes on a job as the job has nonces. That is 2^32 on RandomX, whose nonce is four bytes; a Quantus job offers more than any rig searches. The search stops (E127, once per job, nonce_space_exhausted) and the workers wait for the next job instead of hashing the same nonces again.
• A message: client.show_message is shown once, as text, tagged with the pool; the escape sequences and the control characters are taken out, the text is cut at 200 characters, and nothing in it is ever interpreted. The same text again is not shown.
• A redirect: client.reconnect (host, port, wait) is followed only when the host is in the pool list, on any port, after the wait it asked for, capped at 60 s. A redirect anywhere else is refused with one E126 line naming the host; the session goes on where it is. A redirect to another pool of the list is a move to that pool: the session logs in with that pool's wallet, password and pin, and it counts as a pool switch.
• Slow replies: --max-latency, above (E129).

$ fearminer -o A -o B -u YOUR_WALLET.rig1 --submit-timeout 15 --max-latency 300
E125 share unanswered: share 42 on job j7 from GPU0 not answered within 15 s (3 unanswered in a row)
E129 pool latency over the limit: pool: moving to stratum+ssl://B (backup 2/2): answers in 48 ms, stratum+ssl://A in 310 ms
[ REJECTED ] 3/10 · GPU0 · 4.00M · stale · "Stale share" · 40 ms

The wallet and its pool #

A wallet always comes with its pool: -o (or FEARMINER_URL, url or [[pools]] in the file) beside -u, WALLET, FEARMINER_USER or user. The pool is your choice; the miner never picks one.

Without -a, the chain comes from the address: every algorithm of the build is asked whether it decodes for its chain, nothing is guessed.

Each is refused before anything connects, exit 2, at a start as under --check-config.

With no wallet and no pool the miner mines for no one.

The preflight runs, the terminal panel shows the cards with their telemetry, /stats says mode monitoring, until Ctrl+C.

-d picks the GPUs:

• by index, as --list-devices prints them (PCI order, same as nvidia-smi)
• by PCI id
• by UUID
• by vendor
• by exclusion

Items combine as a set.

NVIDIA gets the exact cards; Vulkan and Metal take the first N, -d 0..N-1 only.

-d is refused on a CPU-only algorithm (RandomX).

cpu is not a card, -t picks CPU threads.

--list-devices prints the listing and nothing else.

One value per card #

One grammar for every per-card option (--temp-limit, --temp-resume).

• A single value covers every card.
• Comma-separated values go one per card, in the order of the cards mined on: -d order with a use-list, listing order otherwise; an excluded card keeps its place.
• _ keeps that card's default.
• A list shorter than the cards leaves the rest at their default.
• A longer one is E206 with the count.

--dry-run prints how a list lands (gpu: --temp-limit #0 85, #2 80).

The first --temp-limit position is the common core limit.

A position that differs is that card's own, resumed the same distance below it as the common pair: --temp-limit 90,80 --temp-resume 75 pauses card 1 at 80, resumes it at 65.

--device-missing #

A -d item naming no card here (-d 5 on a one-card rig, a UUID from another rig): E206, exit 2, before any engine starts; --check-config says the same.

--device-missing first or last (FEARMINER_DEVICE_MISSING) keeps the configuration and mines the selected cards that exist; the log names those expected and not found.

Per-card lists lie over the cards found from the first position on (first) or from the last back (last).

A selection with no card present selects nothing: the log says no card of the selection is present, the CPU threads mine.

With -t 0 the start is E301 (exit 3), predicted by --check-config and --dry-run with the same line and code.

Excluding an absent card excludes nothing under either.

--list-devices --json #

--list-devices --json prints one JSON document:

• the cards in the driver's order (the indices -d takes), each with its engine (null for a card left out, or on an algorithm without a GPU engine)
• the CPU
• the RAM

Facts come from nvidia-smi, the driver's files and sysfs, the readers of the checks before a connection.

A fact nothing gives is null, never a guess.

{"gpus": [{"index": 0, "name": "NVIDIA GeForce RTX 4070 Ti", "pci_bus_id": "0000:01:00.0",
           "uuid": "GPU-3f2a1b4c-5d6e-7f80-9a1b-2c3d4e5f6a7b", "vram_mb": {"total": 12282, "free": 11870},
           "compute_capability": "8.9", "driver": "570.86", "vendor": "nvidia", "engine": "cuda"}],
 "cpu": {"model": "AMD Ryzen 9 7950X 16-Core Processor", "physical_cores": 16, "threads": 32, "l3_mib": 64, "aes": true, "numa_nodes": 1},
 "ram_mb": 64036}

Device states #

Every state change is logged with its code and, under the supervisor, appended to watchdog.log. /stats carries state per card, aligned with hs; /api/v1/devices, state per entry.

Sensors #

NVML reads the NVIDIA cards twice a second:

• core temperature
• fan
• board power and its limit
• clocks
• the driver's throttle reasons

And where the card exposes them:

• memory temperature (most cards from the 3090 class up; a laptop or small card says nothing)
• the energy counter
• the volatile ECC counters (with ECC on)
• the PCIe replay counter
• the PCIe link now and at maximum (gen 1 x1 under load: a bad riser)

The terminal panel row shows the temperatures the card has (64°C · mem 78 · hot 81).

/api/v1/devices and /stats carry every reading (temp_mem_c, temp_hotspot_c, energy_mj, throttle_reasons, ecc_corrected, ecc_uncorrected, pcie_replays, pcie_gen, pcie_width, pcie_max_gen, pcie_max_width), null where there is none.

Throttle reasons are stable labels: idle, app_clocks, power_cap, hw_slowdown, sync_boost, sw_thermal, hw_thermal, hw_power_brake, display_clock; [] when none.

The hotspot (junction) sensor is not in NVML, so it stays absent on NVIDIA.

The last XID error is not reported: no NVML API, and the kernel log needs root.

--no-nvml leaves NVML closed, for a driver whose NVML misbehaves: every reading absent (null on /api/v1/devices and /stats).

The gpu start line then says sensors off (--no-nvml): no thermal cut-off instead of the thresholds, and mining goes on.

Vulkan and Metal report no sensors.

Thermal cut-off #

Each sensor has its own limit:

0 disables that sensor's cut-off.

A sensor must hold at or over its limit for --temp-hold seconds (15) before the card pauses; a dip below restarts the count.

The card finishes its search, then idles, sensor and reading on the row (Paused (mem 106 °C)).

It resumes once every sensor that held it has cooled past its resume point: core to --temp-resume (75), memory and hotspot to their limit minus --temp-hysteresis (10).

A sensor that stops answering while holding the card keeps holding it.

Logged once on pause (E306: sensor, reading, limit, resume point) and once on resume.

temp_high fires after ten seconds of pause, temp_critical after ten minutes or at 10 °C over the limit.

--temp-limit and --temp-resume take one value per card.

--temp-shutdown is the last resort, off by default.

A paused card whose core holds at or over it for --temp-hold seconds, counted from that pause, stops the miner: exit code 11, E319 on the log, a temp_critical event.

Under the supervisor the miner restarts after its backoff and gives up after --max-restarts if the card is still that hot; that card is blamed for taking the miner down.

The value must be over --temp-limit: the cut-off pauses first, the shutdown catches a card that keeps heating while paused (a dead fan, a card heated by its neighbours).

$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET --temp-limit 85 --temp-limit-mem 100 --temp-hold 20 --temp-shutdown 95
$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET -d 0,1,2 --temp-limit 85,80,_ --temp-resume 70,65,_

Before it connects #

Runs after the arguments, before the fee terms, the stats port and the pool. One line each.

A -d index past the cards the driver lists: E206, exit 2, before any engine starts.

Nothing left to mine on: E301, exit 3, before any connection. That is every card left out by -d or by the checks, or none at all, and no CPU thread (-d '!0' -t 0 on a one-card rig). The same list with -t 2 mines on the CPU, the card shown Excluded.

--check-config runs these device checks too. --skip-preflight prints the same report and applies nothing.

Facts come from the driver's files and nvidia-smi (600 ms), never an engine. The check takes well under a second.

Crash counters #

A mining process that exits because of a card (hang, watchdog verdict, thermal shutdown) names it; the supervisor folds it into crashes.json in the state directory.

Keyed per card by UUID when the driver gives one, by PCI id otherwise, never by index: a card keeps its record in another slot, a new card in the same slot starts clean.

Each record:

• count
• last time
• last cause
• times of the last crashes

A card lost while the miner goes on is counted by the child.

The terminal panel row shows crashes N once there is one.

/api/v1/devices carries crashes per card, /api/v1/summary restarts, the supervisor's count this run.

Blamed for --device-quarantine restarts (3) within --restart-window, a card is Quarantined at the next start.

--reset-crashes clears the file.

A crash after a long stable run means too much overclock; a crash at the first search points at the driver, the riser or the slot.

Tuning #

At first start the miner measures a few launch geometries on your own card and caches the best in tuning.json (~/.config/fearminer on Linux and Windows, ~/Library/Caches/fearminer on macOS).

--retune measures again, after a driver change for example.

--gpu-batch is a floor for the nonces per launch, rounded up to whole passes of the card's tuned geometry, the batch in force on the CUDA device start line.

--throttle pauses between batches, for a card that must stay quiet.

Defaults are the measured values.

Overclocking #

Off unless asked: without an OC option the miner touches no clock, power limit or fan register.

An overclock set outside (HiveOS flight sheet, Afterburner, nvidia-smi) stands.

--no-oc makes it explicit: every OC option and any [oc] section ignored, said on the start log.

Given an option, the card is set through NVML (NVIDIA; no X server needed, the calls of nvidia-smi -lgc, -lmc and -pl) and read back after every set.

The log, fearminer oc show and /api/v1/oc give the read-back, never what was asked.

Setting a clock, power limit or fan needs root on Linux, administrator on Windows; the miner runs as a plain user.

Run it as root with --allow-root (HiveOS does), or keep the overclock outside.

Without the privileges every set is E703 with what to do, and mining goes on at the card's current clocks.

AMD and Intel are not controlled in this version.

Six value options: --cclock, --lock-cclock, --mclock, --lock-mclock, --pl, --fan.

Each takes one value for all cards, or one per card in -d order with the --temp-limit list grammar (_ leaves that card alone).

Settings reach the card in a safe order:

• power limit and fan
• then memory
• then core, held back by --oc-delay for rigs that crash when the offset lands on a cold card

One line per set; one line per refusal, with its code and the card's own bounds or steps (E701 to E705).

A refused setting leaves the others alone.

Every change opens a step; ten minutes later a summary gives the rate averaged over the window and the shares accepted, rejected and invalid since the change.

$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET --lock-cclock 1500 --mclock 800 --pl 220
$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET -d 0,1,2 --cclock 100,_,-50 --pl 80% --fan 70% --oc-delay 20
oc       GPU0: applied pl 176 W, mem +800; reads core 1900 MHz (+0), mem 10251 MHz (+800), pl 176 W, fan 40 %
OC step: GPU0 core +100, mem +800, pl 220 W -> hashrate over the next 10 min and rejects/invalids
$ fearminer oc show
$ fearminer oc reset
$ fearminer oc reset --defaults -d 0

Before the first set, each card's read-back (offsets, power limit, fan mode and speed, clocks) goes to oc-restore.json in the state directory, keyed by UUID: the values at launch, not the factory ones.

E706 if it cannot be written, and nothing is applied.

Put back:

• at a clean stop
• by the supervisor after the mining process crashed or was killed (before the restart)
• by fearminer oc reset after a run killed without cleanup

Every restoration line carries the cause (E708).

The driver has no read-back for a lock, so a lock the miner set is reset to the driver's default, removing a lock set outside before the start too.

Offsets, power limit and fan return to their read-back.

Both take -d.

In the file each option is a key of [oc] and a FEARMINER_<OPTION> variable.

Per-algorithm sets go in [oc.quantus], [oc.randomx]..., applied at start for the algorithm mined, over [oc] and under the environment and the command line.

--dry-run prints the sets and the resulting policy as oc:.

[oc]
pl = "80%"
oc_delay = 20

[oc.quantus]
lock_cclock = 1500
mclock = 800

POST /api/v1/oc is the API's one write: a set on one card at once, the delay aside, read back and recorded for the restore like the options.

It needs the token from anywhere, this machine included.

--oc-script PATH runs a program of yours once per card before mining starts, with the card in its environment.

Every engine the run mines with answers its known-answer vectors before the first share.

Every solution a card hands back is re-computed on the CPU before submit.

A miscomputing card is found at start, not after a day of rejected shares.

One that starts miscomputing is found at its first wrong solution, which the pool never sees.

The record, and when the test is skipped #

selftest.json in the state directory holds one record per engine:

A start skips an engine's test and says so (selftest cuda: passed on <date> ...; skipped) when the record shows a pass on:

• the same binary and the same engine version
• the same driver
• the same cards in the same order
• the same engine configuration
• at least as many nonces

It runs again on a new binary, a driver update, a card added, removed or moved, a knob changed, more nonces asked for, or a failure on record.

--self-test on a mining run forces it at start.

Alone, without pool or wallet, --self-test runs offline for the algorithm of -a (--self-test=randomx for another, --self-test=all for every algorithm of the build).

It prints one line per device and per engine, records the verdict, and exits 0, or 3 when a device failed.

Verified shares #

A GPU solution is re-computed on the CPU with the algorithm's reference before submit: every one while the check stays inside its budget, one in ten past it (below).

For Quantus: the Poseidon2 hash of the header and the 64-byte nonce against the target, about 6 µs on a desktop core.

A refused solution is never sent: dropped, and logged under E507 with the card and the overclock hint (first search: the miner or the driver; after a long stable run: likely the overclock).

Where it shows:

The count is the miner's own, not the pool's.

CUDA and Metal already re-check candidates inside the kernels' crate.

Vulkan hands back its kernel's hash, and the host check is its only one.

CPU solutions are not re-checked: the engine that found them is the reference.

Every solution is checked while the check costs under 1 % of a core in the current second, and one in ten past that.

That budget is 10 ms, or 1 600 solutions a second at 6 µs; a pool serves a rig one every few seconds at most.

--verify-shares off (FEARMINER_VERIFY_SHARES=off) turns it off: a wrong solution is then submitted and counted by the pool as rejected.

Started to mine, fearminer is a supervisor plus the mining child it re-executes with the same arguments.

The supervisor holds no GPU context and survives whatever the driver does to the child.

The terminal panel and the plain log are the child's, unchanged.

The supervisor prints only its own events, prefixed supervisor:, and appends them to watchdog.log.

The watchdog #

• One record per GPU worker, judged twice a second, plus the session's own verdicts.
• Every verdict is logged with its code and cause and appended to watchdog.log.
• Each rule is off on its own at 0.
• A paused or quarantined card is not judged.
• A card's clocks (grace, share windows, ten-minute average) start over on a thermal resume and on a session reconnect.
• The session-level rules (--max-rejects, --max-no-submit-responses, --no-share-timeout) apply to a CPU-only rig too.

$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET --hashrate-min 60% --hashrate-grace 600 --share-famine 8 --max-rejects-device 3
$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET --hashrate-reference 600M,350M --hashrate-max 1.2G --device-quarantine 2

--on-failure #

exit (the default) or script:<path>: the script runs first, with the exit code, the cause and the restart count in its environment, then the supervisor exits 12. Power-cycle a riser there, or page someone.

$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET --max-restarts 5 --restart-window 30 --on-failure script:/opt/fearminer/on-failure.sh
# on-failure.sh: FEARMINER_EXIT_CODE, FEARMINER_CAUSE, FEARMINER_RESTARTS in its environment

--no-supervisor · --no-watchdog #

A benchmark, --list-devices, --self-test and the other one-shot runs are always one process.

The supervisor (or the single process) takes an advisory lock on fearminer.lock in the state directory. A second instance exits 4 (E210).

The OS releases the lock whenever the holder dies, so a stale lock never blocks the next start.

watchdog.log #

The supervisor's own log, in the state directory (~/.cache/fearminer), capped at 256 KB: every restart with its timestamp and cause, every give-up. The child's log goes to the console and, with --log-file, to the file you name.

A TOML file, one key per option: the third way to set the miner up, beside the command line and the environment.

config example prints a complete one.

--dry-run shows what it makes and whether the miner would start; --check-config gives the verdict alone.

Where it is looked for #

The first that exists is read; --config "" reads none. The miner never writes it, and it is nowhere near the state directory.

A mistake never leaves an option silently at its default.

To a Telegram chat, a Discord channel, your own webhook, or all three.

The bot token, the webhook tokens and the secret never appear in the log.

The events #

What keeps the noise down #

• --notify-min-severity (warning by default) is the bar under which nothing is sent.
• Pending when it appears, firing once it has held for its confirmation delay: hashrate_low 120 s, gpu_down 30 s, temp_high 10 s, pool_disconnected 60 s; the others immediate. A pool back in thirty seconds is never mentioned.
• A firing condition repeats every four hours at most, and is resolved with a message when it clears: hashrate_low by hashrate_recovered, pool_disconnected and pool_failover by pool_recovered, temp_high by the resume, gpu_down by the card mining again.
• rig_down covers gpu_down, which covers hashrate_low, as does pool_disconnected: a covered alert is not told, and neither is its resolution.
• What is told within thirty seconds goes out as one group, one message per chat; a critical event does not wait. The log shows alert firing: ... and alert resolved: ... for what was sent. /stats counts alerts_firing and notifications_sent.

The webhook #

One POST per notification: Content-Type application/json, User-Agent fearminer/<version>, X-FearMiner-Event with the event's name, and with --notify-secret X-FearMiner-Signature, the HMAC-SHA256 of the body under the secret. Body, format version 1:

POST your URL
Content-Type: application/json
User-Agent: fearminer/1.15.2
X-FearMiner-Event: gpu_down
X-FearMiner-Signature: sha256=<hex>

{
  "version": 1,
  "event": "gpu_down",
  "severity": "error",
  "status": "firing",
  "rig": "rig1",
  "ts": "2026-09-22T10:00:00.000Z",
  "fingerprint": "gpu_down/rig1/0",
  "labels": {"rig": "rig1", "device": "0", "pci": "0000:41:00.0", "device_name": "NVIDIA GeForce RTX 3090", "pool": "stratum+ssl://pool.example.com:3335"},
  "annotations": {"cause": "..."},
  "summary": "GPU0 lost (reported by the driver)",
  "details": ""
}

Telegram gets a sendMessage with plain text (no Markdown), Discord a content with the same text, one message per group.

The heartbeat #

A service without them (an Uptime Kuma push URL, with its query string) works with the plain URL; its /start and /fail get 404.

Failures log at debug, one warning per ten minutes at most.

The ping: a 10 s timeout, never blocking mining.

Under the supervisor, the mining process sends the events and the heartbeat; the supervisor sends watchdog_restart and, giving up, rig_down, with the same settings.

GET  https://hc-ping.com/UUID          every 60 s
GET  https://hc-ping.com/UUID/start    at startup
GET  https://hc-ping.com/UUID/fail     on a critical event
POST {"rig","hashrate_hs","hashrate_effective_hs","shares_accepted","shares_rejected","uptime_secs","restarts","alerts_firing"}   --heartbeat-post

A versioned API beside /stats, on 127.0.0.1:4300 by default: the reads, plus three writes.

Every object under /api/v1 carries api_version (1), the path's version.

The server is up before the terms are fetched and before the first connection (zeros and nulls until then, mode already set), and stays up through reconnections and fee rounds.

$ curl -s http://127.0.0.1:4300/api/v1/summary | jq .hashrate
$ curl -s -H "Authorization: Bearer $(fearminer token show)" http://rig:4300/api/v1/devices
$ curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:4300/readyz
$ fearminer token rotate
$ curl -s -X POST -H "Authorization: Bearer $(fearminer token show)" -H 'Content-Type: application/json' -d '{"device": 0, "power_limit": "80%"}' http://127.0.0.1:4300/api/v1/oc
$ curl -s -X POST -H "Authorization: Bearer $(fearminer token show)" -H 'Content-Type: application/json' -d '{"command": "pause"}' http://127.0.0.1:4300/api/v1/commands
$ curl -s -X PUT -H "Authorization: Bearer $(fearminer token show)" http://127.0.0.1:4300/api/v1/config

Under HiveOS the stats port is fixed at 127.0.0.1:4300, where h-stats.sh reads /hive-stats. On a host reachable from untrusted networks, firewall the port before opening it with --api-bind.

mode is mining or monitoring. effective_hs and effective_pct are null under ten accepted shares in the window. efficiency_kh_per_w is null without a power reading. time_to_first_share_s is null before the first accepted share. Full schema of every object: /openapi.json.

A sensor the card or the driver does not give is null; with --no-nvml every sensor is null.

Commands and a configuration reload work on a running miner, with no restart. Four ways in: the local API, the terminal panel, a signal, a file in the state directory. Nothing here leaves the machine.

Four ways to send one #

• POST /api/v1/commands, with the token from anywhere, this machine included (Use the local API).
• The terminal panel: p holds the whole rig and lets it go again, 1 to 9 one card each (1 is GPU0).
• SIGUSR1 toggles the rig's pause, one per signal. Send it to the pid a service manager knows, the supervisor's, which passes it to the mining process.
• Sentinel files, no token and no right to signal needed: <state dir>/stop, /pause and /resume. The miner consumes each, that is deletes it, within a second. The same file written again is the same command again. A file that cannot be deleted is E137 and is not acted on.

$ curl -s -X POST -H "Authorization: Bearer $(fearminer token show)" -H 'Content-Type: application/json' -d '{"command": "pause", "devices": [0]}' http://127.0.0.1:4300/api/v1/commands
$ kill -USR1 $(pgrep -o fearminer)
$ touch ~/.cache/fearminer/pause
command  pause from file: the rig paused
command  stop from api refused: E217 command not allowed: stop needs --unrestricted-api operate

Every command is logged with its source (api, tui, signal, file) and its outcome, refused or not.

Hot reload #

SIGHUP, the file watched under --watch-config and PUT /api/v1/config all do the same.

• The configuration is read again from the file, then the environment, then the command line, which keeps the last word, as at a start.
• Validated whole before anything is applied.
• The reloadable keys are applied.
• What changed is printed, the wallet first.

$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET --watch-config --log-file fearminer.log
$ kill -HUP $(pgrep -o fearminer)
$ curl -s -X PUT -H "Authorization: Bearer $(fearminer token show)" -H 'Content-Type: application/json' -d '{"set": {"temp_limit": "85"}}' http://127.0.0.1:4300/api/v1/config
reload   SIGHUP: 2 key(s) changed: temp_limit 90 -> 85 · url stratum+ssl://A -> stratum+ssl://B
reload   1 key(s) held from the API, over the file: temp_limit (write one as null to hand it back)
E219 the change needs a restart: algo (quantus -> randomx) is kept, the rest is applied

GET /api/v1/config serves reloadable[] and restart_required[]; fearminer --help prints them.

Exhaustive together: every key the configuration file accepts is in exactly one.

• A reload that changes the pool list ends the session on the air cleanly, at its next half-second round.
• Nothing in flight, nothing held against the pool.
• The next opens on the new primary, in the same process.
• A key written with set keeps beating the file at every later reload.
• Every reload names the keys it is holding, on the log and in held[].
• Writing one as null hands it back, and needs no level.

Hooks #

--hook <EVENT>:<PATH>, repeatable or comma-separated, runs a local program on an event.

• The program is run directly, never through a shell.
• It gets 30 s, then is killed.
• Its exit code goes on the log, E139 when it is not zero.
• Whatever a hook answers, the mining carries on.

The context arrives in the environment, never on the command line: FEARMINER_EVENT always, then the fields the event has.

• FEARMINER_DEVICE
• FEARMINER_PCI_BUS
• FEARMINER_UUID
• FEARMINER_ALGO
• FEARMINER_POOL
• FEARMINER_CODE
• FEARMINER_SUMMARY

A field the event does not carry is absent, not empty, so a script tells no card from card 0.

The four device variables are spelt as --oc-script spells them.

$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET --hook temp-high:/opt/rig/hot.sh --hook device-lost:/opt/rig/lost.sh
# hot.sh: FEARMINER_EVENT, FEARMINER_DEVICE, FEARMINER_PCI_BUS, FEARMINER_UUID, FEARMINER_ALGO, FEARMINER_POOL, FEARMINER_CODE, FEARMINER_SUMMARY
E139 hook script failed: temp-high /opt/rig/hot.sh exited 1 after 0.4 s

• --check-config checks the shape of the value and nothing else.
• The path is checked when the event fires, so --hook temp-high:/nonexistent passes and is E139 the first time the rig gets hot.
• E221 (bad hook) is the value itself, <EVENT>:<PATH> with an event that is one.

--background · --priority #

The calling shell is free; a closing terminal takes neither process.

Give --log-file with it, or the log goes nowhere and only the API can read the rig.

Above 2 needs a privilege on Linux; refused by the OS: E613, and the miner keeps normal priority.

Each rig keeps its own history, in its own state directory: no server, no database, nothing to set up.

It answers offline; a dashboard reads the same data over the API.

The last 24 hours are kept in memory and written to <state dir>/history.bin once a minute: a restart or a kill -9 does not lose them.

On disk the same samples are rolled up as each window closes.

GET /api/v1/history #

The same data on the API port, query in the URL: the token from another machine, as everywhere under /api/v1.

$ curl -s 'http://127.0.0.1:4300/api/v1/history?from=-24h&step=5m&metric=hashrate_hs'
{"api_version": 1, "from_ms": 1789689600000, "to_ms": 1789776000000, "step_s": 300, "layer": "minute", "device": null,
 "clock": {"drift_ms": 12, "gaps": 0, "samples": 288},
 "t_ms": [1789689600000, 1789689900000, ...],
 "series": [{"metric": "hashrate_hs", "unit": "H/s", "aggregate": "avg", "values": [611900000, 612400000, null, ...]}]}

An unsampled bucket is null, not a zero.

Every sample carries the rig's monotonic clock and its wall clock; the interval between two is the larger of the two deltas.

NTP stepping the clock back never makes an interval negative; a machine suspended for two hours shows that gap.

Wall-clock drift: clock.drift_ms, and a metric of its own, clock_drift_ms.

history.bin #

A 64-byte header, then one fixed-size ring per tier. The header holds:

• FEARHIST, the magic
• the format version
• the sample schema version
• the record size
• the field counts
• the device slots
• each tier's capacity and step
• a CRC-32

A record: two clocks, span, f32 values, a CRC-32.

A minute's records go out in one write per tier, at the tier's own place in the file; nothing else moves.

The file never grows and is never rewritten: the oldest sample is written over, one slot at a time.

None of this stops the miner starting.

A reader of another build or language stays compatible by:

• checking the magic
• reading field counts and record size from the header rather than compiling them in
• taking the smaller of what it knows and what the file says
• stepping over the rest by the record size

Fields are appended, never reordered, renamed or removed.

The terminal panel is the full-screen panel: hashrate, sparkline, share ticker, one row per card, the log.

--no-tui prints the same records as a plain scrolling log, for a service or a mining OS.

--log-file keeps them in a file, in either mode.

The first minute #

Before it connects, the miner prints where the hash goes and what it runs on: the plain log (--no-tui) shows the lines below, the terminal panel the same in its header and device rows.

fearminer 1.15.2 (a1b2c3d4e, 2026-09-22)
wallet   qzjd5MS1GSCpXLYp8DjZASifnkgtUpx5WwhmEzW3ppHdDe3uq (checksum ok)
worker   rig1
pool     stratum+ssl://pool.example.com:3335 (primary)
pool     stratum+tcp://backup.example.com:3333 (backup 2/2)
custody  pool (the pool pays the wallet)
algo     quantus
fee      2.00% of the mining time to the fee pool
build    1.15.2 (a1b2c3d4e, 2026-09-22)  sha256 3a3524b62caa8307
egress   stratum+ssl://pool.example.com:3335 · fee pool (one-minute rounds) · cfg.fearminer.com (terms, every 20 min) · telemetry.fearminer.com (telemetry every 15 min: event, install id, format, version, system, mining, hardware, hashrate bucket, features, uptime bucket, errors, pool host; fearminer telemetry show, fearminer.com/telemetry) · download.fearminer.com (engines, hourly)
driver   NVIDIA 570.86, libcuda.so.1 and libnvidia-ml.so.1 present
gpu #0   NVIDIA GeForce RTX 4070 Ti [0000:01:00.0]: compute 8.9, 11470 MB free of 12282
ram      64.0 GB
host     bare metal, kernel lockdown none, Secure Boot off
network  dns system · ip any
dns      pool.example.com → 203.0.113.10 (system resolver)
cpu      off on 32 threads, 1 GPU (-t N turns it on)
connected to stratum+ssl://pool.example.com:3335 (203.0.113.10:3335)
fee      window: 2.00 % of the time, first round in about 49 min
job 9dd830e6 diff 18.25G
first share accepted after 12.3 s
fee round started (1 min)
fee round ended: 2 share(s)

wallet

The address as checked against the chain (checksum ok), or UNCHECKED with --ignore-wallet-check. The worker is appended to it: you see what the pool sees.

pool

The pools as given with -o, the first primary, the others its backups in order. A wallet without a pool is refused before this line (E224).

custody · fee

custody: who pays the wallet (the pool). fee: the rate for this algorithm, mined in one-minute rounds on a separate connection, 2 % on Quantus, 0.85 % on RandomX, 1 % on Pearl, 2 % on TensorCash (mined by its engine on the same pool), none when the signed terms name no fee pool for it.

build · egress

build: the version and the first sixteen hex digits of the running binary's SHA-256. egress: every host the miner will talk to, and there is no other; telemetry.fearminer.com comes with its cadence, the groups of fields it sends and where to see them (with --no-telemetry its place reads no telemetry (--no-telemetry)).

driver · gpu · ram · host · network · dns · cpu

The preflight covers: the NVIDIA driver and its libraries; each card's compute capability and free memory against the algorithm's needs; the system memory; the host (bare metal or a VM, kernel lockdown, Secure Boot). Then how the pools are reached (proxy or DNS mode, address families, trust on first use), what each pool name resolves to and who answered. A card failing a check is Excluded with its code; the others mine. cpu: the CPU threads mining beside them, off on a rig with a GPU unless -t N, one per physical core on RandomX. A count past what the machine can spare (every thread but two, and one per card) is capped to it, and the line says so.

fee window · fee round

Once the engines are up, fee window gives the rate as a share of the time and when the first round is due. Each round logs fee round started (1 min) and fee round ended: N share(s). No line names the fee pool. An algorithm with no fee pool in the terms says so once and mines free.

first share

Before the first share every engine answers its known-answer test (Check correctness and measure speed); a start on the same binary, driver and cards skips it and says so. The first start also measures a few launch geometries on your card and caches the best (--retune measures again). Then the first job, then the first accepted share, said once with its delay, /stats carrying it as time_to_first_share_s. At a share a minute, the effective hashrate means something after ten minutes.

The terminal panel: the rolling hashrate, the sparkline with min, average and max, the share ticker, one row per card (state, temperature, fan, power, acc/rej, time since its last share), and the log. Keys:

The plain log #

--no-tui prints one line per record: accepted (✔) and rejected (✘) shares with the card, the difficulty and the round trip, new jobs, connections, verdicts with their code.

Once a minute a line carries three hashrates, each named for its window, then the effective one:

• the instant rate
• the ten-minute average
• the session average: every hash since start over the uptime
• what the pool credits, with its share of the local figure

The line comes whatever the rate, on the process's clock: at zero it names the paused card, as below.

--no-color drops the colour, -v adds the debug records.

19:12:14 ✔ 5/6 · GPU0 · 18.25G · 24 ms
19:12:21 hashrate 588.5 MH/s (10m 587.9, session 586.2, eff 580.2 / 98 %)
19:13:21 hashrate 0.0 H/s (10m -, session -, eff -) - GPU0 Paused (mem 106 °C) - shares 3/3 - diff 1.60M

The log file and its rotation #

--log-file PATH writes every record the miner logs, panel mode or plain, one line each: 2026-09-20T19:33:49.788Z INFO message (UTC, milliseconds, no colour), the pool password replaced by ***.

Appended to, never truncated. Rotated by size into PATH.1 ... PATH.N.

A rotation that fails is reported on the console and the miner keeps writing.

$ fearminer -o stratum+ssl://POOL:PORT -u YOUR_WALLET --log-file fearminer.log --log-level-file debug --log-max-size 10 --log-keep 5
2026-09-20T19:33:49.788Z INFO  connected to stratum+ssl://pool.example.com:3335 (203.0.113.10:3335)

Every fault line carries a code and a message, nothing else.

fearminer explain <CODE> prints the cause, the impact and the fix, offline.

A shipped number is never reused.

FearMiner checks the wallet before the first packet, says at every start where the hash goes, warns when it changed, refuses privileges it does not need, and lists every host it talks to.

The wallet check and the wallet-changed warning #

Checked before the miner connects anywhere.

• The wallet is the part of -u before the .worker.
• A +diff suffix and a solo: prefix skip the check and go as typed.
• A non-decoding address, or one of another network: refused with the cause, exit code 2, no connection, no guessing between chains.
• --ignore-wallet-check sends it as typed, warns at start (E402), marks the banner UNCHECKED.

Also remembered per pool host: a hash of the host and the wallet in wallets.json in the state directory, never in clear, written after the session's first accepted share.

If the file knows another wallet for that host, the next start:

• prints WARN wallet changed since the last session on <host> (was <date>)
• shows wallet changed in the header
• sets wallet_changed on /stats and the API
• sends the critical alert wallet_changed
• keeps mining

The warning returns at every start until the new wallet earns a share.

Root and passwords #

• On Linux and macOS a miner started as root exits 3.
• --allow-root runs it anyway; the HiveOS package passes it.
• A systemd unit runs the miner under a dedicated user.
• The supervisor checks once, before spawning the mining process; Windows has no check.

• A real pool password in -p or FEARMINER_PASS (anything but the conventional x) shows in the process list, and the miner says so once at start.
• --pass-file reads it from a file, one line per pool; the mining process sees the path, not the password.
• A world-readable file is warned about.
• In the log file and on /api/v1/config the password is ***.

The MSR tweaks and the huge-page reservation RandomX needs root for go through fearminer-helper (Algorithms, fees and requirements).

• a separate audited binary, no network, no configuration
• reached through sudo -n before the first connection and never after
• a miner run as root does it in-process, no helper

Setting a clock, a power limit or a fan needs the miner itself as root (--allow-root), or the overclock stays outside.

Verify a download #

Every release carries SHA256SUMS over its files and SHA256SUMS.minisig, its minisign signature by the release key.

fearminer verify has the key compiled in and checks, one line each:

• the signature offline (Ed25519)
• the SHA-256 of every file the sums name present in the same directory

Exit 0 only when the signature is good and every present file matches.

Anything else prints verification FAILED; do not run this download.

Given an archive, it looks for SHA256SUMS beside it.

minisign and sha256sum do the same by hand.

The key changes only with a release that announces it.

$ fearminer verify SHA256SUMS
$ fearminer verify fearminer-linux-x86_64.tar.gz
$ minisign -Vm SHA256SUMS -P RWQR3owV+nRhfgNJeUBqcRK868S52NFG2BOrIzKpkQ5ey6lCEfM9+3Eg
$ sha256sum -c SHA256SUMS --ignore-missing
PS> .\fearminer.exe verify SHA256SUMS
PS> Get-FileHash .\fearminer-windows-x86_64.zip -Algorithm SHA256

The sums also cover sbom.cdx.json, the binary's CycloneDX bill of materials: every component inside, with its version, to check against the advisory databases.

The Linux and Windows binaries carry their dependency list in a section cargo audit bin reads.

Every archive carries THIRD-PARTY-NOTICES.txt, the licences of the open-source components inside.

Why the binaries are unsigned #

The binaries are not code-signed yet, so Windows and macOS stop them at the first run; antivirus engines file any miner under HackTool or CoinMiner. The first says the publisher is unknown, the second says the program mines.

Check the download first. Every release carries SHA256SUMS over its files and SHA256SUMS.minisig, its minisign signature by the release key. fearminer verify has that key compiled in: the signature offline, then the SHA-256 of every file the sums name in the same directory; exit 0 only when everything matches. minisign checks the same signature with the published key. sha256sum, or Get-FileHash in PowerShell, compares a hash by hand against the sums on the release page.

A good run prints ok for every file you downloaded, and MISSING for the assets you did not: that still exits 0. Only a bad signature or a MISMATCH is verification FAILED; do not run this download: delete it, fetch it again. After that, what follows is the operating system talking about a missing signature, not about the file.

Signing is planned, with no date: an Authenticode certificate and an Apple developer account are a recurring bill. Until then the signature that counts is the one on SHA256SUMS, which you can check yourself, offline.

What it writes on disk #

Each archive unpacks into a folder named like the archive.

What the relay sees #

The option or the command that answers. When a log line carries a code, fearminer explain <CODE> answers first.

# /etc/systemd/system/fearminer.service
[Unit]
Description=FearMiner
After=network-online.target

[Service]
User=fearminer
StateDirectory=fearminer
WorkingDirectory=/var/lib/fearminer
Environment=HOME=/var/lib/fearminer FEARMINER_NO_TUI=1
EnvironmentFile=/etc/default/fearminer
ExecStart=/usr/local/bin/fearminer
Restart=always
RestartSec=2s
RestartPreventExitStatus=2 3 4 12
TimeoutStopSec=30s
KillSignal=SIGINT

[Install]
WantedBy=multi-user.target

The unit leaves the restarting to the miner's supervisor and lets systemd restart everything only once it has given up; the final codes are left alone. FEARMINER_NO_SUPERVISOR=1 in the environment file gives systemd all the restarting.

Option, value, default, environment variable, what it does.

Every option can also be set from the environment as FEARMINER_<OPTION> and in the configuration file under its long name with underscores (--temp-limit is temp_limit; --1gb-pages is huge_pages_1g).

The command line wins over both.