November 14, 2026

The November 4 TENDRIL incident on BNB Smart Chain illustrates why a pool’s gross outflow, its net depletion and the amount received by a subsequent address must be reported separately. The SentinelTX case report records a net decrease of 555,670.538752928908475139 USDT at the affected pair, while a recipient address received 308,959.36754317326 BSC-USD in the seed transaction. The approximately 4.42 million USDT transfer was a gross movement, not the net loss.
The report places execution at November 4, 2026, 16:02:45 UTC, in block 131653427. Its observation date is November 11, 2026. November 5 was the date of subsequent reporting, not the execution timestamp. The investigation focuses on BNB Smart Chain; Ethereum coverage is limited to incoming funding.
The pair-level accounting contains four USDT transfers. They should not be added to the recipient’s receipt as though they represented separate losses.

Figure 1. Pair-level USDT accounting. Bars share a zero baseline. Display values are rounded; exact quantities are preserved above. Source: SentinelTX CASE-ASYNC020, page 3.
The exploit contract’s receipt from, and return to, the pair differ by 323,505.716479930213500802 USDT. Separately, the report records 308,959.36754317326 BSC-USD transferred from the exploit contract to the recipient. It does not establish why these two quantities differ. A complete exploit-contract transfer list was unavailable within the report’s scope.
The flash-loan principal and lender are not established. An empty result for the relevant exploit-contract USDT lookup is a coverage gap, not evidence that no flash loan occurred. This article therefore does not assign a principal amount or combine one with pool losses.
The recipient address appears throughout the report’s preparation and proceeds narrative. On Ethereum, it received seven transfers totaling 6.970873286826 ETH from an address labeled Tornado.Cash’s 1 ETH pool. Six Relay.link routes brought funds to BNB Smart Chain. The report says transaction-hash correlation and receipts were checked for those routes. Some arrival-token identities remain unspecified, so their displayed quantities are not combined into a cross-asset total.
The database label includes a sanctions descriptor, but the report did not separately establish current sanctions status. A service label is also not identification of the person controlling an address.
On BNB Smart Chain, the recipient deployed five contracts between October 27 and October 29. Repeated calls to one of those contracts on November 3 and November 4 were associated with BSC-USD transfers and TENDRIL receipts. The report interprets this as preparation consistent with accumulating TENDRIL while limiting net BSC-USD expenditure. It did not decode that contract’s logic, so the interpretation remains an analytical assessment.
The report marks the aggregate TENDRIL quantities and several preparation transfers as unverified. In particular, its displayed pre-positioned TENDRIL amount and the eight-day acquisition total do not establish the source of the full token inventory. Those quantities are not used here to claim a complete inventory reconciliation.
The caller deployed two contracts at 15:41:13 and 15:45:48 UTC on November 4, then signed the seed transaction at 16:02:45 UTC. The later deployment is the exploit contract identified in the report. The recipient supplied TENDRIL before execution and subsequently received BSC-USD.
Public-source excerpts cited within the report describe a sell-hook burn-and-sync mechanism and a 30% sell-tax logic flaw. The report assesses the observed transfers as consistent with a token-logic-driven AMM reserve-manipulation exploit. It did not independently decode the relevant bytecode or reconstruct all internal calls. The precise controller role and full execution mechanism therefore remain analytical rather than conclusively established.
The caller, exploit contract, recipient and pair have distinct observable roles. Their funding and receipt relationships do not, by themselves, establish common ownership or control. The record also does not establish that the recipient’s four other deployed contracts were involved in additional attacks.
The strongest documented post-incident segment is a CoW Protocol settlement at November 6, 2026, 13:20:18 UTC. Its decoded Trade event records BSC-USD as both the sell and buy token, with the recipient as order owner.
The settlement input exceeds the seed-transaction receipt by 151.63245682674 BSC-USD. The report attributes that difference to a possible pre-existing balance; it is an estimate, not a demonstrated allocation. The zero feeAmount field should not be rewritten as a claim that the sell and buy amounts were identical.

Diagram 2. The documented same-token settlement and the separate, unverified onward lead. Solid arrows represent the report’s confirmed settlement transfers. The dashed arrow represents a transfer the report explicitly marks unverified. Source: SentinelTX CASE-ASYNC020, pages 7–9 and 13.
Although the settlement contract carries an exchange label, this is not established as a custodial exchange deposit or a KYC identification point. Funds were paid to another EOA in the same block.
The report subsequently records a call at 13:20:27 UTC to an address publicly labeled “HOT Bridge: Treasury,” alongside a displayed transfer of 309,110.9980173841 BSC-USD. It explicitly treats that transfer and the service attribution as an unverified lead. The destination chain and subsequent movement were not established. A shared treasury’s unrelated payouts must not be assigned to this incident merely because they use the same address.
The report prioritizes preservation and examination of the possible bridge operator’s withdrawal records, CoW order-submission metadata and six Relay.link requests. It makes the bridge step conditional on establishing the operator’s address attribution. These are investigative recommendations, not claims that records have been obtained, assets frozen or funds recovered.
It also calls for contract-level analysis to establish the lender, principal and execution sequence, and review of the recipient’s remaining deployed contracts. The report assesses recovery prospects as below medium; that is its qualitative judgment, not a recovery probability or promise.

Figure 3. The source’s central conclusion and limits. Pair depletion and recipient receipt are different measures. Attribution and the destination beyond the onward lead remain unresolved. Source: SentinelTX CASE-ASYNC020, pages 12–13.
The practical conclusion is specific: report the pair’s net depletion, distinguish the recipient’s receipt, and follow the recipient-centered evidence rather than treating a short-lived caller as the whole operation. The documented settlement establishes movement after the incident. It does not establish a final cash-out, an ultimate beneficiary or a completed cross-chain route.
This article is a faithful English adaptation of SentinelTX CASE-ASYNC020, generated November 11, 2026. It is not an independent on-chain audit. The source’s primary narrative is on pages 3–13, with methodology and controlled-transaction records on pages 22–28.
The report reached three of five requested tracing stages. Several counterparties’ histories were not fully read, 35 labels were unresolved, and the chains beyond BNB Smart Chain and the limited Ethereum funding scope were not investigated. No absence of further movement is inferred from these limits.
The appendix excludes four addresses from its connected graph, including the post-settlement EOA and the possible treasury, because they were not directionally connected to the case origin in that graph. It explicitly states that preserved transfers alone do not confirm that funds passed through the case origin. Accordingly, this article does not present the appendix graph as proof of a complete proceeds route.
17 reads