lets a compatible stream of work support and Dogecoin while each chain retains its own , transactions, balances and . It does not merge the coins, require every DOGE block to coincide with an LTC block, or promise that a miner receives every auxiliary reward.
Expanded review · 22 October 2026. Technical references are pinned to Litecoin Core 0.21.5.8 and Dogecoin Core 1.14.9. The target and revenue examples are synthetic calculations, not captured jobs, observed or payout forecasts.
How one stream of work serves two chains
In this relationship Litecoin supplies the parent mining work, and Dogecoin accepts auxiliary proof of work, or AuxPoW. A pool constructs an auxiliary candidate and commits to it through the parent coinbase transaction. Its miners search parent headers using Scrypt. A qualifying result can then be submitted with evidence linking that work to the auxiliary candidate.
It helps to separate the links in that evidence:
- The auxiliary block hash is linked, possibly through an auxiliary-chain , to a committed auxiliary root.
- That root appears in the parent coinbase's input script, together with auxiliary-tree parameters.
- A separate parent-transaction Merkle branch links the coinbase to the parent header's Merkle root.
- The parent header supplies the result tested against the auxiliary block's target.
These are two different Merkle relationships: auxiliary candidate to commitment, then parent coinbase to parent header. A proof is more than a claim that two pools used the same algorithm. Dogecoin's AuxPoW validator checks commitment placement, the coinbase branch, chain-tree size and the deterministic index. Its data structures define the merged-mining marker as bytes fa be 6d 6d.
That marker is not a complete proof. The implementation also has a historical compatibility path for certain commitments without it. Neither a miner screenshot nor the presence of those four bytes establishes that a candidate satisfies all consensus checks.
Separate targets: why a DOGE block need not be an LTC block
A proof-of-work target is a numeric upper bound: a smaller target is harder to meet. Each chain determines its own target. The pool's share target is a third threshold used for accounting; ordinary accepted shares are usually far easier to find than network blocks.
| Assumed work result | Target comparison | What could be submitted |
|---|---|---|
| 80 | 80 ≤ 100 and 80 ≤ 400 | Qualifies for both work thresholds |
| 250 | 250 > 100 but 250 ≤ 400 | Auxiliary work threshold only |
| 500 | 500 > both targets | Neither network block threshold |
All rows still assume the required commitment, current templates and other validity rules. A threshold match alone does not guarantee block acceptance or survival in the active chain. If the targets had the opposite ordering, a result could meet the parent target without meeting the auxiliary target. Never infer today's ordering from this illustration.
The auxiliary proof uses the parent header as evidence; it does not require that header to become an accepted Litecoin block. The auxiliary chain can therefore accept work that fails Litecoin's harder threshold in the second row. Its own block validation, parent-work selection and work-target checks remain relevant. There is no rule that a DOGE block must wait for the next LTC .
When Dogecoin adopted AuxPoW
Dogecoin's AuxPoW activation occurred at block 371,337 on 11 September 2014. The 1.8.0 software release preceded that activation on 24 August. These are different events. The dates and activation boundary are documented in the maintainer's 1.8.x retrospective.
A history should distinguish software availability, a consensus activation height and later implementation changes. The retrospective also discusses later compatibility problems; a simple “merged in 2014” timeline is not a complete account of every release's behavior. Our documented fork and code-history guide makes the same distinction.
Shared work, different rules
| Property | Litecoin | Dogecoin |
|---|---|---|
| Work relationship | Parent Scrypt proof of work | Scrypt AuxPoW support |
| Target spacing | 150 seconds | 60 seconds |
| Subsidy schedule | Halving interval 840,000 blocks | 10,000 DOGE ongoing subsidy in the current schedule |
| Current LTC subsidy era | 6.25 LTC at heights 2,520,000–3,359,999 | No matching LTC-style halving |
| Ledger and payment destination | Litecoin transactions and scripts | Dogecoin transactions and scripts |
See Litecoin parameters, Dogecoin parameters and the Dogecoin subsidy function. At target spacing, the schedules imply 576 LTC blocks and 1,440 DOGE blocks per day: 3,600 LTC in the stated era and 14.4 million DOGE in subsidy. The latter annualizes to 5.256 billion DOGE over 365 days. Actual block counts vary.
An balance does not acquire DOGE through this relationship. Consensus upgrades, fees, wallet compatibility and supply rules remain chain-specific. A Litecoin transaction cannot move DOGE merely because a pool mines both chains.
Why it matters to mining economics
Calculate expected coins separately for each chain before adding their values in one currency. The assumed network work rate must correspond to that chain. Using Litecoin's hashrate as Dogecoin's denominator without justification can distort the estimate.
For an explicit teaching case, assume a miner delivers 16 GH/s continuously and both networks have an effective 3 PH/s of relevant Scrypt work. Assume target block counts, constant difficulty, the subsidy era above, no transaction fees and no other auxiliary coins. These are scenario inputs, not current network observations.
Miner fraction = 16 / 3,000,000
Expected LTC/day = fraction × 576 × 6.25 = 0.0192
Expected DOGE/day = fraction × 1,440 × 10,000 = 76.8If a hypothetical operator deducted 2% separately from both theoretical subsidy streams, the modeled credits would be 0.018816 LTC and 75.264 DOGE per day. This is not a quote for any pool: real ratios, additional coins, fees and accounting can differ.
| Modeled credit | Assumed price | Value per day |
|---|---|---|
| 0.018816 LTC | $60 per LTC | $1.12896 |
| 75.264 DOGE | $0.10 per DOGE | $7.52640 |
| Combined modeled revenue | Same currency and period | $8.65536 before operating costs |
Now assume 3.36 kW continuous wall power at $0.10/kWh. Electricity costs 3.36 × 24 × 0.10 = $8.064/day, leaving $0.59136 before cooling, maintenance, hardware cost, conversion, taxes and other costs. A small change in an assumption can remove that margin. The calculation is reproducible in the downloadable model; it is not evidence that a particular machine is profitable.
Count the miner's electricity once for this shared hashing stream. Adding two separate estimates for the same device's power would double count it. , pool infrastructure and networking still have overhead. The energy guide explains why shared work does not produce a unique physical allocation of all electricity between coins.
A pool checklist before connecting hardware
Ask which chains are actually credited, which assets leave the pool, and how the operator calculates each balance. A pool can pay LTC and DOGE separately, convert proceeds, or include some auxiliary revenue in a reward ratio. Protocol compatibility does not dictate that commercial agreement.
On 22 October 2026, LitecoinPool's own help page described separate LTC and DOGE payout destinations and stated that other auxiliary proceeds support its PPS ratio rather than being distributed as every underlying coin. That is a dated operator declaration, not an independent payout audit or a market-wide rule.
Record per-coin fees, conversion spreads, withdrawal conditions, stale-share treatment and outstanding balances. Confirm that you control the intended LTC and DOGE destinations; one is not interchangeable between them. Reconcile actual receipts rather than treating a combined dashboard estimate as settled revenue. The pool-selection guide adds a ledger and a PPS/PPLNS comparison.
What merged mining does not guarantee
Sharing work does not guarantee equal security, independent mining populations, a price floor or twice the profit. Operator participation, block-template control, software validation and each chain's economic incentives still matter. Adding reported hashrates can also count the same hardware twice; do not describe that sum as independent computing power.
An LTC changes the LTC subsidy component. In the hypothetical case above, halving only that component would reduce total pre-fee subsidy value from $8.832 to $8.256/day, about 6.52%, while holding all prices, work rates and DOGE rules fixed. It would not halve the modeled combined revenue. Real difficulty, participation and prices can change, so this is a sensitivity calculation rather than a forecast.
Download the target comparison cases and offline calculation script. The script contacts no pool, creates no mining job and cannot submit a block. The download notes explain the evidence types; SHA-256 checksums identify the files. For Scrypt's actual hashing parameters, use the algorithm guide.
Frequently asked questions
Must an LTC block exist for every DOGE AuxPoW block?
No. The auxiliary proof can use a parent header that meets Dogecoin's target without becoming an accepted Litecoin block.
Does merged mining send DOGE to my LTC address?
No. The ledgers and destinations remain separate. Follow the pool's supported payout routes for each asset.
Do all Scrypt pools pay every auxiliary coin?
No. The operator's reward rules determine what is credited, converted or included in a payout ratio. Inspect the current terms.
Does a valid pool share mean I found a network block?
Usually not. Share targets serve pool accounting and are generally easier than network block targets.
Should I double the miner's electricity for LTC and DOGE?
No. Count the same device's measured electricity once for its shared hashing operation, while accounting separately for other infrastructure.
Does an LTC halving halve combined LTC and DOGE revenue?
Not mechanically. It changes the LTC subsidy component. Combined revenue also depends on DOGE, fees, prices, difficulty and the pool's accounting.
