Разработка контракта миграции токенов

Разработка контракта миграции токенов

Миграция токенов — это один из тех процессов, где один баг может стоить всего TVL проекта. Сожгли старый токен, новый не выдали. Или выдали дважды. Или выдали правильно, но событие не эмитировалось и frontend показывает неверное состояние. Случаи реальные, не гипотетические.

Поводов для миграции несколько: ребрендинг (новый тикер/имя), технический апгрейд (добавление функциональности), смена чейна, исправление критической уязвимости в старом токене, изменение токеномики.

Паттерны миграции

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, подходит для аирдроп-миграций.

Ключевые параметры безопасности

Лимиты на контракте. Максимальный объём миграции за один вызов, дневной лимит, общий лимит на всё время миграции. Это ограничивает ущерб от единственной ошибки.

Дедлайн миграции. Миграция должна заканчиваться. Непогашенные старые токены после дедлайна — это нормально (их держатели сделали выбор). Бессрочная миграция создаёт вечную нагрузку на поддержку.

Верификация соотношения. Если конверсия не 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, если он не отозван). Убеждаемся, что только владелец токенов может инициировать миграцию.

Процесс

Разработка контракта с тестами: 1.5-2 дня. Деплой на mainnet через multisig + timelock: +1 день. Опционально — dashboard для мониторинга прогресса миграции (% мигрированных токенов, адреса-лидеры, временной анализ): +1-2 дня.

Перед деплоем обязателен audit миграционного контракта — даже если это небольшой контракт. Именно «небольшие и простые» контракты исторически содержат самые дорогостоящие баги.