Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#42 2 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@robertocarlous y travaille déjà.

Depuis le 21/7/2026.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

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)

Langage dominant
Python
Étoiles
4
Forks
7
Merge moyen
3 j 58 min
PR mergées (30 j)
39

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de InfiniteZeroFoundation/DevNet

Toutes les issues de InfiniteZeroFoundation/DevNet

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.