Merged mining, formally known as Auxiliary Proof of Work (AuxPoW), allows the proof of work produced for a parent blockchain to be reused as valid proof of work for an auxiliary chain that implements the AuxPoW mechanism. It does not divide a miner's hashrate between chains, and it does not automatically apply to every coin that shares an algorithm with the parent chain—only chains explicitly configured into a pool's merged-mining stack receive credit. On ViaBTC, for instance, BTC workers may receive NMC and FB rewards, and LTC workers may receive DOGE, BELLS, PEP, and DINGO rewards, subject to PPS+ or PPLNS eligibility as described in the pool's current documentation (ViaBTC Help Center).
When merged mining produces unexpected results—missing auxiliary rewards, rejected shares, or rejected auxiliary blocks—first identify whether the problem concerns your account, your miner's submissions, or the pool's AuxPoW implementation. These require different checks: a missing coin balance does not by itself establish a mining fault, and an ASIC share rejection does not by itself establish an AuxPoW construction error.
Start with the symptom
- Auxiliary rewards are missing: Check supported coins, payout-mode eligibility, My Assets, and automatic conversion settings and records.
- Your miner reports rejected shares: Read the rejection reason, then check the corresponding connection, hardware, or setup issue.
- Your pool or self-hosted node rejects an auxiliary block: Preserve the exact node error and serialized submission, then follow the advanced AuxPoW checks below.
Ordinary pool users can start with the account and share checks. The advanced sections are intended for pool operators, proxy developers, and self-hosted merged-mining setups.
Missing rewards and account checks
Receiving parent-chain rewards without seeing an auxiliary-coin balance does not necessarily mean merged mining has failed. On ViaBTC, first confirm that the parent coin and payout mode qualify for the auxiliary rewards you expect. The current documentation lists NMC and FB for BTC mining, and DOGE, BELLS, PEP, and DINGO for LTC mining, in PPS+ or PPLNS mode.
Next, check My Assets. Also review whether Auto Conversion is enabled and inspect the relevant conversion records: supported merged-mining coins can be converted to BTC or USDT, so their current balances alone do not establish whether rewards were received. These product details were checked against the ViaBTC Help Center on September 28, 2026.
If these checks do not explain the discrepancy, contact pool support with the affected coin, account or worker, time period, and relevant asset records. Avoid changing miner hardware settings solely because an auxiliary-coin balance is missing.
Share-level and block-level errors
Share-level errors occur when a miner's submissions to the parent-chain pool are stale, invalid, duplicated, or misconfigured. These issues are identical in nature to ordinary pooled-mining rejections and are resolved at the level of a single ASIC, site, or network connection. They can reduce credited work and related rewards, but they do not by themselves indicate a failure of the merged-mining mechanism.
AuxPoW construction errors occur when a pool or self-hosted mining stack submits a proof that the auxiliary node rejects because of its coinbase commitment, Merkle branch, chain index, or serialized payload. These checks concern template construction and proof validation, so ordinary miners should refer such errors to the pool operator.
Miner-side share errors
Stale shares occur when a miner submits work for a job the pool has already superseded. Network latency, packet loss, unstable routing, or a distant pool endpoint are common contributors. Reviewing the selected endpoint, connection stability, and whether the pattern affects a single miner or an entire site is the usual first step; wired connections are generally more stable than wireless links in this context.
Invalid shares typically point to hardware instability: overheating, insufficient or fluctuating power delivery, aggressive frequency or voltage settings, degrading hashboards, or firmware issues. Reverting to a known stable profile and inspecting temperatures, fans, power delivery, and hardware logs—one variable at a time—helps isolate the cause. Switching pool endpoints does not resolve invalid shares caused by hardware instability.
Duplicate shares arise when the same result is submitted more than once, often due to retry logic, proxy behavior, or an unstable session. Reviewing miner and proxy logs, along with retry configuration, is the appropriate diagnostic path. A duplicate repeats a share already received; the first submission may have been accepted or rejected. Check its original status before interpreting duplicate counts as lost work, since a repeated submission is not a separate unit of hashing work.
Authorization and setup failures usually trace back to an incorrect pool URL, port, worker-name format, password field, or coin/algorithm selection. Rechecking the pool's current setup instructions for the specific coin and miner model, and verifying each connection field individually, resolves most of these cases.
Rejected shares are the umbrella category; stale, invalid, duplicate, and configuration-related rejections are distinct reasons within it, and pool dashboards may report them separately. ViaBTC's own troubleshooting guidance identifies these same causes—stale submissions, unstable hardware, network latency, duplicate submissions, and incorrect settings—as the common drivers of rejected shares, and recommends diagnosing the specific rejection reason before changing hardware settings, since no single rejection-rate threshold applies universally across coins, miners, and pool configurations (ViaBTC Blog).
When a numeric rejection rate is useful for comparison, it should be calculated and labeled explicitly as a raw-count figure:
Raw-count rejection rate = rejected shares ÷ (accepted shares + rejected shares) × 100%
This calculation does not account for varying share difficulty across submissions, so it may not match a pool's own difficulty-weighted dashboard figure. Local device hashrate and the pool's hashrate estimate are separate measurements derived from different data; a drop in the pool-side estimate should be diagnosed against rejection reasons, uptime, and recent configuration changes rather than assumed to mirror the miner's local reading.
Advanced: AuxPoW construction and submission errors
The following issues apply to pool operators and self-hosted merged-mining implementations rather than ordinary ASIC users. They correspond to consensus validation checks in current AuxPoW implementations such as Namecoin Core and Dogecoin Core, and the specific numeric limits cited below are properties of those implementations rather than universal AuxPoW rules.
A missing chain Merkle root in the parent coinbase typically means the auxiliary-chain root cannot be located inside the parent block's coinbase scriptSig. Common causes include serializing the wrong root, a byte-order error, committing a stale auxiliary-chain template, or constructing a parent coinbase that differs from the one actually hashed. Recompute the auxiliary-chain Merkle root from the auxiliary block hash and its chain branch, then compare its expected byte representation with the commitment in the coinbase actually used for mining. If only the submitted payload is wrong, reconstruct it from the original mining data. If the mined coinbase itself contains the wrong commitment, fix the template and mine new work: changing that coinbase changes its transaction hash and the parent header's Merkle root, so the existing proof of work cannot simply be reused with the edited commitment.
Multiple merged-mining headers in the coinbase indicate that the magic header marking the commitment appears more than once, often due to a proxy layer or template-assembly step appending a duplicate. A header present but not immediately followed by the committed root points to incorrect field ordering; no other bytes should sit between the header and the root.
Where a legacy commitment omits the merged-mining header, the Namecoin Core and Dogecoin Core implementations require the auxiliary-chain root to begin within the first 20 bytes of the parent coinbase scriptSig. Using the explicit merged-mining header format avoids this constraint and is preferable for new implementations.
An incorrect Merkle root generally means the submitted coinbase transaction and its Merkle branch do not reconstruct the parent block's actual Merkle root; the transaction Merkle branch, branch order, and index should be independently recomputed. A missing tree size and nonce, or a mismatched Merkle-branch size, points to the 8 bytes following the committed root—two 32-bit fields encoding tree size and nonce in the cited implementations—being absent, misordered, or inconsistent with 2 raised to the branch length. The maximum permitted auxiliary-chain Merkle-branch length in these implementations is 30 elements; exceeding it, or miscalculating it, will cause validation to fail.
A wrong chain index indicates that the claimed index does not match the deterministic value derived from the nonce, chain ID, and Merkle-tree height for the target chain; the chain ID and byte order must be confirmed against that specific chain's parameters rather than reused from another implementation. Where strict chain-ID checking applies, a parent header that identifies itself with the same chain ID as the auxiliary chain will also be rejected. These validation checks—coinbase commitment, Merkle proof, tree size, nonce, index, and chain-ID handling—are implemented directly in the Namecoin Core and Dogecoin Core AuxPoW validation code and are illustrative of the checks performed by similar implementations, not a universal taxonomy applicable to every AuxPoW chain (Namecoin Core, auxpow.cpp; Dogecoin Core, auxpow.cpp). These implementation details were checked on September 28, 2026; operators should compare them with the exact node version they deploy.
Finally, a block rejected only after a software upgrade or a chain's rule change usually means a template builder, serializer, or node version no longer matches current consensus or RPC behavior. Reviewing the target chain's release notes and testing against the exact node version in production, rather than assuming continuity from a previous deployment, is the appropriate response.
Advanced: Troubleshooting a block-level AuxPoW rejection
- Identify the layer of failure first: an ASIC share rejection at the pool, a parent-chain block issue, or an auxiliary-chain AuxPoW rejection. These require different diagnostics and should not be treated interchangeably.
- Preserve the exact node error message, timestamp, node version, chain, and the parent-block and child-block hashes involved, along with a reference to the serialized payload.
- Confirm that the submitted AuxPoW corresponds to the auxiliary-chain template and the parent-chain block actually used to produce the proof; a mismatch between template generation and final submission can invalidate the proof.
- Inspect the final parent coinbase
scriptSigdirectly, checking for the committed auxiliary-chain root, correct byte order, the merged-mining header where required, and the tree-size and nonce fields. - Independently recompute both Merkle paths: the auxiliary-chain branch from the child block hash to the committed root, and the parent-chain transaction branch from the coinbase transaction to the parent block's Merkle root.
- Validate tree size, nonce, chain ID, and chain index against the specific auxiliary chain's consensus implementation, since these values are chain-specific rather than shared across all AuxPoW coins.
- Compute the parent header's proof-of-work hash using the target auxiliary chain's required algorithm and verify that its numeric value is less than or equal to that chain's block target. Passing a pool's share threshold alone does not establish block eligibility. An easier requirement corresponds to a numerically higher target and lower difficulty.
- Change one variable at a time when retesting—template code, coinbase construction, node version, or proxy behavior—so that the cause of a resolved or persisting error can be isolated.
A real-world illustration
An August 2025 Dogecoin Core issue reported the node error "Aux POW missing chain merkle root in parent coinbase" from a custom pool implementation in which several auxiliary coins were accepted successfully while DOGE and DINGO submissions were rejected (Dogecoin Core issue #3881). The report remains an operator-submitted issue rather than a confirmed defect with an identified root cause, but it illustrates a useful principle for anyone operating merged-mining infrastructure: a successful commitment for one auxiliary chain does not confirm that the same serialization logic satisfies every other chain's validation requirements. Each auxiliary chain's coinbase commitment, Merkle branch, and chain-ID handling should be verified independently against the final serialized payload rather than assumed from a working configuration elsewhere.
Practical takeaways
For ordinary miners, merged mining generally requires no special configuration beyond connecting supported hardware to the correct parent-chain pool endpoint; the pool handles auxiliary-chain templates, commitments, and submission logic. When rewards appear to be missing, check eligibility, asset records, and automatic conversion first. When the miner reports rejected shares, diagnose the stated rejection reason. Because supported coins and payout eligibility can change, checking a pool's current documentation, rather than relying on earlier articles or screenshots, remains the most reliable way to confirm which auxiliary-chain rewards apply to a given worker and payout mode.
For pool operators and self-hosted setups, AuxPoW errors are consensus-level validation failures rooted in coinbase construction, Merkle-branch calculation, and chain-specific parameters. These require inspecting the exact serialized payload against the target chain's own validation code rather than assuming behavior consistent across chains.
FAQ
Does merged mining reduce my Bitcoin mining hashrate or rewards?
No. AuxPoW reuses the same proof of work already produced for the parent chain; it does not divide hashrate between chains or reduce the parent chain's mining output.
Why did I receive BTC rewards but no NMC or FB rewards?
On ViaBTC, confirm that your BTC mining uses an eligible PPS+ or PPLNS mode, then check NMC and FB in My Assets. Review Auto Conversion settings and records, since these rewards may have been converted to BTC or USDT. If the discrepancy remains, provide the affected time period and asset records to support. Supported coins and eligibility can change, so check the current documentation.
Is a stale share the same as an invalid share?
No. Both are subcategories of rejected shares, but stale shares result from timing—submitting work after a new job was issued—while invalid shares typically indicate hardware instability. They require different troubleshooting steps.
Can one successful auxiliary-chain block submission confirm my AuxPoW implementation works for all auxiliary chains?
No. Each auxiliary chain validates its own coinbase commitment, Merkle branch, chain ID, and index independently, so a working configuration for one chain does not guarantee correctness for another.
What should I check first if my pool-side hashrate estimate drops but my miner looks normal locally?
Compare the same time window across miner-side reported hashrate, pool-side estimate, rejection reasons, and recent configuration changes, since these are distinct measurements rather than interchangeable figures.