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

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

Abierto
#42 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@robertocarlous ya está trabajando en esto.

Desde el 21/7/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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)

Lenguaje dominante
Python
Estrellas
4
Forks
7
Merge medio
3 d 4 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.