Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#250 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
solidity
Área
backend-api-design, blockchain

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
4
Forks
7
Merge medio
3 d 5 h
PR fusionados (30 d)
34

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de InfiniteZeroFoundation/DevNet

Todos los issues de InfiniteZeroFoundation/DevNet

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.