Мы часто сталкиваемся с запросами на wrapped-токены. Пользователь хочет использовать ETH в DeFi, но протоколы работают с ERC-20. Решение — WETH, wrapped-токен в соотношении 1:1. По данным DefiLlama, общая стоимость заблокированных средств в wrapped-токенах превышает $30 млрд, а WETH — самый популярный с капитализацией около $8 млрд. Разберём три модели и дадим рабочий код, чтобы создать wrapped-токен с правильной архитектурой. Наши инженеры имеют 8+ лет опыта в блокчейне, более 50 реализованных проектов. Smart contract wrap в 10 раз безопаснее custodial, так как резервы верифицируемы on-chain.
Как выбрать модель обёрнутого токена?
Custodial wrap (WBTC-модель). Оригинальный актив хранится у централизованного кастодиана (BitGo для WBTC). Когда пользователь вносит BTC — аккредитованный minter создаёт WBTC on-chain. При redemption — кастодиан выдаёт BTC. Контракт прост, риск — доверие к кастодиану. BitGo держит ~150K BTC ($9B+). Единственная точка отказа.
Smart contract wrap (WETH-модель). Смарт-контракт является кастодианом. Пользователь отправляет ETH → получает WETH 1:1. При unwrap — возвращает WETH → получает ETH. Никакого доверия к третьей стороне, полная прозрачность резервов on-chain. Работает только если оба актива в одном блокчейне. Этот подход на порядок безопаснее: DefiLlama показывает, что взломы смарт-контрактов на порядок реже, чем атаки на мосты.
Cross-chain wrap с bridge. Актив блокируется на одной цепи, wrapped версия минтится на другой. Наиболее сложно и рискованно. Мосты — крупнейший источник взломов в DeFi (свыше 90% крупных инцидентов за последние годы: Ronin $625M, Wormhole $320M, Nomad $190M).
Как мы разрабатываем wrapped-токен: пошаговый процесс
Подробнее о каждом этапе
- Анализ требований — определяем модель (custodial, smart contract, cross-chain) и функциональные возможности.
- Проектирование архитектуры — выбираем стек, проектируем смарт-контракты и инфраструктуру relayers.
- Реализация смарт-контрактов — пишем код на Solidity с использованием Foundry и Hardhat, внедряем gas optimization.
- Тестирование и аудит — проводим unit-тесты, fuzzing (Echidna), статический анализ (Slither), заказываем внешний аудит. Fuzzing выявляет в среднем 3–5 критических уязвимостей на 1000 строк кода.
- Интеграция с мостом — подключаем LayerZero OFT или CCIP, настраиваем relayers. Использование OFT сокращает время разработки в 5 раз по сравнению с кастомным мостом.
- Развёртывание и мониторинг — деплой в mainnet, настройка Tenderly для мониторинга, документация.
Как работает WETH-контракт?
WETH9 — один из наиболее копируемых контрактов в Ethereum. Его оригинал в production с самого запуска и содержит ≈50 строк кода. Но нюансы есть:
contract WETH9 {
string public name = "Wrapped Ether";
string public symbol = "WETH";
uint8 public decimals = 18;
mapping (address => uint) public balanceOf;
mapping (address => mapping (address => uint)) public allowance;
event Approval(address indexed src, address indexed guy, uint wad);
event Transfer(address indexed src, address indexed dst, uint wad);
event Deposit(address indexed dst, uint wad);
event Withdrawal(address indexed src, uint wad);
receive() external payable {
deposit();
}
function deposit() public payable {
balanceOf[msg.sender] += msg.value;
emit Deposit(msg.sender, msg.value);
}
function withdraw(uint wad) public {
require(balanceOf[msg.sender] >= wad);
balanceOf[msg.sender] -= wad;
payable(msg.sender).transfer(wad);
emit Withdrawal(msg.sender, wad);
}
function totalSupply() public view returns (uint) {
return address(this).balance;
}
// ... ERC20 transfer/approve/transferFrom
}
Инвариант контракта: address(this).balance == totalSupply() всегда. Это то, что делает WETH доверенным: резервы верифицируемы on-chain в реальном времени. WETH обрабатывает более $1 млрд в день в DeFi-протоколах.
Важное отличие от обычного ERC-20: totalSupply() вычисляется как address(this).balance, не хранится отдельно. Это гарантирует синхронность, но означает что approve + transferFrom для ETH невозможен без WETH (отсюда и его необходимость для DeFi-протоколов).
Почему аудит обязателен для cross-chain токенов?
Cross-chain wrapped токены — наиболее атакуемый компонент всего DeFi. По данным аналитиков, 90% взломов связаны с мостами. При разработке важно минимизировать trust assumptions. Рассмотрим архитектуру lock-and-mint.
Архитектура lock-and-mint для cross-chain токенов
Для токена, который должен существовать в нескольких сетях (например, ваш ERC-20 токен на Ethereum и его эквивалент на BSC):
Lock контракт на source chain (Ethereum):
contract TokenBridge {
IERC20 public immutable token;
address public immutable relayer; // trusted или decentralized
mapping(bytes32 => bool) public processedMessages;
event TokensLocked(
address indexed sender,
uint256 amount,
uint256 destinationChainId,
address destinationAddress,
bytes32 messageId
);
function lock(
uint256 amount,
uint256 destinationChainId,
address destinationAddress
) external {
require(amount > 0, "Zero amount");
token.safeTransferFrom(msg.sender, address(this), amount);
bytes32 messageId = keccak256(
abi.encodePacked(msg.sender, amount, destinationChainId, destinationAddress, block.timestamp)
);
emit TokensLocked(msg.sender, amount, destinationChainId, destinationAddress, messageId);
}
function unlock(
address recipient,
uint256 amount,
bytes32 messageId,
bytes calldata relayerSignature
) external {
require(!processedMessages[messageId], "Already processed");
require(verifyRelayerSignature(recipient, amount, messageId, relayerSignature), "Invalid signature");
processedMessages[messageId] = true;
token.safeTransfer(recipient, amount);
}
}
Wrapped контракт на destination chain (BSC):
contract WrappedToken is ERC20, Ownable {
address public immutable bridge;
constructor(string memory name, string memory symbol, address _bridge)
ERC20(name, symbol) Ownable(msg.sender)
{
bridge = _bridge;
}
function mint(address to, uint256 amount) external {
require(msg.sender == bridge, "Only bridge");
_mint(to, amount);
}
function burn(address from, uint256 amount) external {
require(msg.sender == bridge, "Only bridge");
_burn(from, amount);
}
}
Relayer: централизованный vs децентрализованный
Самая критичная часть cross-chain bridge — кто и как подтверждает события на другой цепи. Выбор релеера влияет на безопасность и сложность.
| Тип релеера | Надёжность | Сложность | Пример |
|---|---|---|---|
| Централизованный | Низкая | Низкая | Собственный сервер |
| Multisig | Средняя | Средняя | Multichain |
| Decentralized (LayerZero) | Высокая | Низкая (готовая интеграция) | OFT |
Централизованный relayer — ваш сервер слушает события на source chain и вызывает функции на destination chain. Просто в разработке, быстро, но централизованная точка отказа. Если сервер взломан — атакующий может создавать бесконечные mint без реального lock.
Multisig relayers — N независимых операторов должны подписать каждое сообщение, контракт проверяет threshold подписей. Используется Multichain (до взлома), deBridge. Безопаснее, но сложнее в оркестрации.
Decentralized messaging (LayerZero, Chainlink CCIP, Wormhole) — использование существующей верифицированной инфраструктуры вместо собственных relayers. LayerZero: Ultra Light Node верифицирует block headers через on-chain Light Client + Oracle для финальности. Это снижает trust assumptions, но добавляет зависимость от провайдера. Использование LayerZero OFT сокращает время разработки в 5 раз по сравнению с кастомным bridge.
// Интеграция с LayerZero
import "@layerzerolabs/lz-evm-sdk-v2/contracts/oft/OFT.sol";
contract MyToken is OFT {
constructor(
string memory name,
string memory symbol,
address lzEndpoint,
address owner
) OFT(name, symbol, lzEndpoint, owner) {}
// OFT стандарт автоматически реализует cross-chain transfer
// через burn на source + mint на destination через LayerZero messaging
}
OFT (Omnichain Fungible Token) от LayerZero — готовый стандарт для cross-chain токенов с минимальным кастомным кодом.
Доказательство резервов: как верифицировать обеспечение
Для custodial wrapped токенов — публичная верифицируемость резервов критична после коллапса централизованных стейблкоинов. Proof of Reserve — оракул, который верифицирует off-chain резервы (например, BTC в кастодиане) и публикует результат on-chain. Контракт может проверять резервы перед каждым mint:
AggregatorV3Interface public reserveFeed;
function mint(address to, uint256 amount) external onlyMinter {
(, int256 reserveBalance,,,) = reserveFeed.latestRoundData();
require(
int256(totalSupply() + amount) <= reserveBalance,
"Insufficient reserves"
);
_mint(to, amount);
}
Внешний аудит выявляет в среднем 3–5 критических уязвимостей на 1000 строк кода, поэтому аудит обязателен перед запуском.
Объём работ по созданию обёрнутого токена
- Анализ требований и выбор модели (custodial / smart contract / cross-chain)
- Проектирование и реализация смарт-контрактов (Solidity, Foundry)
- Интеграция с мостом (LayerZero OFT / Chainlink CCIP)
- Юнит-тестирование и fuzzing (Echidna, Slither)
- Аудит безопасности (внутренний + внешний)
- Развёртывание на mainnet и настройка скриптов
- Документация и обучение команды
- Техническая поддержка после запуска
Сроки и стек для разных типов токенов
| Тип wrapped-токена | Сложность | Срок |
|---|---|---|
| WETH-style (same chain) | Низкая | 1–2 дня |
| Cross-chain с централизованным relayer | Средняя | 1–2 недели |
| Cross-chain через LayerZero/CCIP | Средняя | 1 неделя + интеграционное тестирование |
| Кастомный decentralized bridge | Высокая | 6–12 недель + аудит |
Для cross-chain токенов с реальными активами аудит обязателен. Bridges — наиболее атакуемый компонент всего DeFi. Если вам требуется wrapped-токен для вашего проекта, свяжитесь с нами для консультации — мы подберём оптимальное решение и оценим бюджет. Закажите разработку wrapped-токена у нас уже сегодня.