Skip to content

SNCT mainnet airdrop — 4-phase distribution plan

Policy reminder (from CLAUDE.md): NO testnet activity counts. Every snapshot, claim, and eligibility check below operates on mainnet activity only. This filters out mercenary farmers who only show up for the drop.

Mainnet launch target: 2026-06-16 / 2026-06-17 (Day 0).


Schedule overview

PhaseSnapshot dayClaim opensBucket focus
Phase 1Day 90Day 90 → Day 180Genesis users — first to actually transact on mainnet
Phase 2Day 180Day 180 → Day 270Privacy + bridge — users who exercised the differentiated features
Phase 3Day 270Day 270 → Day 360DEX liquidity + .snct early holders
Phase 4Day 365Day 365 → Day 455Long-tail loyalty — sustained activity across all features

Each snapshot is a single block height committed publicly before the phase begins so retroactive farming is impossible.

Total airdrop allocation, phase split, and exact percentages: operator-side plan, not in this repo. This doc captures structure, eligibility logic, and anti-sybil heuristics only.


Phase 1 — Day 90 (Genesis users)

Eligibility window: Day 0 → Day 89 mainnet activity.

BucketSignalWeight
Active validatorsUptime in signed_blocks_window-weighted ratio over the 90-day windowHigh
First 10k unique addressesAddress received ≥ 1 mainnet tx before Day 30Medium
Staking dApp delegatorsNet delegated SNCT > 100 by snapshot, held for ≥ 30 daysMedium

Anti-sybil:

  • Validators get one allocation per priv_validator_key.json (consensus pubkey), not per operator address.
  • "First 10k addresses" excludes addresses funded only from a single source (chain analysis: 1-hop ancestor cluster).
  • Min delegation duration prevents flash-stake-snapshot-unstake.

Phase 2 — Day 180 (Privacy + bridge)

Eligibility window: Day 0 → Day 179 mainnet activity.

BucketSignalWeight
Shielded pool users(Shield + Send + Unshield) tx count by snapshot, capped per addressHigh
Bridge usersHyperlane adapter transferRemote count (either direction), cappedMedium
Anonymity-set contributorsAddresses that held > $X equivalent in the shielded pool for > 30 contiguous daysHigh

Anti-sybil:

  • Per-address cap on shielded-pool tx count blunts spam-shielding.
  • Bridge count cap blunts the trivial 100x-round-trip farm.
  • Anonymity-set hold-time uses on-chain commitment ranges; can't be faked retroactively.

Phase 3 — Day 270 (DEX + .snct)

Eligibility window: Day 0 → Day 269 mainnet activity.

BucketSignalWeight
DEX swappersUnique-day count with ≥ 1 swap, capped at 60 unique-daysLow
LP providersTVL-time integral on any WSNCT pair, normalizedHigh
.snct domain holdersDomain registered + held > 90 days, OR auction wonMedium
MasterChef farmersLP staked in farm for > N days, weighted by stake-timeMedium

Anti-sybil:

  • LP TVL-time integral resists flash-LP — has to be in for real time.
  • Domain holders deduped by reverse-resolution (same wallet across multiple domains gets one allocation).
  • Wash-trade detection: same-block opposite swaps on the same pair from the same address get filtered.

Phase 4 — Day 365 (Loyalty)

Eligibility window: Day 0 → Day 364 mainnet activity.

This is the retention payoff. Eligibility = users who scored in at least two of Phases 1, 2, 3 AND had non-zero on-chain activity in 6 of the 12 mainnet months.

Anti-farmer bonus: addresses that bridged OUT > 90% of received SNCT and never bridged back lose Phase 4 eligibility.


Operational requirements before Day 0

These need to be in place before mainnet launches, otherwise Phase 1 can't snapshot cleanly:

  • [ ] Snapshot block committed publicly before each phase begins. Pre-commit by signing a Tweet / blog post / GitHub release with the target block height N + estimated date.
  • [ ] Claim contract written + audited. Standard Merkle-drop pattern: snapshot script produces a tree, contract verifies proofs at claim time. Reuse OpenZeppelin's MerkleProof.
  • [ ] Off-chain snapshot tooling — repeatable Python or Go script that ingests Blockscout + chain data and outputs the eligibility CSV. Auditable.
  • [ ] Claim UI — Next.js page at claim.sanect.com showing per-address eligibility + claim button. Wallet-gated to the eligible address only.
  • [ ] Sybil disclosure — published heuristics so users can self-check before claim, AND so we don't get accused of arbitrary filtering after the fact.

Things this doc deliberately does NOT specify

  • Total airdrop % of supply (operator-side decision)
  • Phase split between phases (operator-side)
  • Bucket-level allocations (operator-side)
  • Vesting schedule for claimed tokens (operator-side)
  • Treasury / team / community pool sizes (operator-side)

If a future Claude session needs those numbers, the answer is: "ask the operator, not in this repo."