У вас есть смарт-контракт на 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 рекомендует проверять параметры перед загрузкой. Получите консультацию — мы подготовим контракт к верификации и пройдёте проверку с первого раза. Закажите верификацию под ключ, пишите — поможем.