Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

P3 slashing: conditions taxonomy, penalty tiers, slashed-stake destination, dispute resolution (P3-4.1/4.2/4.3)

Open
  • Is something wrong?
#38 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
solidity
Domain
blockchain, security

Research direction

Read MECHANISM_DESIGN §4 and inspect DINTaskCoordinator's openDispute/resolveDispute path; the issue names no source or test files. First clarify the open penalty and dispute parameters, then trace how slashing and stake destinations are handled. Done means implementing the S1–S6 conditions, penalty tiers, explicit slash destination, and recomputation-based dispute flow, with invariants covered by the P3-6.3b fuzz tests.

Written by the indexing model from the issue text.

Description

enhancement

Part of the P3 mechanism-design push (#36).

Summary

Today slashing is liveness-only with a flat minStake() penalty, and slashed stake strands in the stake contract (an accidental burn). Specify and implement correctness-based slashing: a conditions taxonomy, partial/full penalty tiers, an explicit slashed-stake destination, and a dispute-resolution layer.

Scope (from MECHANISM_DESIGN §4)

  • Conditions taxonomy S1–S6: missed audit vote, missed T1/T2 submission, score deviation from cross-auditor median (S3), invalid aggregation proven by recomputation (S4), recidivism (S5), registration without capacity (S6)
  • Penalty tiers: partial slash as a DAO-settable fraction of minStake (today's flat amount over-punishes liveness faults); full slash + blacklist reserved for provable malice (S4) and recidivism (S5); keep jailing below min stake
  • Explicit slashed-stake destination — burn / treasury / redistribute / split (recommendation: 50% burn / 50% treasury; no redistribution to reporters beyond a fixed dispute bounty)
  • Dispute resolution (P3-4.3): dispute bond + window, fresh-subgroup re-evaluation excluding accused + original batch, bounty from treasury if upheld
  • Folded in from #40 (2026-09-10, #40 closed as a result): aggregator auditing — T1/T2 outputs must be verifiable by recomputation, with any validator able to open an S4 dispute (no proactive re-audit of every batch). This is the general dispute path on DINTaskCoordinator (openDispute/resolveDispute), distinct from PR #110's test-data-specific dispute mechanism on DINTaskAuditor (which closed the rest of #40's scope). Today this path is centralized (onlyOwner) with no recomputation-based verification — it's the same "general dispute path" gap already named above, just making explicit that S4/aggregator-recomputation is part of it.
  • Invariants feeding P3-6.3b fuzz tests (staked supply never increases after a slash; slashed amount always reaches its declared destination; no negative stake states)
  • White paper §8.1 semantics to weigh: delegator penalty % and permanent removal + re-registration (gap item 4 in the whitepaper summary) — ✅ Resolved for 2.0 (Abraham, 2026-07-21): jail/blacklist, not permanent removal. Full §8.1 alignment (forced re-registration, delegator penalties) deferred until delegation lands.

Open decisions (→ slashing-economics discussion)

  • Slashed-stake destination (MECHANISM_DESIGN §9, decision 1) — ✅ Resolved: 50% burn / 50% treasury. Burn is a deflationary sink; treasury funds dispute adjudication; reporters get a fixed bounty only, never a share of the slash (Abraham, 2026-07-21).
  • Partial-slash fraction and S3 deviation threshold — needs P3-SCR empirical data; shadow-mode first (decision 2). Still open on the exact numbers, but Abraham's reply layered an Ethereum-style penalty framework on top to build the fraction/threshold into: a correlation penalty scaling with how many validators are slashed in a short window, ejection to a draining withdrawal queue, and an inactivity leak for persistent offline validators. Note: this framing is in Ethereum consensus terms (double-signing, 1/32 immediate penalty) and needs translating to DIN's S1–S6 liveness/correctness conditions — not a literal drop-in.
  • Dispute bond size and window length (decision 7) — not addressed, still open

Design sources

MECHANISM_DESIGN §4 · whitepaper-summary §4.5, §8 gap items 3–4

Roadmap anchors: P3-4.1 (conditions spec, in progress), P3-4.2 (engine), P3-4.3 (disputes), P3-DOC3 (slashing rules reference — external-validator blocking requirement)

Dominant language
Python
Stars
4
Forks
7
Avg merge
3d 5h
Merged PRs (30d)
34

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InfiniteZeroFoundation/DevNet

All issues in InfiniteZeroFoundation/DevNet

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.