Mentioned in This Article
1. Tendril exploit drains about $555,000 from a BNB Chain pool
An attacker drained nearly all of the USDT backing the TENDRIL token on November 5, taking roughly $555,000 in net losses from the TENDRIL/USDT pool on PancakeSwap V2, a decentralized exchange on BNB Chain. Security analysts traced the theft to a flaw in the token's sell hook, a piece of custom code that runs whenever someone sells the token.
TENDRIL is a small token that had attracted little attention before the attack, and the incident is modest next to the largest thefts of the year. It is nonetheless a clear example of a recurring weakness in tokens that bolt extra logic onto standard templates, and the way the attack worked is instructive for developers and liquidity providers alike.
The sections below explain what a sell hook is, how the attacker used it to distort the pool's pricing, why the reported loss figures differ, and what the episode suggests for people who provide liquidity to young tokens.
2. What is a sell hook, and why did it matter here?
A hook, in this context, is custom code that a token contract runs when a particular action occurs. Many tokens on BNB Chain add logic to sells: a fee that is sent to a treasury, a burn that removes tokens from circulation, or an adjustment to a reserve. Developers use these features to give a token distinctive economics, usually by modifying a widely copied template.
The TENDRIL contract included one such sell hook. According to analysis from CertiK Alert, the hook allowed a seller to deduct tokens from the pair's balance and synchronize the pool's reserves before the remainder of the sale input had arrived. In other words, the contract let a participant change the pool's recorded holdings in the middle of a transaction.
That ordering is the heart of the problem. A pool is supposed to update its records only after assets have actually moved. When a token's own code can alter those records while a sale is still in progress, the exchange is working from numbers that no longer reflect reality.
To see why the timing matters, consider a simple analogy. A shop clerk who counts the till at the end of a transaction cannot be fooled by a customer who hands over money slowly. A clerk who updates the ledger the moment a customer says how much they intend to pay can be fooled by a customer who then pays less. The sell hook put the exchange in the second position, recording a change before the corresponding assets had been delivered.
3. How the attacker turned the flaw into a drain
Automated market makers such as PancakeSwap V2 do not use an order book. They price assets from the ratio of the two tokens held in a pool, so that when one side shrinks, the other becomes more valuable relative to it. The system is designed so that every trade moves the ratio in a controlled way and the pool always holds enough of each asset to honor trades.
In this case, the attacker used the sell hook to reduce the token side of the pool and sync the reserves before the rest of the sale input was delivered. The pool then saw a pair in which TENDRIL appeared scarce and USDT appeared plentiful relative to it. When the delayed input arrived and the sale was completed, the pool paid out almost all of its USDT at the distorted price.
The result was a net loss of about $555,000 for the pool. No private keys were stolen and no administrator account was compromised. The attacker simply used the contract's own sell logic, in the intended sequence of calls, to manipulate the arithmetic that the exchange trusted.
The pool's design assumes that the product of its two reserves stays roughly constant after each trade, apart from fees. Once the token reserve was reduced by the hook and synchronized, that relationship was recalculated around the wrong figure, and the trade that followed was priced against it. Nothing in the exchange's code was broken; the faulty input came from the token.
4. Why do the reported loss figures differ?
Early estimates of the damage were lower than the figure now in circulation. TenArmorAlert, a monitoring service, first reported a loss of approximately $309,000 on the TENDRIL/USDT pool. Later analysis, including the alert from CertiK Alert, put the net loss at about $555,000.
Gaps of this kind are common in the first hours after an exploit. Early alerts are typically generated automatically from the first suspicious transactions, and they may capture only part of a sequence that takes several steps. Analysts then trace every transaction, add up everything that left the pool, and net out any amounts that flowed back. The more complete the trace, the closer the estimate gets to the final figure.
Different methods can also produce different numbers from the same events. Total drained pool balance, attacker profit after costs, and net loss to liquidity providers are separate measures, and an outlet that reports one may not match an outlet that reports another. For this article the figure used is the roughly $555,000 net loss.
Readers comparing coverage of the incident should therefore check which measure each figure refers to before concluding that sources disagree. The numbers cited here come from monitoring services and security analysts that reviewed the same pool and the same transactions.
5. Custom token logic and the risks it brings
Tokens on BNB Chain are cheap to create, and many of them are built by copying a standard contract and adding features. A fee on sells, a burn, or a reflection mechanism that redistributes tokens to holders can all be written in a few lines. Each addition, however, creates a new path through which the token can interact with the exchange where it trades.
Standard exchange contracts assume that tokens behave predictably: a transfer moves a stated amount and nothing else changes. A token that burns supply, rewrites balances or triggers calls into the pool during a transfer breaks that assumption. The exchange cannot defend itself against it, because the exchange's own code is working as designed.
For this reason, audits of custom tokens focus heavily on the order of operations. A secure design finishes the movement of assets before it updates any state that other contracts rely on. Where state is changed first, an attacker can arrange for another contract, such as a liquidity pool, to read a value that is temporarily wrong.
Experienced auditors often describe this class of mistake as a failure to separate effects from interactions: a function should complete its own bookkeeping, then make external calls, and never let an external party observe a half-finished state. Tokens with hooks make that discipline harder, because the hook runs at the exact moment the exchange is mid-trade.
6. What it means for holders, liquidity providers and developers
For people who hold TENDRIL, the immediate problem is liquidity. With nearly all of the USDT gone from its main pool, there is little left to absorb sales, and the token's market price is no longer backed by meaningful reserves. Holders who wanted to exit through that pool face a market that has been largely emptied.
For liquidity providers, the lesson is that the safety of an established exchange does not extend to every token listed on it. A pool on a well-known venue is only as safe as the token contract on one side of it, so providers who deposit stablecoins next to a lightly reviewed token take on the risk of that token's code.
For developers, the practical guidance is to keep sell hooks and burn functions away from pool balances where possible, to complete all external transfers before changing any recorded state, and to commission an independent audit before a token attracts real liquidity. Reviewers specifically look for state changes made before transfers finish, the pattern the analysts identified in this case.
Traders who buy small tokens on decentralized exchanges can reduce exposure by checking whether the contract has been audited, whether it contains special sell or burn functions, and how much liquidity backs it. None of these checks eliminates risk, but together they help distinguish a plain token from one with extra moving parts that an attacker can study.
7. Where the incident fits in the wider pattern of DeFi exploits
Attacks on small BNB Chain tokens are frequent, and a number of them in recent months have followed a similar outline: a token with custom sell or burn logic, a thinly funded pool paired with USDT, and a single transaction sequence that empties the pool. Individually the losses are modest, but they add up across a year and feed the tallies kept by security firms.
The TENDRIL incident adds to that record. Because the attack required no stolen credentials, it also underlines how much of the risk in decentralized finance sits in code that is public and can be studied by anyone, including attackers looking for contracts whose logic can be turned against the pools they trade in.
Security firms publish regular tallies of losses from hacks and exploits, and incidents of this size usually appear in the count for the period in which they occur. They matter less for their dollar amounts than for the patterns they reveal, because the same coding mistake is often repeated by other teams that copy the same template.
8. What to watch next
Security firms that monitor the incident may publish further analysis of the vulnerable contract and the transaction trail, which could refine the loss estimate or show where the proceeds went.
For the wider market, the incident is a reminder to check how a token's contract treats sales before depositing funds into its pool, and to treat any token with custom hooks as higher risk until an independent review says otherwise.