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 documentation описывает это как ключевой механизм защиты от 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.