Разработка wrapped-токена

Разработка wrapped-токена

Wrapped-токен — это токен, который представляет другой актив в соотношении 1:1. WETH — это ETH, завёрнутый в ERC-20 интерфейс. WBTC — Bitcoin на Ethereum, обеспечённый реальным BTC у кастодиана. wstETH — stETH в неребалансирующейся форме. За простотой идеи скрывается несколько принципиально разных архитектурных моделей с очень разными гарантиями безопасности.

Три модели wrapped-токенов

Custodial wrap (WBTC-модель). Оригинальный актив хранится у централизованного кастодиана (BitGo для WBTC). Когда пользователь вносит BTC — аккредитованный minter создаёт WBTC on-chain. При redemption — kастодиан выдаёт BTC. Контракт прост, риск — доверие к кастодиану. BitGo держит ~150K BTC ($9B+). Единственная точка отказа.

Smart contract wrap (WETH-модель). Смарт-контракт является кастодианом. Пользователь отправляет ETH → получает WETH 1:1. При unwrap — возвращает WETH → получает ETH. Никакого доверия к третьей стороне, полная прозрачность резервов on-chain. Работает только если оба актива в одном блокчейне.

Cross-chain wrap с bridge. Актив блокируется на одной цепи, wrapped версия минтится на другой. Наиболее сложно и рискованно. Мосты — крупнейший источник взломов в DeFi (Ronin $625M, Wormhole $320M, Nomad $190M).

WETH-контракт: детали реализации

WETH9 — один из наиболее копируемых контрактов в Ethereum. Его оригинал в production с 2017 года и содержит ≈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);

    // Обёртка через fallback — депозит при отправке ETH напрямую
    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 в реальном времени.

Важное отличие от обычного ERC-20: totalSupply() вычисляется как address(this).balance, не хранится отдельно. Это гарантирует синхронность, но означает что approve + transferFrom для ETH невозможен без WETH (отсюда и его необходимость для DeFi-протоколов).

Cross-chain wrapped token с lock-and-mint

Для токена, который должен существовать в нескольких сетях (например, ваш 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);
    }

    // Релеер вызывает unlock при burn на destination chain
    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
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 токенов с минимальным кастомным кодом.

Proof of reserves

Для custodial wrapped токенов — публичная верифицируемость резервов критична после коллапса BUSD и других централизованных стейблкоинов.

Chainlink 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);
}

Сроки и стек

Для cross-chain токенов с реальными активами — аудит обязателен. Bridges — наиболее атакуемый компонент всего DeFi.