Bitaxe – Stratum ConfigurationOutOfOrder (Braiins / BOSminer)

Fill all four Primary stratum fields cleanly before hitting Save. Open AxeOS → Settings → Stratum. Type a bare hostname into Primary URL (no stratum+tcp://, no https://, no trailing slash, no whitespace). Type the pool's documented stratum port — Public-Pool 21496/21497, Solo-CKPool 3333, Ocean 3334, NiceHash 9200 (SSL only), Braiins 3333 — into Primary Port. Type your on-chain BTC address followed by .workername (e.g. bc1qxx....bitaxe-gamma-01) into User. Type x into Password. Verify all four read correctly before clicking Save. Single-shot save, no edit-then-edit-then-save dance.

Cold power-cycle for 10 seconds after Save. Unplug USB-C (or XT30 / barrel input on Hex / GT) for ten full seconds. A soft reboot through the AxeOS UI does not reliably reload the stratum task on every firmware revision — the cold power-cycle does. Plug back in and watch the dashboard. A clean handshake produces an Accepted count within one pool job cycle, typically 30-60 seconds.

Configure the Fallback stratum block to a different working pool. AxeOS → Settings → Stratum → scroll to Fallback. Set Fallback URL = solo.ckpool.org, Port = 3333, SSL = OFF, User = <your bc1q address>.fallback, Password = x. Save. This guarantees that if your Primary breaks for any reason — pool downtime, port change, SSL cert expiry — the Bitaxe rotates to a working pool instead of sitting at zero shares for hours. Diversifying primary and fallback across pool operators is also a quiet decentralization win.

Strip every protocol prefix from both URL fields. AxeOS's URL parser treats anything before :// as part of the hostname. Pasting stratum+tcp://public-pool.io makes the device try to resolve stratum+tcp as a hostname, which fails at DNS and never opens a socket. Same trap for https://, wss://, or any other prefix. Bare hostname only — public-pool.io, solo.ckpool.org, eu.stratum.braiins.com. The port goes in the separate Port field.

Match SSL toggle to the port you chose. If you enabled SSL in AxeOS, you must use the pool's SSL port (Public-Pool 21497, Braiins SSL endpoint as documented). If SSL is off, use the plain port (21496, 3333). A mismatch produces mbedtls_ssl_handshake errors in the serial log instead of a useful diagnostic. Public-Pool, CKPool, and Ocean all run plain TCP by default — SSL is optional, not required.

Test the User field by pasting your address into a block explorer like mempool.space. If the explorer shows 'Address not found' or rejects the format, your User field is wrong — likely a Lightning address, an lnurl... string, or a typo. Bitaxe pools require an on-chain Bitcoin address (bc1q... SegWit, bc1p... Taproot, 1... legacy, or 3... SegWit-compatible). The .workername suffix is optional but useful for tracking multiple Bitaxes on one address.

Wait three minutes after every config change before declaring failure. AxeOS implements exponential backoff on repeated subscribe failures — the wait between retries doubles with each failure. After three or four consecutive misses the next attempt may be 4-8 minutes out. Panic-editing the config during a backoff window resets the timer without helping. If you just saved and power-cycled, give the device three minutes uninterrupted before reading the dashboard.

Confirm WiFi is on a 2.4 GHz SSID. Bitaxe's ESP32-S3 does not support 5 GHz. If the AxeOS dashboard loads but stratum subscribe never fires, double-check you're on a 2.4 GHz SSID, not the 5 GHz half of a dual-band router. Some mesh systems (Eero, Google Nest, Plume) hide the 2.4 GHz band behind a single SSID and steer Bitaxes onto the 5 GHz radio at random — pin to a 2.4-GHz-only SSID where possible.

Read the USB-C serial console at 115200 baud end-to-end. Plug a data-capable USB-C cable (>=3A, not a charge-only brick cable) into the Bitaxe. Open screen /dev/ttyUSB0 115200 on macOS / Linux, PuTTY → Serial → 115200,8,N,1 on Windows, or use Chrome WebSerial. Reboot the device with the serial monitor running and capture the boot sequence end-to-end. The lines after wifi: STA connected, IP: <addr> are where stratum lives. Save a 2-minute capture — this is the artifact D-Central's bench team asks for first on Bitaxe stratum tickets.

Cross-check pool port against pool's current documentation. Pools occasionally renumber stratum endpoints — Public-Pool moved from 3333 to 21496 years ago, and the legacy port no longer responds. Open the pool's getting-started page (web.public-pool.io, solo.ckpool.org, pool.braiins.com, ocean.xyz/docs/getting-started) and copy the current port, not the one in a year-old YouTube video. Confirm SSL availability on the same page — some pools have dropped or added SSL endpoints over time.

Use AxeOS REST API to set the four fields atomically. Power users: hit POST http://<bitaxe_ip>/api/system with a single JSON body containing stratumURL, stratumPort, stratumUser, stratumPassword together. This avoids the field-by-field web-UI edit pattern that produces partial saves. Document your API call so you can re-run it after firmware updates. After the POST, call POST /api/system/restart to trigger the reboot — the serial-console-equivalent of a clean Save + power-cycle for scriptable deployments.

Verify DNS resolution before blaming AxeOS. From a laptop on the same LAN, run nslookup <pool-hostname>. Slow resolution or NXDOMAIN means router DNS is the problem — not your Bitaxe. Override router DNS to 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google) at the WAN settings, reboot the router, then power-cycle the Bitaxe. Canadian operators on Bell, Rogers, Vidéotron, Cogeco, or Shaw see this DNS-flake pattern often — the public resolvers are noticeably more reliable for stratum hostnames than Canadian residential ISPs' defaults.

Disable SSL temporarily to isolate TLS bugs from order bugs. Set Primary SSL = OFF, change Primary Port to the pool's plain-TCP port, save, power-cycle. If subscribe now works, the TLS layer was masking the underlying handshake. Some AxeOS builds have edge-case mbedTLS bugs with specific pools' certificates — switching to plain TCP gets you back online while you wait for a firmware fix or change pools. Public-Pool and Solo-CKPool both run plain TCP by default; SSL is optional on both.

Review fallback stratum config with the same discipline as primary. AxeOS shows two stratum blocks but only enforces the discipline on one in most operator's habits. Open Fallback fields, read all four aloud, fix protocol prefixes, port mismatches, stale URLs from previous experiments. The fallback's job is to save you when primary breaks — a half-configured fallback breaks at the worst possible moment. Save, power-cycle, then test by deliberately breaking primary (typo the URL) and confirming the device rotates to fallback within 3-5 minutes.

Flash the latest stable firmware via USB-C web flasher to clear NVS schema drift. Visit https://bitaxe.org/flash in Chrome or Edge (WebSerial required). Connect Bitaxe via USB-C, click Connect, select your exact board revision (Ultra 205 / 207, Gamma 601 / 602, Hex 303 / 304, GT 701 / 702 — the revision is silkscreened on the PCB). Pick the factory .bin for that revision, click Flash. This wipes NVS entirely — your stratum config is gone, your WiFi creds are gone, you'll re-enter everything from scratch. That's the point: NVS schema drift between firmware versions is one of the sneakier root causes of BITAXE_STRATUM_ORDER, and a clean factory flash is the only deterministic fix.

Wireshark the full handshake against Braiins Pool to confirm or refute Issue #84. Set Primary to Braiins (eu.stratum.braiins.com:3333, plain TCP, valid Braiins worker name in User). Capture on a laptop on the same LAN. Watch for the JSON exchange order. The correct order is mining.configure → response → mining.subscribe → response → mining.authorize → response. If your Bitaxe sends mining.subscribe first (or skips configure entirely) and the response contains ConfigurationOutOfOrder, you've reproduced Issue #84 on your firmware build. File a comment on skot/ESP-Miner Issue #84 with your firmware version and capture — this is how the bug actually gets fixed upstream.

Build ESP-Miner from source with extra logging around the configure/subscribe sequence. Clone bitaxeorg/ESP-Miner. Open main/tasks/stratum_task.c. Add ESP_LOGI(TAG, '...') traces around every state transition in the configure/subscribe path. Build with ESP-IDF v5.1 or later, flash via USB-C. The extra log lines at 115200 baud show you exactly where the state machine routes — and once you have a reproducible defect with a specific firmware version, file a PR. The Bitaxe ecosystem is open-source precisely so plebs with soldering irons and Git accounts can fix the bugs upstream rather than wait for a vendor.

Spin up a local stratum server and point Bitaxe at it. Run a local CKPool instance or a public-pool fork on a Raspberry Pi or old laptop on your LAN. Set Primary URL = 192.168.x.y, Port = 3333, User = <your bc1q>.local. If subscribe and authorize complete locally, your device + firmware are fine — the issue is upstream (ISP, NAT, pool-side filter, geographic routing). If subscribe still fails locally, the bug is on the device. Local stratum is also useful for development work — you can capture every byte of every Bitaxe handshake without depending on a public pool's logging.

Stop DIY and ship the device when (a) factory-flashed Bitaxe with all four primary fields set cleanly, cold power-cycled, fails to subscribe on public-pool.io:21496 with 1.1.1.1 DNS over a known-good 2.4 GHz LAN; (b) Wireshark confirms the JSON handshake going out correctly but the pool's response decodes to an error string D-Central's docs (and ours) can't decipher, and the same response repeats on Solo-CKPool; (c) failure survives cable swap, PSU swap, pool swap, factory flash, DNS override, SSL toggle, and 2.4 GHz SSID move; (d) physical damage is visible (scorched USB-C, cracked PCB near the ESP32-S3, bulged capacitor on the 5V or 12V rail, scorching near the TPS546). D-Central pioneered the Bitaxe ecosystem — built the original Bitaxe Mesh Stand, developed the first heatsinks for Bitaxe and Bitaxe Hex, stocks every variant since launch — and our bench keeps stratum-path test rigs ready for exactly these tickets. Book at https://d-central.tech/services/asic-repair/.