У вас є смарт-контракт на BSC, але BscScan показує тільки байткод? Інвестори не бачать логіку, аудитори відмовляються працювати без вихідників, а лістинг на біржі застряг. Верифікація вирішує це за годину. Ми перетворюємо байткод назад у читабельний Solidity, роблячи проєкт прозорим і доступним для взаємодії. Наш досвід: понад 50 контрактів на BSC, Ethereum та Polygon, 5 років допомагаємо проєктам проходити перевірки з першого разу.
Чому верифікація зривається навіть у досвідчених розробників?
Найчастіша причина провалу — неспівпадіння байткоду. BscScan перекомпілює завантажений вихідник із вказаними параметрами та порівнює з on-chain байткодом. Якщо компілятор іншої версії, інший optimizer runs або не співпадає evmVersion — результат не зійдеться. Ми гарантуємо точну відповідність параметрів завдяки детальному аналізу конфігурації деплою.
Флаттенінг контрактів із залежностями також створює проблеми. Якщо контракт імпортує OpenZeppelin, потрібно або завантажити всі файли через Standard JSON Input, або сфлаттенити в один файл. При флаттенінгу через hardhat flatten іноді дублюються SPDX-License-Identifier та pragma solidity — це викликає помилку компіляції. Рішення: залишити по одній директиві на початку файлу.
Immutable variables записуються в байткод при деплої з конкретними значеннями. Верифікація через стандартну форму іноді не дозволяє вказати аргументи конструктора коректно для immutable — Standard JSON Input надійніше.
Підготовка контракту до верифікації
Перший крок — отримати точні параметри компіляції, які були використані при деплої. Для цього можна прочитати метадані з байткоду через solc --metadata або використати Tenderly. Потім переконайтеся, що вихідний код сфлаттен правильно: не повинно бути дубльованих ліцензій та прагм. Якщо контракт використовує immutable, обов'язково вкажіть їх значення в конструкторі. При помилках завантажуйте вихідники через Standard JSON Input — він дає повний контроль над структурою.
Способи верифікації
| Метод | Складність | Коли використовувати |
|---|---|---|
| Hardhat Verify | Низька | Стандартні проєкти, один контракт |
| Standard JSON Input | Середня | Складні проєкти з залежностями |
| API верифікація | Висока | CI/CD, автоматичний деплой |
Типові помилки при верифікації
| Помилка | Причина | Рішення |
|---|---|---|
| Неспівпадіння байткоду | Невірні optimizer runs або evmVersion | Перевірити метадані деплою |
| Дублювання ліцензії | Флаттенінг з hardhat flatten | Видалити зайві SPDX-License-Identifier |
| Помилка компіляції pragma | Дві директиви pragma solidity | Залишити одну на початку файлу |
Як ми верифікуємо контракти
Ми використовуємо всі три методи залежно від завдання. Типовий процес виглядає так:
- Аналіз байткоду та конфігурації деплою (версія Solidity, optimizer, evmVersion).
- Підготовка вихідного коду: флаттенінг або збірка Standard JSON.
- Перевірка на локальній ноді: компіляція та порівняння байткоду.
- Завантаження в BscScan через обраний метод.
- Тестування Read/Write функцій — переконуємось, що все працює.
- Документація процесу для вашої команди.
Кейс: Нещодавно верифікували DeFi-протокол з 15 контрактами, що імпортують кілька версій OpenZeppelin. Hardhat Verify не впорався через конфлікт pragma. Ми підготували Standard JSON Input з явними посиланнями на кожен файл — верифікація пройшла з першого разу. Економія часу розробника склала не менше 4 годин на контракт, а вартість робіт варіюється від $250–1kів залежно від складності.
Що робити, якщо верифікація не проходить?
Аналізуйте помилку BscScan. Якщо він повідомляє про неспівпадіння байткоду, перевірте: версію компілятора, optimizer runs, evmVersion. Використовуйте локальну ноду для симуляції. Переконайтеся, що всі бібліотеки підключені коректно. Якщо контракт імпортує зовнішні пакети (наприклад, OpenZeppelin), використовуйте Standard JSON Input — це єдиний спосіб гарантувати точну структуру залежностей. При повторних помилках зв'яжіться з нами — ми допоможемо відновити конфігурацію.
Що входить в роботу під ключ
- Відновлення точних параметрів компіляції (optimizer runs, evmVersion).
- Флаттенінг або збірка Standard JSON Input.
- Завантаження верифікації в BscScan.
- Перевірка коректності через Read/Write Contract.
- Коротка документація по процесу.
- Підтримка при повторній верифікації після апгрейду.
Строки та вартість
Верифікація одного контракту — від 1 до 2 годин. Якщо контракт уже задеплоєно і немає вихідників з точними параметрами — до кількох годин на відновлення конфігурації через аналіз байткоду. Вартість розраховується індивідуально залежно від складності та обсягу робіт. BscScan documentation рекомендує перевіряти параметри перед завантаженням. Отримайте консультацію — ми підготуємо контракт до верифікації і пройдете перевірку з першого разу. Замовте верифікацію під ключ, пишіть — допоможемо.