Обёрнутый токен под ключ: WETH, WBTC, bridge

Мы часто сталкиваемся с запросами на 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-токен: пошаговый процесс

Как работает 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 — кто и как подтверждает события на другой цепи. Выбор релеера влияет на безопасность и сложность.

Централизованный 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 и настройка скриптов
• Документация и обучение команды
• Техническая поддержка после запуска

Сроки и стек для разных типов токенов

Для cross-chain токенов с реальными активами аудит обязателен. Bridges — наиболее атакуемый компонент всего DeFi. Если вам требуется wrapped-токен для вашего проекта, свяжитесь с нами для консультации — мы подберём оптимальное решение и оценим бюджет. Закажите разработку wrapped-токена у нас уже сегодня.