Представьте: ваш проект привлёк $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.
Получите консультацию по вашему токенсейлу — мы оценим модель и предложим оптимальные решения. Свяжитесь с нами для бесплатной оценки.