Разработка безопасного контракта миграции токенов под ключ — наша специализация. Мы разрабатываем контракты миграции токенов, в которых один баг может обнулить 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 стоил проекту 150 млн руб — это не гипотеза, а реальная статистика. 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 день и предложим оптимальный паттерн. Закажите разработку контракта миграции уже сегодня.