Розробка UI для безпечної міграції токенів v1 → v2

Розробка UI для безпечної міграції токенів v1 → v2 Типова ситуація: користувач отримує сповіщення «мігруйте ваші токени», переходить за посиланням — і бачить єдину кнопку «Migrate». Натискає, підписує апрув на `uint256.max`, не розуміючи, що контракт може списати всі його баланси. Результат — втр

Напрямки блокчейн-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1450
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1308
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1003
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1269
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    717
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1008

Розробка UI для безпечної міграції токенів v1 → v2

Типова ситуація: користувач отримує сповіщення «мігруйте ваші токени», переходить за посиланням — і бачить єдину кнопку «Migrate». Натискає, підписує апрув на uint256.max, не розуміючи, що контракт може списати всі його баланси. Результат — втрата коштів або фішинг. Наше завдання: побудувати інтерфейс, який розкриває кожну деталь транзакції та не дає діяти наосліп. UI з попереднім переглядом балансу втричі знижує ризик помилок порівняно з інтерфейсом без попереднього перегляду.

Чому міграція токенів вимагає окремого UI?

На відміну від звичайної передачі токенів, міграція вимагає підписання апрува на контракт, якому користувач може не довіряти повністю. Якщо UI не показує явно allowance та курс, ризик фішингу та помилок зростає. Ми гарантуємо, що ваш інтерфейс розкриває всі деталі транзакції, а клієнт завжди може звірити дані з контрактом. Прозорість — запорука довіри: ви бачите exact суму апрува, курс конвертації та комісію мережі ще до підписання.

Як ми будуємо інтерфейс міграції?

Стандартна схема: старий токен (v1) → новий токен (v2) через контракт-мігратор. Контракт приймає v1, спалює або блокує його, мінтить v2 у співвідношенні 1:1 (або іншому).

UI має покрити три транзакції:

  1. approve(migratorContract, amount) на v1 токені
  2. migrate(amount) на контракті-мігратор
  3. (опціонально) додати v2 у MetaMask через wallet_watchAsset
async function migrateTokens(amount: bigint) { // Шаг 1: проверяем текущий allowance const currentAllowance = await v1Token.allowance(userAddress, MIGRATOR_ADDRESS); if (currentAllowance < amount) { const approveTx = await v1Token.approve(MIGRATOR_ADDRESS, amount); await approveTx.wait(); } // Шаг 2: миграция const migrateTx = await migrator.migrate(amount); const receipt = await migrateTx.wait(); return receipt; } 

Що показує баланс-дисплей до/після?

Показуємо користувачу явно, що відбудеться: скільки v1 спишеться, скільки v2 отримається. Якщо курс не 1:1 — це особливо важливо. Дисплей динамічно оновлюється при введенні суми, щоб користувач бачив точні цифри до підписання.

function MigrationPreview({ amount, exchangeRate }: Props) { const v2Amount = (BigInt(amount) * BigInt(exchangeRate * 100)) / 100n; return ( <div className="migration-preview"> <div className="from"> <span>Отдаёте: {formatEther(amount)} {V1_SYMBOL}</span> </div> <ArrowIcon /> <div className="to"> <span>Получаете: {formatEther(v2Amount)} {V2_SYMBOL}</span> </div> </div> ); } 

Stepper зі станами транзакцій

Кожен крок — approve, migrate, done — відображається з явним статусом: очікування, pending, confirmed, error. Користувач ніколи не гадає, на якому етапі процес.

type MigrationStep = 'idle' | 'approving' | 'approved' | 'migrating' | 'done' | 'error'; const stepConfig = { idle: { label: 'Готов к миграции', icon: 'clock' }, approving: { label: 'Подтверждаем апрув...', icon: 'spinner' }, approved: { label: 'Апрув подтверждён', icon: 'check' }, migrating: { label: 'Мигрируем токены...', icon: 'spinner' }, done: { label: 'Миграция завершена', icon: 'check-circle' }, error: { label: 'Ошибка', icon: 'x-circle' }, }; 

Посилання на Etherscan для кожної транзакції, щойно отримано txHash — не чекаємо підтвердження. Це дозволяє користувачу самостійно відстежувати статус.

Як захистити користувача від infinite approve?

Якщо контракт запитує type(uint256).max approve — явно повідомити користувача. Запропонувати вибір: exact amount або unlimited. Для міграції правильніше exact amount — користувач мігрує конкретну кількість. Вибір не має бути прихований у налаштуваннях: ми виводимо попередження з поясненням ризиків прямо перед підписанням.

Параметр Exact amount Unlimited (max)
Безпека Висока — лише запитана сума Низька — контракт може списати все
Зручність Потрібен повторний апрув для другої міграції Один апрув назавжди
Рекомендація ✅ Для міграції ❌ Уникати

Як обробляються помилки та крайні випадки?

Часткова міграція: користувач мігрував частину токенів, повернувся пізніше. Показуємо поточні баланси v1 і v2, залишок для міграції. UI автоматично визначає, скільки вже мігровано, і не пропонує повторно апрувити.

Дедлайн міграції: контракти-мігратор часто мають deadline після якого міграція неможлива. Якщо дедлайн заданий — показуємо countdown, попереджаємо заздалегідь (за 7 днів, 24 години). Після дедлайну кнопка міграції блокується, виводиться пояснення.

Revert причини: якщо транзакція reverted — намагаємося декодувати причину через parseRevertReason і показати зрозуміле повідомлення замість «Transaction failed». Ми обробляємо понад 10 типів помилок, включаючи 'Migration ended', 'Insufficient balance', 'user rejected'. Це знижує кількість звернень у підтримку та прискорює вирішення проблем.

function parseRevertReason(error: any): string { const message = error?.info?.error?.message || error?.message || ''; if (message.includes('Migration ended')) return 'Період міграції завершено'; if (message.includes('Insufficient balance')) return 'Недостатньо токенів'; if (message.includes('user rejected')) return 'Транзакцію скасовано користувачем'; return 'Невідома помилка. Спробуйте пізніше.'; } 

Що робити, якщо користувач помилився в апруві?

Якщо користувач підписав апрув на суму більше необхідної, UI має негайно відобразити попередження та запропонувати відкликати зайвий allowance через approve(0). Ми реалізуємо кнопку «Reset allowance» прямо в інтерфейсі, щоб мінімізувати ризик.

Покрокова інструкція для користувача

  1. Підключіть гаманець (MetaMask, WalletConnect).
  2. Введіть кількість токенів для міграції.
  3. Підтвердьте апрув на потрібну суму.
  4. Підтвердьте міграцію.
  5. Додайте новий токен у гаманець (автоматично).

Етапи розробки та терміни

Етап Тривалість Результат
Аналітика 0.5–1 день Документ із логікою контракту та сценаріями
Проектування 0.5–1 день Wireframe stepper, поведінка помилок, тексти
Реалізація 1–2 дні Код на React/Next.js, ethers.js або viem
Тестування 0.5–1 день Симуляція всіх сценаріїв на testnet
Деплой 0.5 дня Production, моніторинг транзакцій

Повний UI міграції з stepper, балансами, транзакціями та обробкою помилок — від 2 до 5 днів. Термін залежить від складності контракту та необхідності кастомної логіки. Вартість розраховується індивідуально.

Що входить в роботу під ключ

  • Інтеграція контракту-мігратора (ERC-20, ERC-1155, будь-які кастомні) з використанням ERC-20 стандарту.
  • Компоненти approve/migrate з попереднім переглядом балансів.
  • Stepper транзакцій з Etherscan-посиланнями.
  • Обробка edge cases: часткова міграція, дедлайн, реверти.
  • Додавання нового токена в гаманець (wallet_watchAsset).
  • Тестування на testnet (Goerli, Sepolia).
  • Документація щодо запуску та підтримки.

Замовте консультацію — ми оцінимо ваш проект за один робочий день. Наша команда має 10+ років досвіду в розробці смарт-контрактів та Web3-інтерфейсів. Отримайте консультацію інженера прямо зараз, щоб обговорити інтеграцію.