Avalon 1466 – 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, and the Canaan UI does not version your edits.

Delete the primary pool entry — do not edit in place. MM4 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 across the entire A14 family on D-Central's bench.

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 in our queue.

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 closest one to your physical location. Switching from a generic `stratum.pool.com` to `us-east.stratum.pool.com` from a Toronto, Montreal, or Calgary 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 change ISP. If a specific peering hop is the bottleneck, switch pools or pool regions until you find a clean path.

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 A1466 manual; entirely community knowledge via Zeus Mining and BitcoinTalk Avalon threads.

Pull the cgminer API `pools` output and verify `Last Share Difficulty` is sane. On a healthy A1466 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 via vardiff — usually because reject% is high enough that the pool is dropping vardiff defensively, 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 MM4 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 A1466) 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. The `avalon7` flag prefix covers the A14 family despite the name.

Pull the full `PVT_T` and `PVT_V` arrays for all three boards. Sort each board by chip temperature. Any `A3198` 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 Zeus Mining Avalon A11/A12-series hash board repair guide (the same heatsink mounting pattern carries to A1466). 12+ month old paste accounts for `2-5 °C` of junction-temp headroom — and on `A3198` silicon, which runs at the tighter 21.5 J/TH envelope, the paste cycle is shorter than on prior-gen Avalon hardware. Full re-paste on an A1466 takes ~75-90 minutes per board and frequently drops chip-level reject contribution materially without any chip replacement.

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 `A3198` chip from Zeus Mining's parts inventory at $11.90 USD per unit (BIN must match the hash board marking — Zeus publishes a step-by-step replacement tutorial). The A1466 covers the same Avalon universal test file as A1166/A1166Pro/A1246/A1346/A1366/A1446, which speeds bench validation if you have the test fixture; without it, validate by reinstall + bench-run + pool reject% over 24 h.

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

Implement a stratum-proxy in front of your A1466 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 independent 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. Open-source options are free; Braiins Farm Proxy is commercial.

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' because the failure mode is intermittent.

Stop DIY and ship to bench when any of these are true: `PVT_T` / `PVT_V` isolates three or more drifting `A3198` 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 from a stratum-extension regression and a stratum proxy hasn't worked around it; a known-good AUC swap did not restore reject performance; capacitor bulging or burnt-component smell is present anywhere; 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 on an A1466 reject case: programmable load + Canaan factory test binary (the universal test file that covers A1166 → A1466) to map each `A3198` chip individually, internal stratum simulator that captures every submitted share for per-chip reject attribution, chip replacement from graded `A3198` salvage 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. US and international accepted. Include your API `pools` and `stats` dump plus the pool dashboard's last-reject-reason history in the shipment note.