start fair-launch token distribution

Open
  • Is something wrong?
#75 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
solidity
Domain
blockchain

Research direction

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.

Written by the indexing model from the issue text.

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.

Dominant language
Python
Stars
4
Forks
7
Avg merge
3d 7h
Merged PRs (30d)
33

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InfiniteZeroFoundation/DevNet

All issues in InfiniteZeroFoundation/DevNet

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.