Una venta desencadena la quema de tokens y deja seco el pool de liquidez de TENDRIL en BNB Chain

CoinDesk informa: el 4 de noviembre de 2026, una quema de tokens activada por una orden de venta dejó prácticamente vacío el lado TENDRIL del pool de liquidez de TENDRIL en BNB Chain y habilitó un intercambio que extrajo cerca de 4,42 millones de USDT. La salida neta de la operación fue mucho menor, de 555.670,538752928908475139 USDT, porque una cantidad importante de USDT ya había entrado en esa misma transacción. ¿Cómo activa una venta la quema de tokens? Antes de que el TENDRIL restante del vendedor entrara en el pool se invocó un controlador. A las 16:02:45 UTC, la llamada transferFrom del router inició la venta de 39.053.180.124,060957132414461269 TENDRIL y disparó la lógica de comisiones y del controlador del token. Los envíos al pool principal soportan un impuesto de venta del 30%, salvo cuando proceden de las dos direcciones configuradas, _poolControl y _markControl. El contrato que ejecutó esta operación no cumple ninguna de las dos exenciones. Por eso el token envía primero 11.715.954.037,218287139724338380 TENDRIL a _poolControl y después llama a la función sellToken del controlador, a la que pasa el importe original de la venta, no solo el de la comisión. La llamada se completa antes de que el token registre el 70% restante en el pool. El rastro histórico de llamadas muestra la secuencia: transferFrom, sellToken, controlburn y sync, seguidas del swap final. El rastro de opcodes del controlador confirma que multiplicó por 2 el importe original de la venta para fijar la cantidad exacta retirada después del pool. Controlburn saca tokens del pool sin reducir el suministro total: transfiere TENDRIL del saldo del pool a una dirección muerta, pero no reduce el suministro total registrado del token ni quema los tokens del proveedor de liquidez. Su comprobación de permisos exige que quien llama coincida con _poolControl. Una vez autorizado, usa _basicTransfer para descontar tokens del saldo del pool y abonarlos en una dirección muerta. Aquí no hay autorización del pool ni retirada de liquidez: el contrato del token controla directamente sus propios registros de saldo. El registro 28 recogió la retirada de 78.106.360.248,121914264828922538 TENDRIL y dejó solo 6.678 unidades originales en el pool. Con 18 decimales, el remanente equivale a 0,000000000000006678 TENDRIL. La quema no retiró USDT al mismo tiempo. Casi todos los saldos de TENDRIL desaparecieron y el USDT del pool quedó disponible para el siguiente intercambio. La renuncia a la propiedad no desactivó esta vía. En el bloque 131653426, antes del incidente, owner() devolvía la dirección cero. Controlburn verifica el controlador configurado, no owner(), de modo que esa ruta de acceso sigue vigente. La función no está abierta a cualquiera: cualquier llamada falla en la comprobación de autorización. El reinicio de reservas permite retirar casi todo el USDT. El controlador llama a sync() justo después de la destrucción y registra el saldo del token ya vaciado, antes de que lleguen los tokens restantes de la venta. El registro 29 fija la reserva en 4.421.023,357469283419586501 USDT y 0,000000000000006678 TENDRIL. Después entran en el pool 27.337.226.086,842669992690122889 TENDRIL. El swap final retira 4.421.023,357469283419586499 USDT y deja únicamente 0,000000000000000002 USDT. La fórmula del producto constante explica esta magnitud de salida. Omitiendo comisiones y redondeos, la salida de USDT resulta de multiplicar la reserva de USDT por la entrada de tokens y dividir el resultado entre la suma de la reserva de tokens y esa entrada. Cuando la reserva registrada de tokens es casi nula, la entrada domina el denominador y la salida se aproxima a la totalidad de la reserva de USDT. El importe final retirado no equivale al neto extraído del pool. La salida total de USDT alcanzó 5.117.517,824288279504509510 y la entrada total sumó 4.561.847,285535350596034371. La diferencia arroja una salida neta de 555.670,538752928908475139 USDT. El código del contrato y la traza histórica permiten reconstruir toda la secuencia. La quema activada por esta venta se reconstruyó con el código fuente verificado, las llamadas históricas, los registros de eventos y los rastros de opcodes de un explorador de bloques. Tras recompilar con Solidity v0.8.24+commit.e11b9ed9 y la optimización desactivada, el código de ejecución del bloque 131653426 coincide con el bytecode del contrato, excluidos los metadatos del compilador. Los parámetros decodificados de la quema coinciden exactamente con el importe transferido del pool a la dirección muerta. Las operaciones con enteros también se corresponden con la comisión, los tokens restantes de la venta y el saldo de la reserva. El suministro total no cambia entre los bloques contiguos anteriores y posteriores a la transacción. La transacción se registró en el bloque 131653427. Los recibos verificados en dos puntos RPC públicos de BNB Chain coincidieron y, en la revisión del 6 de noviembre de 2026, el flujo de USDT a nivel de dirección resultó plenamente consistente. Este artículo se elaboró con ayuda de inteligencia artificial y fue revisado por el equipo editorial.