Токенсейл: лотереї, 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 та захист від атак.
Які моделі алокацій існують?
Порівняння моделей алокацій
| Модель | Складність реалізації | Захист від ботів | Справедливість | Гнучкість |
|---|---|---|---|---|
| Лотерея (VRF) | Низька | Висока | Випадкова | Низька |
| FCFS з батчами | Середня | Середня | Рівна | Середня |
| Score-based | Висока | Залежить від ваг | Пропорційна | Висока |
| Tiered system | Висока | Висока | Диференційована | Висока |
Лотерея (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
Кілька рівнів з різними лімітами та пріоритетами:
| Tier | Умова входу | Гарантована алокація | FCFS понад гарантію |
|---|---|---|---|
| Gold | Stake >= 10,000 токенів 90 днів | $5,000 | Так, до $15,000 |
| Silver | Stake >= 1,000 токенів 30 днів | $1,000 | Так, до $5,000 |
| Bronze | KYC пройдено | $200 | Ні |
| Public | — | — | FCFS, залишок |
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.
Деталі реалізації Sybil-захисту
Для інтеграції Gitcoin Passport використовується оракул, який видає бали за верифіковані дії. Приклад умови: require(passport.getScore(msg.sender) >= 15). Стейкінг з lockup реалізується через власний контракт, де токени блокуються на заданий період. Кластеризація адрес виконується за допомогою off-chain ML-моделі, яка аналізує транзакційні паттерни.
Чому важлива газ-оптимізація?
Кожна транзакція в мережі 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.
Отримайте консультацію щодо вашого токенсейлу — ми оцінимо модель та запропонуємо оптимальні рішення. Зв'яжіться з нами для безкоштовної оцінки.