Triângulos Impossíveis e Compromissos
Iniciar a fascinante jornada no mundo do DeFi frequentemente começa com uma profunda imersão no whitepaper do Bitcoin. É lá que encontro o intrigante 'triângulo impossível', um conceito que ilustra de maneira eloquente o intrincado equilíbrio entre descentralização, segurança e escalabilidade.
No seu cerne, a descentralização representa um princípio fundamental no espaço cripto, permitindo que indivíduos tenham a liberdade de se tornarem validadores dentro da rede. No entanto, ao considerarmos os requisitos fundamentais de uma blockchain pública, a segurança emerge como o pilar central. É a fundação não negociável sobre a qual tudo mais repousa, tornando-a uma pedra angular do triângulo impossível.
Em contraste, a escalabilidade muitas vezes fica em segundo plano na equação, abrindo caminho para os outros dois componentes críticos. É por isso que você pode notar que as taxas de transação no Bitcoin ou as taxas de gás na Ethereum superam as dos métodos de pagamento tradicionais, apesar da percebida desvantagem de velocidade ou largura de banda.
No entanto, mesmo dentro das limitações da escalabilidade, soluções engenhosas surgiram. Elas possibilitam transações complexas de tokens com a máxima eficiência, mantendo designs elegantes de contratos inteligentes. Uma criação particularmente cativante que surgiu após o fervor do DeFi Summer é a introdução dos tokens de reflexão - uma abordagem única e criativa para apoiar a tokenomia e garantir o sucesso contínuo do DeFi.
O que é o token de reflexão
Imagine que cada vez que um detentor de token faz uma transferência ou troca, uma pequena porcentagem desse token é deduzida do seu saldo. O que acontece a seguir é onde a magia começa - uma parte desse token é devolvida ao pool de liquidez, enquanto o restante é distribuído entre os demais detentores. O cálculo subjacente e a lógica de código podem parecer simples no mundo das finanças tradicionais. No entanto, no reino das criptomoedas, introduzir uma taxa em cada transferência, combinada com o recálculo do saldo de cada endereço envolvido, poderia resultar em um consumo surpreendentemente alto de gás.
Aqui entra o conceito engenhoso dos tokens de reflexão, uma inovação de código aberto pioneira no renomado projeto SafeMoon. Não apenas fornece insights valiosos, mas também serve como fonte de inspiração para aprimorar a eficiência do gás e simplificar todo o processo ao máximo.
Explicação do Código
Variáveis de Gerenciamento de Conta
As duas primeiras variáveis são as mais importantes, para salvar respectivamente o mapeamento do saldo da conta de token reflexivo e o saldo original do token. Se uma conta pode ou não receber recompensas também é gerenciado por variáveis entre elas.
mapping(address => uint256) private _rOwned; // token reflexivo possuído
mapping(address => uint256) private _tOwned; // token possuído
mapping(address => mapping(address => uint256)) private _allowances;
mapping(address => bool) private _isExcludedFromFee; // Conta que paga ou não paga taxa de transação
mapping(address => bool) private _isExcluded; // Contas que receberão recompensas ou não (se verdadeiro: (a conta está excluída de receber recompensa), se falso: a conta não está excluída: portanto, pode receber recompensas)
address[] private _excluded; // Contas que não recebem recompensas
Variáveis Aritméticas
A única coisa que vale a pena mencionar para as variáveis abaixo é que a quantidade de tokens reflexivos é exatamente um certo número de vezes a quantidade de tokens originais.
uint256 private constant MAX = ~uint256(0); // 2^256 - 1 = 1.15792089237316195423570985008687907853269984665640564039457584007913129639935×10⁷⁷
uint256 private _tTotal = 1000000000 * 10**6 * 10**9; // 10^9 * 10^6 * 10^9 = 10^24 = Um Septilhão
uint256 private _rTotal = (MAX - (MAX % _tTotal)); // 1.15792089237316195423570985008687907853269984665640564×10^77
/// @notice Total de taxas coletadas através de transferências
uint256 private _tFeeTotal;
string private _name = "Token Reflexivo";
string private _symbol = "RFT";
uint8 private _decimals = 9;
uint256 public _taxFee = 5;
uint256 private _previousTaxFee = _taxFee;
uint256 public _liquidityFee = 5;
uint256 private _previousLiquidityFee = _liquidityFee;
IUniswapV2Router02 public immutable uniswapV2Router;
address public immutable uniswapV2Pair;
bool inSwapAndLiquify;
bool public swapAndLiquifyEnabled = true;
uint256 public _maxTxAmount = 5000000 * 10**6 * 10**9; // 50^21
uint256 private numTokensSellToAddToLiquidity = 500000 * 10**6 * 10**9; // 50^20
Cálculo de Saldo
Existem dois cálculos principais para o cálculo do saldo. O primeiro é usar um valor de taxa para dividir a quantidade de tokens reflexivos de um endereço para calcular seu saldo original de tokens.
> _balanceOf(address) = rAmount / currentRate_
O segundo é sobre como a taxa é calculada. Até agora, sabemos que o denominador da fórmula é um número fixo que é igual à quantidade total de tokens originais (ou seja, _tTotal).
Até agora, você pode ter uma compreensão aproximada de que quando o fornecimento total de tokens reflexivos diminui, a taxa também diminui. Quando tal situação ocorre durante trocas ou transferências de tokens, a taxa diminui. Combinando isso com a primeira fórmula, a quantidade de tokens originais na conta do usuário aumentará.
> _currentRate = rSupply / tSupply_
function balanceOf(address account) public view override returns (uint256) {
if (_isExcluded[account]) return _tOwned[account];
return tokenFromReflection(_rOwned[account]);
}
/// @notice Esta função calcula quantos tokens por reflexão
/// @dev No valor inicial da reflexão, ele deve ser maior ou você pode ter uma ideia
/// executando {reflectionFromToken} para obter reflexo por token
function tokenFromReflection(uint256 rAmount) public view returns (uint256) {
require(rAmount <= _rTotal, "A quantidade deve ser menor que o total de reflexos");
uint256 currentRate = _getRate(); // 1.15792089237316195423570985008687907853269984665640564×10⁵³ return rAmount.div(currentRate); // (2 * 10^53) / (1.15792089237316195423570985008687907853269984665640564×10⁵³) = 1
}
/// @notice Calcula a taxa atual do token.
/// @return Taxa atual pela fórmula simples (reflexo de oferta restante / oferta total restante)
function _getRate() private view returns (uint256) {
(uint256 rSupply, uint256 tSupply) = _getCurrentSupply(); // (1.1579×10^53 , 10^24)
return rSupply.div(tSupply); // 1.15792089237316195423570985008687907853269984665640564×10⁵³
}
Transferência de Tokens
Em condições típicas de transferência de tokens, o que significa que nem o remetente nem o destinatário estão excluídos da distribuição de recompensas, o código de implementação é a função "_transferStandard".
/// @notice Esta função obtém os valores de reflexão e transferência (incluindo taxas de reflexão e transferência).
/// subtrai a quantidade de reflexo do remetente do saldo de reflexo dele
/// adiciona a quantidade de transferência de reflexo ao saldo de transferência do destinatário
/// o contrato inteligente retira a liquidez e reflete ambas as taxas
/// @param {sender} endereço do remetente
/// @param {recipient} endereço do destinatário
/// @param {tAmount} quantidade a ser transferida
function _transferStandard(
address sender,
address recipient,
uint256 tAmount
) private {
(
uint256 rAmount,
uint256 rTransferAmount,
uint256 rFee,
uint256 tTransferAmount,
uint256 tFee,
uint256 tLiquidity
) = _getValues(tAmount);
_rOwned[sender] = _rOwned[sender].sub(rAmount);
_rOwned[recipient] = _rOwned[recipient].add(rTransferAmount);
_takeLiquidity(tLiquidity);
_reflectFee(rFee, tFee);
emit Transfer(sender, recipient, tTransferAmount);
}
Antes de atualizar o saldo da conta, é necessário calcular os valores de transferência, taxa de imposto e taxa de liquidez para ambos os tokens reflexivos e originais. Os valores dos tokens originais são calculados primeiro e, em seguida, os valores dos tokens reflexivos são computados multiplicando as taxas a eles.
O saldo refletivo do token do remetente e do destinatário é atualizado subtraindo ou adicionando valores obtidos de "_getValues".
/// @notice Calcular valores de transferência e reflexão
/// @param {tAmount} Valor total da transferência
/// @return rAmount Quantidade de reflexão
/// @return rTransferAmount Quantidade de reflexão transferida
/// @return rFee Taxas de reflexão
/// @return tTransferAmount Quantidade de transferência
/// @return tFee Taxa de transferência
/// @return tLiquidity Liquidez da transferência
function _takeLiquidity(uint256 tLiquidity) private {
uint256 currentRate = _getRate();
uint256 rLiquidity = tLiquidity.mul(currentRate);
_rOwned[address(this)] = _rOwned[address(this)].add(rLiquidity);
if (_isExcluded[address(this)]) _tOwned[address(this)] = _tOwned[address(this)].add(tLiquidity);
}
O valor da taxa de liquidez é registrado no saldo de tokens reflexivos do contrato do token. Se o contrato estiver excluído de receber recompensas, então o saldo original de tokens deve ser atualizado. E quando o estado de exclusão é revertido para falso, o saldo original de tokens será definido como 0.
/// @notice Esta função aumentará o saldo de reflexão e transferência do contrato inteligente por meio de rLiquidity e tLiquidity
/// @param {tLiquidity} É calculado pela função calculateLiquidityFee()
function _reflectFee(uint256 rFee, uint256 tFee) private {
_rTotal = _rTotal.sub(rFee);
_tFeeTotal = _tFeeTotal.add(tFee);
}
A lógica da implementação do código em diferentes condições de transferência de tokens é em grande parte semelhante à função "_transferStandard".
/// @notice Esta função realiza verificações de taxas e, em seguida, de acordo com o remetente e o destinatário,
/// exclui bandeiras de transferência, transferindo a quantia fornecida para o destinatário.
/// @param {sender} endereço do remetente
/// @param {recipient} endereço do destinatário
/// @param {amount} quantidade a ser transferida
/// @param {takeFee} sinalizador para cobrar ou não taxas
function _tokenTransfer(
address sender,
address recipient,
uint256 amount,
bool takeFee
) private {
/// se takeFee for falso, removeAllFee() é chamado para definir as taxas (taxFee e liquidityFee) como zero
if (!takeFee) removeAllFee();
if (_isExcluded[sender] && !_isExcluded[recipient]) {
_transferFromExcluded(sender, recipient, amount);
} else if (!_isExcluded[sender] && _isExcluded[recipient]) {
_transferToExcluded(sender, recipient, amount);
} else if (!_isExcluded[sender] && !_isExcluded[recipient]) {
// A função _transferStandard é chamada se tanto o remetente quanto o destinatário não estiverem excluídos de receber recompensas (ambos podem receber recompensas)
_transferStandard(sender, recipient, amount);
} else if (_isExcluded[sender] && _isExcluded[recipient]) {
_transferBothExcluded(sender, recipient, amount);
} else {
_transferStandard(sender, recipient, amount);
}
if (!takeFee) restoreAllFee();
}
Outros Elementos para o Pico da SafeMoon
Timing: Uma Aposta Bem Feita
Tudo começou em novembro de 2021, quando mergulhei no tempo de verificação do contrato inteligente de proxy de token. Naquela época, o mundo dos memes on-chain ainda estava em alta, com a sombra de desafios subsequentes, como o escândalo de SBF e a espiral da morte da LUNA, ainda por vir. Investidores de varejo estavam ansiosamente buscando a próxima sensação do Dogecoin ou do meme stock, assim como a loucura do WallStreetBets. Nesse cenário, Bitcoin e Ethereum atingiam máximas históricas, saturando o mercado com liquidez. Foi precisamente neste momento que a SafeMoon fez sua estreia, capitalizando na tempestade perfeita.
Operações de Mercado: A Liderança Visionária
À frente da SafeMoon estava John Karony, um líder visionário especializado em gerenciamento de programas e redação técnica. Ele conduziu o projeto com uma série de estratégias de mercado bem elaboradas, estabelecendo um novo padrão de confiabilidade para investidores de varejo. Enquanto muitos projetos na época levantaram preocupações ao distribuir uma parcela significativa de tokens para empreendimentos ou membros centrais, a SafeMoon tomou um caminho diferente. Não apenas queimou todos os tokens de desenvolvedores no lançamento, mas também adotou mecanismos justos e transparentes de IEO e IDO. A tokenomia e o inovador esquema de reflexão foram executados com precisão. Trilhões de moedas foram sistematicamente retiradas de circulação para manter um suprimento escasso, criando uma onda de entusiasmo no mercado.
Espiral da Morte
zero fundamentos e uso
No meio da loucura do aumento de preços alimentado pelo FOMO, o valor de mercado da SafeMoon chegou a ultrapassar US$1 bilhão. No entanto, desde então, despencou mais de 90% de seu valor de mercado, e seu baixo volume de negociação agora dá a aparência de um projeto inativo. Os resultados indicam falta de utilidade ou incentivos para os "diamond hands" se a tendência de preço mudar de uma tendência de alta para uma tendência de baixa.
Além disso, a inatividade do projeto tanto no desenvolvimento quanto no mercado de negociação sugere que a equipe não demonstrou muito comprometimento em manter ou aprimorar a utilidade do token.
É um caso de uma má tokenomia?
Assemelha-se mais a ponzinomics do que apenas a uma má tokenomia. Esses dois conceitos compartilham algumas semelhanças. Em um esquema Ponzi, você ganha dividendos com a entrada de novos participantes no esquema, enquanto em shit coins, você ganha reflexos de outros comprando.
No entanto, há uma desvantagem notável: os detentores são obrigados a pagar impostos quando se envolvem em negociações. Isso sinaliza que o foco principal do projeto é inflar o preço, mas tal estratégia geralmente é de curta duração.
Fonte
Este artigo foi escrito por 0xCryptoQuant e traduzido por Adriano P. de Araujo. O original em inglês pode ser encontrado aqui.
Top comments (0)