Верифікація смарт-контрактів на BscScan

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Верифікація смарт-контрактів на BscScan
Простий
~2-3 години
Часті запитання

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

Етапи блокчейн-розробки

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

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

Верифікація смарт-контрактів на BscScan

Задеплоєний контракт без верифікованого вихідного коду — це байткод на блокчейні. BscScan показує транзакції, але не показує що саме робить функція. Користувачі не можуть прочитати логіку, аудитори працюють тільки з декомпільованим кодом, а інтеграції через Read/Write Contract недоступні. Верифікація перетворює байткод назад у читаний Solidity.

Чому верифікація іноді не проходить

Найчастіша причина провалу — невідповідність байткода. BscScan перекомпілює завантажений вихідник з указаними параметрами та порівнює з on-chain байткодом. Якщо версія компілятора інша, інші optimizer runs, або не збігаються evmVersion — результат не сходиться.

Флаттенінг контрактів з залежностями. Якщо контракт імпортує OpenZeppelin, потрібно або завантажити всі файли через Standard JSON Input, або сфлаттенити в один файл. При флаттенінгу через hardhat flatten іноді дублюються SPDX-License-Identifier та pragma solidity — це помилка компіляції. Потрібно залишити по одній директиві на початку файлу.

Immutable змінні. Змінні immutable записуються в байткод при розгортанні з конкретними значеннями. Верифікація через стандартну форму іноді не дозволяє правильно указати аргументи конструктора для immutable — Standard JSON Input надійніший.

Як верифікуємо

Три способи, від простого до надійного:

Через плагін Hardhat Verify. Одна команда після деплою:

npx hardhat verify --network bsc DEPLOYED_ADDRESS "arg1" "arg2"

Плагін автоматично визначає версію компілятора, optimizer settings з hardhat.config.ts та формує коректний запит до BscScan API. Працює для більшості випадків.

Standard JSON Input. Для складних проектів з множеством залежностей. Foundry генерує його командою forge verify-contract або можна отримати через hardhat compile --show-stack-traces. JSON містить усі вихідники, налаштування компілятора, metadata. Завантажується через BscScan UI на вкладці "Standard Json-Input".

API верифікація. Для CI/CD: POST-запит на https://api.bscscan.com/api з API-ключем. Використовується при автоматичному деплою — скрипт деплоїть та одразу верифікує. Foundry підтримує це нативно через --verify --etherscan-api-key.

Терміни

Верифікація одного контракту — 1-2 години. Якщо контракт уже задеплоєний та немає вихідників з точними параметрами компілятора — до кількох годин на відновлення конфігурації через аналіз байткода.