DIA — updateRewardRatePerDay accrues 20 where the old rate accrued 100000

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 57924-incorrect-calculation-of-accrued-rewards-in-updaterewardrate. Standalone Foundry PoC and full write-up: 57924-incorrect-calculation-of-accrued-rewards-in-updaterewardrate_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/reward-calculation · vuln/arithmetic/precision-loss

Reproduction: a self-contained Foundry PoC that compiles and runs offline with only forge-std — no fork and no RPC. Trace: output.txt. PoC: test/57924-incorrect-calculation-of-accrued-rewards-in-updaterewardrate_exp.sol.

Key info#

TL;DR#

updateRewardRatePerDay stores the new rate, then accrues the elapsed days with that new rate, and divides by 10,000. The claim divides by 10,000 again.

Here 100 days already elapsed at rate 1,000. The fair accumulator delta is 1000 * 100 = 100000. The function sets the rate to 2,000 first, then adds (2000 * 100) / 10000 = 20. A 10,000 principal is paid 20 * 10000 ether / 10000 = 20 ether. 99,980 WDIA stays in the distributor.

rewardLastUpdateTime is set 100 days before this block in the constructor. run() does not warp. The replay block is timestamp 8,640,001.

The vulnerable code#

rewardRatePerDay = newRewardRate;
uint256 daysElapsed = (block.timestamp - rewardLastUpdateTime) / SECONDS_IN_A_DAY;
// @> VULN: rewardsAccrued = (rewardRatePerDay * daysElapsed) / 10000 uses the new rate and divides twice
uint256 rewardsAccrued = (rewardRatePerDay * daysElapsed) / 10000;
rewardAccumulator += rewardsAccrued;

The claim then does stakerReward = (stakerDelta * principal) / 10000, which is the second division the report describes.

Root cause#

Two mistakes stack. The elapsed period is priced at the rate that was not in force, and the per-day index is scaled down by 10,000 before a second 10,000 scale is applied at claim time. For any realistic rate the first division collapses the index.

Preconditions#

• 100 days separate rewardLastUpdateTime from this block.
• The rate in force was 1,000. The update sets 2,000.
• The staker's index is 0 and the principal is 10,000 ether.
• The distributor holds 100,000 WDIA.

Attack walkthrough#

1. Call updateRewardRatePerDay(2000).
2. The accumulator becomes 20.
3. Claim. The user receives 20 WDIA.
4. The distributor still holds 99,980.

Control: accrue oldRewardRate * daysElapsed with no extra division, then set the new rate. The claim pays 100,000 and the distributor balance is 0.

Diagrams#

Impact#

The staker is underpaid by 99,980 WDIA on a single 10,000 principal. Every stake whose index was last updated before this call shares the same collapsed delta. The reward tokens remain in the distributor instead of being paid.

Remediation#

Accrue with oldRewardRate * daysElapsed before writing rewardRatePerDay, and do not divide the accumulator by 10,000. Leave that scale to the claim, which already divides by 10,000.

Sources#

• AuditVault finding 57924
• MixBytes DIA Lumina Staking, June 2025
• DIARewardsDistribution.sol at dfd0bb6

Taxonomy#

• vuln/logic/reward-calculation · vuln/arithmetic/precision-loss

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 57924-incorrect-calculation-of-accrued-rewards-in-updaterewardrate_exp (evm-hack-registry mirror).
• AuditVault finding: 57924-incorrect-calculation-of-accrued-rewards-in-updaterewardrate.

Alerts & third-party analyses

• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.