Queima de token acionada por venda esvazia pool de liquidez do TENDRIL na BNB Chain

Segundo a CoinDesk, uma queima de token acionada por uma ordem de venda quase esvaziou o lado TENDRIL do pool de liquidez TENDRIL na BNB Chain em 4 de novembro de 2026, em uma operação de troca que retirou quase 4,42 milhões de USDT. A saída líquida da transação foi menor, de 555.670,538752928908475139 USDT, pois uma quantia relevante de USDT já havia entrado antes dessa mesma transação. Como a venda aciona a queima? Antes de o TENDRIL restante do vendedor entrar no pool, um controlador foi acionado. Às 16:02:45 UTC, a chamada transferFrom do roteador iniciou a venda de 39.053.180.124,060957132414461269 TENDRIL, disparando a lógica de taxa e de controlador do token. Transferências para o pool principal estão sujeitas a uma taxa de venda de 30%, exceto quando enviadas pelos dois endereços configurados, _poolControl e _markControl. O contrato que executou a transação não se enquadra em nenhuma das isenções. Por isso, o token primeiro envia 11.715.954.037,218287139724338380 TENDRIL para _poolControl. Em seguida, chama a função sellToken do controlador, passando o valor original da venda, não apenas o valor da taxa. Essa chamada é concluída antes de o token registrar os 70% restantes no pool. O rastreamento histórico da chamada mostra a sequência: transferFrom, sellToken, controlburn e sync, seguidos pela troca final. O rastreamento de opcode do controlador confirma que ele multiplicou o valor original da venda por 2 para determinar a quantidade exata depois removida do pool. O controlburn remove tokens do pool sem reduzir o suprimento total. A função controlburn transfere TENDRIL do saldo do pool para um endereço morto, mas não reduz o suprimento total registrado para o token nem queima os tokens do provedor de liquidez. Sua verificação de permissão exige que o chamador corresponda a _poolControl. Uma vez autorizada, a função usa _basicTransfer para deduzir tokens do saldo do pool e creditá-los a um endereço morto. Não há autorização do pool nem saque de liquidez nesse ponto: o contrato do token controla diretamente seus próprios registros de saldo. O Log 28 registrou a remoção de 78.106.360.248,121914264828922538 TENDRIL, deixando apenas 6.678 unidades originais no pool. Considerando as 18 casas decimais do TENDRIL, o valor restante é de apenas 0,000000000000006678 TENDRIL. Essa queima não removeu USDT ao mesmo tempo. Quase todos os saldos de TENDRIL desapareceram, enquanto o USDT no pool permaneceu disponível para a próxima troca. A renúncia à propriedade não desativou esse caminho. No bloco 131653426, antes do incidente, owner() retornou o endereço zero. controlburn verifica o controlador configurado, não owner(), e essa rota de acesso continua válida. A função não está aberta a todos; qualquer chamador falhará na verificação de autorização. A redefinição da reserva permite que quase todo o USDT seja sacado. O controlador chama sync() imediatamente após a destruição, registrando o saldo de tokens depois de esvaziado e antes de chegarem os tokens restantes da venda. O Log 29 define a reserva em 4.421.023,357469283419586501 USDT e 0,000000000000006678 TENDRIL. Depois, 27.337.226.086,842669992690122889 TENDRIL entraram no pool. A troca final retirou 4.421.023,357469283419586499 USDT, deixando apenas 0,000000000000000002 USDT. A fórmula do produto constante explica a escala dessa saída. Ignorando taxas e arredondamentos, para fins de ilustração, o USDT de saída pode ser calculado multiplicando a reserva de USDT pelo token de entrada e dividindo pela soma da reserva de tokens com o token de entrada. Quando a reserva registrada de tokens está perto de zero, a entrada domina o denominador e a saída se aproxima de toda a reserva de USDT. Ainda assim, o valor final retirado nesta operação não é o valor líquido extraído do pool. A saída total de USDT chegou a 5.117.517,824288279504509510, enquanto a entrada total foi de 4.561.847,285535350596034371. A subtração dos dois valores resulta em uma saída líquida de 555.670,538752928908475139 USDT. O código do contrato e o histórico reconstruíram toda a sequência. A queima de token acionada por essa venda foi reconstituída com código-fonte verificado, chamadas históricas, logs de eventos e rastreamentos de opcode por meio de um explorador de blocos. Após recompilação com Solidity v0.8.24+commit.e11b9ed9 com otimização desativada, o código de execução em runtime no bloco 131653426 corresponde ao bytecode do contrato, excluindo metadados do compilador. Os parâmetros decodificados da queima batem exatamente com o valor transferido do pool para o endereço morto. Operações de inteiros também correspondem corretamente à taxa, aos tokens restantes para venda e ao saldo da reserva. O suprimento total permanece inalterado entre blocos adjacentes antes e depois da transação. A transação bem-sucedida do evento apareceu no bloco 131653427. Os recibos verificados por dois endpoints públicos RPC da BNB Chain coincidiram, e, em revisão feita em 6 de novembro de 2026, o fluxo de USDT no nível dos endereços estava totalmente consistente. Este artigo foi gerado com auxílio de inteligência artificial e revisado pela equipe editorial.