Обгорнутий токен під ключ: WETH, WBTC, міст

Ми часто стикаємося із запитами на 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 та налаштування скриптів
• Документація коду та інструкції для команди
• Технічна підтримка протягом 30 днів після запуску

Також ми надаємо навчання команди щодо управління контрактами та моніторингу.

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

Для cross-chain токенів із реальними активами аудит обов'язковий. Bridges — найбільш атакований компонент всього DeFi. Якщо вам потрібен wrapped-токен для вашого проекту, зв'яжіться з нами для консультації — ми підберемо оптимальне рішення та оцінимо бюджет. Замовте розробку обгорнутого токена під ключ у нас вже сьогодні. Пишіть нам для безкоштовної оцінки проекту!