What went wrong

6 October 2026, 20:10 to 20:11 UTC · lasted 1 min 33 s

Incident 2026-10-06-2010 · noticed by our monitoring

What happened

For about a minute and a half (20:10:04 to 20:11:36 UTC) the node answered that it was syncing, so the pool could not get new work from it. Miners stayed connected but kept working on the same job, and the 4 blocks found on it in that time were rejected by the node, about 647 BDAG. Payouts were not affected.

The monitoring kept its alert on for 30 minutes after the event, so the page first showed it as lasting 30 minutes; the times and figures here are now those of the event itself.

Impact on miners

• Blocks found by miners in that time: 4; the network rejected 4.
• The rejected blocks would have paid about 647 BDAG (at 161.75 BDAG, what one block paid the pool wallet on average in the two weeks before).
• Payouts from the start until an hour after the end: 89 sent (30,489.832 BDAG), none failed.

Measured on 7 October 2026, 17:48 UTC from the status checker's samples, the pool's share log and its own log, and the payout records.

Why it happened

The node went through three reorganisations of the DAG in a row while it was up to date with its peers, then nearly stopped processing blocks: 7 blocks in about a minute and a half, while the network moved more than 130 ahead. For that time it called itself syncing and refused the blocks and new work. It caught up in about 10 seconds once it moved again. This is the same fault as on 29 September (46 seconds) and 4 October (2 seconds), and the longest so far.

What we changed so it does not happen again

The pool already sends a block again for 10 seconds when the node refuses it only because it is syncing. That did its job here, but the node stayed refusing for much longer; the last block, sent the moment the node answered again, was refused as too old. Waiting longer would not have saved these blocks. The fix has to come from the node: the fault is being reported to its developers, with this third occurrence.

4 October 2026, 00:04 to 00:04 UTC · lasted 2 s

Incident 2026-10-04-0004 · noticed by our monitoring

What happened

For about 2 seconds (00:04:40 to 00:04:42 UTC) the node answered that it was syncing, so the pool could not get new work from it. One block found in that moment was rejected by the node, about 162 BDAG. Miners stayed connected and kept working; payouts were not affected.

The monitoring kept its alert on for 30 minutes after the event, so the page first showed it as lasting 30 minutes; the times and figures here are now those of the event itself.

Impact on miners

• Blocks found by miners in that time: 1; the network rejected 1.
• The rejected blocks would have paid about 162 BDAG (at 161.75 BDAG, what one block paid the pool wallet on average in the two weeks before).
• Payouts from the start until an hour after the end: 68 sent (15,737.813 BDAG), none failed.

Measured on 4 October 2026, 01:10 UTC from the status checker's samples, the pool's share log and its own log, and the payout records.

Why it happened

The node ran a sync of its block graph for 1 min 23 s while it was in fact up to date with its peers, then went through three reorganisations of the DAG in a row, one of which it logged as an error of its own. For those 2 seconds it called itself syncing and refused the block and new work. The same thing happened on 29 September (46 seconds, 2 blocks).

What we changed so it does not happen again

The node takes blocks that arrive several seconds late: in its own copy of the DAG there are blocks joined 6 to 9 levels behind the tip, and the block lost here would have been about 6 levels behind once the node answered again. So the pool will send such a block again, for a few seconds, when the node refuses it only because it is syncing. A block that arrives late is more likely to be orphaned, but it gets a chance instead of none. The node's error is being reported to its developers.

1 October 2026, 13:05 UTC to 2 October 2026, 15:47 UTC · lasted 26 h 42 min

Incident 2026-10-01-1305

What happened

This was a fault in DagCore Miner, the program miners run on their own machines, not in the pool. The pool, its share accounting and payouts were not affected. Ten faults were found and fixed together; all fixes are in DagCore Miner 1.3.2-rc3.

Graphics cards:

• Two different cards could show up under the same name: an RTX 3070 next to an RTX 2060 SUPER was listed as "RTX 3070" twice. Mining was not affected: each card mined correctly, and none mined twice.
• The power limit, clock settings and readings such as temperature could reach a different card than the one shown, on rigs with more than one NVIDIA card.

Autotune:

• The default settings were weak on some cards: an RTX PRO 4000 mined at 1.22 MH/s where 1.77 MH/s is possible.
• On a rig with different cards, one card's tuning overwrote another's, so a card repeated its trials at every start.
• The hashrate measured during the trials was wrong on rigs with several cards, because it added up the hashes of all of them.
• An interrupted tuning saved a partial result.
• Some trials were run that could not help: work sizes too large for the card were tried twice.

Hashrate chart history:

• On Windows the history was saved once and then never updated.
• On every system, saving at shutdown did not run, so each stop lost up to 2 minutes of history.

Impact on miners

• Miners with a card affected by the weak default setting earned less than the card could: on the RTX PRO 4000 about 30 % less.
• On rigs with several NVIDIA cards, a power limit or clock set from the dashboard may have been applied to another card than intended.

Why it happened

The miner read the list of graphics cards incorrectly, and the rest of the list was written past the end of the memory set aside for it. It also assumed that OpenCL, which does the mining, and nvidia-smi, which sets power and clocks, number the cards in the same order; that is not guaranteed. The autotune kept one saved result per rig instead of one per card, and its default settings had been chosen on other cards.

How it was fixed

DagCore Miner 1.3.2-rc3, on the download page since 15:47 UTC on 2 October:

• Every card is matched by its PCI address, and on Windows without nvidia-smi through NVML, so settings and readings reach the right card.
• The miner tunes itself the first time it starts on a card: about 8 minutes, during which it mines normally. The result is saved and applied at once on later starts.
• Saved tuning is kept per card; an interrupted tuning saves nothing and starts again next time; work sizes that do not fit are not tried twice, and under 2 % difference the smaller one wins.
• Tuning saved by earlier versions is still read, so rigs keep their settings after the update.
• The chart history is saved regularly on Windows too, and at every shutdown.

To get the fixes, download 1.3.2-rc3, stop the miner and start the new one with the same wallet address. Your balance and payouts are not affected.

29 September 2026, 13:31 to 13:31 UTC · lasted 46 s

Incident 2026-09-29-1332 · noticed by our monitoring

What happened

For 46 seconds the node answered that it was syncing, so the pool could not get new work from it. Two blocks found in that time were rejected by the node, about 324 BDAG. Miners stayed connected and kept working; payouts were not affected.

Impact on miners

• Blocks found by miners in that time: 2; the network rejected 2.
• The rejected blocks would have paid about 324 BDAG (at 162.25 BDAG, what one block paid the pool wallet on average in the two weeks before).
• Payouts from the start until an hour after the end: 84 sent (23,392.452 BDAG), none failed.

Measured on 29 September 2026, 14:37 UTC from the status checker's samples, the pool's share log and its own log, and the payout records.

Why it happened

The node briefly reported itself as syncing while it was in fact up to date with its peers. Its own status showed no lag before or after.

28 September 2026, 21:18 UTC to 29 September 2026, 05:11 UTC · lasted 7 h 53 min

Incident 2026-09-28-2118

What happened

This was not an outage: the pool ran and paid all night. But a miner on another continent, about 170 ms away from the pool over the network, had about one share in six rejected as "stale" and not credited. A miner close to the pool lost about one share in thirty-five the same way.

We found it by comparing the two: the miner's own figures showed 16 % stale shares against 2.8 % for the nearby one, and every one of the far miner's stale shares had reached the pool less than a third of a second after its job had been replaced.

Impact on miners

• From 21:18 UTC on 28 September to 05:11 UTC on 29 September, 502 shares of the far miner were rejected as late: about 16 % of the shares it sent.
• A nearby miner lost 108 shares the same way, about 3 %.
• That work was not credited, so the rewards of that time were split as if those miners had done less work; the other miners received the difference.
• Payouts made before the fix were not recalculated.

Why it happened

The network produces a new block about once a second, and each one gives miners a new job that replaces the last. A share found on the previous job, and still on its way to the pool when the new job was sent, arrived too late and was rejected. How often that happens depends only on the distance between the miner and the pool: about 17 % for a miner 170 ms away, about 3 % for one 31 ms away. None of the late shares arrived later than 0.27 s after the change, so the mining equipment was working correctly; it was the network delay.

How it was fixed

Since 05:11 UTC on 29 September, a share that arrives up to half a second after its job was replaced is credited like any other: the work was done on a valid job. Since then no share has been rejected as late.

A block found on a job that has just been replaced is still credited as a share but is not sent to the network, because the block it would build on is no longer the newest.

What we changed so it does not happen again

• Late shares are now counted for every miner and shown on the miner page as "Stale" (the history of that night is included).
• The half-second allowance covers miners anywhere in the world: the farthest one we have measured needed less than 0.3 s.