A sell-triggered token burn nearly emptied the TENDRIL side of a BNB Chain liquidity pool on November 4, 2026, setting up a swap that removed almost 4.42 million USDT. The transaction’s net pool outflow was smaller—555,670.538752928908475139 USDT—because substantial USDT amounts had entered earlier in the same transaction.
Key takeaways
TENDRIL’s controller removed twice the original sale amount from the pool.
The pool recorded almost no TENDRIL before receiving the seller’s remaining tokens.
Renounced ownership did not disable the controller’s burn permission.
The final swap output and the transaction’s net outflow measure different amounts.
How the sale activated the sell-triggered token burn
The sale invoked a controller before the seller’s remaining TENDRIL reached the pool. At 16:02:45 UTC, a router’s transferFrom call initiated the sale of 39,053,180,124.060957132414461269 TENDRIL , triggering the token’s tax and controller logic.
Transfers into the main pool carried a 30% sale tax , except when sent by either of two configured addresses, _poolControl and _markControl. The executing contract qualified for neither exemption. The token therefore sent 11,715,954,037.218287139724338380 TENDRIL to _poolControl first.
Next, the token invoked the controller’s sellToken function with the original sale amount—not merely the tax. That call completed before the token credited the remaining 70% to the pool.
The historical call trace shows the sequence: transferFrom, sellToken, controlburn and sync, followed by the final swap. The controller’s opcode trace confirms that it multiplied the original sale amount by two, producing the exact amount subsequently removed from the pool.
Controlburn removed pool tokens without reducing total supply
The controlburn function moved TENDRIL from the pool’s balance to a dead address. It did not reduce the token’s recorded total supply or burn liquidity-provider tokens.
Its permission check required the caller to match _poolControl. Once authorized, it used _basicTransfer to subtract tokens from the pool’s balance and credit the dead address. No pool allowance or liquidity withdrawal was involved: the token contract controlled its own balance records.
Log 28 records the removal of 78,106,360,248.121914264828922538 TENDRIL . That left 6,678 raw units in the pool. With TENDRIL’s 18 decimals, the remainder was only 0.000000000000006678 TENDRIL.
The burn did not simultaneously remove USDT. Almost the entire TENDRIL balance disappeared while the pool’s USDT remained available for the next exchange.
Renounced ownership did not block this path. At block 131653426, immediately before the incident, owner() returned the zero address. But controlburn checked the configured controller rather than owner(), so that separate permission remained effective. The function was not publicly unrestricted; an arbitrary caller would fail its authorization check.
The reserve reset enabled an almost complete USDT withdrawal
The controller called sync() immediately after the burn, recording the depleted token balance before the remaining sale tokens arrived. Log 29 set the reserves at 4,421,023.357469283419586501 USDT and 0.000000000000006678 TENDRIL.
Only afterward did 27,337,226,086.842669992690122889 TENDRIL enter the pool. The final swap transferred 4,421,023.357469283419586499 USDT out, leaving 0.000000000000000002 USDT.
The constant-product arithmetic explains the scale of that output. Setting aside fees and rounding for the sake of example, the USDT output can be calculated by multiplying the USDT reserve by the token input, then dividing that result by the token reserve plus the token input. With an almost-zero recorded token reserve, the input dominates the denominator and the output approaches the full USDT reserve.
That final withdrawal was not the net amount extracted from the pool across the transaction. Total USDT outflows reached 5,117,517.824288279504509510, while inflows totaled 4,561,847.285535350596034371. Subtracting them gives the 555,670.538752928908475139 USDT net outflow .
Contract code and historical traces establish the sequence
The sell-triggered token burn was reconstructed using explorer-verified source, historical calls, event logs and an opcode trace. Recompiling the token with Solidity v0.8.24+commit.e11b9ed9, with optimization disabled, matched its executable runtime bytes at block 131653426, excluding compiler metadata.
The decoded burn argument matched the pool-to-dead transfer exactly. Integer arithmetic also reconciled the tax, remaining sale tokens and reserve balances. Total supply stayed unchanged between the blocks immediately before and after the transaction.
The successful incident transaction appeared in block 131653427. Receipt checks through two public BNB Chain RPC endpoints matched, and address-level USDT flows reconciled exactly when rechecked on November 6, 2026.
Article produced with the assistance of artificial intelligence and reviewed by the editorial team.
