Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

DINTaskAuditor.claimReward: per-participant floor-division dust is permanently stranded, every GI, every pool

オープン
  • 何か問題がありますか？
#250 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
solidity
領域
backend-api-design, blockchain

調査の方向性

Read foundry/src/DINTaskAuditor.sol, focusing on claimReward() around lines 590–628 and settleRewards() around lines 553–576; compare the three participant-level divisions with the treasury dust handling described for BL-14. Decide whether the intended outcome is to track and recover these remainders or document them as accepted dust. Done means the chosen behavior is covered for client, auditor, and aggregator pools, including multiple participants and rounding remainders.

索引モデルが issue の本文から書いたものです。

説明

Approved bug

Summary

settleRewards splits a GI's giRewardPool[gi] into clientPool/auditorPool/aggregatorPool/treasury by bps, with the treasury share absorbing that split's rounding dust (BL-14, resolved). But each of the three role pools is divided again at claim time, once per participant, and that division's rounding dust is never tracked or swept anywhere.

Where

foundry/src/DINTaskAuditor.sol, claimReward() (~lines 590-628), building on settleRewards() (~553-576), verified against develop @ 6e361cb:

amount += (snap.clientPool * sub.finalMedianScore) / totalApproved;      // :598
amount += (snap.auditorPool * weight) / totalWeight;                    // :607
amount += (snap.aggregatorPool * aggWeight) / aggTotalWeight;            // :626

Each participant's share is floor-divided independently. sum(shares) <= pool_bucket always holds (no insolvency), but nothing tracks the difference, and there's no counter anywhere recording "distributed so far" vs. the bucket total — so a future fix can't even sweep it without re-deriving the total off-chain from RewardClaimed-style events. DINTaskCoordinator/DINTaskAuditor are both non-upgradeable, so any fix needs a redeploy.

Why this isn't already covered

  • BL-14 (resolved) is specifically the top-level 4-way bps split (client/auditor/aggregator/treasury) — its dust goes to treasury, and that fix is correct and unrelated to this.
  • DINTaskAuditor.md §13 No. 4 ("Unclaimable remainders") documents only the zero-participant edge case for a role (nobody approved, nobody revealed, no aggregator weight) — not the ordinary case where a role has 2+ participants and each one's floor-divided share leaves a few wei behind.
  • Confirmed via git history this isn't new: diffed against the pre-BL-10-refactor DINTaskAuditor.sol (the per-participant settlement loops that existed before the claim-pull rework, PR #134) — the same floor-division-with-no-remainder-collection gap existed there too, just inside a loop instead of at claim time. This has survived the original reward-engine design (PR #64), the BL-10 claim-pull refactor (PR #130/#131/#134/#136), and every review round since.
  • Unlike DinFeeRouter's accruedEth/accruedDin buckets (tracked, even though also currently unswept per #221/BL-29) or the top-level treasuryAccrued, this per-bucket leftover isn't accounted for at all — it's not merely un-swept, it's untracked.

Scenario

A GI settles with clientPool = 1000 DIN among 3 approved clients, each scoring 1 (totalApproved = 3). Each client's share: 1000 * 1 / 3 = 333. Three claims later: 999 DIN distributed, 1 DIN-wei permanently stuck in the contract — uncredited to anyone, unswept, no code path to ever recover it. Repeats every GI, across all three pools, scaling with how unevenly scores/weights divide.

Severity

Low in absolute terms (bounded by floor-division error — typically a small fraction of a token per bucket per GI, economically negligible at 18 decimals) but it's a genuine, permanent, previously-unflagged fund-trapping gap with zero recovery path in a non-upgradeable contract.

Possible fixes (for discussion, not prescribing one)

  1. Track a running "distributed" counter per bucket per GI; once the last expected claimant claims (or after some deadline), sweep the remainder to treasury — mirrors the BL-14 pattern one layer down.
  2. Accept it as documented, permanent dust and extend DINTaskAuditor.md §13 No. 4 to cover this case explicitly rather than only the zero-participant edge case, if the per-wei amounts are judged not worth the added complexity of a sweep.
主要言語
Python
スター
4
フォーク
7
平均マージ
3日 4時間
マージ済み PR（30日）
34

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

InfiniteZeroFoundation/DevNet のほかの issue

InfiniteZeroFoundation/DevNet の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。