Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

P3 tokenomics: token utility, emission schedule, supply policy, treasury (P3-5.1/5.2)

Offen
#42 2 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@robertocarlous arbeitet bereits daran.

Seit 21.7.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

enhancement

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

Summary

Turn DIN from a devnet utility/staking token into a credible protocol asset. Today DinToken mints only via DinCoordinator.depositAndMint (fixed dinPerEth rate, owner-withdrawable ETH, no cap, no burn, no emission, no treasury).

Scope (from MECHANISM_DESIGN §7)

  • Utility / demand sinks: staking (primary), DIN-denominated fees, reward-pool deposits, governance weight (P5+ hook only)
  • Emission contract (P3-5.2): per-GI reward subsidy on a diminishing schedule — ✅ geometric decay per epoch confirmed, GI-lifecycle-tied inflation guard confirmed. MAX_SUPPLY: ✅ resolved as deliberately open/dynamic for now, not a hard cap at freeze time (supply governed by issuance vs. burn; hard cap possible later via governance)
  • depositAndMint: effectively an unlimited mint at an admin-set rate — ✅ Resolved: keep active (faucet mode) on DevNet; cap on testnet; retire on mainnet, replaced by either a proper on-ramp/ICO or a validator-airdrop program rewarding testnet participants — both kept open, final model TBD; route deposited ETH backing to treasury instead of owner() withdrawal
  • Burn sinks: ✅ Resolved: explicit 50% slashed-stake burn share; fee-burn fraction from both on-chain protocol fees and validator network fees (dual sources), start at 0%, keep the hook
  • Treasury: dedicated address/contract receiving network fee split, slashed-stake share, deposit backing; DAO-controlled spend
  • Modelling before contracts (P3-5.2): simulate whether pool + emission produce stable validator income at target / 10× / 0.1× participation — wrong answers are expensive post-audit

Open decisions (→ tokenomics discussion)

  • Emission schedule shape and MAX_SUPPLY (MECHANISM_DESIGN §9, decision 5) — ✅ partially resolved, see above
  • Reward split percentages (decision 3, simulated in P3-5.2) — still open, not addressed
  • depositAndMint cap/retirement plan (decision 8 — flag before audit) — ✅ resolved, see above

Status (2026-07-21): the above resolutions are from Abraham (CEO, white-paper author) via Slack; recorded in MECHANISM_DESIGN.md §9 and tokenomics-design.md §6. Note the fee-denomination recommendation elsewhere in this doc's sibling issue (#43) is also revised — see there.

Design sources

MECHANISM_DESIGN §7 · issues/tokenomics.md · whitepaper-summary §5, §8 gap item 8 (white paper: Eth2-style decreasing inflation + fee-funded burn)

Roadmap anchors: P3-5.1 (token utility design), P3-5.2 (emission & distribution model), P3-DOC5 (tokenomics paper)

Vorherrschende Sprache
Python
Sterne
4
Forks
7
Ø Merge
3 T. 5 Std.
Gemergte PRs (30 T.)
34

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

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus InfiniteZeroFoundation/DevNet

Alle Issues in InfiniteZeroFoundation/DevNet

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.