WarpAxe 0.1.41 adds encrypted connections to home mining pools
Source report: 2026-11-10 · Editorial analysis published: 2026-11-11
The firmware can remember a verified key for a self-hosted pool. It also adds recovery for a stalled chip domain and reduces memory use on large pool jobs.
A private pool can keep its own certificate
WarpAxe published version 0.1.41 on November 10. A supported home miner can now open an encrypted TLS connection to a self-hosted pool that issues its own certificate. TLS is the same kind of protection browsers use for HTTPS. In this case, the miner can recognize the pool by a key the owner has verified, even when the address is a local IP address.
WarpPool running on Umbrel is the example in the release notes. WarpPool v1.48.0 displays the fingerprint of its public key in its connection window. A fingerprint is a short representation of the key that can be compared between screens. The WarpAxe pool screen shows the corresponding value before asking the operator to trust it. The developers tested the connection on a NerdAxe Gaia by hostname and by IP.
Check the fingerprint on both screens
Compare the miner’s fingerprint with the value shown on a pool dashboard you already trust. Once approved, the miner remembers that key for this pool. Its primary and backup pool settings keep separate keys. If the pool presents a different key later, WarpAxe stops that connection and requests fresh approval. The Forget control removes a remembered key.
That separation matters when two pool addresses are saved and one moves to a different server. An unexpected change might be an ordinary rebuild, but the pool operator can establish that from their own dashboard before approving the replacement key. Publicly issued certificates continue through the firmware’s existing trust store. For those certificates the update adds date checks after the device obtains network time.
When part of a chip goes quiet
Some chips report work in separate groups called domains. WarpAxe adds a recovery rule for BM1370 and BM1373 chips when one group reports much less work than its neighbours. If a domain stays below a quarter of the average of the other domains for ten minutes while jobs are being sent, the firmware power-cycles the chips. The developers put the interruption at about six seconds. The configured clock and voltage stay in place.
The rule shares a limit of one restart per hour with recovery for a silent chip. If the fault returns within an hour after each of three restarts, the firmware leaves it alone until the next boot or a change to clock or voltage. The developers verified this new case in a chip simulator and say they had yet to see it on real hardware. Their earlier recovery for a whole silent chip arrived in 0.1.40. A stable miner should continue hashing as before.
Large payout lists use less memory
Some pools place direct payouts to many miners inside the coinbase, the first transaction in a Bitcoin block. Their job messages can carry a long list of outputs. WarpAxe now decodes the coinbase once per job and reuses it across chip work, reducing the number of copies that compete for the small controller’s memory. The authors tested messages with 110 to 3,000 outputs and reported that shares kept flowing in that test.
The payout panel shows up to 32 outputs, with the remaining entries grouped in a single line. That is a limit on the display. The pool’s block transaction still determines which addresses get paid. An incoming pool line over 512 KB causes a reconnect, which gives the firmware a way to recover from a message beyond its limit.
Who decides when to recover
WarpTune v1.48.0 can read which failures the firmware handles. The release says WarpTune waits when WarpAxe detects a quiet chain, a silent chip or a stuck domain. The two newer recovery timers pause while the pool is away. This gives the miner time to establish whether work is available before treating missing counts as a chip fault.
For operators using an external tuner, the release also adds a temporary in-memory indication that the tuner is active. A restart clears that state. Alongside accepted shares, this helps explain which program was handling recovery when the operator looks back at a pause.
What to check after an update
The project publishes one firmware image for its supported boards and separate first-install files. A device owner can check the board against the project’s compatibility information and keep the current pool settings before changing firmware. The most direct checks after an update are the identity of the connected pool, incoming accepted shares and the event log. A pool dashboard and the miner’s screen show different parts of that path.
For a private pool, the new feature gives the owner a way to verify the connection they set up. The recovery rule addresses a more specific failure on the two named chip families. When the event appears repeatedly, the log gives the operator a timestamp and domain to compare with temperatures, power and pool availability before changing tuning settings.
Source: WarpAxe / official release notes ↗ · WarpPool v1.48.0 ↗
Mining calculator ↗
