Токенсейл: лотереї, 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.

Отримайте консультацію щодо вашого токенсейлу — ми оцінимо модель та запропонуємо оптимальні рішення. Зв'яжіться з нами для безкоштовної оцінки.