Розробка системи fair price discovery для нових токенів

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Розробка системи fair price discovery для нових токенів
Складний
~1-2 тижні
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1285
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1198
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    902
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1121
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    589
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    858

Розробка системи справедливого визначення ціни для нових токенів

Одне з найскладніших завдань при запуску токена — честне визначення початкової ціни. Класичні механізми — фіксована ціна на IDO або листинг через CEX — системно несправедливі: інсайдери знають ціну заздалегідь, боти скупають перші блоки, роздрібні покупці входять на піку. Результат передбачуваний: різкий pump на старті, dump протягом кількох годин, спільнота несе збитки.

Fair price discovery — це не просто «честна ціна», а механізм, при якому ціна формується агрегованим ринковим сигналом, а не позицією команди чи великих учасників. Реалізацій кілька, і вибір залежить від специфіки проекту.

Механізми fair launch: порівняння підходів

Dutch Auction (нисхідний аукціон)

Ціна починається високою і лінійно (або експоненціально) знижується доти, поки не накопиться достатній спрос. Учасники бачать поточну ціну і вирішують: купувати зараз чи чекати зниження. Рівноважна ціна — та, при якій весь обсяг розміщення розпродається.

Реалізація в Solidity:

contract DutchAuction {
    uint256 public immutable startPrice;
    uint256 public immutable endPrice;
    uint256 public immutable startTime;
    uint256 public immutable duration;
    uint256 public immutable totalTokens;
    uint256 public tokensSold;

    function currentPrice() public view returns (uint256) {
        if (block.timestamp >= startTime + duration) return endPrice;
        uint256 elapsed = block.timestamp - startTime;
        uint256 priceDrop = (startPrice - endPrice) * elapsed / duration;
        return startPrice - priceDrop;
    }

    function buy(uint256 tokenAmount) external payable {
        uint256 price = currentPrice();
        uint256 cost = price * tokenAmount / 1e18;
        require(msg.value >= cost, "Insufficient ETH");
        require(tokensSold + tokenAmount <= totalTokens, "Sold out");
        tokensSold += tokenAmount;
        // transfer tokens + refund excess
    }
}

Переваги: цінотворення визначається ринком, без фіксованої алокації. Недоліки: стратегія «чекати до останнього моменту» створює поспіх в кінці аукціону — всі чекають мінімальної ціни, потім одночасно купують. Це MEV-рай.

Gnosis використав Dutch Auction для розміщення GNO. Результат був змішаним: механіка працювала, але газові війни в останніх блоках нівелювали частину переваг для роздрібних учасників.

Liquidity Bootstrapping Pool (LBP)

Механізм Balancer: пул зі змінними ваговими коефіцієнтами. Стартує з перевагою токена проекту (наприклад, 96/4 TOKEN/USDC), поступово переходить до збалансованого розподілу (50/50). Початкова висока ціна знижується в міру продажів і зміни ваг.

Ключова відмінність від Dutch Auction: ціна реагує на реальний спрос в реальному часі. Немає попередньо визначеної кривої зниження — є AMM, який коригується під покупки та продажі.

// Параметри LBP в Balancer v2
const poolParams = {
    tokens: [projectToken, USDC],
    startWeights: [0.96, 0.04],   // 96% TOKEN, 4% USDC на початку
    endWeights: [0.50, 0.50],     // 50/50 в кінці
    swapFeePercentage: ethers.utils.parseEther("0.01"), // 1%
    duration: 3 * 24 * 60 * 60,  // 72 години
};

Чому це справедливіше: великий кит не може скупити все в першому блоці — висока початкова вага токена підвищує ціну експоненціально при великих покупках. Боти без інформаційної переваги не можуть передбачити, де буде рівновага.

Проекти, які використали LBP: Gitcoin, Radicle, численні DeFi запуски через Copper. Це де-факто стандарт для DeFi token launch на Ethereum.

TWAMM (Time-Weighted Average Market Maker)

Концептуально інший підхід: великі заявки виконуються невеликими кусками протягом тривалого періоду (години, дні). Немає єдиного моменту «листингу» — ціна формується поступово через безперервну торговлю.

FraxSwap реалізував TWAMM on-chain. Для fair launch це означає: замість «листингу в п'ятницю о 14:00 UTC», є «розміщення відбувається з понеділка по п'ятницю, кожен блок невеликий обсяг». Боти втрачають перевагу — немає одного моменту атаки.

Bonding Curve з commit-reveal

Ще один підхід: bonding curve з фазою commit-reveal для боротьби з frontrunning. Учасники на фазі commit відправляють keccak256(amount + salt) без розкриття суми. Після закінчення commit-фази — reveal: всі розкривають свої заявки, фінальна ціна визначається за кривою з урахуванням повного попиту.

// Фаза commit
mapping(address => bytes32) public commitments;

function commit(bytes32 commitment) external payable {
    require(block.timestamp < commitDeadline, "Commit phase ended");
    commitments[msg.sender] = commitment;
    // ETH депозит — максимально можлива сума
}

// Фаза reveal
function reveal(uint256 amount, bytes32 salt) external {
    require(block.timestamp >= revealStart, "Reveal not started");
    bytes32 expected = keccak256(abi.encodePacked(amount, salt, msg.sender));
    require(commitments[msg.sender] == expected, "Invalid reveal");
    // записуємо реальний спрос для розрахунку фінальної ціни
}

Захист від специфічних атак

Sybil-атаки

Один учасник створює тисячі адрес, щоб здатися «широкою базою» та отримати непропорційну частку. Рішення:

  • Proof of Humanity / Worldcoin: верифікація унікальності особистості. Складно інтегрувати в контракт, але можливо через Merkle-докази.
  • Quadratic funding weighting: алокація пропорційна квадратному кореню від суми, а не сумі. Sybil втрачає сенс: 100 адрес по $1 дають $10 «ваги», одна адреса на $100 — $10 «ваги». Рівнозначно для чесних, збитково для Sybil.
  • Snapshot + whitelist: використовувати off-chain критерії (on-chain активність, NFT權) для формування whitelist через Merkle tree.

Whale manipulation

Кит вносить величезний обсяг в останній момент аукціону, зміщуючи ціну. Захист:

  • Max allocation per address: обмеження частки на одну адресу. Не вирішує Sybil, але обмежує явний whale вплив.
  • Gradual price adjustment: LBP механічно стійкий до цього — експоненціальний ріст ціни при великих покупках.
  • Time-locked participation: учасники повинні зареєструватися за N днів до аукціону. Знижує можливість останньої хвилини.

MEV на фінальних блоках Dutch Auction

Якщо аукціон закінчується в конкретний timestamp — останні блоки це MEV-аттракціон. Пом'якшення: випадковий deadline через Chainlink VRF, або безперервний Dutch Auction без фіксованого кінця.

On-chain vs off-chain price discovery

Повністю on-chain discovery: прозорий, верифіцируємий, але дорогий у газі та повільний. Кожен учасник взаємодіє з контрактом.

Гібридний підхід: off-chain orderbook + on-chain settlement. Учасники підписують заявки off-chain (EIP-712), фінальний розподіл постить on-chain однією batch-трансакцією. Це модель Gnosis Auction.

// Приклад batch settlement
struct Order {
    address bidder;
    uint256 sellAmount; // USDC
    uint256 buyAmount;  // мінімум TOKEN
    bytes32 signature;
}

function settleAuction(
    Order[] calldata orders,
    uint256 clearingPrice  // USDC за TOKEN, 18 decimals
) external onlyAuctioneer {
    for (uint i = 0; i < orders.length; i++) {
        uint256 tokensOut = orders[i].sellAmount * 1e18 / clearingPrice;
        require(tokensOut >= orders[i].buyAmount, "Below min");
        // transfer tokens
    }
}

Аукціоніст (централізований елемент) розраховує clearing price off-chain і постить результат. Це компроміс між ефективністю та децентралізацією — аукціоніст може бути multisig або DAO.

VRGDA (Variable Rate Gradual Dutch Auction)

Механізм, розроблений командою Art Gobblers. Ціна регулюється в залежності від відхилення реальних продажів від запланованого графіку. Якщо токени продаються швидше плану — ціна зростає, повільніше — падає.

function getVRGDAPrice(
    int256 timeSinceStart,  // в секундах, signed
    uint256 sold           // токенів уже продано
) public view returns (uint256) {
    return targetPrice.mulWadUp(
        decayConstant.mulWadUp(timeSinceStart - getTargetSaleTime(sold + 1)).expWad()
    );
}

VRGDA підходить для безперервного викиду (NFT серії, governance токени з поточним розподілом), менш застосовується до разових IDO.

Інтеграція ліквідності DEX після запуску

Fair price discovery — це лише перший крок. Наступне критичне завдання: не дозволити ціні негайно впасти після завершення аукціону. Рішення:

Автоматична seed ліквідність: частина зібраних коштів + частина токенів автоматично додається до Uniswap v3 пулу. Смарт-контракт робить це атомарно при завершенні аукціону.

Concentrated liquidity positioning: замість повного діапазону (як у Uniswap v2), ліквідність розміщується в діапазоні ±30% від clearing price. Це забезпечує глибокий ринок близько справедливої ціни.

Vesting LP tokens: LP позиція команди заблокована на 6–12 місяців через TimeLock. Це сигнал ринку: ліквідність не буде rug-pulled.

Stack і процес розробки

Компонент Технологія
LBP контракт Balancer v2 SDK + користувальницькі параметри
Dutch Auction Solidity + Foundry
Batch settlement Gnosis Auction fork або користувальницький
Price oracle Chainlink + Uniswap v3 TWAP
Frontend wagmi + viem + React, реальтайм ціна через WebSocket
MEV захист Flashbots Protect RPC

Фаза 1 (1–2 тижні): вибір механізму під конкретну токеноміку, аудит параметрів (starting price, duration, min/max allocation), юридичний аналіз (не всі механізми регуляторно нейтральні у всіх юрисдикціях).

Фаза 2 (3–4 тижні): розробка контрактів, інтеграція з Balancer або користувальницький auction контракт, тестування на mainnet fork.

Фаза 3 (1–2 тижні): frontend для участі, моніторинг, скрипти для post-auction ліквідності.

Фаза 4: зовнішній аудит контрактів — обов'язковий, особливо для користувальницьких механізмів. LBP на Balancer наслідує аудит Balancer, користувальницькі реалізації — ні.

Честна price discovery напрямо впливає на довіру спільноти до проекту. Технічно це вирішується, і вибір правильного механізму під конкретний проект важливіший, ніж ідеальна реалізація невідповідного.