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

Разработка 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 снижает риски в 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 или встраиваемый виджет.

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

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

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

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

Разработка токенов: ERC-20, токеномика, вестинг

«ERC-20 — это просто» — фраза, после которой начинаются проблемы. Базовый transfer написать несложно. Но токен, у которого через шесть месяцев не происходит инфляционный коллапс, governance работает как задумано, а вестинг нельзя обойти через хитрую схему с делегированием — это уже проектирование.

ERC-20: что под капотом

Стандарт ERC-20 — девять функций. Сложность начинается с расширений:

ERC-20Permit (EIP-2612) — gasless approve через подпись. Пользователь подписывает permit(owner, spender, value, deadline, v, r, s) off-chain, spender вызывает permit() + transferFrom() в одной транзакции. Это убирает отдельный approve step. Но: подпись можно перехватить и использовать — нужен deadline и проверка nonce.

ERC-20Votes (EIP-5805) — snapshot балансов для governance. Checkpoint-система хранит историю балансов по номеру блока. getPastVotes(address, blockNumber) — баланс на момент создания proposal, а не текущий. Это предотвращает flash loan governance attack: нельзя занять токены и проголосовать ими в одной транзакции.

Rebasing токены (stETH, Ampleforth) — balanceOf меняется автоматически через изменение internal shares ratio. Высокая сложность интеграции: большинство DeFi протоколов не работают корректно с rebasing без wrapping в non-rebasing версию.

Fee-on-transfer токены — при каждом transfer снимается процент. Ломают AMM расчёты: пул получает меньше, чем ожидал. Uniswap v2/v3 не поддерживают fee-on-transfer нативно — нужны специальные pair/router.

Tokenomics: где математика превращается в экономику

Токеномика — это не таблица в Excel с суммой 100%. Это модель инцентивов, которая либо работает в долгосрочной перспективе, либо создаёт давление продаж которое убьёт проект.

Emission schedule и инфляция

Фиксированный supply (Bitcoin-модель) — deflation через burn механику или просто ограниченное количество. Подходит для store-of-value или utility токенов с ограниченным спросом на новые токены.

Инфляционная модель (Ethereum post-Merge, Curve) — новые токены выпускаются для стимулирования участников. Нужен баланс: emission должен быть ниже или равен value capture протоколом. Если протокол зарабатывает $100k/месяц, а эмиссия в рыночной стоимости $500k/месяц — постоянное давление продаж неизбежно.

Halving schedules (Bitcoin-style) — уменьшение emission со временем. Создаёт предсказуемость, но требует что утилити токена росла чтобы компенсировать падающие rewards для stakers/validators.

Supply distribution

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >33% voting power при запуске. Иначе governance — фикция.

Vesting контракты: детали имеют значение

Linear vesting с cliff — стандарт для команды и инвесторов. cliff — период после TGE, в течение которого ничего не доступно. После cliff: линейный unlock до duration.

function releasable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliff) return 0;

    uint256 elapsed = block.timestamp - schedule.cliff;
    uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
    uint256 vested = schedule.totalAmount * elapsed / vestingDuration;

    return vested - schedule.released;
}

Типичные ошибки при реализации:

Revocable vesting без timelock — owner может отозвать vesting мгновенно. Если owner key скомпрометирован или команда недобросовестна — все unvested токены могут быть отозваны. Решение: revocation через multisig + governance vote.

Cliff не блокирует governance права — если используется ERC-20Votes, recipient может делегировать voting power с первого дня, даже если токены ещё не unlocked. Нужно явно разделить voting power и claim logic.

Отсутствие emergency pause — если обнаружена уязвимость в vesting контракте, нужна возможность приостановить claim. Pausable + timelock на unpause.

Liquidity Bootstrapping

Запуск ликвидности — критический момент. Три основных подхода:

Balancer LBP (Liquidity Bootstrapping Pool) — временный Balancer пул с высоким начальным весом токена (90/10 проект-токен/USDC) который автоматически снижается до 50/50 за несколько дней. Создаёт нисходящее ценовое давление, препятствуя ботам скупить всё по одной цене. После LBP ликвидность переносится в постоянный пул.

Fjord Foundry — специализированная платформа для LBP и fair launches. Меньше операционного overhead чем прямая интеграция с Balancer.

Uniswap v3 с ограниченным range — добавить ликвидность в узкий диапазон вокруг начальной цены. Высокая capital efficiency, но требует активного управления range.

TWAMM (Time-Weighted AMM) — механика для постепенной продажи/покупки больших объёмов без slippage. Paradigm предложил, реализован в FraxSwap.

Governance токены и voting механики

OpenZeppelin Governor — стандартная реализация on-chain governance. Модульная архитектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для изменяемых параметров.

Quorum — минимальный процент supply для валидности голосования. Слишком высокий quorum = apathy failure (не набирается голосов). Слишком низкий = whale capture. Compound установил quorum 400k COMP (4% supply) — на практике достигается редко без координации крупных holders.

Flash loan governance attack — атакующий занимает токены через flash loan, делегирует их себе, создаёт proposal или голосует, возвращает токены. ERC-20Votes с snapshot по номеру блока полностью блокирует это: нужно иметь токены на момент создания snapshot, который берётся в момент создания proposal.

Delegation — пользователи с малыми балансами часто не голосуют. Liquid delegation (как в Optimism) позволяет делегировать voting power конкретным addresses (delegates) без передачи ownership токенов.

Стек для токен-разработки

Контракты: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)

Аудит токеномики: Python модели с симуляцией emission/demand, cadCAD для complex systems modeling

Деплой и управление: Foundry scripts, Gnosis Safe для treasury, OpenZeppelin Defender для автоматизации

Аналитика: Dune Analytics для on-chain метрик, Token Terminal для protocol revenue

Процесс

Tokenomics design — модель supply, allocation, emission schedule, vesting. Стресс-тестирование сценариев (bear market, whale exit, governance capture attempt).

Контракт разработка — ERC-20 + extensions, vesting, governance. Foundry fuzz тесты на vesting calculations, governance thresholds.

Аудит — особое внимание на governance attack vectors, vesting bypass, permit replay attacks.

LBP / launch — выбор механики, настройка параметров, мониторинг первых 24 часов.

Post-launch — мониторинг supply distribution через Dune, governance participation metrics, treasury management.

Сроки

• ERC-20 с permit и basic governance: 2–3 недели
• Vesting контракт с revocation и cliff: 2–4 недели
• Полный governance (Governor + Timelock + Token): 4–7 недель
• Токен + LBP + governance + vesting: 8–14 недель