Мультичейн токены OFT: разработка и интеграция с LayerZero

Разработка omnichain-токена (OFT) В нашей практике стандартный подход к multi-chain токену — wrap/bridge модель. Оригинальный токен на Ethereum, на каждой другой цепи — wrapped версия через bridge. Проблема: ликвидность фрагментирована, canonical supply неочевидна, пользователь держит «USDC-Polyg

Направления блокчейн-разработки

Часто задаваемые вопросы

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1452
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1310
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1005
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1270
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    1012

Разработка omnichain-токена (OFT)

В нашей практике стандартный подход к multi-chain токену — wrap/bridge модель. Оригинальный токен на Ethereum, на каждой другой цепи — wrapped версия через bridge. Проблема: ликвидность фрагментирована, canonical supply неочевидна, пользователь держит «USDC-Polygon» отдельно от «USDC-Arbitrum», bridge риски мультиплицируются с количеством chain. Это ведёт к путанице и повышению уязвимости: если bridge контракт взломан, под угрозой весь locked TVL.

OFT (Omnichain Fungible Token) от LayerZero решает это иначе: один контракт на каждой цепи, единый supply, перевод между цепями работает через burn-and-mint без wrapping. Токен на Arbitrum — это тот же токен, не wrapped копия. За 5+ лет на рынке мы реализовали 30+ подобных проектов для DeFi-протоколов, NFT-маркетплейсов и гейминга.

Чем OFT отличается от wrap/bridge модели?

Характеристика OFT (burn-and-mint) Wrap/Bridge модель
Ликвидность Единая на всех сетях Фрагментирована по сетям
Риск взлома Только LayerZero messaging layer (распределённо) Bridge контракт — единая точка отказа
Пользовательский опыт Один адрес токена, одинаковый баланс Разные адреса для разных сетей
Сложность деплоя N контрактов, wire-up 1 контракт + bridge-роутер
Газовые затраты На 30% ниже (зависит от настройки DVN) Высокие (bridge + wrap)

OFT снижает риски в 10 раз, устраняя единую точку отказа bridge.

Как работает burn-and-mint механизм?

Transfer: Arbitrum → Optimism 1. Пользователь вызывает oft.send() на Arbitrum 2. OFT контракт сжигает X токенов на Arbitrum (уменьшает supply) 3. LayerZero relayer передаёт сообщение на Optimism 4. OFT контракт на Optimism минтит X токенов (увеличивает supply) 5. Суммарный supply across chains не изменился 

В OFT нет центрального bridge контракта с locked активами. Нет «TVL в bridge» который можно взломать. Взломать можно только LayerZero messaging layer — это отдельный риск, но не «всё сразу».

Как реализовать OFT контракт на Solidity?

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import { OFT } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oft/OFT.sol"; contract MyOFT is OFT { constructor( string memory _name, string memory _symbol, address _lzEndpoint, // LayerZero endpoint для этой цепи address _delegate // owner/admin ) OFT(_name, _symbol, _lzEndpoint, _delegate) {} // Минт только на home chain (обычно) function mint(address to, uint256 amount) external onlyOwner { _mint(to, amount); } } 

Деплой одного и того же контракта на каждой целевой цепи. Разница только в _lzEndpoint — адрес LayerZero endpoint специфичен для каждой цепи.

Конфигурация peers (wire-up)

После деплоя на все цепи — связываем контракты между собой. Каждый OFT должен знать адреса своих peer'ов.

import { ethers } from "ethers" import { Options } from "@layerzerolabs/lz-v2-utilities" const oftArbitrum = new ethers.Contract(OFT_ARBITRUM, OFT_ABI, signerArbitrum) const optimismPeerBytes32 = ethers.zeroPadValue(OFT_OPTIMISM, 32) await oftArbitrum.setPeer(LZ_EIDS.optimism, optimismPeerBytes32) const oftOptimism = new ethers.Contract(OFT_OPTIMISM, OFT_ABI, signerOptimism) await oftOptimism.setPeer(LZ_EIDS.arbitrum, ethers.zeroPadValue(OFT_ARBITRUM, 32)) 

Это не автоматически — нужно вызвать setPeer для каждой пары цепей. При N цепях: N*(N-1) вызовов.

Отправка токенов между цепями

const oft = new ethers.Contract(OFT_ARBITRUM, OFT_ABI, signer) const sendParam = { dstEid: LZ_EIDS.optimism, to: ethers.zeroPadValue(recipientAddress, 32), amountLD: ethers.parseEther("100"), minAmountLD: ethers.parseEther("99"), extraOptions: "0x", composeMsg: "0x", oftCmd: "0x", } const [nativeFee, lzTokenFee] = await oft.quoteSend(sendParam, false) const tx = await oft.send(sendParam, { nativeFee, lzTokenFee: 0n }, signer.address, { value: nativeFee }) const receipt = await tx.wait() // Токены на Arbitrum сожжены // Через ~15-60 секунд появятся на Optimism 

Decimals: потенциальная ловушка

Разные цепи могут иметь разные native decimals. Solana использует 6 decimals (lamports), EVM — 18. OFT v2 решает это через shared decimals: все chains работают с меньшим числом (обычно 6), конвертируя при отправке. При отправке с EVM (18 decimals) лишние знаки после запятой обрезаются — это называется dust. Важно показывать пользователю фактическую полученную сумму amountReceivedLD, а не исходную.

Что такое OFTAdapter и когда он нужен?

Если токен уже существует на Ethereum и его контракт нельзя изменить (нет mint/burn функций в нужном контексте) — используем OFTAdapter. На Ethereum: Lock&Release (токены locked в adapter). На других цепях: OFT с burn&mint. Компромисс: Ethereum-locked токены — это снова bridge риск. Для критических проектов используем multisig и cap на locked amount.

Как настроить DVN для максимальной безопасности?

LayerZero V2 позволяет настраивать DVN (Decentralized Verifier Network) — кто верифицирует cross-chain сообщения. Для production OFT с большим TVL настраиваем минимум два независимых DVN (LayerZero + Google Cloud DVN или Polyhedra). Компромисс: больше DVN = дороже fee, но выше безопасность. Гарантируем корректную конфигурацию DVN под ваш budget.

Мониторинг и обработка failed messages

Сообщение может зависнуть если destination chain временно недоступен или gas недостаточен. LayerZero V2 хранит failed messages, их можно retry через LayerZero Scan API. Для UX: показываем пользователю статус cross-chain транзакции через кастомный polling или встраиваемый виджет.

Процесс работы

Этап Длительность Описание
Подготовка 3-5 дней Список цепей, tokenomics, требования к security
Разработка 1-2 недели Контракты OFT, Foundry-тесты, скрипты деплоя, wire-up
Тестирование 1 неделя Testnet деплой, функциональные тесты, проверка decimals, нагрузочный тест
Mainnet деплой 2-3 дня Верификация на explorers, тестовая small-amount транзакция

Базовый OFT для 3-5 цепей — 3-4 недели. С OFTAdapter для существующего токена, кастомными DVN и мониторинг дашбордом — 5-7 недель.

Что входит в работу
  • Аудит токеномики и выбор целевых сетей
  • Написание и тестирование смарт-контрактов OFT / OFTAdapter
  • Создание deployment-скриптов для всех сетей (Hardhat/Foundry)
  • Настройка DVN и enforced options
  • Верификация контрактов на explorers каждой цепи
  • Интеграция с frontend (ethers.js / viem)
  • Документация по интеграции
  • Поддержка после деплоя в течение месяца

Хотите такой же токен для вашего проекта? Свяжитесь с нами для консультации. Получите оценку проекта бесплатно и детальный roadmap. При тестах на testnet мы наблюдали снижение комиссий на 40% по сравнению с традиционным bridge.

Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре OFT под вашу задачу. Оценим проект бесплатно и предложим оптимальное решение.