Enable Stratum V2 on a Bitaxe (AxeOS v2.14+)

Since ESP-Miner v2.14.0 (released 2026-06-04), every Bitaxe on stock AxeOS speaks Stratum V2 natively — an encrypted, binary pool connection with no proxy box beside the miner and no firmware swap. The support landed in PR #1553 by @warioishere (first shipped in the v2.14.0b3 beta on 2026-05-19; current release is v2.14.2), and enabling it is five settings in the AxeOS web UI. This page is the operational half: the exact settings, which pools accept a native SV2 connection today, and how to verify shares are flowing over the encrypted channel. For what Stratum V2 actually changes on the wire, start from Stratum V1 vs V2 and the full Stratum V2 guide.

Jump to: what you get (and don’t) · prerequisites · pool matrix · the five settings · fallback design · verify the channel

What Stratum V2 gives a Bitaxe — and what it does not

Be precise about the win before flipping the switch. Verified against the merged implementation at the v2.14.2 tag:

• You get: an encrypted transport — a Noise_NX handshake (full suite: Noise_NX_Secp256k1+EllSwift_ChaChaPoly_SHA256) with ChaCha20-Poly1305 encryption on every pool message; compact binary framing in place of Stratum V1’s plaintext JSON; optional verification of the pool’s authority public key, so your miner can confirm it is talking to the real pool; per-share SV2 response-time measurement on the dashboard; and a four-way primary/fallback protocol design (below).
• You do not get: your own block templates. ESP-Miner v2.14.x implements both SV2 channel types — extended channels are the default (and forced on BM1397 chips, which lack hardware version rolling), with standard channels honored when configured on other chips — but there is no Job Declarator client either way, so the pool still constructs the block template and picks the transactions, exactly as under V1 (on extended channels the pool supplies the template too, as a coinbase prefix and suffix). If anyone tells you SV2 on a Bitaxe means “you choose the transactions,” that is a different, heavier part of the Stratum V2 stack that this firmware does not ship.

So the honest pitch is: encryption (your pool credentials and shares are no longer readable plaintext on the wire), integrity (a hijacked connection fails the handshake instead of silently redirecting your hashrate), and lower per-share overhead. That is worth five settings.

Prerequisites

• Any Bitaxe on stock AxeOS, running ESP-Miner v2.14.0 or later (current: v2.14.2, 2026-07-08). v2.14.0 also carries the SV2 submit-latency fix (TCP_NODELAY on pool sockets) and per-share SV2 response-time measurement — both landed during its beta cycle.
• If you are below v2.14.0: update over the air from the AxeOS web UI — both files, esp-miner.bin (firmware) and www.bin (the web UI itself), so the interface and the firmware move together. Scripted fleets can use the OTA endpoints POST /api/system/OTA and POST /api/system/OTAWWW — see our AxeOS advanced configuration & API guide.
• An account (or a solo-mining address) on a pool that accepts native SV2 — next section.

Which pools accept native SV2 from a Bitaxe

The pool landscape moves monthly; the live who-supports-what record is our Stratum V2 deployment tracker.

Turn it on: five settings in AxeOS

Step 1 — Confirm the firmware version.

• Action: open the AxeOS dashboard in your browser (the Bitaxe’s IP address) and read the firmware version.
• You should see: v2.14.0 or later — ideally v2.14.2. If you are below v2.14.0, OTA-update both esp-miner.bin and www.bin first (Prerequisites above).
• What it proves: the SV2 stack, the submit-latency fix, and per-share SV2 response-time measurement are all on board. Read-only; nothing to undo.

Step 2 — Set the primary pool’s protocol to Stratum V2.

• Action: in AxeOS pool settings, set the protocol selector for the primary pool to Stratum V2. The selector exists for the primary and the fallback pool independently.
• You should see: V1-only options disappear and an SV2 public key field appears — the UI reshapes around the selected protocol.
• What it proves / how to undo: your build carries the PR #1553 UI. Undo is the same selector back to Stratum V1; nothing else changes until you save. A channel-type setting also exists in the device configuration — extended is the default, and on BM1397 chips the firmware forces extended; you rarely need to touch it.

Step 3 — Enter the pool endpoint and its public key.

• Action: fill in the pool host and port, and paste the pool’s public key into the SV2 public key field. For Braiins Pool: host stratum.braiins.com, port 3333, key 9awtMD5KQgvRUh2yFbjVeT7b6hjipWcAsQHd6wEhgtDT9soosna — copy it character-for-character from the pool’s own page, never from a third-party post.
• You should see: the key accepted into the field; it is stored in the device’s NVS with the rest of the pool config.
• What it proves: the key is what lets your miner verify the pool’s identity during the Noise handshake — the anti-hijack half of the win. A wrong or stale key fails the handshake, which is the system working, not breaking.

Step 4 — Worker credentials.

• Action: set the stratum user to userName.workerName (your pool username, a dot, then a label for this Bitaxe). Password: anything — SV2 pools don’t authenticate on it.
• You should see: the same credential shape you already use on V1 — nothing SV2-specific here.

Step 5 — Set the fallback, save, restart.

• Action: configure the fallback pool (keeping it Stratum V1 is fine — see the next section), save, and let the device restart.
• You should see: after reboot, the pool settings’ protocol indicator showing Stratum V2 on the live connection, and accepted shares climbing on the dashboard.
• What it proves / how to undo: you are mining over the encrypted channel. Undo is Step 2 in reverse — set the selector back to V1 and save. Pool-side accounting is unaffected either way.

Fallback design: all four combinations work

The protocol coordinator supports every primary/fallback pairing — verified in PR #1553:

Verify the encrypted channel

• Protocol indicator: AxeOS pool settings show which protocol the live connection is actually using — if the primary handshake failed and the miner fell back, you see it here first.
• Per-share SV2 response time: v2.14.0+ measures and displays it per share — your direct read on the latency half of the SV2 pitch, and a useful canary: a sudden jump usually means network trouble, not miner trouble.
• Shares accepted: the number that matters. Watch it climb on the dashboard, or poll it from any LAN machine: curl -s http://<bitaxe-ip>/api/system/info | jq .sharesAccepted — the same heartbeat our auto-restart watchdog is built on, and every field that call returns is documented in the AxeOS API reference.
• If shares stall on V2 but flow on V1: re-copy the pool public key from the pool’s own page (a stale key fails the handshake by design), confirm the port is the pool’s SV2 port, and check the deployment tracker for pool-side changes.

What about the rest of the fleet?

As of mid-2026, VNish and LuxOS are still Stratum V1-only — so a Bitaxe shelf can go native SV2 today while the Antminers beside it cannot, unless they run Braiins OS+ (native SV2 on supported industrial models) or you put the SRI translation proxy in front of them, which upgrades any V1 miner’s pool link without touching its firmware. The full protocol picture across firmwares and pools lives on the deployment tracker.

Spreading beyond the Bitaxe: the NerdQAxe+ family is getting the same stack — PR #544 porting SV2 support was merged into the NerdQAxePlus fork in April 2026. On NerdQAxe-class hardware running a release that includes it, the steps on this page map across nearly one-for-one.

FAQ

Does Stratum V2 on a Bitaxe let me choose my own transactions?

No. ESP-Miner implements both standard and extended channels — extended is the default, and forced on BM1397 — but there is no Job Declarator client, so the pool builds the block template exactly as under V1. What you gain is an encrypted, authenticated, binary connection and per-share latency you can measure.

Which pools accept a native Stratum V2 connection from a Bitaxe?

Braiins Pool publishes an SV2 endpoint with its pool public key; BlitzPool and the SRI reference pool are the two the implementation was tested against in PR #1553; mkpool documents its own Bitaxe SV2 path. DEMAND has no published endpoint for a bare Bitaxe connection at last verification. For every other pool, the SRI translation proxy is the bridge.

Do I need new worker credentials for Stratum V2?

No. The user is the same userName.workerName shape you already use, and the password can be anything. The only new field is the pool’s SV2 public key — copy it from the pool’s own documentation, character for character.

What happens if the SV2 pool goes down?

The miner fails over to your fallback pool. All four primary/fallback protocol combinations are supported, so a V1 fallback behind a V2 primary keeps the Bitaxe hashing through any SV2-side outage — the protocol indicator in pool settings shows which connection is live.

Credits

Native Stratum V2 on the Bitaxe exists because @warioishere wrote it — PR #1553, merged into ESP-Miner v2.14.0 by the bitaxeorg maintainers (GPL-3.0), followed by his own latency and response-time refinements in the same release train. mkpool published the first Bitaxe-specific SV2 setup walkthrough — prior art, gladly credited. Endpoint specs come from Braiins’ own academy documentation and the PR’s test record; the protocol itself is the work of the Stratum V2 reference implementation (SRI) project.

Record last verified: 2026-08-13. Release dates, PR contents, channel-type behavior (verified at the v2.14.2 tag, main/tasks/stratum_v2_task.c), and the current v2.14.2 release were re-checked against the ESP-Miner source and PR #1553 on that date. The Braiins pool public key must be re-copied from academy.braiins.com at publish time.