79thVault deployer drains $14.35 million PancakeSwap pool despite burned LP tokens
A $14.35 million drain from a PancakeSwap liquidity pool for 79AU reveals that burned LP tokens, a standard safeguard against rug pulls, cannot prevent an admin function baked into the token itself from extracting value without compensation. Institutional investors and DEX protocols now face a design flaw that affects staking projects with dual governance: the ability to lock liquidity does not guarantee that founders cannot drain a pool through alternative mechanisms.
- 79thVault’s deployer used a privileged token function to pull 2.52 million 79AU from the pool without payment on October 7, 2026, then sold it for $14.35 million in USDT
- 79% of the pool’s liquidity provider receipts had been burned to signal immutable liquidity, yet the exploit bypassed LP token redemption entirely
- Two wallets retain the ability to pull approximately 95% of remaining 79AU from the pool without paying, raising questions about whether the drain has actually ended
- $14.35M USDT extracted from 79AU pool via unauthorized pulls in October 2026
- 251,986 times the project legitimately used the same function for four months to pay rewards
- 79% of LP token receipts were burned, but did not prevent the drain
A critical vulnerability in 79thVault’s token design allowed an attacker to drain its largest liquidity pool by exploiting a built-in administrative function that bypassed all standard protections. According to a Bitquery investigation, between 07:41 and 12:32 UTC on October 7, 2026, two wallets pulled 2.52 million 79AU tokens directly from the pool and sold them back for $14.35 million in USDT, the full measure of the loss, which exceeded earlier estimates. The deployer’s hot wallet held the key to an administrative permission embedded in the 79AU smart contract that allowed token removal without payment. No purchase was necessary; the pool simply updated its price ratio as if a legitimate buyer had arrived and departed. Over four months the project had used the same function 251,986 times to fund its staking rewards, moving roughly twice the pool’s daily token inventory in aggregate.
Burned liquidity tokens did not stop coins moving out of the pool
PancakeSwap V2 documentation describes LP tokens as receipts that represent a provider’s share of a liquidity pool’s assets. When liquidity providers deposit capital, they receive these receipts; holding a receipt gives the holder redemption rights over that portion of the underlying token pair. To prevent founder rug pulls, 79thVault burned 79% of the pool’s LP tokens by sending them to a dead address that no one controls, rendering that share permanently non-redeemable.
The drain circumvented LP redemption entirely. Instead of cashing in a liquidity receipt to remove paired tokens, the attacker used a separate, privileged function written into the 79AU token contract itself, a transfer permission that allowed a specified wallet to move coins out of the pool without consuming LP receipts and without reducing the pool’s USDT reserves in exchange.
Two free pulls at 07:41 UTC illustrate the mechanism. Each extracted 500,000 79AU without moving a single USDT dollar out of the pool. The pool’s price, calculated as USDT divided by 79AU, jumped from $8.15 to $22.73 in four seconds.
Those coins were then sold back into the pool for real dollars. The pool’s internal balance records showed the 79AU side shrank while the USDT side remained static during the pulls; only the ratio changed, and a rational seller would profit from the artificial spike.
Two wallets can still access the same extraction function
The vulnerability persists. According to Bitquery’s read-only simulation of the current contract state, two wallets retain the ability to pull approximately 95% of the remaining 79AU from the pool without payment: the deployer wallet and a new wallet added to the permission set on October 8, 2026, the day after the drain.
Meanwhile, roughly 17,881 BNB, the proceeds from the $14.35 million drain converted to the blockchain’s native token, sits across three wallets. An on-chain message from the attacker asked to retain 25% of the stolen value; the team countered with an offer of 10%. The negotiation remained unresolved as of the Bitquery report.
A single LP token holder retaining 21% of the original receipts does possess ordinary redemption rights over their share, but that applies only to the dwindling liquidity remaining after the pulls.
The design flaw affects any project mixing privileged token transfers with locked liquidity
This attack exploits a fundamental architectural mistake: the assumption that burning LP tokens removes all paths to drain a pool. That assumption holds only if the token itself has no special privileges. Most ERC-20 tokens, and their BNB Chain equivalent BEP-20 tokens, allow only the token owner or an explicitly approved spender to move coins.
Standard liquidity pools rely on that constraint: LP tokens grant withdrawal rights, and nothing else touches the pool’s reserves.
79AU inverted the model. It granted an admin-level permission function, a transfer mechanism that works independently of the LP mechanism. This is not inherently malicious; many projects use such functions to automate reward distribution or rebalancing.
The error was leaving that function active and non-revocable after launching to users. A properly designed token would have either removed the function after launch, restricted it to non-pool wallets, or placed it under multi-signature control requiring consensus to execute.
The comparison to past protocol exploits is instructive: Jonathan Spalletta was convicted for $53 million in Uranium Finance hacks by exploiting unpatched smart contract logic, though in that case the vector was a direct contract vulnerability rather than a legitimate-but-misused administrative function.
For institutional investors and DEX integrators, this case demonstrates that visibility of burned liquidity alone is insufficient due diligence. A pool can report 79% locked liquidity while remaining vulnerable to extraction through parallel mechanisms.
Any staking or treasury project offering pool-based redemption should publish its full token contract and undergird its privileged functions, if any exist, with either multi-signature escrow, timelock delays, or permanent revocation.
The CCS read. We see institutional LP providers now facing a new risk category: administrative functions in the token contract itself, distinct from the liquidity pool’s own code. Burned LP tokens became a marketing signal trusted by retail users but did not constrain the actual threat surface. This will likely prompt a shift toward requiring privileged function disclosure in due diligence frameworks, and toward preferring tokens with no special permissions over those with “dormant” admin keys. Projects claiming locked liquidity must now prove the token’s transfer logic blocks all paths to drainage, not merely the LP path.
The immediate question for 79thVault stakeholders is whether the team will execute a contract upgrade to permanently revoke the remaining two wallets’ extraction permissions, and whether they have committed to a timeline for doing so. Until then, the 95% of remaining 79AU said to be at risk remains extractable, and the current settlement negotiations over the stolen funds may prove moot if a second drain occurs.
