How a privileged token function drained the 79AU pool

On October 7, 2026, the 79th Vault project’s hot-wallet key authorized nine transactions that removed 2,520,000 79AU from a PancakeSwap pool on BNB Smart Chain without paying the pool. Recipients could then sell the tokens back into that same pool to extract USDT and convert the proceeds to BNB. The decisive capability was inside the token contract: an administrative function could move the pool’s tokens directly to a chosen recipient.

The full incident extended beyond the first selling wallet described in the initial alert. SentinelTX’s October 9 investigation follows the wider nine-pull scope, the subsequent BNB consolidation and the on-chain negotiation. Its snapshot found approximately 17,881 BNB still held across three wallets, with no recovery recorded.

This article adapts the native SentinelTX report, “79th Vault (79AU) Privileged-Function Exploit — Investigation Report,” case CASE-ASYNCAF7. All incident findings and qualifications below come from that report. Times are UTC; balances and recovery status are its October 9 snapshot.

A token permission let 79AU leave the pool without payment

The 79AU token contract, the PancakeSwap pool and the project hot wallet had different roles. The token contract contained the function. The pool held the tokens. The hot-wallet key had permission to invoke it.

The function, identified by selector 0x2a2c5923, accepted a pool address, a recipient and an amount. A permitted caller could use those arguments to transfer 79AU from the pool to the recipient without a corresponding payment. The public analysis cited in the PDF describes this function as part of routine reward funding and says the deployer and hot wallet both held the permission when the drain occurred.

That changed the pool’s balances before any sale took place. Removing 79AU reduced the token side while leaving the USDT side in place, raising the quoted token price. Selling the removed tokens back then drew USDT out. The report illustrates the price effect with a source-reported move from $8.15 to $22.73 across the two 500,000-token pulls at 07:41.

Burning liquidity-provider receipts did not close this route. The PDF states that 79% of the pool’s LP receipts had been burned, protecting against liquidity withdrawal through those receipts. The token’s own permission still allowed it to move 79AU out of the pool.

Diagram 1. A privileged token transfer changed the pool’s balances before the tokens were sold back. This is a simplified explanatory diagram based on the report, not a screenshot of the native investigation graph.

Color key: Slate = privileged control; sage = 79AU movement; amber = USDT extraction.

Address/role key: Hot wallet 0x019bD8ED…30c85cA3; token 0xC35ef056…eeBaa9Ca; pool 0x02D50b93…f08FDa09.

Source: SentinelTX, “79th Vault (79AU) Privileged-Function Exploit — Investigation Report,” October 9, 2026, pp. 3 and 10.

Nine pulls reached three recipients

The first pull occurred at 07:25:23 on October 7: 10,000 79AU moved from the pool to the address the report calls Seller A. The transaction was signed by the hot wallet and called the privileged token function. Further pulls increased the amounts reaching Seller A, including a 500,000-token transfer at 07:38:40.

At 07:41:04, a separate 500,000 79AU went to Seller B. Four seconds later, another 500,000 went to Seller A. A third wallet received 10,000 at 08:07:29, according to the source chronology reproduced in the report. The ninth and final pull, at 08:18:59, sent a further 500,000 to Seller A.

The recipient totals define the scope:

• Seller A, 0xc3E90f78…4b80A099: 2,010,000 79AU across seven pulls
• Seller B, 0xf219d073…dd690938: 500,000 79AU in one pull
• Third wallet: 10,000 79AU in one pull; its purpose remains unexplained in the report

Figure 2. The initial withdrawals from the pool totaled 2,520,000 79AU across nine pulls. These are recipient token quantities, not dollar losses or balances after trading.

Color key: Slate = Seller A; sage = Seller B; amber = the third wallet.

Address/role key: Seller A is 0xc3E90f78…4b80A099; Seller B is 0xf219d073…dd690938. The PDF does not print a complete address for the third recipient.

Source: SentinelTX, October 9, 2026, p. 7, “The nine pulls.”

The initial CertiK alert summarized in the PDF covered Seller A: seven pulls, 2,010,000 79AU and approximately $12.5 million. The broader account adds Seller B and the third recipient, with approximately $14.35 million in USDT extracted. These dollar figures are the cited public write-up’s accounting of USDT that left the pool. They should not be added together or treated as a valuation of the tokens pulled.

Seller A’s selling window ran from 07:28 to 08:29. The cited write-up counts 92 sales and approximately $12.60 million in USDT proceeds for that branch; the PDF includes a PancakeSwap router call at 08:28:15. Seller B’s later sale of 500,000 79AU, between 12:48 and 12:59, is source-reported as 21 transactions for approximately $1.75 million. Its retained on-chain route in the PDF establishes the incoming 500,000-token pull; it does not establish a verified Seller B-to-pool return leg.

Seller B also existed before the incident. Its contract was created on August 23, six weeks before the drain. The cited analysis links its earlier gas funding to the wallet that funded Seller A on the morning of October 7. SentinelTX treats that as a pre-positioning indicator. It does not resolve the identity behind either seller.

Seller A’s proceeds converged with the hot wallet’s remaining BNB

At 10:10:47, Seller A sent 16,249.117811 BNB to the collection wallet, 0x629b368c…fe8a6231. This is the consolidation transaction associated with the initial alert.

Forty-one seconds later, at 10:11:28, the project hot wallet sent its remaining 3.790317 BNB to the same collection address. The shared destination links the pool-drain proceeds to the sweep of the hot wallet’s own BNB. SentinelTX assesses the sequence as evidence that the party controlling the key controlled both actions.

The collection wallet then distributed the BNB. A secondary wallet received 1,302 BNB and sent eight transfers of 10–20 BNB through fresh one-hop relays between 10:22:24 and 12:52:40. At 14:40:46, 1 BNB went through the Tornado.cash proxy to its 1 BNB pool. At 14:58:23, 14,394.916171 BNB moved to the main holding wallet. The collection wallet was empty by the report’s snapshot.

Figure 3. Selected onward BNB transfers from the collection wallet. Its cited incoming transfers were 16,249.117811 BNB from Seller A and 3.790317 BNB from the hot wallet. The diagram is not a complete reconciliation of every outgoing transaction, and arrow width does not encode amount.

Color key: Slate = collection and routes; sage = holding destinations; amber = the Tornado.cash proxy.

Address/role key: Collection 0x629b368c…fe8a6231; primary holding 0xa9537b40…b2174f89; secondary wallet 0x1e2a669e…f31216a3; Tornado.cash proxy 0x0d5550d5…859b17.

Source: SentinelTX, October 9, 2026, pp. 7–8 and 10.

The key-control evidence has a boundary. Chain data cannot settle whether an outsider stole the key or an insider misused it. The same key later signed the team’s negotiation message. The article therefore identifies addresses by their reported roles without assigning a real-world identity to the person who used the privilege.

Small exit routes accompanied much larger parked balances

Three deposits of approximately 10 BNB each reached the same KuCoin deposit address, 0x635308e7…8c7553d9, on October 7 at 10:41:49, 10:53:49 and 11:02:49. Together they account for approximately 30 BNB. The PDF identifies this as the only custodial cash-out point anchored by deposit transaction hashes in the trace, making the receiving account a focused lead for a freeze or KYC-information request.

A separate route reached a high-throughput cross-chain swap-service hub, 0xadd2b380…e792d1d. The report cites 10 BNB moving to a relay, followed by the onward leg and 7,619.37 USDT (BSC-USD), at 12:53:24–12:54:24. It assesses these funds as likely to have left BNB Chain. The destination-chain payouts are outside the screened scope, and the hub’s wider traffic cannot be assigned to this case.

The 1 BNB Tornado.cash interaction is consistent with a test deposit in SentinelTX’s assessment. Other Tornado.cash contracts observed nearby were not part of the traced flow. Together with the small exchange deposits and the relay transfers, the report interprets the activity as staged cash-out preparation while most proceeds remained parked.

As of October 9, the report listed:

• Main holding wallet, 0xa9537b40…b2174f89: 14,384.806266 BNB
• Seller B, 0xf219d073…dd690938: 2,284.478912 BNB
• Secondary wallet, 0x1e2a669e…f31216a3: approximately 1,212 BNB

The report summarizes these holdings as approximately 17,881 BNB. The earlier 14,394.916171 BNB transfer to the main holding wallet is a transaction amount; 14,384.806266 BNB is the later reported balance. A 10 BNB transfer on October 8 from that wallet to 0x789012dc…9233b935 has no established purpose in the report.

The bounty negotiation had produced no recovery

The on-chain conversation began on October 8. At 05:15:21, a message from the project hot wallet offered a 10% white-hat bounty, with 90% to be returned to a designated refund address and no further legal action.

At 11:48:59, the holding wallet countered at 25% and demanded removal of the address label and a waiver of legal action. A further message at 13:27:59 requested private contact through Telegram.

Those messages document negotiation. The designated refund address, 0x2bfcf047…262eb7b2, held 0.005274 BNB and no tokens in the report’s snapshot. SentinelTX recorded no returned assets. A bounty offer, a counter-demand and a request to continue talking did not establish a recovery.

The remaining pull permission was the central preventive issue

The source chronology says the team removed the original hot wallet’s pull permission at 08:24 on October 7 and stripped its rights across all eight project contracts by 16:13. On October 8, between 12:37 and 12:40, the team multisig granted the same permission to a new wallet.

According to the public write-up’s dry-run checks cited in the PDF, the deployer and newly added wallet retained or received the capability, leaving approximately 95% of the pool’s remaining 79AU pullable. SentinelTX’s preventive recommendation is to revoke that permission or migrate the contract before further user funds are exposed.

The case therefore leaves two practical priorities. On the investigative side, the three KuCoin deposits provide a specific custodial lead, while the large holdings and unresolved swap-service payouts remain important to follow. On the preventive side, the authority embedded in the token must be addressed. Replacing the wallet that holds a permission does not remove the permission’s ability to extract pool tokens.

Figure 4. The report’s October 9 conclusion pairs unrecovered holdings with a concrete custodial lead and a continuing permission risk. The approximately 95% pullability assessment comes from the cited write-up’s dry-run evidence. The destination-chain payouts remain outside the report’s scope.

Color key: Sage = holdings; slate = negotiation and recovery status; amber = investigative and preventive priorities.

Source: SentinelTX, October 9, 2026, pp. 3, 11 and 13–14.

Follow the holdings and unresolved outflows

A useful continuation starts with the collection transaction and asks what happened next to the identified holdings and exit routes. Keep the BNB Chain evidence separate from any proposed cross-chain match, and test a recovery claim against actual transfers to the designated refund address.

Request SentinelTX access or sign in, then use this starting prompt:

Investigate the 79th Vault / 79AU incident on BNB Smart Chain (chain ID 56), using transaction 0xee0e44167518ff0071ede02a03b3710a1a8438d52616aad4bf1d5e417b37b0df as the seed. Start with the October 7–9, 2026 activity described in case CASE-ASYNCAF7, then state the exact cutoff of any updated query. Follow the identified holding wallets and the cited KuCoin and swap-service outflows. Has there been a value-bearing continuation or a return to refund address 0x2bfcf0475e7b40cd68e91a7178cf5e43262eb7b2? Include transaction links and query times, distinguish directly supported findings from candidate relationships or inference, and keep any unestablished destination-chain payout outside the confirmed route.

Source note

The sole factual source for this adaptation is the native SentinelTX PDF dated October 9, 2026, case CASE-ASYNCAF7, “79th Vault (79AU) Privileged-Function Exploit — Investigation Report,” 34 pages. The incident occurred on October 7; the negotiation messages are dated October 8. The report’s October 9 query cutoffs fall between about 06:10 and 06:16 UTC; the PDF was generated at 06:33 UTC.

Dollar estimates, selected chronology and the residual-permission dry-run assessment retain the PDF’s attribution to its cited public write-up.