#RANT Exploit Analysis
On July 05, 2025, #RANT Token was exploited through a vulnerability in the _transfer function on the BNB Smart Chain, resulting in the loss of approximately $204,000. Let's take a closer look at how the attack was carried out.
Original Attacker: https://bscscan.com/address/0xad2cb8f48e74065a0b884af9c5a4ecbba101be23
Vulnerable Contract: https://bscscan.com/token/0xc321ac21a07b3d593b269acdace69c3762ca2dd0
Attack Tx: https://bscscan.com/tx/0x2d9c1a00cf3d2fda268d0d11794ad2956774b156355e16441d6edb9a448e5a99
Attack flow
The #RANT Token smart contract extends the ERC20 standard with several custom mechanisms designed to control trading, manage liquidity and implement token burn events on its associated liquidity pool.
The _transfer function introduces complex logic to differentiate between buying, selling and liquidity-related operations. When either the sender or recipient is a liquidity pair, the contract determines whether the transaction adds or removes liquidity by comparing token reserves and balances in the pair contract. Buying is allowed only when openSwap is true or the recipient is the rant_center. Selling is permitted only when openSwap is true or the sender is the rant_center. Removing liquidity is unrestricted, whereas adding liquidity is tracked via addLpTime to schedule periodic burns.
The contract supports two types of burns from the liquidity pool:
Automatic burn (
_autoBurnLiquidityPairTokens): When called internally during normal transfers or externally by the owner viaBurnLiquidityPairTokens, this function reduces the pool's token balance based on a burn rate and a time-based exponent.
Sell-burn (
_sellBurnLiquidityPairTokens): Triggered during non-whitelisted transfers to the contract itself, this mechanism splits a specified amount between a "note" portion sent to therant_nodecontract and a "dead" portion sent to a burn address.
When a non-whitelisted user sends tokens to the contract itself, the _transfer override calls _sellBurnLiquidityPairTokens(amount). This mechanism aims to burn a portion of the liquidity pool whenever someone sells their tokens, making the token deflationary.
Instead of calculating the burn from the pool size, it takes the user's amount and divides it between 0xdead and rant_node. It then removes precisely these amounts from the token pair. This step drains virtually all of the LP's #RANT, leaving just a token or so in the pool.
The attacker flash-borrows WBNB from a Pancake V3 pool, approves the router, and swaps it for #RANT tokens on the #RANT/WBNB pair. At this point, the Pancake pair holds a balance of #RANT tokens.
The attacker then calls transfer with the token contract itself as the recipient. Because the sender is unwhitelisted and the recipient is address(this), this call triggers the "sell" branch of the _transfer function and invokes _sellBurnLiquidityPairTokens(amount).
After the transfers complete, _sellBurnLiquidityPairTokens calls PancakePair.sync(), which recalculates the reserves. The _transfer function then swaps the attacker's RANT for WBNB at the now-inflated price and returns the proceeds to the attacker.
After the token operations, the attacker repays the flash loan and withdraws the remainder.
Conclusion
The exploit occurs when _sellBurnLiquidityPairTokens trusts a user-supplied _amount to determine how many tokens to withdraw from the LP. This vulnerability allows attackers to manipulate the pool price. Sharing these insights highlights the critical need for thorough security audits and robust smart contract design to prevent manipulation, especially in decentralized exchanges. DeFi systems must implement effective risk mitigation strategies to protect user funds, as even minor flaws can lead to significant financial losses.