Розробка системи аллокацій для токенсейла
Стандартна проблема при запуску токенсейла: або whitelist переподписан в 20 разів и більшість учасників отримують нуль, або аллокації розподілені по принципу «first-come, first-served» и боти купують збоку. Система аллокацій — це механізм справедливого розподілу права на покупку токенів до старта продажі.
Задача системи: визначити, хто отримує аллокацію, скільки, і забезпечити виконання цього on-chain без можливості зловживань.
Моделі розрахунку аллокацій
Lottery (випадкова виборка)
Найпростіший варіант: з N зареєстрованих вибираємо K переможців випадково. Чесно, але удача не корелює ні з залученістю, ні з інтересом до проекту.
Джерело рандомності — це завжди проблема on-chain. Chainlink VRF v2 — правильне рішення для production:
contract AllocationLottery is VRFConsumerBaseV2 {
address[] public applicants;
address[] public winners;
function drawWinners(uint256 count) external onlyOwner {
uint256 requestId = COORDINATOR.requestRandomWords(
keyHash, subscriptionId, 3, 100000, 1
);
}
}
FCFS з ограниченням за часом (Batch round)
Замість pure FCFS ділимо продажу на часові батчи: кожен батч — 1 година, в кожному батчі кожен верифікований учасник може купити не більше 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;
}
}
Tiered система
Кілька рівнів з різними лімітами та приоритетами:
| 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, остаток |
Механіка виконання: whitelist + покупка
Після визначення аллокацій — публікація whitelist (merkle root) та період покупки.
Защита від 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: кластери адрес з подібними on-chain паттернами (створені в один день, фінансовані з одного джерела) виключаються з whitelist.
Добре спроектована система аллокацій — це й техніка, й теорія ігор. Ціль: зробити чесне учасництво дешевше, ніж маніпуляції. Merkle-based whitelist — це мінімальний baseline; tier staking і Sybil protection — те, що відрізняє продуманий launchpad від примітивного FCFS.