Three dormant/no-op mechanisms awaiting a product decision: disableModel kill-switch, rejectModel fee handling, S6 slashing (M-2, L-4, BL-31)
Maintainer antworten meist innerhalb von 1 Tag
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Refactoring
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- solidity
- Bereich
- backend, blockchain
Rechercherichtung
Read Developer/BACK_LOG.md BL-31 and the cited audit findings M-2 and L-4, then review DINModelRegistry.sol, DINTaskCoordinator.sol, DINTaskAuditor.sol, and DinValidatorStake alongside #38. The issue needs product and mechanism design decisions across three independent behaviors before implementation can be scoped; done means documenting or implementing each agreed decision consistently.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Three separate findings, batched because they share the same shape: each is a mechanism that exists in some form (an admin function, a fee flow, a slashing path) but nobody has made — or at least documented — the decision on whether/how it's actually meant to be used. None are exploitable bugs; all three just need someone with product/mechanism-design authority to decide, so the code (or the docs) can be made to match.
M-2: DINModelRegistry.disableModel() doesn't reach the live task contracts
modelDisabled[modelId] (DINModelRegistry.sol:119) only gates requestModelRegistration/requestManifestUpdate inside the registry itself (L151, L330). Confirmed by inspection against develop @ 740a613: DINTaskCoordinator.sol has zero references to DINModelRegistry, and DINTaskAuditor.sol's only two references are doc comments, not functional checks. A model the DIN-Representative has disabled — e.g., because its task contracts have a bug wrongfully slashing honest validators — keeps running full GIs completely unaffected. The task contracts' own doc table calls this a "kill-switch," which it currently isn't.
Decision needed: wire the task contracts to check DINModelRegistry.modelDisabled(modelId) before state-changing calls (real fix, requires threading the model ID + registry address into contracts that don't currently know about the registry at all), or explicitly document disableModel as registry-metadata-only so operators stop treating it as a circuit breaker.
L-4: rejectModel() never refunds the registration fee
Checked the full flow: feePaid is recorded at requestModelRegistration() (DINModelRegistry.sol:197) and is never refunded on either outcome — not on rejectModel() (L261-271) and not on approveModel() either (L217-258 doesn't touch feePaid at all). This consistency suggests the fee is intentionally a pay-to-apply cost regardless of outcome (anti-spam), not an oversight specific to rejection — but this was never written down anywhere as a deliberate choice.
Decision needed: confirm non-refundable-regardless-of-outcome is the intended design and document it (in DINModelRegistry.md and/or the dinrep role docs), so a future reader doesn't "fix" it into an inconsistent partial-refund state.
BL-31: S6 no-participation slashing is implemented, tested, but never called
DinValidatorStake.recordNoParticipation() (S6: escalating 10%-per-breach slash past a threshold, L333-354) is fully implemented and has its own tests. Every call site in both task contracts is a comment explaining why it's deliberately not called (DINTaskAuditor.sol:1391, DINTaskCoordinator.sol:1185) — slashPartial (S1/S2) already penalizes the same missed-work behavior, and calling both would double-penalize past MIN_STAKE. Confirmed: zero functional call sites anywhere in foundry/src/.
Decision needed: either S6 is meant to cover a gap S1/S2 don't (e.g., a validator registered but never assigned to any batch, so S1/S2 never trigger on them at all) and needs wiring to that specific case, or it's superseded dead code that should be removed along with its threshold parameter and event, per the slashing taxonomy (#38).
References
Developer/BACK_LOG.mdBL-31Documentation/technical/audits/foundry-src-security-review.mdM-2, L-4 (confirmed still accurate againstdevelop@740a613; several of that doc's other findings — M-3, M-4, L-1, L-5, L-7 — are already fixed but the doc was never updated to say so, a separate minor doc-hygiene item not covered by this issue)- PR #204 review (BL-31's source)
- #38 (slashing taxonomy, relevant to the S6 decision)
- Vorherrschende Sprache
- Python
- Sterne
- 4
- Forks
- 7
- Ø Merge
- 3 T. 7 Std.
- Gemergte PRs (30 T.)
- 33
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus InfiniteZeroFoundation/DevNet
-
ROADMAP.md: refresh "What is still open for P3" (several items were fixed in October)Evtl. vergeben @umermjd11 hat das vor 4 Tagen übernommen. Offendocumentation good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
InfiniteZeroFoundation/DevNet#285 · 1 Kommentar · 1 zugewiesene Person ·
Maintainer antworten meist innerhalb von 1 Tag
-
Update the 25 translated organisation READMEs to match the English versionEvtl. vergeben @mrCabez hat das vor 2 Tagen übernommen. Offengood first issue help wanted
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
InfiniteZeroFoundation/DevNet#277 · 3 Kommentare · 1 zugewiesene Person ·
Maintainer antworten meist innerhalb von 1 Tag
-
Update the client-service guide to explain training and uploading separatelyEvtl. vergeben @Santiagocetran hat das vor 2 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
InfiniteZeroFoundation/DevNet#266 · 1 zugewiesene Person ·
Maintainer antworten meist innerhalb von 1 Tag
-
Few questions related to GI2 aggregatorEvtl. vergeben @Abidoyesimze hat das vor 1 Tag übernommen. Offen
InfiniteZeroFoundation/DevNet#307 · 1 Kommentar · 1 Reaktion · 4 zugewiesene Personen ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug python
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 52/100
InfiniteZeroFoundation/DevNet#306 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in InfiniteZeroFoundation/DevNet
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
-
[Bug]: Responses API 500s on assistant message with empty content listEvtl. vergeben @shadowmodder hat das heute übernommen. Offenbug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
vllm-project/vllm#64940 ·
Maintainer antworten meist innerhalb von 1 Tag
-
limits
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
agent-ready area: docs documentation good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Soneso/stellar-agent-wallet#524 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Keybind quest outdatedOffenStatus: Triage Type: Quest
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
GTNewHorizons/GT-New-Horizons-Modpack#27490 ·
Maintainer antworten meist innerhalb von 1 Tag