Como criar um Wrapped Token em Solidity

Neste tutorial eu vou lhe ensinar o que é, para que serve e como criar um smart contract de Wrapped Token em Solidity, ou seja, compatível com todas blockchains que possuam uma EVM (Ethereum Virtual Machine), o que corresponde a mais de 80% do mercado web3 na data que escrevo este tutorial.

É importante frisar que este tutorial exige que você já saiba programar tokens ERC-20, o tipo mais popular de token do mercado cripto, algo que você pode aprender neste outro tutorial aqui. Além disso, irei utilizar aqui a ferramenta Remix, que é online e gratuita, mas você pode usar toolkits como Truffle e HardHat se quiser, sem qualquer problema.

Vamos lá!

#1 – O que é um Wrapped Token?

Um “token embrulhado” ou “token empacotado”, em uma tradução literal, é um token ERC-20 cujo valor está diretamente relacionado a um lastro em outro token ou criptomoeda guardado na carteira do contrato do wrapped token. Como exemplo mais famoso temos o token WETH, que é um Wrapped Token do Ether (ETH) original.

Mas para que alguém precisaria de um wrapped token?

Wrapped tokens servem geralmente para que você forneça suporte ao padrão ERC-20 para tokens que originalmente não ofereciam suporte ao mesmo, como no caso citado do ETH. Como o ETH é nativo da rede Ethereum ele não segue qualquer padrão de mercado, até porque os padrões todos foram criados depois dele surgir. Assim, protocolos DeFi tem problemas para negociar ETH nativo uma vez que ele não respeita as mesmas regras dos demais tokens existentes no ecossistema. Para garantir o máximo de compatibilidade e eficiência nos algoritmos financeiros, costuma-se utilizar WETH ao invés de ETH em aplicações como dex, lending, staking e outros.

Mas não apenas isso, os wrapped tokens são a base para interoperabilidade de tokens entre blockchains diferentes também, como por exemplo no caso do BTCB que é o wrapped token do Bitcoin na rede da Binance. Ou seja, o BTC de verdade, só existe na blockchain original do Bitcoin. Todos os demais BTC que você vê à venda nas exchanges geralmente são versões wrapped dos mesmos, cujo lastro deles está associado a BTC real na blockchain do Bitcoin (ou assim esperamos né).

E por fim, os wrapped tokens também são a base para a construção de stablecoins lastreadas em moeda fiat, já que a ideia de interoperabilidade é a mesma, embora as provas de reservas sejam mais complexas de fornecer, mas isso é assunto para outro tutorial.

Agora a questão é: como se cria um wrapped token?

#2 – Wrapped Token de Moeda Nativa

Aqui eu vejo dois caminhos possíveis. O primeiro e mais óbvio é o de criar um wrapped token de moeda nativa da blockchain. Ou seja: um wrapped de ETH para a rede ETH, um wrapped de MATIC para a rede Polygon e assim por diante. Isso já foi criado em todas as blockchains comerciais, mas caso você precise no futuro ou apenas queira estudar esse tipo de smart contract, o código abaixo vai te ajudar.


// SPDX-License-Identifier: MIT

pragma solidity ^0.8.18;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";

contract WrappedEther is ERC20, ERC20Burnable {

    constructor() ERC20("Wrapped Ether", "WETH") {}

    function deposit() external payable {
        _mint(msg.sender, msg.value);
    }

    function withdraw(uint amount) external {
        require(balanceOf(msg.sender) >= amount, "Insufficient balance");
        _burn(msg.sender, amount);
        payable(msg.sender).transfer(amount);
    }

}

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.18;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";

contract WrappedEther is ERC20, ERC20Burnable {

constructor() ERC20("Wrapped Ether", "WETH") {}

function deposit() external payable {

_mint(msg.sender, msg.value);

}

function withdraw(uint amount) external {

require(balanceOf(msg.sender) >= amount, "Insufficient balance");

_burn(msg.sender, amount);

payable(msg.sender).transfer(amount);

}

Aqui eu estou usando os contratos da OpenZeppelin, que são praticamente um padrão no mercado. Com ele, eu crio facilmente um novo token ERC-20 que servirá como wrapper para a moeda nativa da rede, que aqui estou presumindo que seja o Ether. Ou seja, esse é um WETH “clone”.

Basicamente nosso WETH-clone tem duas funções, uma de depósito, payable, que recebe ETH e em resposta minta a mesma quantidade de WETH para aquela pessoa que chamou a função. É praticamente uma função de conversão, entende? A partir de então quem recebeu os WETH poderá utilizá-lo em qualquer protocolo DeFi que seja compatível com este token, sabendo que ele poderá ser trocada depois pela mesma quantidade de ETH quando for conveniente.

A segunda função é justamente para essa troca. Aqui dizemos quanto de WETH queremos trocar e, se tivermos saldo para tanto, nossos tokens WETH são queimados (para manter a paridade de 1:1) e os ETH originais são transferidos de volta para o requisitante.

E basicamente é assim que funciona um Wrapped Token de moeda nativa.

#3 – Wrapped Token de token ERC-20

A outra situação possível é você querer fazer um wrapped token de outro token ERC-20. Neste caso a utilidade original de criar compatibilidade com o padrão certamente não será o objetivo, mas sim alguma modificação no token original que você pretenda fazer. De repente alguma proporção de troca diferenciada? Alguma regra de segurança adicional (multisig, etc)? Enfim, você vai fazer isso quando quiser alguma mudança em cima do padrão ERC-20 original, o que foge aqui do escopo do tutorial e deixa a critério da sua criatividade.

No exemplo abaixo, um wrapped token de outro token ERC-20 qualquer, que será definido no momento do deploy (via constructor).


// SPDX-License-Identifier: MIT

pragma solidity ^0.8.18;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";

contract WrappedToken is ERC20, ERC20Burnable {
    IERC20 public immutable token;

    constructor(address tokenAddress) ERC20("Wrapped Token", "WTKN") {
        token = IERC20(tokenAddress);
    }

    function deposit(uint amount) external {
        token.transferFrom(msg.sender, address(this), amount);
        _mint(msg.sender, amount);
    }

    function withdraw(uint amount) external {
        require(balanceOf(msg.sender) >= amount, "Insufficient balance");
        _burn(msg.sender, amount);
        token.transfer(msg.sender, amount);
    }
}

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.18;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";

contract WrappedToken is ERC20, ERC20Burnable {

IERC20 public immutable token;

constructor(address tokenAddress) ERC20("Wrapped Token", "WTKN") {

token = IERC20(tokenAddress);

}

function deposit(uint amount) external {

token.transferFrom(msg.sender, address(this), amount);

_mint(msg.sender, amount);

}

function withdraw(uint amount) external {

require(balanceOf(msg.sender) >= amount, "Insufficient balance");

_burn(msg.sender, amount);

token.transfer(msg.sender, amount);

}

Note que tem algumas mudanças bem importantes aqui como por exemplo o uso de uma variável de estado que referencia o padrão IERC20, que é inicializada no constructor com o endereço passado. Ou seja, esse token é genérico para embrulhar qualquer outro token ERC-20, mas uma vez definido o endereço do mesmo na inicialização, não poderá mais ser mudado (immutable).

Além disso, essa implementação depende que, para que o depósito ocorra, que o dono dos fundos (depositante) use a função approve previamente no contrato do token original para dar permissão para o depósito ocorrer de fato, já que usamos aqui uma transferência delegada aqui. Note que esta não é uma escolha de design, mas uma obrigação para que um protocolo como esse funcione, já que se o usuário transferisse tokens diretamente para a carteira do contrato não teríamos como reagir a essa transferência e consequentemente não faríamos o mint para gerar o WTKN para ele.

Já o saque é bem parecido, pelo menos no algoritmo necessário.

E se quiser aprender a reduzir o consumo de gás nos seus smart contracts, este é o artigo certo.

E com isso concluímos mais este tutorial. Até o próximo!