Ми часто стикаємося із запитами на 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, впроваджуємо оптимізацію газу.
- Тестування та аудит — проводимо 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 та налаштування скриптів
- Документація коду та інструкції для команди
- Технічна підтримка протягом 30 днів після запуску
Також ми надаємо навчання команди щодо управління контрактами та моніторингу.
Строки та стек для різних типів токенів
| Тип 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-токен для вашого проекту, зв'яжіться з нами для консультації — ми підберемо оптимальне рішення та оцінимо бюджет. Замовте розробку обгорнутого токена під ключ у нас вже сьогодні. Пишіть нам для безкоштовної оцінки проекту!