Recentemente escrevi um tutorial aqui no blog ensinando a criar um protocolo DeFi bem simples, que permite depositar e sacar tokens. No entanto, todo protocolo DeFi, simples ou complexo, enfrenta um desafio muito grande que é como atrair provedores de liquidez (liquidity providers), ou seja, investidores com dinheiro que queiram depositar no protocolo. Afinal, se o protocolo não tiver capital investido, ele não conseguirá operar.
Para fazer essa atração é obrigatório ter incentivos como compartilhamento de taxas, pagamento de dividendos, etc. Uma dessas técnicas muito populares em contratos inteligentes é a chamada Liquidity Mining ou Mineração de Liquidez. No Liquidity Mining os depositantes recebem recompensas na forma de tokens proporcionalmente ao período e montante depositados no liquidity pool do protocolo. Esses tokens obviamente devem ter algum valor, seja para serem trocados (swap) por outros, negociados em corretoras (exchange) ou serem usados para staking ou governança/poder de voto (em DAOs).
Neste tutorial nós vamos fazer um smart contract para liquidity mining, dando continuidade ao tutorial anterior de protocolo DeFi, que é importante que você tenha feito antes de fazer este.
Além disso, é obrigatório que você já tenha conhecimentos de Solidity pois este é um tutorial intermediário. Se for seu primeiro contato, comece por este aqui.
E por fim, você já deve ter conhecimento de como implementar tokens ERC-20 e já ter um seu, publicado na blockchain. Caso nunca tenha feito um token antes, aprenda aqui.
Vamos lá!
#1 – Liquidity Token
Eu vou começar construindo o token de liquidez que será dado como recompensa a todos provedores de liquidez que deixarem seus tokens depositados em nosso protocolo. Este será um token ERC-20 padrão, usando as bibliotecas da OpenZeppelin para produtividade e segurança. Abaixo o código do arquivo LiquidityToken.sol e a explicação logo na sequência.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/security/ReentrancyGuard.sol"; import "./ILPToken.sol"; contract LiquidityToken is ILPToken, ERC20 { address immutable owner; address public liquidityMining; constructor() ERC20("LiquidityToken", "LQT") { owner = msg.sender; } function setLiquidityMining(address _liquidityMining) public { require(msg.sender == owner, "Unauthorized"); liquidityMining = _liquidityMining; } function mint(address receiver, uint amount) external{ require(msg.sender == owner || msg.sender == liquidityMining, "Unauthorized"); _mint(receiver, amount); } } |
Começamos importando as bibliotecas que vamos usar e uma interface que vou criar logo na sequência.
Depois, definimos as variáveis de estado, que serão duas:
- owner: endereço do dono do contrato;
- liquidityMining: endereço do contrato de mineração de liquidez;
Esses dois endereços terão privilégios especiais, por isso eu armazeno o owner no constructor do nosso contrato, que será executado automaticamente durante o deploy. Mais tarde, o owner usará a função setLiquidityMining para informar o segundo endereço.
Todas as funções ERC-20 serão fornecidos pela herança do contrato ERC20 da OpenZeppelin, e apenas crio a minha versão personalizada da função mint, que será chamada somente pelo owner ou pelo contrato de liquidity mining para mintar e enviar as recompensas para o usuário que merecer.
Essa função é a única que precisamos ter na nossa interface ILPToken.sol, como abaixo.
|
1 2 3 4 5 6 7 8 9 10 |
// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; interface ILPToken is IERC20 { function mint(uint amount, address receiver) external; } |
Essa segregação via interface é importante para um código bem estruturado e aberto para extensão futura. Você pode agora fazer deploy do seu token para ter o endereço dele para a próxima etapa.
#2 – Liquidity Mining
Agora vamos adaptar o contrato Colchao.sol do meu tutorial anterior que no momento está assim:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; contract Colchao { IERC20 public token; mapping(address => uint) public balances;//user => balance constructor(address tokenAddress){ token = IERC20(tokenAddress); } function deposit(uint amount) external { token.transferFrom(msg.sender, address(this), amount); balances[msg.sender] += amount; } function withdraw(uint amount) external { require(balances[msg.sender] >= amount, "Insufficient funds"); balances[msg.sender] -= amount; token.transfer(msg.sender, amount); } } |
Vou renomear o contrato e o arquivo para LiquidityMining e fazê-lo herdar de ReentrancyGuard da OpenZeppelin, pois teremos que proteger algumas funções críticas de Reentrancy Attacks (repare nos imports).
|
1 2 3 4 5 6 7 8 9 10 11 |
// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; import "@openzeppelin/contracts/security/ReentrancyGuard.sol"; import "./ILPToken.sol"; contract LiquidityMining is ReentrancyGuard { |
Agora, vamos definir as variáveis de ambiente. Além da informação do token que o protocolo vai operar (o seu liquidity pool), precisaremos do token que ele vai dar como recompensa (ILPToken), temos de saber o fator de entrega destas recompensas e também armazenar os checkpoints dos depósitos (já explico).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
IERC20 public token; ILPToken public reward; mapping(address => uint) public balances;//user => balance mapping(address => uint) public checkpoints; //user => deposit block number uint public rewardPerBlock = 1; constructor(address tokenAddress, address rewardAddress){ token = IERC20(tokenAddress); reward = ILPToken(rewardAddress); } |
No constructor do nosso contrato recebemos o endereço do token do liquidity pool (que já tínhamos) e do token de recompensa do liquidity mining (que acabamos de fazer). Usamos estes dois endereços para inicializar as respectivas variáveis de estado que usaremos em diversos momentos do nosso contrato.
Agora falando dos checkpoints, como vai funcionar:
- toda vez que o usuário fizer um depósito, vamos registrar o número do bloco da transação que ele depositou;
- se for o primeiro depósito, apenas armazenamos as informações;
- se for um depósito subsequente, pagamos a recompensa devida e atualizamos o checkpoint, para que as próximas recompensas sejam calculadas com o saldo atualizado;
Desta forma, alteramos nossa função de depósito já existente como abaixo.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
function deposit(uint amount) external nonReentrant { token.transferFrom(msg.sender, address(this), amount); uint originalBalance = balances[msg.sender];//necessário para recompensas balances[msg.sender] += amount; if(checkpoints[msg.sender] == 0){ checkpoints[msg.sender] = block.number; } else rewardPayment(originalBalance);//paga o que deve a ele até aqui } |
Repare como guardei o saldo original antes de atualizá-lo, a fim de pagar as recompensas com o saldo que de fato ficou imobilizado.
Na sequência verifico se é um primeiro depósito, para atualizar o checkpoint, ou se for um subsequente, chamamos a função rewardPayment abaixo.
|
1 2 3 4 5 6 7 8 9 |
function rewardPayment(uint balance) internal { uint difference = block.number - checkpoints[msg.sender]; if(difference > 0){ reward.mint(balance * difference * rewardPerBlock, msg.sender); checkpoints[msg.sender] = block.number; } } |
Nesta função nós calculamos a diferença entre o bloco atual e o bloco original do depósito e usamos esta informação mais o fato de recompensas por bloco e a quantidade de capital depositado para chegar na recompensa total. Recompensa esta que será mintada e enviada para o usuário imediatamente, finalizando com a atualização do checkpoint para que o cálculo futuro seja feito em cima do saldo atualizado.
Não esqueça de usar o function modifier nonReentrant para evitar Reentrancy Attacks aqui.
#3 – Encerrando o Liquidity Mining
Para finalizar, na função de saque fazemos ajuste semelhante. A vantagem de ter criado uma função rewardPayment é que podemos usá-la aqui.
|
1 2 3 4 5 6 7 8 9 |
function withdraw(uint amount) external nonReentrant { require(balances[msg.sender] >= amount, "Insufficient funds"); uint originalBalance = balances[msg.sender];//necessário para recompensas balances[msg.sender] -= amount; token.transfer(msg.sender, amount); rewardPayment(originalBalance);//paga as últimas recompensas devidas } |
Repare que a diferença dessa função para a original é:
- usamos o function modifier nonReentrant;
- pegamos o saldo original, antes do saque;
- pagamos as recompensas;
Como a maior parte do trabalho foi feita no passo de depósito, realmente ficou bem simples aqui. Então para complementar, que tal criarmos uma função que estima quanto um usuário tem de recompensas para resgatar?
|
1 2 3 4 5 6 |
function calculateRewards() external view returns (uint) { uint difference = block.number - checkpoints[msg.sender]; return balances[msg.sender] * difference * rewardPerBlock; } |
É praticamente o mesmo algoritmo já existente no rewardPayment, mas aqui sendo uma função view pode ser chamada em um dapp sem incorrer em custos. Muito útil para colocar em um dashboard, por exemplo.
E por fim, que tal uma função que exibe o total depositado no liquidity pool do protocolo?
|
1 2 3 4 5 |
function liquidityPool() external pure returns(uint) { return token.balanceOf(address(this)); } |
Isso é bem simples, basta consultar o saldo da conta do contrato LiquidityMining no token ERC20 que está sendo usado na sua operação.
E se quiser aprender a reduzir o consumo de gás nos seus smart contracts, este é o artigo certo.
Até a próxima!
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.