Розробка мультичейн-токена: архітектура, реалізація та безпека

Чому мультичейн-токен складніший, ніж здається?

Мультичейн-токен — це не просто деплой одного й того ж ERC-20 у кілька мереж. Це архітектурне рішення з серйозними наслідками для supply management, безпеки та UX. Ми бачимо, як багато команд потрапляють у пастку: неправильно спроєктований мультичейн-токен створює ілюзію єдиного активу при реально роздробленому supply, відкриває поверхню для bridge-атак (середній збиток від яких за останні роки перевищив $1,5 млрд, а згідно звіту SlowMist Hacked Report — вже $2,5 млрд) та ускладнює governance. Наша команда з 10+ роками досвіду в блокчейні та 20+ реалізованими мультичейн-проєктами допомагає уникнути цих пасток.

Яку архітектуру обрати?

Перш ніж писати код, потрібно обрати архітектурну модель. Їх три, і вони фундаментально різняться.

Lock & Mint (канонічна модель)

Токен існує нативно на одному чейні (home chain, зазвичай Ethereum). На всіх інших чейнах існують wrapped версії. Bridge блокує токени на home chain і минтить wrapped на destination chain. При бриджингу назад — burning wrapped, unlock оригіналу. Єдиний canonical supply і проста ментальна модель для користувачів — це плюс. Але якщо bridge зламано, зловмисник може минтити wrapped токени без забезпечення. Саме так сталося при найбільших bridge-атаках, що забрали мільярди доларів.

Burn & Mint (omnichain модель)

При трансфері токен спалюється на source chain і минтиться на destination chain. Total supply глобально постійний. Цей підхід використовують LayerZero OFT та Axelar ITS. Немає замороженої ліквідності на одному чейні, токени рівноцінні на всіх мережах. Мінус — транзакція не атомарна: токен знищено на source, але може не домінтитися на destination при збої. Потрібен механізм recovery, який ми обов'язково закладаємо в контракт.

Liquidity Pool модель

Незалежні токени на кожному чейні з'єднані через AMM-пули в bridge-протоколах (Stargate, Synapse). Bridge нативного свопу, не wrapped tokens. Миттєвість (атомарний своп з пулу), немає wrapped токенів, але потрібен bootstrap liquidity на кожному чейні та можливий slippage при незбалансованих пулах.

Реалізація на LayerZero OFT

LayerZero став де-факто стандартом для нових мультичейн-токенів. OFT — це burn & mint модель з messaging через LayerZero Endpoint. За нашими тестами, OFT у 2 рази безпечніший за Lock&Mint при тому ж рівні gas. У цьому розділі — повний код та конфігурація.

Базова реалізація OFT

// SPDX-License-Identifier: MIT pragma solidity ^0.8.22; import { OFT } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oft/OFT.sol"; import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol"; contract MyToken is OFT { constructor( string memory _name, string memory _symbol, address _lzEndpoint, // LayerZero Endpoint адреса для поточної мережі address _delegate ) OFT(_name, _symbol, _lzEndpoint, _delegate) Ownable(_delegate) {} function mint(address _to, uint256 _amount) external onlyOwner { _mint(_to, _amount); } } 

На home chain деплоїмо цей контракт і минтимо весь supply. На інших чейнах деплоїмо той самий контракт, але без початкового минтингу — токени туди приходять через bridge.

Конфігурація після деплою

Після деплою на всіх чейнах потрібно зв'язати контракти через setPeer:

function configurePeers() external onlyOwner { // eid = endpoint ID в системі LayerZero // Ethereum mainnet: 30101, Arbitrum: 30110, Base: 30184, BSC: 30102 oft.setPeer(30110, bytes32(uint256(uint160(ARBITRUM_OFT_ADDRESS)))); oft.setPeer(30184, bytes32(uint256(uint160(BASE_OFT_ADDRESS)))); } 

Відправка токенів між чейнами

function bridgeTokens( uint32 _dstEid, address _recipient, uint256 _amount ) external payable { SendParam memory sendParam = SendParam({ dstEid: _dstEid, to: bytes32(uint256(uint160(_recipient))), amountLD: _amount, minAmountLD: (_amount * 995) / 1000, // 0.5% slippage tolerance extraOptions: OptionsBuilder.newOptions() .addExecutorLzReceiveOption(200000, 0), // gas на destination composeMsg: "", oftCmd: "" }); MessagingFee memory fee = oft.quoteSend(sendParam, false); oft.send{ value: fee.nativeFee }(sendParam, fee, payable(msg.sender)); } 

Управління supply між чейнами

Це найскладніший аспект. Потрібен моніторинг:

Для Lock & Mint моделі (якщо використовуєте кастомний bridge) потрібен invariant check: sum(wrapped supplies) <= locked_on_home_chain. Моніторинг через Tenderly або власний скрипт з алертингом.

Безпека: DVN, rate limiting, pause

Налаштуйте 2 з N верифікаторів для підтвердження повідомлення. Мінімальна безпечна конфігурація:

UlnConfig memory ulnConfig = UlnConfig({ confirmations: 15, requiredDVNCount: 2, optionalDVNCount: 0, optionalDVNThreshold: 0, requiredDVNs: [LAYERZERO_DVN, GOOGLE_CLOUD_DVN], optionalDVNs: new address[](0) }); 

Для production ми використовуємо LayerZero DVN + один незалежний DVN (Google Cloud, Nethermind, p2p.org).

Навіть з надійним bridge — додайте rate limiting на рівні токен-контракту як останню лінію захисту:

mapping(uint256 => uint256) public dailyBridgeVolume; uint256 public constant MAX_DAILY_BRIDGE = 1_000_000e18; // 1M токенів/день modifier withRateLimit(uint256 amount) { uint256 today = block.timestamp / 1 days; require( dailyBridgeVolume[today] + amount <= MAX_DAILY_BRIDGE, "Daily bridge limit exceeded" ); dailyBridgeVolume[today] += amount; _; } 

Якщо bridge зламано — rate limit дасть час на реакцію, обмеживши збиток.

Контракт повинен мати pause функцію, керовану мультисигом з коротким timelock. При виявленні аномальної bridge-активності — миттєва зупинка передач. Ми гарантуємо, що всі контракти проходять аудит та stress-тестування.

Процес роботи від ідеї до деплою

1. Аналіз вимог: обираємо чейни, модель, tokenomics.
2. Проектування архітектури: смарт-контракти, bridge, governance.
3. Розробка: пишемо код, використовуємо Foundry/Hardhat, підключаємо LayerZero.
4. Тестування: unit-тести, fork-тести на всіх чейнах, fuzzing.
5. Аудит безпеки: внутрішній + зовнішній (2–3 фірми).
6. Деплой: послідовний деплой, верифікація, налаштування моніторингу.

Що входить у розробку мультичейн-токена?

• Повний код смарт-контрактів (OFT або кастомний bridge).
• Скрипти деплою та конфігурації для всіх чейнів.
• Налаштування LayerZero Endpoint та DVN.
• Інтеграція rate limiting та pause.
• Технічна документація та інструкція з експлуатації.
• Підтримка після деплою (2 тижні інцидент-менеджменту).

Терміни та вартість

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

Типові помилки та як їх уникнути

• Неправильна модель: обирати Lock&Mint без оцінки ризиків bridge. Використовуйте безпечну альтернативу — OFT з DVN.
• Відсутність rate limiting: без нього збиток від bridge-атаки необмежений.
• Один верифікатор: покладатися тільки на LayerZero DVN. Додайте незалежний.
• Ігнорування gas на destination: не налаштований executorLzReceiveOption призводить до збоїв бриджингу.
• Немає моніторингу: bridge-потоки повинні відстежуватися в реальному часі.

Отримайте консультацію по вашому проєкту — наші інженери з 10+ річним досвідом допоможуть обрати оптимальну архітектуру та уникнути типових помилок.