Avalon 1346 – Stratum Rejected Shares

Open the miner's web UI, navigate to Configuration → Mining → Pools. Screenshot the current config before you change anything — you will need it for rollback if a change makes things worse. Note the exact worker name, pool URL, and port for each of the three pool slots Canaan firmware supports (primary, secondary, tertiary). Do not skip the screenshot; reject-percentage debugging without a baseline turns into guessing fast.

Delete the primary pool entry — do not edit in place. Canaan firmware in some 2024-2025 builds caches the previous worker string in NVRAM and an in-place edit doesn't fully overwrite it. Save the empty config, reboot the miner, then re-add the primary pool from scratch. This is a 5-minute fix that closes a surprising percentage of 'I changed my pool address and now everything rejects' tickets.

Re-enter the pool URL with the explicit `stratum+tcp://` prefix (some Canaan firmware revisions assume `tcp://` if the prefix is missing, which causes a silent protocol mismatch on stratum-only endpoints). Use the exact port your pool publishes — `3333` and `4444` are common but pool-specific. Triple-check — wrong-port-number is a top-three cause of 'everything rejects after I switched pools' tickets.

Re-enter the worker name in the exact format your pool requires. For solo or public-pool endpoints: `<your_btc_address>.<workername>`. For managed pools (Foundry, ViaBTC, F2Pool, Braiins): `<account>.<workername>`. No leading or trailing spaces. No Lightning addresses (`lnbc...` is NOT a Bitcoin address). No commas, semicolons, or Unicode whitespace. Validate the BTC address by pasting it into any block explorer first — if the explorer can't show it, the pool can't credit it.

Verify your address format is supported by your pool. Taproot (`bc1p...`) is supported by every major commercial pool in 2026 but inconsistent on hobbyist solo endpoints — check your pool's docs and fall back to `bc1q...` segwit-v0 if needed. Legacy `1...` and `3...` addresses always work but receive higher network fees on payouts.

Switch to a regional pool endpoint. Most pools publish per-region URLs: `us-east`, `us-west`, `ca-central`, `eu`, `asia`, `sa`. Pick the one closest to your physical location. Switching from a generic `stratum.pool.com` to `us-east.stratum.pool.com` from a Toronto rig routinely drops reject% from `2-4%` to `<0.5%` for North American operators — the single biggest network-side intervention with zero hardware investment.

From any LAN host, run `ping stratum.<your-pool>.com` for 60 seconds and record min/avg/max RTT plus packet loss. Target avg RTT `<100 ms`, packet loss `0%`. Then run `mtr -n stratum.<your-pool>.com` (Linux/macOS) or `pathping stratum.<your-pool>.com` (Windows) to identify which hop is contributing latency or loss. If your ISP is the bottleneck, document the trace and either escalate to ISP support or switch ISP. If a specific peering hop is the bottleneck, switch pools or pool regions.

Change the miner's DNS from the Canaan stock default (`114.114.114.114` — a Chinese public DNS that resolves unreliably outside mainland China) to `1.1.1.1` (Cloudflare) or `8.8.8.8` (Google). One field, five seconds. Symptom of DNS-side issue: pool URL resolves intermittently, stratum reconnects every few minutes, reject% spikes during reconnect cycles. Documented nowhere in the English-language A1346 manual; entirely community knowledge via Zeus Mining and BitcoinTalk.

Pull the CGMiner API `pools` output and verify `Last Share Difficulty` is sane. On a healthy A1346 against a typical pool, this value should be in the low thousands and stable. Wild oscillation (rapidly jumping between `1024` and `65536`, for example) indicates the pool is rapidly retargeting your miner — usually because reject% is high enough that the pool is dropping vardiff, which compounds the problem. Reduce the underlying reject cause; vardiff stabilizes within 5-10 minutes once the underlying issue is resolved.

Test pool authorization in isolation with `ncat`: `ncat stratum.<your-pool>.com 3333` then send `{"id":1,"method":"mining.subscribe","params":[]}` followed by `{"id":2,"method":"mining.authorize","params":["<worker>","<password>"]}`. If `mining.authorize` returns `result: true`, credentials are accepted; if `false`, your account/worker isn't registered or your IP is banned. If credentials are accepted but production submits still reject, the problem is per-share validation — continue to Tier 3.

Verify the AUC bus is healthy under load. From the API `stats` output, confirm `ECHU[0 0 0]` (zero comm errors per board) and `SYSTEMSTATU = 3` (all three MM modules present). If either is wrong, you have an AUC-class bus issue compounding stratum rejects — pivot to the Avalon AUC Communication Error guide (same failure family on A1346) before continuing.

Run cgminer with conservative AUC bus settings if you suspect bus-side noise is producing marginal nonces: add `--avalon7-aucspeed 200000 --avalon7-aucxdelay 24000` to the cgminer launch command. Undocumented by Canaan, canonical in cgminer `ASIC-README`. Conservative values eliminate intermittent `CODE_MMCRCFAILED` retries and reduce the chance of work-packet corruption that produces invalid shares.

Pull the full `PVT_T` and `PVT_V` arrays for all three boards. Sort each board by chip temperature. Any chip `> 5 °C` above the board median is a candidate nonce-drift contributor. Refresh thermal paste on the affected board with Arctic MX-6 or Thermal Grizzly Kryonaut, reassemble with correct heatsink torque per the Canaan A1346/1366 service guide. 12+ month old paste accounts for `2-5 °C` of junction-temp headroom — and on A3200 silicon (which runs hotter-per-watt than A3206 on the A1246), the paste cycle is shorter. Full re-paste takes ~60 minutes and frequently drops chip-level reject contribution materially.

Reflow the worst-performing chip identified from `PVT_T` outliers. Remove heatsink, flux the target BGA, preheat the board's bottom side to `~150 °C`, apply top-side hot air at `~310-330 °C` for `~30 s`, let cool naturally, re-apply thermal paste, reassemble. If reflow fails to recover the chip, replace with an `A3200CFA` (or `A3200CMA` / `A3200CMCV3` per the chip revision on your board) from Zeus Mining's parts inventory. Replacement chips run `$9.50 USD` per unit at 20-chip MOQ; Zeus publishes a step-by-step replacement tutorial.

Roll firmware one version back or forward from `avalonminer.org/firmware-document/`, using a build confirmed by the BitcoinTalk Avalon A13 thread as good for your specific hardware revision. Regressions on stratum extension handling (extranonce-subscribe, version-rolling, ASICBoost flag negotiation) have shipped in past Canaan releases. Verify hardware revision on the control-board sticker before flashing — wrong-revision firmware is a brick event because Canaan signs all A1346 firmware. Canaan's signed bootloader blocks firmware downgrade on many A1346 batches; if a recent build is the regression and rollback is blocked, escalate to bench.

Implement a stratum-proxy in front of your A1346 fleet. Tools like `stratum-proxy`, Braiins Farm Proxy, or a self-hosted `ckpool` instance let you (a) terminate stratum locally and forward upstream over a stable connection, (b) retry / retry-with-backoff on transient pool errors instead of leaking reject%, (c) consolidate multiple miners onto one pool connection, (d) get full per-share telemetry independently of the miner. For multi-miner deployments, this is the single most effective anti-reject infrastructure investment available — and it works around firmware bugs without requiring a flash.

Swap the AUC with a known-good unit. If you have cleared every other layer and the API shows clean `ECHU` but reject% is still elevated, marginal AUC silicon (FTDI USB-bridge ageing in the fan-vibration / ESD environment of the chassis) can produce sporadically corrupted work packets that the chips compute against, generating apparently-valid-but-actually-invalid nonces. Replacement AUC: `CAD $40-90`, 5-minute swap. If a fresh AUC drops reject% materially, retire the old one — do not shelve it as 'probably fine.'

Stop DIY and ship to bench when any of these are true: `PVT_T` / `PVT_V` isolates three or more failing chips on the same board (beyond single-chip reflow); reject% remains >2% after Tier 1-3 work and pool/network/credential factors are confirmed clean; Canaan's signed bootloader blocks a firmware rollback you need for recovery; a known-good AUC swap did not restore reject performance; capacitor bulging or burnt-component smell is present; or you suspect PMIC / voltage-domain damage on a board also showing chip nonce drift. Book a D-Central ASIC Repair slot. D-Central bench process: programmable load + Canaan factory test binary, internal stratum simulator that captures every submitted share for per-chip reject attribution, chip replacement from graded A3200-series stock, voltage-domain capacitor audit, full reflow and reseal, 24-hour full-load burn-in at nameplate against a real pool with reject% logging. Canadian turnaround: 5-10 business days. Include your API `pools` and `stats` dump plus the pool dashboard's last-reject-reason history in the shipment note.