-
v1.39.2
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m14sCI / Rust fmt (push) Successful in 1m20sCI / Rust test (push) Successful in 7m25sCI / UI (SvelteKit) (push) Successful in 1m27sCI / Security Audit (push) Successful in 1m26sdocs / build (push) Successful in 42sRelease / Docker Multi-Arch (push) Successful in 32m42sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 13m57sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 12m51sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m23sRelease / Linux .deb + .rpm (arm64) (push) Successful in 2m9sRelease / Linux AppImage (aarch64) (push) Successful in 32sRelease / Linux AppImage (x86_64) (push) Successful in 32sRelease / Cosign sign artifacts (push) Successful in 35sRelease / Forgejo Release (push) Successful in 42sdvb-projekt released this
2026-10-11 17:46:43 +00:00 | 0 commits to main since this releaseFixed
- Devices: a WarpTune card that shows the tuner's own voltage check
("Voltage checked …" or "Voltage check · … shares counted") now offers
Calibrate and Quick check now like every other card state; the
buttons were missing there, so a NerdAxe Gaia or a Bitaxe Gamma in a
voltage check could not be calibrated from the card.
Changed
- WarpTune: the savings refresh (every 30 minutes per miner) reads only
the journal lines appended since its last run instead of the whole file
(~25 MB after a month), with the same result — checked against a real
journal. Point windows that ended before the pool's 7-day bucket range
are dropped from memory. - WarpTune: a heartbeat carries the regulator's tables (unstable steps,
efficiency, voltage-trial and calibration memory) only when one of them
changed, after a start and at least every 6 hours; older journals read
as before. About 7 % less journal growth.
dvb-WarpPool v1.39.2 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.39.2(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- WarpTune only:
dvb-warppool-tune-<tag>-<target>.tar.gz(Linux x86_64 + aarch64; macOS added with the .dmg) for running the tuner next to a pool on Umbrel or Docker — see the README inside - macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Devices: a WarpTune card that shows the tuner's own voltage check
-
v1.39.1
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m6sCI / Rust fmt (push) Successful in 1m14sCI / Rust test (push) Successful in 7m17sCI / UI (SvelteKit) (push) Successful in 1m19sCI / Security Audit (push) Successful in 1m19sdocs / build (push) Successful in 34sRelease / Docker Multi-Arch (push) Successful in 27m43sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 12m55sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 12m10sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m10sRelease / Linux .deb + .rpm (arm64) (push) Successful in 2m0sRelease / Linux AppImage (aarch64) (push) Successful in 24sRelease / Linux AppImage (x86_64) (push) Successful in 26sRelease / Cosign sign artifacts (push) Successful in 27sRelease / Forgejo Release (push) Successful in 35s2026-10-11 10:22:56 +00:00 | 5 commits to main since this releaseAdded
- WarpTune: built-in core-current lines per board when neither the
firmware norwarptune.tomlnames one. Stock ESP-Miner and NerdOS report
nocoreCurrentWarnA, so the core current on them ran unchecked. A table
from the reference firmwares (ESP-Minerdevice_config.h/TPS546.c,
NerdOS board classes via WarpAxe's profiles) now supplies the warn and
fault lines and the board's power limit — Bitaxe Gamma, Gamma Duo, Supra
and Ultra (TPS546 revisions), Hex, Supra Hex, Gamma Turbo, Naja Duo, Gamma
Hex, BitForge Nano, NerdAxe Gamma, NerdAxe Gaia, NerdQAxe++, NerdOctaxe-γ,
Q1370, Q1373. On those boards the firmware'scurrentis the regulator's
output and serves as the core current. Every line from the table is marked
"board default" in decisions, the journal and on the card; the config's
line beats it and the firmware's fault line beats everything. Nothing
raises a line the firmware or the config reports. - Devices: the WarpTune card shows the core current against its line
(tooltip) and says so when it sits at or over the share a step up may use
("near the warn line"). A Bitaxe GT at 44.8 A under a 50 A warning was
formally fine and worth a word. - Devices: the card says when the hand point draws more than the board
limit ormax_wattsallows, and the sidecar warns at start. - WarpTune: per-miner
board_limit_wreplaces the board power limit the
firmware reports (and the table's) where that figure is not the board's —
a NerdQAxe++ on WarpAxe still reports NerdOS's 100 W and runs 110 W on a
124 W supply; without the key every restore would be held under 100 W. - Release: WarpTune on its own — every release now carries
dvb-warppool-tune-<tag>-<target>.tar.gzfor Linux (x86_64, aarch64) and
macOS (Apple silicon, Intel) with just the tuner binary, its guide and the
licence, for running WarpTune next to a pool on Umbrel or Docker. Until now
the binary was only inside the full pool packages.
Changed
- WarpTune: a restore never goes above the power limit. The restore
target (after a reboot, on shutdown, after a trip or a latch) was held
under the core current bar only; a Bitaxe GT whose hand point 850 MHz @
1221 mV drew 64.5 W on a 60 W board got it written back after every reboot
and was pulled down "urgent" afterwards. The target is now held under the
lower ofmax_wattsand the board limit as well, on the hand point's
measured watts (the journal's windows, kept across restarts) or, without a
measurement there, scaled f·V² from the last running sample: the highest
ladder step under the limit at or under the hand voltage, with the reason
in the decision and the journal. With no power data at all the restore
goes as before and the decision says it went unchecked. The hand point
itself stays the reference of the savings tile. - Devices: the WarpTune vs. hand points tile leaves work-mode miners (the
Avalon Q) out altogether — not in the sums, the percentages or the miner
count; their kilowatt and their Super mode would make the tile theirs. The
tile names them ("Without … (work modes): its figures are on its own
card."). When every Max point runs at its hand clock, Max adds no hashrate
by construction, so the "Max adds" figure shows the watts saved instead
("less power at the same hashrate (N miners at their hand clock)").
dvb-WarpPool v1.39.1 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.39.1(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- WarpTune only:
dvb-warppool-tune-<tag>-<target>.tar.gz(Linux x86_64 + aarch64; macOS added with the .dmg) for running the tuner next to a pool on Umbrel or Docker — see the README inside - macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- WarpTune: built-in core-current lines per board when neither the
-
v1.39.0
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m27sCI / Rust fmt (push) Successful in 1m19sCI / Rust test (push) Successful in 8m8sCI / UI (SvelteKit) (push) Successful in 1m22sCI / Security Audit (push) Successful in 1m25sRelease / Docker Multi-Arch (push) Successful in 31m15sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 14m8sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 12m41sdocs / build (push) Successful in 34sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m10sRelease / Linux .deb + .rpm (arm64) (push) Successful in 1m54sRelease / Linux AppImage (aarch64) (push) Successful in 23sRelease / Linux AppImage (x86_64) (push) Successful in 23sRelease / Cosign sign artifacts (push) Successful in 27sRelease / Forgejo Release (push) Successful in 35s2026-10-10 15:55:42 +00:00 | 14 commits to main since this releaseFixed
- WarpTune: the voltage trial no longer ratchets a voltage up on noise. A
share vote short of the bar by less than its own noise on the double
window counts as a deficit only when the chip error rate on the point rose
by more than one point over the point's baseline (the error rate of its
last good verdict, or of the next voltage up at that clock) — with the
chip error trigger off as well. With flat errors and no second witness the
verdict is "noise, not a deficit": the point is good, the trial goes on
down toward the lowest good voltage, and a calibrated voltage raised in
operation steps back on such a vote as on a healthy one. Where the firmware
reports no error rate, or no baseline is known, the double window decides
as before. (NerdQAxe++ 2026-10-07 → 10-10: Eco 600 MHz walked 1140 → 1240
mV in 10 mV steps on votes of 95 % over 400 at a flat 0.2 % error rate,
+18 % power.) The baselines are read back from the journal at a start.
Added
- Devices: WarpTune vs. hand point — a tile above the device cards and a
line on every WarpTune card show what the Eco setting saves (watts) and
what the Max setting adds (hashrate) against each miner's hand point: the
point it would run without WarpTune (stockin warptune.toml, or the point
seen at the first start). Measured, not modelled: watts from the miner's
own readings, hashrate from the pool's accepted shares, over every stay on
the point in the last seven days (dvb-warppool-tune yield's table). A
point counts from 200 shares and 30 minutes; below that the card says "not
enough data" with the counts. A point the miner no longer visits (a hand
point replaced by its calibrated voltage) is estimated from the
best-measured point at the same clock, power by V², and marked "≈". The
tooltip carries the hand point, "(= factory setting)" when it is the
maker's default, the measurement behind each figure (shares, minutes, last
stay) and the method; "±" is the share noise. The Avalon Q's work modes are
named as such; work-mode miners are left out of the tile's percentages
(their kilowatt would dominate them) but stay in its watt and hashrate
sums, and the tile names the miner left out. Watts and hashrate only — no
kWh or money figure. The sidecar (savingson the snapshot) recomputes
every 30 minutes on its own task (a failed run keeps the last figures,
shows the error and retries after five minutes); no change to
warptune.toml is needed.
dvb-WarpPool v1.39.0 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.39.0(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
1 download
- WarpTune: the voltage trial no longer ratchets a voltage up on noise. A
-
v1.38.1
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m5sCI / Rust fmt (push) Successful in 1m13sCI / Rust test (push) Successful in 7m14sCI / UI (SvelteKit) (push) Successful in 1m21sCI / Security Audit (push) Successful in 1m23sRelease / Docker Multi-Arch (push) Successful in 27m50sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 14m7sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 12m35sdocs / build (push) Successful in 35sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m5sRelease / Linux .deb + .rpm (arm64) (push) Successful in 1m55sRelease / Linux AppImage (aarch64) (push) Successful in 25sRelease / Linux AppImage (x86_64) (push) Successful in 26sRelease / Cosign sign artifacts (push) Successful in 26sRelease / Forgejo Release (push) Successful in 37s2026-10-10 09:04:14 +00:00 | 19 commits to main since this releaseFixed
- Admin → Workers: the address in a worker login is shortened (start…end) so
the worker name after the dot is always visible; the full login stays in
the tooltip and in the search. - Devices: a miner added as NerdNOS that runs an AxeOS-API firmware (WarpAxe
on NerdNOS hardware) no longer shows "HTTP 404" — a 404 on/api/status
falls back to the AxeOS routes. - WarpTune card: a finished calibration shows the voltage Apply takes over
(found voltage plus reserve) instead of the bare found voltage, says when
the reserve was capped at the starting voltage, titles a quick check as
such, and tells visitors that are not logged in how to apply. The
regulator's own voltage check in operation is labelled "Voltage check"
instead of "Calibrating", and once it has counted past its share target it
says so instead of showing "405/200". - Manuals: the quick check's candidate is the last step that screened good
(10 mV above the first one that failed), as the code does.
Documentation
- WarpTune guide: a Linux section (systemd user service, dry run → live, the
key for the pool's buttons, coupling with an Umbrel pool); "Pool coupling"
no longer carries the internal milestone label; the CLI help and the
example config no longer call WarpTune "dry-run only".
dvb-WarpPool v1.38.1 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.38.1(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Admin → Workers: the address in a worker login is shortened (start…end) so
-
v1.38.0
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m3sCI / Rust fmt (push) Successful in 1m11sCI / Rust test (push) Successful in 7m2sCI / UI (SvelteKit) (push) Successful in 1m18sCI / Security Audit (push) Successful in 1m16sdocs / build (push) Successful in 31sRelease / Docker Multi-Arch (push) Successful in 26m12sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 13m17sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 12m4sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m9sRelease / Linux .deb + .rpm (arm64) (push) Successful in 1m55sRelease / Linux AppImage (aarch64) (push) Successful in 24sRelease / Linux AppImage (x86_64) (push) Successful in 21sRelease / Cosign sign artifacts (push) Successful in 21sRelease / Forgejo Release (push) Successful in 33s2026-10-09 13:29:44 +00:00 | 23 commits to main since this releaseAdded
- Admin → Workers: a list of every known worker (search; connected,
recently active or idle) with a Remove button behind a
confirmation — only a live stratum session ("connected") blocks it.
When more than 500 workers are known the page says it lists only the
500 most recently seen of the total. A second table lists leftovers
without a worker entry (best shares or VarDiff memory whoseworkers
row the retention already evicted,GET /api/admin/workers/orphans),
removable the same way.
DELETE /api/admin/workerswith the JSON body{"user": "<worker>"}
(a body, because worker names can contain/) deletes the worker's
rows inworkers,best_shares,best_shares_all_timeand
vardiff_state(the V1 key and the:sv2snapshot) in one
transaction, and drops the in-memory reject breakdown and the Sv2
VarDiff snapshot cache. Share history and found blocks stay. A worker
connected over V1, V1 + TLS or Sv2 is refused with 409 (its session
would write its state back), an unknown one with 404; the name is
matched exactly as the miner authorized, edge blanks included. Every
attempt, refused or failed ones too, is audited asworker.delete.
/api/workerscarriescurrent_is_connectedper worker and the
totalof known workers. - dvb-WarpTune: quick calibration ("Quick check now" on the devices
page, pool actionquick, audited astune.calib.quick). The same
stages as a full calibration, no clock search, each starting from the
voltage its step runs at now. Every 10 mV step is first screened on the
chip counters for about ten minutes: the start voltage gives the
baseline error mean, and a step down is good while its error mean stays
under baseline + 1.0 point (shifted by the miner's temperature slope),
no chip domain latches off and no chip stands out. The candidate is the
last good step plus one; only it gets the full share verdict (200 / 400
shares), short of good → one step up and again, up to the start
voltage. Apply adds a reserve of 30 mV (instead of
calib_margin_mv), and the card tags the result as a quick one. About
1.5–2 h per Eco/Max stage instead of 6–13 h for a full job. Offered
only on a firmware with a chip error rate (1-minute rate or per-chip
readings;hashrateMonitoralone is not enough); a step without a
single error reading after twice the screen time (2 × 10 min) fails
the stage withno_counters. Journal eventsscreenand
candidate; a screened step is never a result on its own. - dvb-WarpTune: periodic re-check. 28 days after an Apply WarpTune
starts a quick calibration on its own, one step below the applied
voltage — once per apply (also across a service restart), live only,
only on a miner whose regulator mode is Max (the job pins Max for its
screen and share verdict; Eco, Balanced or PV-governed miners keep the
quick-check button), on a firmware with a chip error rate, never while
another job is open. Its result waits on the card as a suggestion
(apply or discard as before; the hint says what passed and failed
mean). - dvb-WarpTune: chain re-init at the hand point (WarpAxe boards with
a chip chain; not the dev-kit CPU miner). A chip domain latched off at
the hand point had nowhere to go — a restore bump to the hand point is
a no-op there (Octaxe 2026-10-09: six domains on five chips off after a
cold start, 9.1 instead of 11.4 TH/s). WarpTune now power-cycles the
chain: it journals the open re-init (chain_off), sends
POST /api/v1/chips/off, waits up to 10 s for the firmware to confirm
the chain stopped (chainStopped, phase OFF, core voltage reading
under 100 mV), holds the rail off forchain_reinit_off_hold_s
([defaults]and per miner, 5–60, default 15 s; ~5.5 s re-latched
another domain on the Octaxe), sendsPOST /api/v1/chips/onand waits
up to 90 s for phase READY. The chips are never left off: an
unconfirmed OFF still gets/on, a failing/onis retried three
times with backoff and then the board is restarted
(POST /api/system/restart); after a WarpTune restart mid-sequence
the openchain_offis recovered (chain stopped →/on, running →
closed) — only for WarpTune's own OFF, never for chips switched off in
the WarpAxe UI. The domain counters are judged again 60 s after the
real READY (the firmware refills them from zero). Live only, at most
three an hour (the count survives a restart) with a 5-minute settle
after each; a latch the re-init could not answer (settle, hourly
bound, calibration running) is retried later without a new event;
past the bound the latch is left and stays reported. A re-init also
waits for a steady state (chip temperature within 3 °C of the target,
fan within ±5 % for two minutes, five minutes since the boot and since
the last READY). A domain off again within five minutes of the READY
after a re-init for it is a relapse; two in a row give it up — no more
re-inits for that domain, the others still get theirs — and the
devices page and the journal (domain_given_up) say it keeps dropping
out at that point, a margin question (hand voltage or clock); re-armed
by a point change, a board boot or after a day, and read back from
the journal at a WarpTune start. NerdNOS boards are excluded for now.
Journal kindchain_reinit(rail off after / never read off, attempt
or reboot, READY after, cause of a failure); the devices page shows
the last re-init. - dvb-WarpTune: per-chip readings from
GET /api/v2/dashboard
(NerdOS ≥ 1.1.1-alpha4, WarpAxe ≥ 0.1.19; one parser for both): the
hashrate and the hashrate lost to errors per chip. They feed the
dead-chip guard's stall verdict without ahashrateMonitor, stand in
for the 1-minute chip error rate where the firmware has none (NerdOS;
gated bychip_error_triggeras before), and one chip whose error
share stands out against the median of the others (≥ 3 points and
≥ 3×, at least three chips) is a second witness that the point is short
of good. The journal's sample summary records the share
(chip_error_pct). A firmware that answers 404 is asked again once an
hour. - Devices page: a finished calibration message (stopped, failed) and a
chain re-init can be dismissed (×) — per viewer, kept in the browser,
the next message shows again. While a calibration runs and under a
finished one the card says since when the applied calibration is in
force ("calibrated since …").
Changed
- dvb-WarpTune, calibration: the yield rule. A stage's result is the
good voltage above every bad one with the most hashrate per watt,
(100 − chip error %) / W, with the chip error as the mean of the
verdict window's readings (at least three; never a lone or cumulative
reading); the lowest good
voltage only when nothing above it is better by at least 0.5 %. Chip
errors cost hashrate one to one at the pool (2026-10-07/08: the Gamma
at 100.0 % of its expected hashrate, the Gaia at 94.0 % with ~6.2 %
chip errors), so a voltage that is stable by the shares can still earn
less per kWh than the step above it. Gamma Max 640 MHz on the journal
of 2026-10-05: the old rule took 1030 mV (6.3 % chip errors), the new
one 1040 mV (1.9 %). The card names the preferred voltage per stage and
why. Journals without error rates keep the old rule. The live voltage
search uses the same comparison — a step judged good whose errors cost
more than its power saving goes back up — only with
chip_error_trigger = true, on error means of at least three readings
on the present point and with a 1 % gate instead of 0.5 % (the step
above is remembered with its mean for seven days). - Stratum: the VarDiff of the NerdMiner class (CPU and ESP32 miners such
as the WarpAxe dev kit) steps up by at most ×2 per retarget
(max_step_up, an operator's lowermax_stepis kept); the window
stays 8 shares, the way down (÷4) and the idle decay are unchanged,
the NerdNOS class too. V1 and Sv2 alike. A lucky run of eight fast
shares tripled the difficulty of a ~290 kH/s dev kit on 2026-10-08
(about 13 instead of 30 shares an hour for 40 minutes until the way
back).
Fixed
- dvb-WarpTune: the dead-chip guard tells a share-path stall from dead
chips. Three verdicts now: electrical death (VR output 0 mV, silent
chain restarts) makes the step a ceiling as before; a hashrate of 0
with the chip counters dark or absent sends the miner to stock and
restarts it, but holds off only the present step; a hashrate of 0
while the chip counters still run is a stall — the miner is restarted
at stock after six decisions (3 min), nothing is marked, no trial
voltage fails, and a calibration stage does not count the restart as a
guard failure. Gaia 2026-10-07: the firmware read 0 for three ticks
with its counters at ~2 TH/s; the guard marked 320 to 380 MHz at once
and Eco sat at 300 MHz for the hold.
dvb-WarpPool v1.38.0 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.38.0(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Admin → Workers: a list of every known worker (search; connected,
-
v1.37.1
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m4sCI / Rust fmt (push) Successful in 1m16sCI / Rust test (push) Successful in 6m37sCI / UI (SvelteKit) (push) Successful in 1m24sCI / Security Audit (push) Successful in 1m27sdocs / build (push) Successful in 41sRelease / Docker Multi-Arch (push) Successful in 25m19sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 13m2sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 11m30sRelease / Linux .deb + .rpm (amd64) (push) Successful in 3m49sRelease / Linux .deb + .rpm (arm64) (push) Successful in 2m2sRelease / Linux AppImage (aarch64) (push) Successful in 29sRelease / Linux AppImage (x86_64) (push) Successful in 29sRelease / Cosign sign artifacts (push) Successful in 29sRelease / Forgejo Release (push) Successful in 40s2026-10-07 16:28:45 +00:00 | 68 commits to main since this releaseFixed
- Stratum V2: the start and floor difficulty of a direct Sv2 channel now
follow the recognised miner class exactly like Stratum V1, instead of a
fixed floor of 4096. A recognised weak class (NerdMiner / CPU miner such
as the WarpAxe dev kit at ~230 kH/s, Bitaxe band) starts at its hashrate
hint inside the class band, computed with the class share interval, and
never below the class floor (NerdMiner 0.001, Bitaxe 1024); without a
hint it starts where V1 starts the class. Before, a NerdMiner-class
channel kept a 4096 target while its VarDiff sat at 0.01, so the miner
found about one share a day and the VarDiff never got a share to
correct it. The channel target now always equals the VarDiff's
difficulty (fresh channel and restored snapshot alike; a restored value
is clamped to the class band). Unrecognised miners keep the 4096 floor
as the guard against a false low hashrate hint. - Stratum V2: the miner-class decision of a direct Sv2 channel is logged on
INFO like the V1 authorize path (vardiff init mit class-Override (Sv2):
worker, class, share interval, start difficulty, restored or not).
dvb-WarpPool v1.37.1 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.37.1(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
1 download
- Stratum V2: the start and floor difficulty of a direct Sv2 channel now
-
v1.37.0
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m3sCI / Rust fmt (push) Successful in 1m18sCI / Rust test (push) Successful in 6m20sCI / UI (SvelteKit) (push) Successful in 1m23sCI / Security Audit (push) Successful in 1m24sdocs / build (push) Successful in 39sRelease / Docker Multi-Arch (push) Successful in 24m24sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 12m35sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 11m33sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m13sRelease / Linux .deb + .rpm (arm64) (push) Successful in 1m57sRelease / Linux AppImage (aarch64) (push) Successful in 28sRelease / Linux AppImage (x86_64) (push) Successful in 28sRelease / Cosign sign artifacts (push) Successful in 30sRelease / Forgejo Release (push) Successful in 40s2026-10-07 14:36:15 +00:00 | 73 commits to main since this releaseAdded
- dvb-WarpTune: calibration with clock search (opt-in per miner,
calib_clock = true; this runs the chip above the owner's validated
point and possibly outside the maker's specification and warranty — the
devices page warns before the start). Before each voltage stage a clock
stage runs: the Max stage climbs in 25 MHz steps above the hand point at
the hand voltage and keeps the highest clock that passes the stability
rule; the Eco stage walks down from the Eco cap at the curve voltages
and keeps the best J/TH step, which becomes the Eco cap on Apply. A
clock candidate is stable only when, over the whole window
([defaults] calib_window_s, 30 min) as maxima: fan ≤ 90 %, chip ≤
target, VR ≥ 15 °C under its shutdown line, core current ≤ 95 % of the
warn line, power ≤max_wattsand ≤ 95 % of the firmware's board
limit, the draw on the supply ≤ 80 % of its rating, the pool's shares
call the point healthy, the firmware's hashrate reads no more than 2
points under the start clock's and the 1-minute chip error rate stays
near the baseline measured at the start clock. The start clock (hand
point, Eco cap) is the reference: judged on the hard limits and the
shares alone, never on the firmware's reading or the error line, so the
method always finds the owner's point at least (Nano 2026-10-04: both
maker points failed absolute bars with the pool at 100 %). Any failure,
a guard move included, ends the stage with the
last stable clock; the search never goes above the maker's maximum,
ladder_cap_mhzorcalib_clock_max_mhz, and never raises the voltage
above the hand voltage. A found Max clock becomes abeyond_spec
ladder step (Max mode only); the hand point stays the restore point;
Discard, Stop and a failed job take every added step out again; a
restart puts them back from the journal (CalibAppliedcarries
eco_cap_mhzandfan_target_c). A board on maker presets (BitForge
Nano) gets its calibration with the opt-in; its presets stay. - dvb-WarpTune: the fan target is part of a calibration. The job records
the firmware's fan target, stops when it changes under it, and the card
shows the target a result was measured under (and that the result is
for the old target once the owner moves it). After a Max clock stage
that ended on the fan alone the card shows the trade-off and, with
enough fan reserve at the last stable clock, suggests +2 °C — marked as
an estimate — with a button:fan_targetgoes through the command
path (POST /api/admin/tune/calibwithtarget_c, audited as
tune.calib.fan_target; sidecarPOST /calib/{host}/fan_target/{°C}),
the sidecar accepts only the suggested value, setstemptarget/
pidTargetTempon the device, journals it (fan_target) and raises its
own target floor to fan target + 2 °C. Never applied on its own. - dvb-WarpTune: in operation, a calibrated step whose automatic fan runs
over 90 % for 30 minutes is left for the step below and held off for six
hours (seasonal drift). Every clock verdict is journaled with the
window's maxima, mean chip temperature and chip error rate, so the
error rate's temperature dependence can be fitted from the journal. - Devices page: the clock stages on the calibration card — the candidate
under test with the window's maxima so far, every candidate as a chip
(verdict and measurements in the tooltip), the clock found against the
start clock, the fan trade-off and the fan-target button; the Start and
Apply confirmations name the clock search and its risk. Eight languages,
reviewed. - dvb-WarpTune: on ESP-Miner a chip the vendor table does not know gets
its ladder from the board's own option lists under/api/system/asic,
as NerdOS and WarpAxe boards already do under/api/v2/settings. A
BM1370 Bitaxe keeps the vendor table; Forge-OS publishes no lists. - dvb-WarpTune, clock search: power supply reserve.
psu_max_watts
is the supply's continuous rating; the window's draw on the supply
stays under 80 % of it (the overclocking guides' 20 % reserve), the
board limit (max_watts, firmwaremaxPower) under 95 % as before.
Unset, the rating of the supply the board ships with applies (Bitaxe
Gamma 25 W, BitForge Nano 60 W; the board's, not the chip's — a
NerdOctaxe gets none) — and a default never fails the hand
point itself, only candidates above it; a board with neither gets no
clock search until it is set (the start warns, the job notes it). Miners on
one shared supply name the samepsu_group: the sum of their draw
counts (the others from their latest snapshots). - dvb-WarpTune: latched chip domains. Where the firmware publishes
the chips' counters (WarpAxehashrateMonitor), a domain at ≤ 5 % of
its chip's best domain on two decisions in a row while that one runs
is latched off — the voltage counts as bad on that point: the trial
steps up, a calibration stage fails the voltage, a clock candidate is
unstable, the way up is blocked; journal linedomain_off; the devices
page names it (domains_off). In Eco below the cap the step is left
for the step above (worse J/TH than it reads) and held off. Octaxe
chip 4, 2026-10-02: ~1.5 % lost, invisible to the shares. - dvb-WarpTune: a share vote short of the bar by less than its own noise
(1/√n) is confirmed on a second window (twice the shares) before it
counts — in the calibration and in the running voltage trial alike —
unless a domain is off, the chip errors or the rejects say the same.
The share history keeps the second window's shares. The Octaxe's Eco
1180 on 2026-10-02 was one noisy window; the NerdQAxe++'s Eco floor
walked 1190 → 1200 → 1210 on 94 % / 95 % over 200 shares at a flat
0.18 % error rate on 2026-10-03. The calibration card shows the voltage
the device runs under test (not the last one judged) and, while a
second window runs, its share count (calib_confirming,
calib_shares_needed400). - dvb-WarpTune, calibration: a service restart in the middle of a
voltage search sends the miner straight back to the search position
(one step under the last good verdict) instead of walking down again
from the voltage the pin writes, one 200-share window per step (Gamma
2026-10-05: pinned at the applied 1120 mV with the search at 1030, a
seven-hour re-walk). After a failure the search goes back to the
voltage under re-check (the lowest good one above every bad one). The
steps already judged are not judged twice. - dvb-WarpTune, calibration:
calib_hard_min_mv(under[defaults]or
per miner) replaces the firmware's lowest offered core voltage as the
search's hard stop and may lie under the firmware's list — never
under the board regulator's clean range: with WarpAxe's
regulatorMinMvthe value (and the trial'svoltage_min_mv) is held
to it, without the field the firmware's list stays the floor; the start
warns and journals the clamp. The card names the voltage asked for
(requested_mv) and the one set instead (clamped_mv). Every write
under that list is read back on the regulator's measured output
(coreVoltageActual— WarpAxe echoes the asked value incoreVoltage
even when its driver refused it): taken (within 5 mV), the step counts and the
search goes on; clamped, the stage ends at once asfirmware_minimum
with the clamped voltage (clamped_mv), the clamped step is no
measurement and live control is not tripped. The Gamma's Eco stage on
2026-10-05 was good all the way to the firmware's 1000 mV. - dvb-WarpTune: WarpAxe v0.1.16's
coreVoltageRefusedends a floor
search at once (no grace tick), and two chain restarts in a row after
silent minutes at the present voltage (chainSilentRestartsSameMv)
count as a dead voltage without waiting the dead ticks. - dvb-WarpTune: a voltage at which every chip goes silent (regulator
output 0 mV, 0 GH/s) is a failed trial voltage as well as a dead step:
held off in the trial memory (doubling per failure), the good memory
at or under it forgotten, so the search never loops back to it. - dvb-WarpTune, calibration: a voltage judged more than once counts as
its latest verdict says — an early short-window failure (the
regulator's hold under 200 shares) that a full window at the same
voltage overturned is no floor; good then bad stays bad. Gamma
2026-10-05: 1080 failed at 73 % over 106 shares, passed at 114 % over
227, and the floor search below it would have been wasted. - dvb-WarpTune, calibration: the configured floor is where the search
starts, not where it stops. A stage still good atvoltage_min_mv(or
calib_max_stepsunder the reference) goes on down in 10 mV steps to
the first bad voltage, never under the chip's hard minimum (the
firmware's lowest offered core voltage; without one 100 mV under the
start floor). The result says how it is bounded —floor_kind:
bracketed,hard_minimumoropen— on the stage and as
calib_floor_kindon the badge. The Gamma's run on 2026-10-04 was good
all the way to its 1100 mV floor and could only say "at least 1100". - dvb-WarpTune: a firmware stop is journaled with the firmware's account
of it —overheatCause(hot / sensor / power),overheatLatched,
overheatTrips,faultCause, the regulator'spower_faulttext and
powerFaultCodes(WarpAxe ≥ 0.1.12; stock AxeOS gives the flag only,
NerdOS the mode) — as astopobject on the sample of every decision
and heartbeat while the stop lasts, and in the pause reason, the hold
label and thestep_badline ("regulator stop (overcurrent; cause
power, codes iout_oc)"). The Nano's trip at 07:09:50Z on 2026-10-03
stayed unexplained because only the flag was kept. - dvb-WarpTune: the chip error lines follow the chip temperature per
miner —error_temp_slope_pct_per_canderror_ref_temp_c(default:
the target) moveerror_down_pct/error_up_max_pct, never under
0.1 %; the clock search's baseline rule moves with the same slope. A
NerdAxe Gaia (BM1373) measured −0.19 points per °C (2026-10-02), with a
healthy baseline of 4–5 % at 960 mV.
Fixed
- WarpTune (audit 2026-10-07): noise robustness of the share
verdicts. A calibrated voltage was raised 10 mV in operation on any
share vote under 95 % from 400 shares on — a one-sigma miss at 400 —
and never lowered again; the Gamma's Eco 1020 mV walked to 1050 in
three hours at 0 % rejects. A vote short of the bar now waits for the
double window unless it is clearly short (bar − max(10 %, 2/√n)) or
a second witness says the same (a latched domain, the chip error line,
the reject line, the firmware's own reading); a raise needs one of
those or a double window short by more than its own noise; at most two
raises per step a day; and after six healthy hours at a raised voltage
the step goes back one trial step toward what the apply set (the
journal's apply line is the floor). A clearly short vote on fewer than
100 shares is no verdict on its own (the Nano's 1050 mV failed at 69 %
over 68 shares with the firmware at 99 % and 0.42 % errors, and passed
at 112 % over 205 later): from 100 shares on, or with a second witness. - WarpTune, clock search: a member of a
psu_groupsilent for over 90 s
counted 0 W on the supply, so the reserve looked free while that miner
drew on. Its last reading counts on; silent for over 10 min, a
candidate above the start clock is not assessable and fails with the
member named (psu_silent). - WarpTune: a chip domain that latched off was answered with +10 mV per
share window, which does not bring a latched domain back (NerdQAxe++
2026-10-06: 1.5 h at 75–80 % until a two-second excursion to the hand
point restored all 16 domains). On a fresh latch the regulator restores
the hand point once (past the pin), holds the latch voltage off at that
step from then on (the learned voltage goes up two trial steps, a
calibrated step raises its entry), and a second latch at the step
within two hours marks it unstable and steps down. A running
calibration pauses on the bump with the reason on the card instead of
failing the stage; resume starts the reference over. - WarpTune, domain-latch follow-up (NerdQAxe++ 2026-10-07 07:10Z: after
the bump the Eco cap walked 800 → 725 → 650 → 600 one decision each
and, with a few OTA restores, tripped the write breaker at 12 writes):
the way back from a bump is one write to the point the mode wants —
the whole way down, without dwell, past steps held off; the bump and
that return write neither ask nor count towardsmax_writes_per_hour
(restores never did); a step with a latch in its past is written no
lower than the latch voltage plus two trial steps, trial window or
not; and more than three bumps an hour hold the miner at the hand
point for an hour with the reason in the journal. The way down passes
over a step marked unstable also pastmax_steps_down. - WarpTune: the latch memory lived in memory only — a service restart
forgot the voltage floor at a latched step, the per-step bump guard
and the hour's bump count (NerdQAxe++ 2026-10-07 07:49Z: right after
a restart the Eco walk wrote 700 MHz @ 1180 mV, held off there 37 min
earlier). A start seeds all three from the journal'sdomain_off
lines of the present epoch (floors kept for seven days). - WarpTune: a latch's voltage floor could sit above the hand voltage —
a journaled latch at the hand point itself (Octaxe 2026-10-07: 700 MHz
@ 1210 mV, floor 1230 over the 1210 mV ceiling) — and a miner without
a trial window would have been written there on its next arrival at
the step. Every latch floor, live and seeded, is capped at the hand
voltage. - WarpTune: a step up checked the predicted power against the budget
but a step the miner had already run was held against the core current
line itself, and a voltage step up (trial, calibrated raise) was not
held against it at all. Gaia 2026-10-07 11:03Z: "up 380→400 MHz,
predicted 31.1 W of 40.0 W allowed", fourteen seconds later the
TPS546's overcurrent fault at ~33 A on the 31.8–32.3 A the journal
already had for 400 MHz. Every way up — ladder step, voltage trial,
calibrated raise, clock-search candidate — is now held under 90 % of
the core current line: the predicted current at the target (the
journal's reading there, the reading here scaled with f·V, or a higher
step's reading) must stay under it, with the reasonup blocked: predicted core current 31.8 A (…) ≥ 90 % of the 33.0 A fault line (config)in the decision and the journal. The line is the regulator's
fault line when the firmware reports it (coreCurrentFaultA, no
firmware does yet), else the miner'score_current_warn_afrom the
config (set it against the part's fault), else the firmware's warn
limit; a board without any line is unchecked as before and the decision
says so. The step-down at the line is unchanged. A miner may set its
own share of the line withcore_current_up_ratio(0.80–0.97,
check-configrejects the rest; default the global 0.90): the Gaia
measures 30.5–31.0 A at 380 MHz and 31.8–32.3 A at 400 MHz against its
33 A fault, socore_current_warn_a = 33withcore_current_up_ratio = 0.95(bar 31.35 A) lets 380 through and holds off 400, where 0.90
(bar 29.7 A) would keep it on 360. - WarpTune: a restore went to the stock point unasked — the shutdown
restore, "reboot detected", the dead-chip and power-collapse restores
and the domain-latch bump (Gaia 2026-10-07 11:56Z: a WarpTune restart's
"restore on shutdown" wrote 400 MHz @ 960 mV and the TPS546 tripped a
second time within the hour). Every restore target is now checked like
a step up: with the stock point's predicted core current (the journal's
reading there, scaled) at or over the bar, the highest ladder step under
it at or under the hand voltage whose prediction passes is written
instead, and the reason saysrestore held under the current bar: 380 MHz @ 960 mV instead of 400 MHz @ 960 mV (…)in the log and the
journal. Nothing known (no line, no reading): the stock point as before. - WarpTune: the settle after a service start was armed at second 0 of
the run clock, which counts from the service start; a device that
answered the first probe minutes later was judged with every rule
armed on its first sample. The loop arms the settle once the run is
prepared. - WarpTune: a clock the search found above the ladder top came back
after a restart as a step whose base was the calibrated voltage, so
the calibrated voltage was its own ceiling (no raise in operation, a
new calibration of the step started there). The step's base is the
top step's reference again. The last discarded result was read back
only together with an applied one; a miner that only ever discarded
said "not calibrated" after a restart. - WarpTune: an apply cleared the calibrated points of other clocks (a
second job with a found Max clock dropped the first job's point at the
hand clock, which then ran at the hand voltage again). The job's points
are merged into the ones in force. - WarpTune calibration: a re-check of the voltage the search goes on
from after a failure left no journal line; verdicts beyond the plan
(an extended floor, a re-check) pushed the card to 100 % and 0 s with a
window still open. Journal eventrecheck; the plan grows with the
floor; the open stage never reads full. - WarpTune, clock search: the Eco clock stage took the next lower ladder
step as its candidate even when that step was held off, which the way
down skips — only the four-hour timeout ended it. The search takes the
next free step below. Withbeyond_spec = falsethe ceiling was still
the maker's beyond-spec line (BM1370: 800 MHz), socalib_clockalone
opened the search above the maker's table; withoutbeyond_specthe
ceiling is the table's top step (an option-list board: its top). - Devices page: the reasons a stage, a clock candidate or the job ended
were the sidecar's English free text in every language. The sidecar
carries each reason structured (fails: kind, values, detail, text;
badgecalib_detail_fails) and the page translates the kind
(miners.calib_fail_*, 32 kinds); an unknown kind falls back to the
English line. The seven non-English locales carry English placeholders
until the native review. - Pool: the audit line of a
fan_targetcommand names the target; the
sidecar compares the control token in constant time. - WarpTune: the PV surplus budget was lifted for the duration of a
calibration (an energy-mode miner ran the clock search at the top for
hours without its cap). The budget stays in force: it limits the way
up only, so a pinned step is measured as before and a clock candidate
above the budget fails at once as "not reachable: budget"; the energy
mode's own switches stay deferred until the job ends. - WarpTune calibration: a stage whose reference is its result because
the voltage under it is held off after a failure (not because the
floor is reached) names that (trial_hold) instead of an unexplained
"open" result. - WarpTune: a fan-target write is read back on the next three samples; a
firmware that keeps its old target gets a journal line (probe_error
"fan target write not taken") and the regulator's target floor goes
back to the previous target. - WarpTune, clock search:
calib_clock_after_voltage(per miner, opt-in)
runs the Max clock stage after the Max voltage stage, at the voltage
that stage takes over (found plus the reserve) plus the ladder's
0.35 mV/MHz per step above the hand point, never above the hand
voltage — the thermal criteria are then judged where the miner will
run (Nano 2026-10-06: at the hand voltage the fan hit 100 % and ended
the search; at the calibrated voltage the same clock needs 58 %).
Default off: the clock stage runs first, at the hand voltage. - Devices page: a miner whose last calibration result was discarded
(hand voltages kept) said "not calibrated" once the job had left the
card (Octaxe 2026-10-02). The last discard rides on the snapshot and
the badge (calib_discarded_at,calib_discarded_found) when it is
newer than the applied calibration; the card says "result discarded
on …" and offers "Calibrate again". - WarpTune: the first sample after a service start was judged with every
rule armed, settle or not (Nano 2026-10-06: the shutdown had written
the hand point back 38 s earlier, the first sample carried a 56 W
transient over the 55 W cap, and the regulator stepped down urgently).
The first sample after a start arms the 45 s settle like a point
change (from the moment the run is prepared, see above); a point
whose age the journal knows — under a running calibration — is judged
as before, the reboot detection and the firmware's protections are not
held. - WarpTune calibration: the clock stage's power, core current and
supply-draw criteria judge the highest mean of three consecutive polls
instead of the highest single poll (the Nano's hand point draws 51 W
with lone 58 W polls against a 55 W cap). Temperatures and the fan
keep their single-poll maxima. - WarpTune calibration: a service restart during a clock stage failed
the stage on the first sample after the start (Nano 2026-10-06: the
shutdown had restored the hand point 650 MHz @ 1160 mV, which draws
56 W over the 55 W cap; the regulator's urgent step down from there
was read as a guard leaving the start clock 425 MHz before the miner
had reached it). A move from a point that is not the candidate is no
verdict on the candidate; the not-reachable rule and the timeout judge
until the miner is on it. - WarpTune calibration: a voltage stage's floor could lie under the hard
minimum (calib_hard_min_mv, WarpAxe'sregulatorMinMv) when the
reference sat within six steps of it — the Nano's Eco stage (reference
1000 mV on the regulator's 1000 mV floor) was planned with a floor of
940 mV and would have asked the firmware for 990 mV, which it refuses
(three refusals → live control off). The floor never goes under the
hard minimum; a reference at the hard minimum is measured and ends the
stage ashard_minimuminstead of failing it. A job read back from
the journal with such a floor is held to the hard minimum again. - WarpTune: a step down onto a calibrated step whose voltage lies under
the voltage window's floor was written at the floor first and only one
settle later at the calibrated voltage (Gamma 2026-10-06, after an OTA
reboot: 525 MHz @ 1100 mV for 90 s, then 1020 mV). The calibrated
voltage is written directly; the window's ceiling still holds. The
heartbeat line journals the calibrated voltages (calibrated_mv) next
to the trial memory, which is never lowered to them. - Devices page: the calibration buttons showed although the pool held
no WarpTune control key, and the command's error landed at the top of
the page (Umbrel 2026-10-06: Apply pressed twice, nothing visible, the
audit log said "no control token"). The badge carriespool_token;
without the key the card says so instead of the buttons, and a
command's error is shown on the card next to them. - Devices page: a day after a calibration job finished the card said
"not calibrated" although the applied voltages were in effect (Nano,
applied 2026-10-04, card on 2026-10-06). The sidecar now reports the
calibration in effect independent of the job (applied: when, the
points, the found voltages, Eco cap, fan target; badge
calib_applied_at/calib_applied_points) and the card shows it
permanently with Calibrate again. - Devices page: the "waits for PV surplus" badge showed on a miner at
the top of its ladder, where no step up exists (NerdOctaxe at 700 MHz,
2026-10-05); the sidecar reportsat_top(the top step of the present
mode) and the badge stays off there. - Devices page, network-range scan: WarpAxe is recognised by its version
string also without an ASIC model (chipless dev kit), and the per-host
timeout is 1.8 s instead of 0.9 s so a miner whose WiFi sleeps between
packets still answers the first probe. - Devices page, add miner: a network-range scan without an admin login
showed "active-scan: HTTP 401"; it now says to log in as admin (the
range sweep has required a login since the July 2026 audit). - Devices page, voltage search line: the power figure reads as power draw
("approx. +16 % power draw"; German "Stromverbrauch" instead of the
ambiguous "Leistung"), and "too many chip errors" is named as the reason
only when the failed voltage's chip error rate was at least 0.5 % and at
least 0.5 points above the rate now; otherwise the line says the
hashrate was too low (NerdQAxe++ 2026-10-04: "too many chip errors
(0.0 %, now 0.0 %)").
dvb-WarpPool v1.37.0 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.37.0(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- dvb-WarpTune: calibration with clock search (opt-in per miner,
-
v1.36.1
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m5sCI / Rust fmt (push) Successful in 1m20sCI / Rust test (push) Successful in 6m32sCI / UI (SvelteKit) (push) Successful in 1m21sCI / Security Audit (push) Successful in 1m24sdocs / build (push) Successful in 38sRelease / Docker Multi-Arch (push) Successful in 23m38sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 11m58sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 10m26sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m3sRelease / Linux .deb + .rpm (arm64) (push) Successful in 1m54sRelease / Linux AppImage (aarch64) (push) Successful in 26sRelease / Linux AppImage (x86_64) (push) Successful in 28sRelease / Cosign sign artifacts (push) Successful in 28sRelease / Forgejo Release (push) Successful in 37s2026-10-03 13:02:42 +00:00 | 135 commits to main since this releaseFixed
- WarpTune, calibration: the ladder walking down to the stage's pinned
step one step at a time ended the stage as if a guard had left it. A
miner whose present frequency sat more than one ladder step above its
Eco step (Bitaxe Gamma: Max 640 MHz, Eco 525 MHz via 575) failed the Eco
stage in its first minute, before anything was measured. A step down
that stays at or above the stage's frequency is now the approach; a step
below it, or any guard on the step itself, still ends the stage.
dvb-WarpPool v1.36.1 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.36.1(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- WarpTune, calibration: the ladder walking down to the stage's pinned
-
v1.36.0
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m2sCI / Rust fmt (push) Successful in 1m15sCI / Rust test (push) Successful in 6m10sCI / UI (SvelteKit) (push) Successful in 1m20sCI / Security Audit (push) Successful in 1m20sdocs / build (push) Successful in 38sRelease / Docker Multi-Arch (push) Successful in 24m16sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 12m3sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 10m53sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m6sRelease / Linux .deb + .rpm (arm64) (push) Successful in 1m52sRelease / Linux AppImage (aarch64) (push) Successful in 27sRelease / Linux AppImage (x86_64) (push) Successful in 27sRelease / Cosign sign artifacts (push) Successful in 28sRelease / Forgejo Release (push) Successful in 38s2026-10-03 06:41:11 +00:00 | 136 commits to main since this releaseCalibration by button for dvb-WarpTune. Calibration only ever lowers the
core voltage below the hand-tuned point at the same frequency, so a miner
never draws more power than there. Each voltage is judged on one window of
200 pool shares, which still varies by several percent: a good voltage can
occasionally fall short, and calibration then keeps more voltage, never
less. A confirmation window near the floor and per-chip checks follow in a
later release.Added
- dvb-WarpTune:
chip_error_trigger(under[defaults]or per miner)
turns off the step-down and the up-hold on the firmware's chip error
rate. WarpAxe v0.1.11 reports an instant value with a counter-restart
spike after voltage writes and a BM1373 baseline of 5–8 %; with the
trigger on, a healthy NerdAxe Gaia was walked from 400 to 320 MHz.
Default on. The journal keeps the reading either way, and WarpTune
prefers WarpAxe's 1-minute rate (errorPercentage1m, v0.1.12) over
the instant value. - Devices page: calibration by button ("Einmessen"). Logged in, every
device WarpTune controls live gets Start calibration; the sidecar then
measures the miner's Eco step and its Max step (the hand-tuned point)
one after the other — the reference voltage first, on 200 pool shares,
then 10 mV less at a time until a step falls short — about 6–8 hours,
the miner keeps mining. The card shows the stage, the voltage under
test, the shares counted, the time left and a progress bar, with Pause
and Stop; at the end the voltage found per step against the reference
with the measured power and pool-side hashrate, and Apply / Discard.
Nothing changes before Apply; the hand-tuned point stays the ceiling
and the restore point. No button on an Avalon, on maker presets (BitForge
Nano), in dry run or without a pool feed — the line says why. Eight
languages, phone layouts. - Command path pool → WarpTune:
POST /api/admin/tune/calib(admin only,
audit actiontune.calib.<action>) forwards start / stop / pause /
resume / apply / discard to the sidecar's newPOST /calib/{host}/{action},
guarded by a shared key:[mining.tune] token_envon the pool and
sidecar.control_token_envin warptune.toml name the same environment
variable — or the key is entered under Admin → Profile → dvb-WarpTune
coupling and stored insecrets.toml(tune_token), the way for
Umbrel. Without the key the sidecar refuses every command; the
snapshot stays readable.scripts/setup-warptune.shexports
warptune-control-tokento the service asWARPTUNE_TOKEN. - WarpTune: the calibration job pins the miner to the stage's step (energy
mode and the PV budget pause, every guard stays on and ends the stage),
journals every state change and continues after a restart of the
service where it was — the open voltage step keeps the shares it had
already counted (journalsamples now carry the share difficulty).
Applied voltages are journaled and become the step voltages from then
on, also after a restart; a reboot that puts the hand point back is
followed by a step down to the calibrated voltage once settled.
[defaults] calib_max_steps(6) andcalib_timeout_s(4 h) bound a
stage; a reference that is short of good ends its stage without a
result. A failure the regulator's guards call on the firmware's
reading, short of the 200 shares a verdict needs, does not end a stage
(the voltage is held off and tried again; a second failure there, or a
share-based one, does), and a stage that times out below a good
voltage ends with that voltage. - WarpTune, calibration: Apply takes each found voltage over with a
reserve —[defaults] calib_margin_mv, 20 mV by default, never above
the stage's reference (the lowest good voltage sits one step above a
failure; the reserve is the headroom). The result rows on the devices
page show both ("1200 → 1180 mV, takes over 1200 mV (+20 reserve)"),
the journal'sCalibAppliedline carriesfoundnext topoints. - WarpTune: a calibrated voltage is re-adjusted in operation. When a
calibrated step falls short of good on the pool's shares (200 under the
bar, or clearly under it sooner; too many rejects count too), the
regulator raises that step's voltage by 10 mV, up to the reference, and
journals it as the new calibrated voltage instead of only stepping the
frequency down. Heat, current, dead chips and the firmware's own stops
keep their frequency downs. - WarpTune: the chip error rate lines are per miner —
error_down_pct
(step down, default 2 %) anderror_up_max_pct(hold the way up and
"short of good", default 1 %) under[defaults]or per[[miner]]; a
BM1373 (NerdAxe Gaia) runs a healthy baseline of 5–8 %. The trigger acts
on the firmware's 1-minute rate only (errorPercentage1m, WarpAxe
≥ 0.1.12; the instant value is journaled, never acted on), not within
60 s of a point change, and steps down on two decisions in a row. - WarpTune: the journal memory of a host (steps judged healthy, voltage
verdicts, core currents, calibrated voltages) ends at a firmware change
of family or major (BitMaker → WarpAxe) with adevice_changedline,
as it does at a board swap; an update inside the family keeps it. - WarpTune: an invariant test runs the regulator over a grid of
temperatures, hashrate ratios, error rates, input voltages and core
currents in every mode and checks each point change against the
window's top, the ladder cap, the hand voltage, a calibrated voltage,
the restore point and the Eco cap.
Fixed
- Devices page: the running voltage search no longer reads
"Calibrated" — that word belongs to the calibration by button. The line
now says Voltage checked, the voltage found against WarpTune's table
voltage for the step ("needs 960 mV (table 940)" / "runs at the table
voltage") and why: the voltage that failed below it with its chip error
rate and the rate now ("at 950 mV too many chip errors (4.6 %, now
3.3 %)"), or "hashrate too low" where the firmware counts no errors.
The power figure is marked as an estimate; the pool-side hashrate, a
snapshot unrelated to the voltage, is gone from the line. WarpTune
journals the chip error rate with every trial verdict
(error_pct); older lines give it from their reason text. - WarpTune, Eco: a step was judged on one J/TH reading against the
all-time minimum of every sample it had ever produced; the firmware's
10-minute average overshoots by 10–15 % now and then, so the minimum
was a bar every later reading failed. A Gamma walked 525 → 400 MHz on
2026-09-30 and saw-sawed 525 ↔ 500 all morning on 2026-10-01 (thirteen
writes in 100 minutes against a breaker of twelve an hour), a
NerdQAxe++ 600 ↔ 590, a Gaia 350 ↔ 340. A step's efficiency is now the
settled mean of its readings with the hashrate capped at the expected
rate, fresh for an hour; Eco leaves a step after three decisions in a
row and only for a step that can be better (measured better, or less
core voltage), and the way back up stays closed while the worse reading
is fresh. - WarpTune: the shutdown restore is written also after live control was
switched off; the miner used to stay on whatever point the last write
left it at, and the next start took that for the hand point (Gaia
2026-09-30: breaker at 320 MHz, restore point 400 → 320). A start
withoutstockwarns when the point it finds differs from the last
start's restore point.stockis range-checked and capped at the
ladder's voltage ceiling;voltage_max_mvcaps the ladder curve also
without a trial;voltage_min_mv/voltage_max_mvare checked whether
the trial is on or not;ladder_cap_mhzmay go down to 200;
calib_max_steps,calib_timeout_sandcalib_margin_mvare
range-checked. - WarpTune, calibration: with
voltage_trialon, the step voltage came
from the trial memory (the search's own verdicts, one reserve below the
applied voltage) and the re-adjustment was off; the Octaxe's 700 MHz
would have run at the found 1180 mV instead of the applied 1200, and
the trial would have probed below it again. A calibrated step is
written at its calibrated voltage, the trial does not go below it, the
raise works with a window; only a running job searches below. - WarpTune: a write that failed with an HTTP error was never retried for
a non-urgent decision (the proposal counted as "unchanged"); live-off
mid-calibration left the job running with its writes dropped (it is
stopped and journaled now); a dead chip that does not come back was
rebooted every three minutes until the write breaker tripped (the
fourth restart within an hour switches live control off). - WarpTune, calibration: a non-urgent move off the pinned step did not
end the stage (it waited for a step just marked unstable, up to the
timeout); any Down or Restore off the step ends it now, the trial does
not give a pinned step up, and a reference short of good on the way back
up ends the stage with the lowest good voltage. A stage starts without
the trial's failure holds at its frequency (a 92 % error spike after a
write had held 1200 mV off for an hour); the timeout clock continues
across a restart; with 200 shares counted the hashrate reading no
longer gates the verdict (WarpAxe 0.1.12 moves 1–3 % per five minutes
whatever the point does). - WarpTune: the core current measured on a step is tied to the voltage
it was measured at (journaled with it); a reading at another voltage
is scaled and held under 97 % of the warn line, and a higher step
bounds a lower one only at a voltage at or above the target's. - WarpTune, voltage trial: an early "short of good" call on fewer than
200 shares has to beat the share count's own noise (two standard
deviations, 2/√n) as well as the fixed 10-point gap. Forty shares read
±16 %, and a VarDiff move right after a voltage write skews the first
minutes further: the Octaxe's 650 MHz @ 1200 mV was failed twice at
77 % and 83 % on 41 shares while the reading said 97–98 % and 1210 mV
booked 98–101 % on 203 (2026-10-01). The verdict text names the
1-minute error rate, not the instant value. - WarpTune, calibration: a stage's result is the lowest voltage judged
good strictly above the highest voltage judged bad, and a voltage good
once and bad on a second measurement counts as bad. The old rule
looked for a good verdict exactly one step above the failure and found
none when the step above had been overturned; the Octaxe's run of
2026-10-01/02 (Eco good 1210…1160, 1150 bad, 1160 bad again; Max good
1210…1170, 1160 and 1170 bad) ran on in both stages until a guard
stepped the miner off and failed the whole job without a result. A
guard that ends a stage after good voltages were measured now ends it
with their result (Eco 1170 → 1190 with the reserve, Max 1180 → 1200
on that run); only a stage without one fails. A reference that is
short of good on the way back up has no result above it and fails. - WarpTune, command path: a calibration command the miner loop has not
picked up within 60 s is dropped (a Start must not fire hours later when
the device answers again), and a command against a miner entry older
than 90 s is refused with 409. A finished job leaves the snapshot after
a day, so the regulator's own trial line shows again. - WarpTune, calibration: a stage's reference (and a search step on the
window's floor) no longer waits for a trial verdict the regulator only
reports when it is news to its trial memory. The Octaxe's re-run on
2026-10-01 sat on the Eco reference for 1.5 h: 650 MHz @ 1210 mV had
been read back from the day before's verdicts, the point was judged
healthy at 08:12Z and no verdict followed. The stage now takes the
regulator's share vote directly. - Devices page, calibration: the progress line names the stage as "Eco
step (1/2)" / "Max step (2/2)", so a finished first stage no longer
reads like a finished calibration. - UI translations (es, fr, it, ja, pt-BR, zh): the three list pages carry
one name each, the same in the menu and as the page title (wallets,
Stratum logins, devices); in Spanish, Japanese and Chinese two pages had
shared a title, in Italian the menu item for the logins was named like
the devices page. The size profiles are translated (es, fr, ja still
showed the German "Klein / Mittel / Gross"). - Header: the nav takes its own line whenever it does not fit beside the
logo and the status pills, measured from the items themselves. A fixed
breakpoint at 1100 px let the nav slide under the pills at wider
windows, logged in and in German. - Admin → Notifications: the HTTP notice keeps its distance from the
status row below and its badge sits at the first line. - Devices page: the WarpTune tooltip line for the PV surplus budget shows
the watts instead of a literal{w}(placeholder written with single
braces).
dvb-WarpPool v1.36.0 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.36.0(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- dvb-WarpTune:
-
v1.35.0
StableAll checks were successfulCI / Rust clippy (push) Successful in 1m57sCI / Rust fmt (push) Successful in 1m14sCI / Rust test (push) Successful in 6m0sCI / UI (SvelteKit) (push) Successful in 1m19sCI / Security Audit (push) Successful in 1m21sdocs / build (push) Successful in 37sRelease / Docker Multi-Arch (push) Successful in 22m51sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 11m44sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 10m26sRelease / Linux .deb + .rpm (amd64) (push) Successful in 2m5sRelease / Linux .deb + .rpm (arm64) (push) Successful in 1m53sRelease / Linux AppImage (aarch64) (push) Successful in 27sRelease / Linux AppImage (x86_64) (push) Successful in 27sRelease / Cosign sign artifacts (push) Successful in 26sRelease / Forgejo Release (push) Successful in 37s2026-09-30 12:38:19 +00:00 | 166 commits to main since this releaseChanged
- Pool UI redesign in the warp design of the WarpAxe web UI. Dashboard:
one hero card with every pool fact, workers sending shares first and
silent ones dimmed with a status dot. Overview: the period's mean as
hero, upright short bar labels with values. Hashrate page: one hero
with the history inside and a smoothed/raw switch; its current rate is
the last complete bucket, as on the dashboard. Miners page: search,
active/all switch, the first 50 with "show all", a hashrate column.
Blocks page: the found count as hero next to the pool's solo odds.
Workers and public wallet pages: live wallets first, hashrate as hero,
a smoothed chart. Every table has phone columns, the phone navigation
shows a small › while items are off to the right, and the header keeps
its shape while the pool loads. - Devices page: each WarpTune device shows its "Einmessen" line (the
voltage search on its present point, with the power and hashrate
against the reference once it is done), a "mining on another pool"
badge for a miner set to a different pool, and "Tariff & solar from
here" where dvb-WarpTune takes its energy feed from this pool. - Energy card laid out like the pool card: present power large with
€/h, tariff and miners, the 24 h / 7 d / lifetime figures as small
tiles, the source mix now and since the start as two bars, whole watts
below 1 kW, the battery as amount plus direction, and the excess tile
says whether more is produced or used.
Added
- Devices page: a miner that runs Max on PV surplus but whose surplus
budget leaves no room above its present draw says "waiting for PV
surplus" on its WarpTune badge, and the tooltip names the budget in
watts. dvb-WarpTune reports the budget in its snapshot (pv_budget_w). - Devices page data: each miner reports the pool it is set to
(stratum_url, host and port only);mines_heretells a miner set to a
public pool on purpose (shown neutral) from one that should mine here
but is not connected (the amber warning stays);energy_source_here
marks miners WarpTune regulates by this pool's tariff and PV surplus. - dvb-WarpTune reports the voltage search on each miner's present point
(off, running with voltage and shares, done with the voltage found,
the core power it saves by V² and the pool-side hashrate), and its
[energy] source; the pool passes both to the devices page. - dvb-WarpTune: a step the miner has already run is judged on the core
current measured there (journaled, survives restarts), against the warn
line itself; only a step it has never run is predicted by f·V with the
90 % headroom. The prediction ran high and kept the Gaia from 400 MHz
(predicted 32.3 A, measured 31.3–31.8 A against a 32 A line). - dvb-WarpTune energy mode:
[energy] sourcenames the pool the tariff
and PV feed come from, when miners mine on another pool. Share counters
still come from each miner's own pool. Miners on pool.warppool.org read
"no tariff" there and sat in Balanced. - dvb-WarpTune:
core_current_warn_aper miner replaces the firmware's
core over-current warn line for the step-up gate and the step-down;
the regulator's own fault limit stays the hard stop. - dvb-WarpTune BitForge Nano: the three maker presets are the only
steps, each at its own voltage — Eco 425 MHz @ 1000 mV, Medium 525 @
1150, Power 625 @ 1160 — no 25 MHz steps between them. The table is
found under Forge-OS's board "800" and WarpAxe's "bitforge-nano", and it
wins over the device's option list, whose curve would have put 1150 mV
on Eco and 1200 mV on Power. - dvb-WarpTune: the core regulator's current is a limit. Where the
firmware reports it (WarpAxecoreCurrentA/coreCurrentWarnA), a step
up past 90 % of the over-current warn line is blocked, and a point at the
line steps down and is held for an hour. A regulator stop for a fault is
left like a heat trip and named for its cause. A NerdAxe Gaia at
420 MHz / 960 mV drew 31–33 A at full load against 28 A warn / 33 A
fault and was cut on 2026-09-29. - Devices: a board of the AxeOS family registered under a sibling label is
relabelled from what its firmware reports. A NerdAxe Gaia that took a
NerdAxe Gamma's address kept the "NerdAxe Gamma" badge on its card
(the probe already knew better), and the devices page has no way to
edit it. - dvb-WarpTune: silent chips are seen within minutes. The dead-chip guard
reads WarpAxe's instantaneoushashRate_nowwhere present (hashRate
is a 10-minute average), and the power-collapse guard arms itself from
the settled draw of the point the miner runs, not only after a step
WarpTune made. A collapse on the point that has run all along restores
stock and restarts the device. On 2026-09-29 all eight chips of a
NerdOctaxe went silent at 52 W and neither guard spoke. - dvb-WarpTune energy mode: on PV surplus a miner climbs only as far as the
surplus carries it — its present draw plus the pool's excess, minus
surplus_reserve_w(new, default 300 W). An Avalon Q went Eco → Super on
~1100 W of surplus, Super's +870 W took the surplus away, and it swung
back to Eco 21 times in three hours on 2026-09-28, each switch a
hash-board restart; on that surplus it now stays at Standard. The budget
limits the way up only. - dvb-WarpTune: after the firmware's own overheat stop the point is held
as a ceiling for an hour and left one step down once the device hashes
again, two steps from the second stop within an hour. ESP-Miner and
WarpAxe resume on their own at the same point, and WarpAxe latches after
the third stop; before, WarpTune paused and then ran the point that
tripped again. A stop for a lost temperature sensor changes nothing.
Reads WarpAxe'soverheatTripsandoverheatCause(0.1.4) where
present.
Fixed
- dvb-WarpTune: a step the miner has not run yet, below a step it has
run under the core current warn line, is bounded by that reading
instead of the f·V guess with 10 % headroom. The NerdAxe Gaia had
measured 400 MHz at 31.6 A of 32 A and was still kept off 380 MHz by a
predicted 30.4 A. - dvb-WarpTune energy mode: the PV surplus budget holds for as long as
the miner runs its surplus mode. The mode outlives the surplus by
surplus_exit_pollsand the hold time; the budget dropped with the
pool's surplus flag, and a miner could climb on grid power in that gap
(NerdAxe Gaia 350→360 MHz at −460 W excess). Without a usable reading
the budget is 0 W: no way up, and nothing is stepped down for it. - Overview and metrics: the daily hashrate (mean and peak) and the
Prometheus pool hashrate divided each 1-minute share bucket by 300 s and
read five times too low (3.06 instead of ~15.8 TH/s on the overview).
The daily mean is now the day's difficulty over the seconds it covers,
the peak the strongest hour. - dvb-WarpTune Eco: the efficiency yardstick is the best J/TH among the
steps Eco may run. With an Eco cap, a better step above it (the
Octaxe's 700 MHz over a 650 cap) made Eco step 650 → 625 and climb back
every fourteen minutes. - Pool UI and API: the live hashrate per miner is the average of the last
ten minutes, not of the last minute. VarDiff holds every miner near
four shares a minute, so a single minute swung by about ±50 %: an
Avalon Q at ~54 TH/s showed 105.6 TH/s on 2026-09-27. Ten minutes are
about 40 shares, ±16 %. A miner that connected three minutes ago is
averaged over those three minutes. Workers, wallet pages and the widget
read the same number; NerdMiner-class devices keep their 30-minute
window. - dvb-WarpTune: a short hashrate reading steps a miner down at once only
when the pool's shares agree beyond their own noise (± 1/√n); until
then it waits for more shares, and a point that is only marginally
short is left to the yield table. Without any shares the reading
decides alone, as before. On 2026-09-27 a Bitaxe Gamma read 89 % and
89 % on about fifty shares, and on 2026-09-28 90 % on 200 shares
(± 7 %); both times a sound 640 MHz was stepped down. Heat, power,
input voltage and chip errors still step down at once. - dvb-WarpTune: a hand-tuned point between two ladder steps is a step of
its own. The Gamma's 640 MHz sat between 625 and 650; after a step down
the climb went 625 → 650 and skipped it, and 650 earned 87 %. - dvb-WarpTune: an input voltage no board can see (outside 0.5–30 V) is
no reading, not a brown-out. A WarpAxe build reported -127500 mV once
after a boot, and the VIN guard proposed an urgent step down. - dvb-WarpTune: shares a miner mines on its fallback pool are not read as
a point that stopped hashing. ESP-Miner-style firmwares report
isUsingFallbackStratum; while it is set, the coupled pool's counters
stand still, so the share and reject windows are dropped and start over
once the miner is back. Before, the share vote saw minutes without a
share and could call a good voltage short.
dvb-WarpPool v1.35.0 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.35.0(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Pool UI redesign in the warp design of the WarpAxe web UI. Dashboard: