How the liquidity pools worked
At first glance, withdrawing liquidity from the 79AU/USDT pool on PancakeSwap looked difficult: most of its liquidity-provider tokens had reportedly been burned. Those tokens represent a holder’s share of the pool, so burning them blocks the usual way to withdraw.
But it did not necessarily close every route. A privileged function in the 79AU contract could still change how many tokens the pool held. So while holders may have been unable to redeem their LP tokens, the contract could still affect the liquidity itself. The pool looked locked, but the underlying control had not necessarily been removed.
The key distinction here is between being able to withdraw an LP position and being able to change what the pool holds. Burning LP tokens may block the usual withdrawal route, but it does not necessarily stop a privileged contract function from moving 79AU out of the pool. That could shift the market price and allow the tokens to be sold for USDT.
What happened with the withdrawals
On 7 October 2026, an address holding the 79AU contract’s OPERATOR_ROLE moved tokens from the PancakeSwap pool. Early reports put the amount at about 2.01 million 79AU, with proceeds of 16,249 BNB—roughly $12.5 million. A later Bitquery investigation traced activity through two selling wallets. It counted about 2.52 million tokens removed and estimated that roughly $14.35 million in USDT left the pool, with 17,881 BNB in proceeds at the time of its analysis. The figures differ because the early estimate covered one seller, while Bitquery’s analysis included a second sale several hours later.
Bitquery’s analysis suggests the function was part of the project’s routine activity, not a tool used only during the incident. Between June and the morning of the attack, it was reportedly called about 251,986 times, moving roughly 5.1 million 79AU into project contracts, including one used for rewards. Yet the same function could move tokens directly from the pool without payment. That raises a design question: how did a permission used in day-to-day operations also retain access to market liquidity?
The project blamed weaknesses in account-permission management. On-chain records show that the operator key signed the transfers, but they cannot show who controlled the key at the time. A compromised key and insider activity remain possible explanations; the available blockchain evidence does not establish which occurred. Bitquery’s investigation provides the transaction analysis.
Lets break down economics
The pool’s pricing formula helps explain how this permission could move the quoted price
before any USDT was withdrawn. Let be the 𝑥 pool’s 79AU reserve and 𝑦 its USDT reserve. The
spot price is approximately:
𝑃 = 𝑦/𝑥
In a standard constant-product market maker, a normal swap changes both reserves while
approximately preserving 𝑥𝑦 = 𝑘. The privileged transfer worked differently: it removed 79AU
without adding USDT. If 𝑞 tokens are taken out, the reserves change from (𝑥0, 𝑦0) to
(𝑥0 − 𝑞, 𝑦0) , making the new quoted price:
𝑃 1 = 𝑦0/𝑥0−𝑞
The same USDT reserve is now divided by fewer 79AU tokens, so the quoted price rises—even
though no new dollars have entered the pool. Bitquery reported that two transfers removed a
combined one million 79AU in about four seconds. Over that period, the quoted price rose from
roughly $8.15 to $22.73, an increase of about 179%.
(22.73/8.15) − 1 ≈ 1. 79
The price jump did not mean 79AU had suddenly become more valuable in any broader
economic sense. It reflected a change in the pool’s balance: the USDT reserve stayed put while
the number of 79AU tokens fell.
The reported price movement and token amount also allow a rough estimate of the pool’s starting
79AU reserve. If the USDT balance stayed constant while one million tokens were removed,
then:
𝑃1/𝑃0 = 𝑥0/(𝑥0−𝑞)
Rearranging gives:
𝑥 0 = 𝑞/(1−(𝑃0/𝑃1))
Using the reported price movement—from (P0= $8.15) to(P1=$22.73)—and the removal of
about 𝑞 = 1 million 79AU, we can estimate the pool’s starting token reserve:
𝑥 0 = 𝑞/(1−𝑃0/𝑃1) = 1,000,000/(1−8.15/22.73) ≈ 1. 56𝑚𝑖𝑙𝑙𝑖𝑜𝑛 79 𝐴𝑈
After the removal, that would leave roughly 560,000 79AU in the pool. If the USDT reserve
stayed unchanged, the original price implies it held about $12.7 million in USDT:
y₀ = P₀ × x₀ ≈ 8.15 × 1,560,000 ≈ 12,714,000 USDT (about $12.7 million)
Dividing that same USDT reserve by the smaller 79AU reserve gives a new quoted price of
about $22.70, close to the reported $22.73. On these assumptions, the pool’s 79AU reserve—and
the reserve product 𝑥𝑦—fell by roughly 64%. This is an estimate from the reported figures, not a
verified reserve balance.
The next phase works in the opposite direction: when 79AU is sold back into the pool, tokens
flow in and USDT flows out. In a standard swap, ignoring fees, the USDT output is:
Δ𝑦 = 𝑦𝑠/(𝑥+𝑠)
Here, 𝑥 and 𝑦 are the reserves after the removal, and 𝑠 is the amount of 79AU sold. Using the
estimated post-removal reserves—about 560,000 79AU and $12.7 million USDT—a sale of one
million 79AU would return roughly $8.1 million USDT, before fees. That figure is only an
illustration based on the reserve estimate, not a reconstruction of the incident’s total proceeds.
The formula also shows why the displayed price is not the price a large seller receives for every
token: as tokens enter the pool, its reserves shift, and each additional token returns less USDT.
The earlier privileged removal changed the reserves the swap began with, so the ordinary swap
formula explains the selling phase but not the manipulation that came before it.
The pool reportedly held about $15.2 million in USDT before the first major sale. Roughly an
hour later, the reserve was down to about $3.9 million—a fall of around 74%:
($15.2 𝑚𝑖𝑙𝑙𝑖𝑜𝑛 − $3.9 𝑚𝑖𝑙𝑙𝑖𝑜𝑛)/$15.2 𝑚𝑖𝑙𝑙𝑖𝑜𝑛 × 100% ≈ 74. 3%
That figure measures how much USDT had left the pool between those two points in time. It is
not a measure of every stakeholder’s total loss, and it is different from the later estimate of
$14.35 million in USDT outflows. One compares the pool’s balances at two moments; the other
adds up proceeds across the selling activity. The figures are related, but they describe different
things. Bitquery’s investigation reports the underlying analysis.
Why all of this is a problem
The distinction points to a wider problem: a token’s spot price is not the same as the amount
holders could actually get by selling. Market capitalization is commonly estimated by
multiplying the spot price by the circulating supply. But the spot price reflects the rate for a small
trade at that moment. It does not tell us how much USDT all holders could collectively withdraw
if they tried to sell into the pool.
For a holder with tokens, multiplying the 𝑄 quantity by the spot price gives a headline value:
𝑉𝑠𝑝𝑜𝑡 = 𝑄 × 𝑃𝑠𝑝𝑜𝑡
But that assumes every token can be sold at the current quoted price. In a shallow pool, a large
sale changes the reserves, so the price received can fall as the sale progresses. The holder’s
realizable value is the USDT actually collected across the sales:
𝑉𝑙𝑖𝑞𝑢𝑖𝑑𝑎𝑡𝑖𝑜𝑛 = 𝑛 [ Σ 𝑦𝑖 ] 𝑖=1
Here, 𝑦 is the USDT received in each sale or tranche. The gap between the spot-marked value 𝑖
and the liquidation value is the liquidity discount:
𝐷𝑙𝑖𝑞𝑢𝑖𝑑𝑖𝑡𝑦 = 1 − (𝑉𝑙𝑖𝑞𝑢𝑖𝑑𝑎𝑡𝑖𝑜𝑛/𝑄×𝑃𝑠𝑝𝑜𝑡)
Multiply 𝐷 by 100 % to express it as a percentage. The larger the holder’s sale is relative 𝑙𝑖𝑞𝑢𝑖𝑑𝑖𝑡𝑦
to the pool’s depth, the more likely the amount they can actually receive will fall below the
spot-marked value.
In the 79AU incident, the sequence had two stages: the privileged transfer reduced the pool’s
supply of 79AU, then the subsequent sales drew USDT out. The quoted price rose after the token
reserve shrank, but that higher price did not show how much holders could actually recover by
selling in larger quantities.
The function’s repeated use to fund rewards raises a further question about how the market price
was shaped. Moving 79AU from the pool into reward contracts without adding USDT could
shrink the token reserve and push up the quoted price. That alone does not show the rewards
were designed to inflate the price, or that recipients relied on the spot quote. It does highlight a
practical issue: a token reward’s headline value may differ sharply from what its recipient can
actually sell it for.
A token reward can look more valuable on paper than it is in practice. If a user receives 𝑅 tokens,
its displayed value is 𝑅 × 𝑃 . The amount the user can actually recover depends on how much 𝑠𝑝𝑜𝑡
USDT the pool can pay out as those tokens are sold. In a shallow pool—or one with permissions
that can change its reserves—the two figures may be far apart. To understand how the rewards
affected the market, an analysis would need to compare token movements into reward contracts
with distribution dates, subsequent sales and changes in pool reserves. The reported number of
function calls alone does not show how many tokens each call moved or whether recipients sold
them.
The effects of this go beyond a single protocol
The effects may also have reached beyond the immediate USDT outflow. Liquidity providers
may have been left with a less useful position; 79AU holders may have faced a less reliable price
and a harder exit; and later traders may have encountered greater slippage as the pool’s USDT
reserve shrank. These effects are connected, so they should not simply be added together as
separate losses. A drop in 79AU’s market value, for example, may already reflect the same
liquidity shock recorded in the pool.
There was also a risk in how safety signals were interpreted. Bitquery reported that 79% of the
pool’s LP tokens had been burned—a fact often taken to mean that liquidity cannot be withdrawn
through ordinary LP redemption. But a separate permission in the 79AU contract could still
move tokens out of the pool. For investors, the distinction is crucial: burned LP tokens addressed
one way of accessing the reserves; they did not rule out every way the contract could change the
pool’s assets. Bitquery’s investigation reports the on-chain analysis.
For liquidity providers, the return is about more than trading fees and token rewards. They also
have to account for security risk, market losses and the cost of monitoring their position. Over a
given period, a simplified estimate of the net return rate is:
𝐸(𝑅 𝐿𝑃) = (𝐹+𝐼−𝐸(𝐿𝑠𝑒𝑐𝑢𝑟𝑖𝑡𝑦)−𝐿𝑚𝑎𝑟𝑘𝑒𝑡−𝐶𝑜𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛)/𝐾
Here, 𝐹 is fee income, 𝐼 is token incentives, 𝐾 is the capital committed, and the remaining terms
represent expected security losses, market-related losses and operating costs. These amounts
need to cover the same period and be measured consistently.
Expected security loss can be estimated as:
𝐸(𝐿 𝑠𝑒𝑐𝑢𝑟𝑖𝑡𝑦) = 𝑝𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑡 × 𝐸𝑒𝑥𝑝𝑜𝑠𝑒𝑑 × 𝐿𝐺𝐷
In this expression, 𝑝 is the probability of an incident during the chosen period, is 𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑡 𝐸𝑒𝑥𝑝𝑜𝑠𝑒𝑑
the value subject to the relevant permission, and 𝐿𝐺𝐷 is the share that would not be recovered if
an incident occurred.
The available evidence does not allow those values to be estimated reliably for 79AU. The
framework still helps show what liquidity providers would need to consider: a permission
capable of moving a large share of a pool increases the potential exposure. If providers see that
risk as higher, they may demand a better expected return or move their capital elsewhere.
That can create pressure on the project to offer larger incentives to maintain pool depth. If capital
leaves and depth falls, even moderate trades can move the price more sharply. This is a plausible
negative feedback loop; the available evidence does not establish that it occurred after the
incident.
Why security teams need to care
For security companies, the 79AU case shows why monitoring should follow changes in the
pool’s economic state, not just count contract calls. An alert for every use of the pull function
could have produced constant noise because it was reportedly used often for routine rewards. A
more informative alert would connect several events: an authorized address removes tokens
without a matching payment; the pool’s reserves update; its quoted price rises even though no
USDT has entered; a connected wallet sells the tokens; and the pool’s USDT balance falls.
One way to frame that analysis is to track each participant’s change in net position:
Δ𝑊𝑖 = 𝑎𝑠𝑠𝑒𝑡𝑠𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑𝑖 − 𝑎𝑠𝑠𝑒𝑡𝑠𝑐𝑜𝑛𝑡𝑟𝑖𝑏𝑢𝑡𝑒𝑑𝑖 − 𝑛𝑒𝑤𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡𝑖𝑒𝑠𝑖
If an outside address gains assets while the pool loses a corresponding amount, the system can
check whether an ordinary trade or documented project action explains the movement. That
shifts the question from simply “Which wallet received the funds?” to “How did value move
between the pool, the project and the seller?”
The incident also shows why a review should verify that the risky permission itself has been
removed. In an 8 October snapshot, Bitquery reported that the deployer still held the pull
permission and that a new wallet had been granted it after the drain. Read-only tests at the time
indicated that either address could pull most of the 79AU still in the pool. The tests did not move
funds, and they describe the contract at that date, not its current state. But they point to a
remediation risk: removing one operator key may not close the exposure if the same permission
remains with another address.
The economics of prevention can be framed simply: compare the cost of a security control with
the loss it is expected to prevent. If a control lowers the probability of an incident from 𝑝 to , 0 𝑝1
and the potential loss is 𝐿, the reduction in expected direct loss is approximately:
(𝑝 0 − 𝑝1)𝐿
A fuller assessment would also consider costs the control might prevent indirectly, such as
reputational damage or disruption to the pool’s liquidity. The available evidence does not provide
reliable estimates for 𝑝 or , so it cannot show whether multisignature approvals, timelocks, 0 𝑝1
role limits or monitoring would have been cost-effective in this specific case. It does give
projects a useful question to ask: does the value exposed to a permission justify stronger
controls?
How did they recover
The recovery added another layer. On 9 October, 15,000 BNB was returned to an address
designated by 79th Vault. That equals about 92% of the initial estimate of 16,249 BNB, or about
84% of Bitquery’s later estimate of 17,881 BNB. The return was substantial, but the percentage
depends on which estimate is used. Reporting available at the time did not establish the status of
the remaining funds.
Bitquery reported that the project initially offered a 10% bounty, while the attacker asked to keep
25% and sought an end to legal action. The later return does not show what motivated the
attacker or which terms were agreed. It can, however, be viewed as a bargaining problem. If 𝑉 is
the value of the funds held, 𝑝 is the perceived chance of losing access to them, and 𝑏 is the share
the attacker would keep as a bounty for returning the rest, a simplified comparison is:
𝐸 𝑘𝑒𝑒𝑝 = (1 − 𝑝)𝑉
𝐸 𝑟𝑒𝑡𝑢𝑟𝑛 = 𝑏𝑉
In this simplified model, returning the funds is financially more attractive when the bounty share
exceeds the expected value of keeping them. The model cannot tell us what the attacker actually
calculated. It does show how tracing, cooperation from exchanges, enforcement risk and limits
on cashing out could all affect negotiations.
What can we take away from this
The bigger concern is that a contract permission can change both the price people see and how
much the pool can actually pay out. If users are unsure what “locked liquidity” really protects,
they may ask more questions before committing funds—or choose pools with permissions and
accounting that are easier to understand. Projects relying on token rewards or their own reserves
might then have to offer stronger incentives to attract liquidity. That’s a possible knock-on effect;
there’s no evidence that funds broadly moved away after this incident.
The 79th Vault incident wasn’t simply a case of money disappearing from a pool. A privileged
permission changed the token reserves, pushing up the quoted price without adding USDT. The
later sales then pulled stablecoins out, leaving a thinner and less dependable market. The return
of 15,000 BNB reduced the apparent loss, but it didn’t settle the central question: what did
“locked liquidity” actually protect against?
For security companies, the challenge is to follow the consequences of a permission: how it
changes reserves, prices and the positions of everyone involved. Traders and liquidity providers
can ask a few practical questions: Who can change the pool’s assets? Could that move the quoted
price without new money entering? And if holders tried to sell, how much could they actually get
back?
