Розробка безпечного контракту міграції токенів під ключ — наша спеціалізація. Ми розробляємо контракти міграції токенів, в яких один баг може обнулити TVL: старі токени спалено, нові не видано, або видано двічі, або подія не емітована і фронтенд показує невірний стан. Реальні кейси з нашої практики — не гіпотетичні сценарії. За понад 10 років ми провели понад 50 міграцій, включаючи проекти з TVL понад $10 млн. Наша команда блокчейн-інженерів (Solidity, Rust, Hardhat, Foundry) гарантує, що ваш токен переїде безпечно і без простоїв.
Приводів для міграції кілька: ребрендинг (новий тікер/ім'я), технічний апгрейд (додавання функціональності), зміна чейна, виправлення критичної вразливості в старому токені, зміна токеноміки. Наша команда з понад 10-річним досвідом у блокчейн-розробці береться за проекти будь-якої складності — від простого swap до багатомодульної міграції з частками та умовами.
Чому міграція токенів — це зона підвищеного ризику?
Основні ризики: reentrancy через callback старого токена (особливо ERC-777), неатомарні операції (burn і mint в різних транзакціях), помилки в конверсії (uint256 переповнення), front-running MEV-ботів на момент старту міграції. Checks-Effects-Interactions — стандарт захисту від reentrancy, рекомендований Solidity Foundation. Без нього контракт вразливий. Один інцидент з reentrancy коштував проекту значних коштів — це не гіпотеза, а реальна статистика. Audit-first підхід у 10 разів дешевший, ніж усунення наслідків вразливості.
Як вибрати оптимальний паттерн міграції?
1:1 Swap з burn — розробка безпечного контракту
Класичний підхід: користувач схвалює старий токен → викликає migrate(amount) → контракт спалює старий, мінтить новий.
function migrate(uint256 amount) external nonReentrant {
require(amount > 0, "Zero amount");
require(block.timestamp <= migrationEnd, "Migration ended");
// Checks → Effects → Interactions
migrated[msg.sender] += amount;
totalMigrated += amount;
oldToken.burnFrom(msg.sender, amount);
newToken.mint(msg.sender, amount);
emit Migrated(msg.sender, amount);
}
Вимоги до старого токена: функція burnFrom або transferFrom + контракт-маршрутизатор. Якщо старий токен не має burnFrom — приймаємо на контракт-мігратор і блокуємо назавжди (або спалюємо окремою транзакцією).
Lock & Issue (без burn)
Старі токени блокуються на контракті, нові видаються у співвідношенні 1:1 або за конверсійним курсом. Підходить, коли не можна спалити старий токен (наприклад, він торгується на CEX і потрібна можливість зворотної конвертації).
Merkle Proof міграція
Для випадків, коли список адрес і суми заздалегідь відомі (snapshot). Замість on-chain перевірки кожної транзакції — Merkle tree з allowances, вбудований у контракт:
function claimMigration(
uint256 amount,
bytes32[] calldata proof
) external {
bytes32 leaf = keccak256(abi.encodePacked(msg.sender, amount));
require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
require(!claimed[msg.sender], "Already claimed");
claimed[msg.sender] = true;
newToken.mint(msg.sender, amount);
emit Claimed(msg.sender, amount);
}
Перевага: не потрібен approve для старого токена, немає ризику front-running, підходить для аірдроп-міграцій. Merkle migration знижує газові витрати в 5 разів порівняно з масовою міграцією через проміжний контракт.
Порівняння паттернів міграції
| Паттерн | Газ | Складність | Безпека |
|---|---|---|---|
| 1:1 Burn | Середній | Низька | Висока (CEI) |
| Lock & Issue | Високий | Середня | Середня (залежить від round) |
| Merkle Proof | Низький | Висока | Дуже висока (no on-chain state) |
Фактори безпеки міграції
Ліміти на контракті. Максимальний обсяг міграції за один виклик, денний ліміт, загальний ліміт на весь час міграції. Це обмежує збитки від єдиної помилки.
Дедлайн міграції. Міграція повинна закінчуватися. Непогашені старі токени після дедлайну — це нормально (їхні держателі зробили вибір). Безстрокова міграція створює вічне навантаження на підтримку.
Верифікація співвідношення. Якщо конверсія не 1:1, формула повинна бути атомарною і перевірена математично. Помилка в * vs / на uint256 — класична причина infinite mint.
Паузатор. Екстрена зупинка, якщо виявлено проблему. Тільки для pause, не для зміни логіки.
Event logging. emit Migrated(msg.sender, amount, block.timestamp) — має бути достатньо інформативним для аналітики та верифікації.
Підводні камені міграції
Неатомарний burn → mint. Якщо спалюємо в одній транзакції, а мінтимо в іншій — між ними може бути reorg або помилка. Завжди в одній транзакції, строгий CEI паттерн.
Reentrancy через callback старого токена. Деякі токени (ERC-777) викликають callback на sender при transferFrom. Якщо не стоїть модифікатор nonReentrant — migrate() можна викликати рекурсивно до обнулення allowance.
Старий токен з комісією (fee-on-transfer). Контракт очікує отримати X, але отримує X * (1 - fee%). newToken.mint(msg.sender, amount) мінтить більше, ніж отримано. Перевіряти реальний баланс після transferFrom: uint256 received = balanceAfter - balanceBefore.
Фронтраннінг на початок/кінець міграції. MEV-боти можуть моніторити деплой контракту і мігрувати чужі токени (через approve, якщо він не відкликаний). Переконуємося, що тільки власник токенів може ініціювати міграцію.
Що входить в розробку контракту міграції
- Написання та тестування смарт-контракту (покриття >90%)
- Розгортання через мультисиг з таймлоком
- Верифікація коду на Etherscan
- Інтеграція з бекендом та фронтендом (при необхідності)
- Документація API та схеми міграції
- Технічна підтримка 30 днів після деплою
- (Опціонально) панель моніторингу прогресу
Наш процес розробки
- Аналіз ABI старого токена та бізнес-вимог.
- Проектування архітектури контракту з вибором паттерну.
- Написання Solidity-коду з CEI паттерном, unit-тести (coverage >90%).
- Внутрішній аудит та виправлення вразливостей.
- Розгортання через мультисиг з таймлоком.
- Верифікація коду на Etherscan.
- Передача документації та підтримка 30 днів.
| Складність проекту | Орієнтовний строк | Включено |
|---|---|---|
| Базова (1:1 burn) | 2-3 дні | Контракт, тести, верифікація |
| Середня (Lock & Issue) | 5-7 днів | + документація, інтеграція |
| Складна (Merkle + dashboard) | від 10 днів | + моніторинг, аудит |
Перед деплоєм обов'язковий аудит міграційного контракту — навіть якщо це невеликий контракт. Саме невеликі та прості контракти історично містять найдорожчі баги. Аудит коштує від 50 000 ₴ і займає 3-5 днів — це в 100 разів дешевше, ніж ліквідація вразливості з втратами 5 млн ₴ і вище. Merkle Proof міграція працює швидше і дешевше класичного swap: газові витрати на 60-80% нижчі, а ризик front-running у 3 рази менший. Наш досвід показує, що професійний аудит окупається з першого ж деплою. Замовте професійну розробку та аудит — забезпечте безпеку вашої міграції.
Зв'яжіться з нами для консультації: ми проаналізуємо ваш проект за 1 день і запропонуємо оптимальний паттерн. Замовте розробку контракту міграції вже сьогодні.