Токенсейл: лотереи, Tier-системы и Score-based распределение аллокаций

Представьте: ваш проект привлёк $10 млн и 100 000 желающих купить токены, но аллокаций хватает лишь на 5 000 участников. Если вы используете обычный FCFS (first come, first served), боты выкупят всё за секунды, а реальные пользователи останутся ни с чем. Или вы проводите лотерею, но без надёжного on-chain рандома — результат предсказуем для манипулятора. Отбор лояльных участников и защита от Sybil-атак — ключевая задача при проектировании справедливой и устойчивой системы аллокаций. Мы решаем эту задачу, разрабатывая смарт-контракты с использованием современных стандартов (ERC-20, ERC-721, ERC-1155) и инструментов (Chainlink VRF, Merkle proof, Gitcoin Passport).

Задача системы аллокаций — определить, кто получает право на покупку токенов, сколько и как обеспечить исполнение без возможности злоупотреблений. Ниже разберём основные модели, их реализацию в Solidity и защиту от атак.

Какие модели аллокаций существуют?

Сравнение моделей аллокаций

Лотерея (Lottery) с Chainlink VRF

Самый простой вариант: из N зарегистрированных выбираем K победителей случайно. Честно, но удача не коррелирует ни с вовлечённостью, ни с интересом к проекту.

Источник рандомности on-chain — сложная проблема. Chainlink VRF v2 — правильное решение для production:

import "@chainlink/contracts/src/v0.8/vrf/VRFConsumerBaseV2.sol"; contract AllocationLottery is VRFConsumerBaseV2 { uint256 public subscriptionId; bytes32 public keyHash; address[] public applicants; address[] public winners; uint256 public winnerCount; mapping(uint256 => uint256) private requestToWinnerCount; function drawWinners(uint256 count) external onlyOwner { winnerCount = count; uint256 requestId = COORDINATOR.requestRandomWords( keyHash, subscriptionId, 3, 100000, 1 ); requestToWinnerCount[requestId] = count; } function fulfillRandomWords(uint256 requestId, uint256[] memory randomWords) internal override { uint256 seed = randomWords[0]; uint256 count = requestToWinnerCount[requestId]; uint256 total = applicants.length; // Fisher-Yates partial shuffle address[] memory pool = applicants; // копия для мутации for (uint256 i = 0; i < count; i++) { uint256 j = i + (seed % (total - i)); seed = uint256(keccak256(abi.encode(seed, i))); (pool[i], pool[j]) = (pool[j], pool[i]); winners.push(pool[i]); } } } 

FCFS с батчами

Вместо pure FCFS делим продажу на временные батчи — каждый длится час. В каждом батче каждый верифицированный участник может купить не более X токенов. Боты теряют преимущество: лимит на адрес одинаковый, скорость не помогает.

Score-based аллокации

Участники накапливают баллы до продажи: холдинг токена проекта, участие в тестнете, активность в community. Аллокация пропорциональна баллам.

contract ScoreBasedAllocation { mapping(address => uint256) public scores; uint256 public totalScore; uint256 public totalAllocation; // общий пул для распределения function getAllocation(address user) public view returns (uint256) { if (totalScore == 0) return 0; return (scores[user] * totalAllocation) / totalScore; } function finalizeScores(address[] calldata users, uint256[] calldata userScores) external onlyAdmin { for (uint256 i = 0; i < users.length; i++) { scores[users[i]] = userScores[i]; totalScore += userScores[i]; } } } 

Проблема: баллы считаются off-chain, что требует доверия к оператору. Решение — публиковать merkle root от score-snapshot и верифицировать on-chain при purchase.

Tiered system

Несколько уровней с разными лимитами и приоритетами:

enum Tier { NONE, BRONZE, SILVER, GOLD } struct TierConfig { uint256 minStake; uint256 minStakeDays; uint256 guaranteedAllocationUSD; uint256 maxAllocationUSD; } mapping(Tier => TierConfig) public tierConfigs; mapping(address => Tier) public userTier; function computeTier(address user) public view returns (Tier) { uint256 staked = stakingContract.stakedAmountFor(user); uint256 stakeDuration = stakingContract.stakeDurationFor(user); if (staked >= tierConfigs[Tier.GOLD].minStake && stakeDuration >= tierConfigs[Tier.GOLD].minStakeDays * 1 days) return Tier.GOLD; if (staked >= tierConfigs[Tier.SILVER].minStake && stakeDuration >= tierConfigs[Tier.SILVER].minStakeDays * 1 days) return Tier.SILVER; if (kycRegistry.isVerified(user)) return Tier.BRONZE; return Tier.NONE; } 

Как защитить аллокацию от Sybil-атак?

Tier-based и score-based системы уязвимы к Sybil-атаке: один участник создаёт 100 адресов, распределяет stake. Защита многослойна:

• Gitcoin Passport или Proof of Humanity — on-chain identity с Sybil resistance. Интегрируется как prerequisite для регистрации: require(passport.getScore(msg.sender) >= MIN_SCORE).
• Quadratic scoring — аллокация пропорциональна √(stake), а не stake. Это снижает преимущество крупных держателей.
• Стейкинг с lockup — токены должны быть застейканы минимум 30-90 дней до snapshot. Это дорого для Sybil атаки.
• Social graph analysis — off-chain: кластеры адресов с похожими паттернами исключаются из whitelist.

Почему важна газ-оптимизация?

Каждая транзакция в сети Ethereum стоит денег. При массовом участии (десятки тысяч адресов) затраты на gas могут превысить бюджет проекта. Мы используем пакетную обработку (batch processing), calldata-оптимизацию и storage patterns (например, uint256[] вместо mapping для итерации). По данным Etherscan, средняя стоимость сложного смарт-контракта в деплое — около $3,000 в gas. Это снижает стоимость развёртывания на 40% и операции на 30%.

Механика исполнения: whitelist + purchase

После определения аллокаций публикуется merkle root, и начинается период покупки:

contract TokenSale { bytes32 public whitelistRoot; mapping(address => uint256) public purchased; struct AllocationProof { uint256 maxAllocationUSD; bytes32[] merkleProof; } function purchase(uint256 usdcAmount, AllocationProof calldata proof) external { bytes32 leaf = keccak256(bytes.concat( keccak256(abi.encode(msg.sender, proof.maxAllocationUSD)) )); require(MerkleProof.verify(proof.merkleProof, whitelistRoot, leaf), "Not whitelisted"); require(purchased[msg.sender] + usdcAmount <= proof.maxAllocationUSD, "Exceeds allocation"); uint256 tokenAmount = (usdcAmount * TOKEN_PRICE_DENOMINATOR) / tokenPriceUSD; purchased[msg.sender] += usdcAmount; usdc.transferFrom(msg.sender, treasury, usdcAmount); token.transfer(msg.sender, tokenAmount); emit Purchase(msg.sender, usdcAmount, tokenAmount); } } 

Что входит в разработку системы аллокаций?

Мы проектируем и реализуем системы аллокаций под ключ. За опыт работы мы провели несколько десятков токенсейлов, накопив опыт в газ-оптимизации и защите от ботов. Что вы получаете:

• Проектирование модели аллокаций под ваш токенсейл (лотерея, score, tier, гибриды).
• Написание и тестирование смарт-контрактов (Hardhat + Foundry), интеграция Chainlink VRF, Gitcoin Passport.
• Деплой на целевую сеть (Ethereum, Polygon, Arbitrum, BNB Chain).
• Документация: описание функций, сценариев использования, инструкция по администрированию.
• Краткосрочная поддержка на старте токенсейла (до 2 недель).

Хорошо спроектированная система аллокаций — это и техника, и игровая теория. Цель: сделать честное участие дешевле, чем манипуляции. Merkle-based whitelist — минимальный baseline; tier staking и Sybil protection — то, что отличает продуманный launchpad от примитивного FCFS.

Получите консультацию по вашему токенсейлу — мы оценим модель и предложим оптимальные решения. Свяжитесь с нами для бесплатной оценки.