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

start fair-launch token distribution

Abierto
  • ¿Algo no está bien?
#75 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
solidity
Área
blockchain

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
4
Forks
7
Merge medio
3 d 58 min
PR fusionados (30 d)
39

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.