Створюємо токени BEP-20 на BSC: від ідеї до верифікації на BscScan

Розробка BEP-20 токена (BNB Chain)

Уявіть: замовник каже «потрібен простий BEP-20 токен, як у всіх». Через тиждень з'ясовується, що потрібен мінт з ролями, берн, snapshots для airdrop та gasless approvals через ERC20Permit. І все це має працювати на BSC з комісією $0.01 за транзакцію. Ми стикалися з такою ситуацією десятки разів — і щоразу рятував грамотний контракт з оптимізацією газу.

Розберемо на прикладі реального контракту, як реалізувати всі ці фічі на Solidity 0.8.x, не наступивши на граблі верифікації та безпеки. BEP-20 на BSC в 4 рази швидше ERC-20 на Ethereum (3 сек проти 12 сек) і в 100 разів дешевше ($0.01 проти $1-50) — але тільки якщо контракт написаний правильно.

Чому BEP-20, а не ERC-20?

BEP-20 — це BNB Chain версія ERC-20. Інтерфейс ідентичний, ABI сумісний, tooling той же — Hardhat або Foundry з невеликими змінами в конфігу мережі. Якщо ви вже розробляли ERC-20 токени — BEP-20 займе мінімум часу на адаптацію. Принципова відмінність: BNB Smart Chain (BSC) використовує Proof of Staked Authority (PoSA) з 21 валідатором замість тисяч нод Ethereum. Це дає швидкі блоки (3 секунди) і дешеві транзакції ($0.01–0.05 за звичайний transfer), але ціною більш централізованої мережі.

Які функції реально потрібні вашому токену?

Базовий токен — 30 рядків поверх OpenZeppelin ERC20. Питання не в тому «як написати токен», а «яка функціональність потрібна вашому проекту». Типовий список:

• Мінтинг і берн — керована емісія через AccessControl
• Gasless approvals — ERC20Permit (EIP-2612) для UX
• Голосування — ERC20Votes для governance
• Snapshots — блокування балансу для airdrop
• Anti-whale — обмеження на максимальний обсяг транзакції

Ось приклад контракту, що об'єднує кілька розширень:

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/access/AccessControl.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol"; contract MyBEP20Token is ERC20, AccessControl, ERC20Permit, ERC20Votes { bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE"); uint256 public constant MAX_SUPPLY = 1_000_000_000 * 10**18; // 1B токенів constructor(address initialAdmin) ERC20("MyToken", "MTK") ERC20Permit("MyToken") { _grantRole(DEFAULT_ADMIN_ROLE, initialAdmin); _grantRole(MINTER_ROLE, initialAdmin); } function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) { require(totalSupply() + amount <= MAX_SUPPLY, "Exceeds max supply"); _mint(to, amount); } function burn(uint256 amount) external { _burn(msg.sender, amount); } function _afterTokenTransfer(address from, address to, uint256 amount) internal override(ERC20, ERC20Votes) { super._afterTokenTransfer(from, to, amount); } function _mint(address to, uint256 amount) internal override(ERC20, ERC20Votes) { super._mint(to, amount); } function _burn(address account, uint256 amount) internal override(ERC20, ERC20Votes) { super._burn(account, amount); } } 

Додаткові розширення можна комбінувати. У таблиці нижче — найбільш популярні:

Що входить в роботу (deliverables)

Після завершення ви отримуєте:

• Вихідний код смарт-контракту з коментарями
• Результати аудиту (звіт Slither, Mythril, Echidna)
• Документацію для користувачів та розробників
• Доступи до мультисиг-гаманця для управління ролями
• Інструкцію по взаємодії через ethers.js / viem
• Підтримку після деплою (1 місяць консультацій)

Процес розробки та гарантії

Ми використовуємо формальну верифікацію з контрактами OpenZeppelin, покриття тестами >95% для ключових функцій, статичний аналіз Slither та fuzzing Echidna. Це мінімізує ризики reentrancy, переповнення та інших вразливостей. Досвід команди — багаторічний досвід в блокчейн-розробці, понад 20 успішних проектів, включаючи токени з рефлексіями та стейкінг-пулами.

Етапи розгортання

1. Аналітика — узгодження функціоналу, вибір стеку (версія Solidity, розширення).
2. Розробка — пишемо контракт з урахуванням газ-оптимізації та безпеки.
3. Тестування — unit-тести + інтеграційне тестування на testnet.
4. Аудит — перевірка Slither, Mythril, Echidna. Виправлення багів.
5. Деплой — на testnet, потім mainnet з мультисигом.
6. Верифікація — відкритий вихідний код на BscScan.
7. Документація — опис функцій та інтерфейсів для користувачів.

Строки: від 3 до 5 робочих днів для стандартного токена без екзотичної логіки. Зв'яжіться з нами — ми оцінимо ваш проект за один день.

Типові помилки новачків

Багато хто забуває використовувати AccessControl, і тоді мінт доступний будь-кому. Часто упускають ERC20Permit — користувачі змушені платити газ за кожен аппрув. Іноді контракт не верифікують на BscScan, через що токен виглядає підозріло. Деякі не обмежують max supply — інфляція вбиває ціну. І нарешті, зустрічається використання transfer замість safeTransfer у сторонніх контрактах, що веде до втрат.

Уникнувши цих грабель, ви заощадите час та гроші. В одному проекті оптимізація газу скоротила витрати на комісії на $3000 на місяць. Ми стандартизували процес — кожен токен проходить через однаковий набір перевірок. Замовте розробку — отримайте готовий контракт з повною документацією.

Бібліотека OpenZeppelin: https://github.com/OpenZeppelin/openzeppelin-contracts