RANT Token Exploit

Introduction

Decentralized finance (DeFi) protocols promise innovation but often come with hidden risks. A recent exploit on the RANT token’s PancakeSwap pair, executed just six hours after liquidity was added, showcases how a seemingly harmless transfer hook can turn into a devastating liquidity drain. This blog post dives into the mechanics of the attack, its impact, and the lessons it offers for DeFi developers and users.

The Vulnerability

On July 3, 2025, the RANT token contract was deployed on the Binance Smart Chain (BSC). Two days later, on July 5, 150 WBNB in liquidity was added to its main PancakeSwap pair. However, a critical flaw in the token’s transfer logic allowed anyone to send RANT tokens directly to the contract address, triggering the _sellBurnLiquidityPairTokens public function. This function burned liquidity proportional to the transferred amount, creating an opportunity for extreme price manipulation.

f4tu gave a clearer understanding of the attack flow on how the attacker carried out the attack by analyzing these flawed logic.

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 via BurnLiquidityPairTokens, 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 the rant_node contract 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).

How the Exploit Unfolded

The attacker executed a meticulously planned attack, leveraging a flash loan and the token’s flawed logic to drain liquidity and profit significantly. Here are the steps:

Flash Loan Acquisition: The attacker borrowed 2,813 WBNB using a flash loan to fund the exploit.
Token Swap: They swapped the 2,813 WBNB for ~96.6M RANT tokens, heavily loading the PancakeSwap pool and gaining control over the token supply.
Pool Imbalance: Post-swap, the pool’s balance was 10.7M RANT against 3,125 WBNB, causing RANT’s price to rise significantly.
Triggering the Burn: The attacker transferred over 90% of the pool’s RANT (~10.7M tokens) to the token contract, activating the _sellBurnLiquidityPairTokens function. This burned a massive portion of the pool’s liquidity, further inflating the price.
Additional Burn: The remaining RANT tokens were sent to a node for burning, reducing the pool to just 1 RANT against 3,125 WBNB.
Price Manipulation: The drastic reduction in RANT supply caused the token’s price to skyrocket by over 100,000,000%.
Token Forwarding: The RANT contract forwarded the 10.7M RANT to the rant_center contract, viewable here.
Profit Extraction: Exploiting the manipulated price, the attacker swapped just 3.8M RANT back into the now critically imbalanced pool, draining all 3,125 WBNB.

The Outcome

The attacker walked away with a profit of 312 WBNB, equivalent to approximately $245,000, after repaying the flash loan. The exploit decimated the PancakeSwap pool’s liquidity, leaving it with just 1 RANT against 3,125 WBNB. The attack, executed in a mere six hours after liquidity was added, highlights the speed and precision with which vulnerabilities can be exploited in DeFi.

Why This Matters

This exploit is a textbook example of how a single design flaw—in this case, an unprotected transfer hook—can lead to catastrophic consequences. The _sellBurnLiquidityPairTokens function, likely intended as a benign feature, became a critical vulnerability when exploited. The attacker’s ability to manipulate the pool’s price and drain its liquidity underscores the importance of rigorous security audits and robust contract design in DeFi protocols.

Lessons for DeFi Developers

Audit Transfer Hooks: Any function that can be triggered by external actions, such as token transfers, must be thoroughly audited for unintended consequences.
Limit Public Functions: Public functions like _sellBurnLiquidityPairTokens should be restricted or protected with access controls to prevent unauthorized execution.
Simulate Attacks: Developers should simulate flash loan attacks and other exploits during testing to identify vulnerabilities in liquidity pools.
Community Vigilance: DeFi users and auditors should scrutinize newly deployed contracts, especially those with significant liquidity additions, to catch flaws early.

Conclusion

The RANT token exploit serves as a stark reminder of the fragility of DeFi protocols when security is overlooked. By exploiting a flawed transfer hook, the attacker turned a seemingly harmless feature into a powerful liquidity drain vector, profiting $245,000 in just six hours. This case study emphasizes the need for meticulous contract design, comprehensive audits, and proactive community oversight to protect DeFi ecosystems from such vulnerabilities.

Stay informed, stay secure, and always double-check the code behind the protocols you trust.

The RANT Token Exploit: A Case Study in DeFi Vulnerabilities