ERC-20 — це інтерфейс, не реалізація. Шість обов'язкових функцій (totalSupply, balanceOf, transfer, transferFrom, approve, allowance) та дві події (Transfer, Approval). Все інше — деталі реалізації, які мають значення. Наш досвід — понад 50 запущених у продакшн ERC-20 токенів — показує, що саме ці деталі визначають, чи буде токен сумісний з DeFi-протоколами, чи його доведеться переписувати.
Який підхід до розробки ERC-20 токена обрати?
Перша дилема — апгрейдуємий (Proxy + Implementation) чи immutable. Proxy дає гнучкість у змінах, але кожна транзакція через delegatecall коштує близько 150 000 gas замість 45 000 для звичайного контракту. Immutable контракти втричі дешевші для користувачів і простіші в аудиті. Рекомендація: для utility токенів та governance — immutable, для DeFi vaults і складних протоколів — upgradeable з обережністю.
Друга проблема — контроль емісії. Якщо minter — EOA, це централізований ризик: ключ витече або власник надрукує необмежену кількість. Рішення — використовувати multisig або смарт-контракт з роллю MINTER. Наші проєкти завжди використовують AccessControl для розподіленого управління.
Третя — gas оптимізація. Невживання ERC20Permit (EIP-2612) змушує користувача витрачати дві транзакції замість однієї для першої взаємодії з DeFi.
Чому варто використовувати OpenZeppelin, а не писати з нуля?
OpenZeppelin — стандарт індустрії. Їх код пройшов сотні аудитів, використовується в мільйонах контрактів. Не пишіть ERC-20 з нуля — це збільшує ризик помилок і знижує довіру інтеграторів. Наші рішення базуються на OpenZeppelin з додатковими кастомними модулями.
Базова реалізація
// SPDX-License-Identifier: MIT pragma solidity ^0.8.24; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol"; import "@openzeppelin/contracts/access/Ownable2Step.sol"; contract MyToken is ERC20, ERC20Burnable, ERC20Permit, Ownable2Step { uint256 public constant MAX_SUPPLY = 100_000_000 * 10**18; // 100M токенів constructor( address initialOwner, address treasury ) ERC20("My Token", "MTK") ERC20Permit("My Token") Ownable2Step() { _transferOwnership(initialOwner); _mint(treasury, MAX_SUPPLY); // весь supply при деплої } } ERC20Permit — важливе розширення: дозволяє approve за допомогою off-chain підпису. Це покращує UX (одна транзакція замість двох) і знижує газ для користувача. Ownable2Step замість Ownable захищає від випадкової передачі контролю на неправильну адресу.
Mintable токен з контролем доступу
Якщо токен повинен випускатися після деплою, використовуємо AccessControl:
import "@openzeppelin/contracts/access/AccessControl.sol"; contract MintableToken is ERC20, ERC20Burnable, ERC20Permit, AccessControl { bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE"); uint256 public immutable maxSupply; constructor( string memory name, string memory symbol, uint256 _maxSupply, address admin ) ERC20(name, symbol) ERC20Permit(name) { maxSupply = _maxSupply; _grantRole(DEFAULT_ADMIN_ROLE, admin); _grantRole(MINTER_ROLE, admin); } function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) { require(totalSupply() + amount <= maxSupply, "Exceeds max supply"); _mint(to, amount); } } MINTER_ROLE повинен бути призначений смарт-контракту (staking reward, vesting), а не EOA.
Порівняння підходів
| Критерій | Immutable контракт | Upgradeable proxy |
|---|---|---|
| Газ (транзакція) | ~45 000 gas | ~150 000 gas (через delegatecall) |
| Гнучкість | Немає змін | Можна оновлювати логіку |
| Ризик | Тільки логічні помилки | Помилки в proxy, storage collision |
| Аудит | Простіше | Складніше (два контракти) |
| Рекомендація | Utility, governance | DeFi vaults, складні протоколи |
Чому decimals повинні бути 18 (зазвичай)
За замовчуванням decimals = 18 (як ETH). Виняток: USDC/USDT використовують 6. Якщо створюєте stablecoin або wrap — перевірте decimals оригіналу. Ніколи не використовуйте 0 decimals для токенів, які будуть торгуватися на DEX — AMM погано працює з цілими числами. Ми стикалися з проєктами, де неправильний decimals призводив до помилок сумісності з протоколами.
Поширені помилки
Transfer tax: кожен transfer бере відсоток — ламає DeFi протоколи. Якщо все ж потрібен, використовуйте whitelist для контрактів Uniswap, Aave, Compound. Centralised blacklist без timelock: для community токена — погано. Reentrancy в transfer hooks: якщо додаєте _beforeTokenTransfer або _afterTokenTransfer, переконайтеся, що не викликаєте зовнішній код.
Етапи роботи
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика | 1-2 дні | Специфікація токена, вибір архітектури |
| Реалізація | 2-5 днів | Смарт-контракт, тести, скрипти деплою |
| Аудит | 1-3 тижні | Звіт про вразливості, виправлення |
| Деплой та верифікація | 1 день | Контракт у ланцюзі, перевірений на Etherscan |
| Підтримка | 1 місяць | Безкоштовні правки після запуску |
Верифікація та деплой
# Тести forge test -vvv # Деплой з верифікацією forge script script/Deploy.s.sol \ --rpc-url $RPC_URL \ --private-key $PRIVATE_KEY \ --broadcast \ --verify \ --etherscan-api-key $ETHERSCAN_KEY Після деплою — верифікуйте контракт на Etherscan/Polygonscan. Неверифікований токен викликає законну підозру у бірж та користувачів.
Що входить в розробку ERC-20 токена під ключ
- Смарт-контракт на Solidity з кастомними функціями (mint, burn, permit, pause, blacklist)
- Модульні тести (Foundry/Hardhat) з покриттям >90%
- Скрипти деплою та налаштування під вашу мережу (Ethereum, Polygon, Arbitrum, BNB Chain)
- Верифікація на блокчейн-експлорері (Etherscan, Polygonscan)
- Документація для розробників та користувачів
- Консультація з інтеграції з DeFi-протоколами
- Гарантія — 1 місяць безкоштовних правок після запуску
Оцінимо ваш проєкт за 1 робочий день. Ми — команда senior-блокчейн-розробників: 5+ років на ринку, 50+ реалізованих токенів. Зв'яжіться з нами, щоб обговорити деталі та замовити розробку ERC-20 токена під ключ.