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

start fair-launch token distribution

Ouverte
  • Quelque chose ne va pas ?
#75 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

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

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
20/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
solidity
Domaine
blockchain

Piste de recherche

Read Developer/tasks/ for the detailed first-slice task, then review the existing Transparent Proxy contract and deploy patterns and DinToken on develop. The issue calls for a distributor contract, deploy script, and Foundry tests using a hand-built Merkle fixture; eligibility computation is deferred until the indexer exists. Done means those contract and test scope items are implemented, including claim, vesting, root freeze, and unclaimed-allocation sweep.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement Long run

Branch: feat/fair-launch-distributor (from develop)
Assignee: @robertocarlous
Roadmap ref: P4 (no ROADMAP.md row yet — tracked via BL-18); depends on P4-IDX1/P4-IDX2 (on-chain indexer) for the eligibility-computation slice

Long-running issue. A detailed task file under Developer/tasks/ covers the first slice — this issue tracks the overall effort, not a single week's task.

Goal

Distribute DIN tokens to validators/active network participants as a fair launch — no ICO, no pre-sale, no VC allocation (Abraham's direction, Jul 31 2026, confirmed Aug 5 2026 as a testnet dry-run: move fast, mistakes are fixable). Resolves the open ICO-vs-airdrop fork in Developer/design/MECHANISM_DESIGN.md §9 item 14, in favor of the validator-airdrop path already named in §9-8.

This is a one-time (or periodic-snapshot) grant, distinct from the existing ongoing per-GI validator reward emission (§7 of MECHANISM_DESIGN.md) — the two flows aren't the same mechanism and shouldn't be conflated.

Design

  • Distributor contract (DinFairLaunchDistributor, Transparent Proxy, matching the existing platform-contract pattern): Merkle-drop claim funded once from treasury, cliff + linear vesting per claimant tracked in one contract (not N single-beneficiary VestingWallet instances). Admin sits behind whatever treasury-scoped wallet exists at deploy time (Gnosis Safe once one exists; EOA acceptable for the testnet dry-run) — per DD-3, no protocol-role multisig, treasury-only.
  • Eligibility computation (who qualifies, for how much) is explicitly a separate slice: computed off the on-chain indexer (P4-IDX1/P4-IDX2, also Robbert's) rather than a raw RPC-log script, executed by whoever holds the treasury-admin key to post the Merkle root — not on-chain logic itself. Sequenced after the indexer lands.

Scope

  • DinFairLaunchDistributor contract: deposit, Merkle-proof claim, cliff+linear vesting release, root freeze on claims-open, unclaimed-allocation sweep after a grace period
  • Deploy script following the existing Transparent Proxy deploy pattern
  • Foundry tests against a hand-built Merkle fixture (no indexer dependency for this slice)
  • (Next slice, not started yet) Indexer-backed eligibility snapshot script, once P4-IDX1/IDX2 exist

References

  • BL-18 — full backlog entry and decision history
  • Developer/design/MECHANISM_DESIGN.md §9 items 8/14 — the faucet-retirement / ICO-vs-airdrop decision this resolves
  • DD-3 — governance/treasury-admin constraint
  • Developer/ROADMAP.md — P4-IDX1/P4-IDX2 (on-chain indexer, dependency for the deferred eligibility slice)

Branching note

Fresh branch off develop, no dependency on the 8 open P3 PRs identified so far — the distributor only needs DinToken, already on develop. If contract-level dependencies on any open P3 PR surface once in the code, that's fine to pull in; call out exactly which PR/commit in the resulting PR description.

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.