Розробка платформи в стилі pump.fun: бондінг-крива, міграція, фабрика

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 вищий.

Порівняння мереж для деплою

Технічний стек

Контракти: 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.

Етапи розробки

Що входить в розробку?

• Вихідний код смарт-контрактів з повним тестовим покриттям (unit + fuzz)
• Документація: архітектурна схема, опис параметрів кривої, deployment guide
• Налаштування індексатора та live-trade API
• Розгортання на testnet та mainnet обраної мережі
• Навчання команди для управління платформою
• Технічна підтримка на 3 місяці