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

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

Мультичейн-токен — це не просто деплой одного й того ж 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+ річним досвідом допоможуть обрати оптимальну архітектуру та уникнути типових помилок.