pump.fun вирішила конкретну інфраструктурну проблему: запуск токена на Solana займав години та вимагав технічних знань. Ми реалізували подібну систему для EVM-мереж, включаючи Base та Arbitrum, з bonding curve, автоматичною міграцією в DEX і фабрикою контрактів. Платформа робить запуск токена за 30 секунд — дешевше в 10 разів порівняно з традиційними методами. Щодня через аналогічні платформи проходять десятки мільйонів доларів. Ми пропонуємо розробку під ключ: від проектування до деплою та індексації. Оцінимо ваш проект протягом тижня. Зв'яжіться для консультації. Наш досвід — 5+ років у DeFi, понад 20 успішних запусків. Гарантуємо безпеку за допомогою аудиту та формальної верифікації.
Як працює bonding curve?
Bonding curve — математична функція, що визначає ціну токена залежно від поточного supply. Немає orderbook, немає LP, немає зовнішньої ціни — контракт сам визначає обмінний курс.
Типи кривих — розробка платформи в
Лінійна крива: Price = initial_price + slope * supply. Проста, передбачувана, але зростання ціни пропорційне обсягу покупок — whale може швидко виштовхнути ціну.
Експоненціальна крива: Price = initial_price * e^(k * supply). Різке зростання при високому supply, ранні покупці отримують значну перевагу.
pump.fun використовує polynomial bonding curve — реалізація з virtual reserves, що імітує поведінку Uniswap AMM без реального liquidity:
virtual_sol_reserves = 30 SOL
virtual_token_reserves = 1_073_000_000 tokens
real_sol_reserves = 0
real_token_reserves = 793_100_000 tokens
Ціна визначається через constant product: k = virtual_sol * virtual_token_supply. При покупці dx SOL: new_virtual_sol = virtual_sol + dx; new_virtual_token = k / new_virtual_sol; tokens_received = virtual_token - new_virtual_token. Це точна копія механіки Uniswap V2, але з віртуальними резервами.
Реалізація на EVM
contract BondingCurve {
uint256 public constant VIRTUAL_SOL_RESERVES = 30 ether;
uint256 public constant VIRTUAL_TOKEN_RESERVES = 1_073_000_000e18;
uint256 public constant TOTAL_SUPPLY = 1_000_000_000e18;
uint256 public constant MIGRATION_THRESHOLD = 69_000 * 1e18;
uint256 public realEthReserves;
uint256 public tokensSold;
function getTokensOut(uint256 ethIn) public view returns (uint256) {
uint256 virtualEth = VIRTUAL_SOL_RESERVES + realEthReserves;
uint256 virtualTokens = VIRTUAL_TOKEN_RESERVES - tokensSold;
uint256 k = virtualEth * virtualTokens;
uint256 newVirtualEth = virtualEth + ethIn;
uint256 newVirtualTokens = k / newVirtualEth;
return virtualTokens - newVirtualTokens;
}
function getEthOut(uint256 tokensIn) public view returns (uint256) {
uint256 virtualEth = VIRTUAL_SOL_RESERVES + realEthReserves;
uint256 virtualTokens = VIRTUAL_TOKEN_RESERVES - tokensSold;
uint256 k = virtualEth * virtualTokens;
uint256 newVirtualTokens = virtualTokens + tokensIn;
uint256 newVirtualEth = k / newVirtualTokens;
return virtualEth - newVirtualEth;
}
function buy(uint256 minTokensOut) external payable nonReentrant {
require(msg.value > 0, "No ETH sent");
require(!migrated, "Token migrated to DEX");
uint256 fee = (msg.value * FEE_BPS) / 10000;
uint256 ethIn = msg.value - fee;
uint256 tokensOut = getTokensOut(ethIn);
require(tokensOut >= minTokensOut, "Slippage exceeded");
realEthReserves += ethIn;
tokensSold += tokensOut;
IERC20(token).safeTransfer(msg.sender, tokensOut);
payable(feeRecipient).transfer(fee);
emit Trade(msg.sender, ethIn, tokensOut, true);
if (realEthReserves >= MIGRATION_THRESHOLD) {
_migrateToDEX();
}
}
function sell(uint256 tokensIn, uint256 minEthOut) external nonReentrant {
require(!migrated, "Token migrated to DEX");
require(tokensIn > 0, "Zero tokens");
uint256 ethOut = getEthOut(tokensIn);
uint256 fee = (ethOut * FEE_BPS) / 10000;
uint256 ethToUser = ethOut - fee;
require(ethToUser >= minEthOut, "Slippage exceeded");
IERC20(token).safeTransferFrom(msg.sender, address(this), tokensIn);
tokensSold -= tokensIn;
realEthReserves -= ethOut;
payable(msg.sender).transfer(ethToUser);
payable(feeRecipient).transfer(fee);
emit Trade(msg.sender, tokensIn, ethToUser, false);
}
}
Чому важлива міграція в DEX?
При досягненні threshold ($69k market cap) контракт автоматично: зупиняє торгівлю через bonding curve, створює пул на Uniswap V2, додає накопичений ETH + залишкові токени як ліквідність, спалює LP-токени назавжди. документація pump.fun описує це як ключовий механізм захисту від rug pull.
function _migrateToDEX() internal {
migrated = true;
uint256 ethForLiquidity = realEthReserves;
uint256 tokensForLiquidity = TOTAL_SUPPLY - tokensSold;
address pair = IUniswapV2Factory(UNISWAP_FACTORY).createPair(token, WETH);
IERC20(token).approve(UNISWAP_ROUTER, tokensForLiquidity);
(, , uint256 lpTokens) = IUniswapV2Router(UNISWAP_ROUTER).addLiquidityETH{value: ethForLiquidity}(
token, tokensForLiquidity, tokensForLiquidity, ethForLiquidity, address(this), block.timestamp + 300
);
IERC20(pair).transfer(address(0xdead), lpTokens);
emit Migrated(pair, ethForLiquidity, tokensForLiquidity);
}
Locked vs burned LP: спалювання радикальніше, але незворотне. При багу в контракті виправити не можна.
Що таке anti-rug механізми?
Основні ризики: творець dump'ає (купив 80% supply при низькій ціні, продає після hype). Архітектурне рішення — після міграції LP залочений. Ми додаємо обмеження максимальної покупки на адресу (10% за транзакцію) та cooldown між покупками для захисту від rapid accumulation.
uint256 public constant MAX_BUY_PERCENT = 10;
function buy(uint256 minTokensOut) external payable {
uint256 tokensOut = getTokensOut(msg.value);
uint256 maxTokens = (TOTAL_SUPPLY * MAX_BUY_PERCENT) / 100;
require(tokensOut <= maxTokens, "Buy too large");
// ...
}
Фабрика токенів
Кожен користувач запускає новий токен. Фабрика деплоїть токен + bonding curve контракт за одну транзакцію. Використовуємо CREATE2 для передбачуваних адрес — frontend може розрахувати адресу до деплою.
Як забезпечити real-time трейдинг та discovery?
З тисячами нових токенів на день потрібен real-time індекс. Використовуємо The Graph subgraph для індексування подій TokenCreated, Trade, Migrated. Trending алгоритм: score = (volume_1h * 3) + (volume_24h * 1) + (buyers_1h * 50) - (sellers_1h * 30). WebSocket для live trades — frontend підписується на події конкретного токена.
Економіка платформи
pump.fun заробляє: 1% fee від кожної trade через bonding curve, 0.5% від обсягу після міграції, платна верифікація творців. При обсязі $1M/день це $10k/день тільки від trading fee. Для EVM реалізації на Base/Arbitrum модель аналогічна, але gas cost вищий.
Порівняння мереж для деплою
| Мережа | Gas (середній) | Швидкість блоку | Аудиторія | Рекомендується для |
|---|---|---|---|---|
| Ethereum | високий | 12 секунд | велика | токени з високою капіталізацією |
| Arbitrum | середній | 1 секунда | зростаюча | фабрики з високою транзакційністю |
| Base | низький | 2 секунди | нова | тестові запуски та low-cap токени |
Технічний стек
Контракти: Solidity + Foundry (тестування з fuzz для invariants: totalEth = sum(all buys) - sum(all sells)). Індексування: The Graph або власний indexer (Node.js + ethers.js + PostgreSQL). Frontend: React + wagmi + viem, real-time через WebSocket. Чарти: TradingView Lightweight Charts. Зберігання метаданих: IPFS.
Етапи розробки
| Фаза | Зміст | Термін |
|---|---|---|
| Bonding curve math | Розрахунок параметрів кривої, тести інваріантів | 1–2 тиж |
| Core contracts | Factory, BondingCurve, міграція | 3–4 тиж |
| Security audit | Особлива увага на маніпуляцію кривою, reentrancy | 2–3 тиж |
| Indexer | Subgraph або кастомний indexer | 2–3 тиж |
| Frontend | Trading interface, discovery, charts | 4–6 тиж |
| Testnet | Повний цикл створення → торгівля → міграція | 2–3 тиж |
| Mainnet | Деплой на target chain | 1 тиж |
Що входить в розробку?
- Вихідний код смарт-контрактів з повним тестовим покриттям (unit + fuzz)
- Документація: архітектурна схема, опис параметрів кривої, deployment guide
- Налаштування індексатора та live-trade API
- Розгортання на testnet та mainnet обраної мережі
- Навчання команди для управління платформою
- Технічна підтримка на 3 місяці
Типові помилки при проектуванні кривої
- Неправильний розрахунок virtual reserves — призводить до imbalance після міграції
- Відсутність anti-робот механізмів — фронтраннінг та MEV-атаки
- Ігнорування slippage при великих покупках — користувачі втрачають кошти
- Неправильний threshold — якщо занадто низький, міграція відбувається до накопичення достатньої ліквідності
Bonding curve краще traditional orderbook тим, що не вимагає зовнішньої ліквідності та забезпечує автоматичне ціноутворення. Порівняння з ручним створенням пула: економія часу в 50 разів.
Готові до запуску? Зв'яжіться з нами для попередньої оцінки вашого проекту. Ми гарантуємо безпеку контрактів та дотримання стандартів ERC-20/ERC-721.