Calculated from recorded token losses using historical USD prices at the incident time.
0x4f8cb9efb3cc9930bd38af5f5d34d15ce683111599a80df7ae50b003e746e3360x37e42b961ae37883bac2fc29207a5f88efa5db66BSC0x1ad2cb3c2606e6d5e45c339d10f81600bdbf75c0BSC0xb4f4cd1cc2dff1a14c4aaa9e9434a92082855c64BSCOn BNB Chain block 31108559, transaction 0x4f8cb9efb3cc9930bd38af5f5d34d15ce683111599a80df7ae50b003e746e336 used a public DODO flash loan to buy GSS, distort pair balances, chain two permissionless skim() calls across the GSS/USDT and GSS/GSSDAO pairs, and then dump the extracted GSS back into USDT. The attacker contract 0x69ed5b59d977695650ec4b29e61c0faa8cc0ed5c finished with 24883439810865059102747 raw USDT units of profit after repaying the 30000000000000000000000 raw-unit flash loan principal, while the GSS/USDT pair lost 25964719534010397527333 raw USDT units.
The root cause is that GSS applies pair-specific fee logic whenever either transfer endpoint equals a tracked pair address. That logic does not distinguish real buys and sells from permissionless pair-maintenance transfers such as skim(). As a result, skim() transfers on GSS-bearing pairs trigger fee redistribution, create fresh excess balances, and let any public caller route and extract unreserved GSS.
skim(address) on a UniswapV2-style pair is permissionless. It transfers balance(token) - reserve(token) to an arbitrary recipient without updating stored reserves. Under normal token semantics, skim() is a reserve-maintenance helper, not a taxable trade.
GSS tracks two AMM pairs in token state: uniswapV2Pair0 for GSS/USDT and for GSS/GSSDAO. The verified GSS source shows that dispatches any transfer touching either pair into or , and those routines always call fee-taking helpers when the sender and recipient are not fee-exempt.
uniswapV2Pair1_transferprocessPair0processPair1if (from == uniswapV2Pair0 || to == uniswapV2Pair0) {
processPair0(from, to, amount);
}
if (from == uniswapV2Pair1 || to == uniswapV2Pair1) {
processPair1(from, to, amount);
}
Inside those paths, _tokenTransfer0 and _tokenTransfer1 deduct holder, burn, LP, and buyback fees before forwarding the remainder. That behavior is appropriate only for genuine pair trades. Once it is applied to pair maintenance, the token and pair accounting diverge.
The vulnerability is an application-level accounting bug in GSS, not a PancakePair flaw. GSS classifies transfers entirely by whether from or to equals a tracked pair address, so a permissionless skim() transfer is treated exactly like a buy or sell. In processPair0 and processPair1, the token then routes the transfer into _tokenTransfer0 or _tokenTransfer1, which remove fees and send portions of the transferred amount to the token contract, the dividend tracker, burn address, LP receiver, and buyback receiver. That breaks the expected invariant for pair maintenance: a skim() call should reduce balanceOf(pair) - reserve(pair) by the amount skimmed and should not create new excess balances elsewhere. Here, skimming from the GSS/USDT pair into the GSS/GSSDAO pair produced fee side effects and a downstream excess balance, and skimming from the second pair to the attacker repeated the same mistake. Because both skim() and sync() are public, any unprivileged actor with enough temporary capital could reproduce the sequence.
The critical breakpoint is the pair-address routing in the verified GSS token:
function _transfer(address from, address to, uint256 amount) internal override {
...
if (from == uniswapV2Pair0 || to == uniswapV2Pair0) {
processPair0(from, to, amount);
}
if (from == uniswapV2Pair1 || to == uniswapV2Pair1) {
processPair1(from, to, amount);
}
...
}
processPair0 and processPair1 do not inspect call context. They only inspect the transfer endpoints and then execute fee-taking paths:
// transfer amount, it will take tax, burn, liquidity fee
_tokenTransfer0(from, to, amount, takeFee);
...
// transfer amount, it will take tax, burn, liquidity fee
_tokenTransfer1(from, to, amount, takeFee);
In _tokenTransfer0, a transfer with recipient == uniswapV2Pair0 is treated as a sell and charged sellLpFee0 + sellBuyBackFee0, sellHoldersFee0, and sellBurnFee0. In _tokenTransfer1, a transfer with sender == uniswapV2Pair1 is treated as a buy and charged buyLpFee1, buyBuyBackFee1, and buyBurnFee1. Those branches are exactly what a skim()-initiated pair transfer hits.
The seed trace shows the complete exploit realization:
0x9ad32e3054268B849b84a8dBcC7c8f7c52E4e69A::flashLoan(..., 30000000000000000000000, ...)
PancakeRouter::swapExactTokensForTokensSupportingFeeOnTransferTokens(30000000000000000000000, ...)
GSS::transfer(PancakePair: [0x1ad2...75C0], 707162351662098288993328)
PancakePair::skim(0xB4F4cD1cc2DfF1A14c4Aaa9E9434A92082855C64)
0xB4F4cD1cc2DfF1A14c4Aaa9E9434A92082855C64::skim(0x69ED5B59D977695650eC4B29E61c0Faa8cc0ed5C)
PancakeRouter::swapExactTokensForTokensSupportingFeeOnTransferTokens(1232737198706559843688819, ...)
BEP20USDT::transfer(0x69ED5B59D977695650eC4B29E61c0Faa8cc0ed5C, 54883439810865059102747)
BEP20USDT::transfer(0x9ad32e3054268B849b84a8dBcC7c8f7c52E4e69A, 30000000000000000000000)
Step by step, the attacker borrowed 30,000 USDT from the public DODO pool, bought GSS through PancakeRouter, then transferred almost the entire GSS/USDT pair balance worth of GSS directly into pair0 to manufacture a large excess balance. When pair0 skimmed to pair1, GSS treated the pair-originated transfer as a taxed pair transfer instead of neutral maintenance. After pair0.sync(), the attacker skimmed pair1 back to the attacker contract, again triggering pair-originated fees. The attacker then sold the extracted GSS back into pair0 for 54883439810865059102747 raw USDT units, repaid the flash loan principal, and retained the remainder.
The balance diff confirms the economic result. The attacker contract gained 24883439810865059102747 raw USDT units, the GSS/USDT pair lost 25964719534010397527333 raw USDT units, and smaller portions were redistributed to fee destinations and token-side accounting buckets. No USDT-denominated fee remained unpaid at transaction end; gas was paid separately in BNB by the sender EOA, so the USDT profit predicate is deterministic.
The adversary cluster contains EOA 0x84f37f6cc75ccde5fe9ba99093824a11cfdc329d, which submitted the transaction and paid gas, and helper contract 0x69ed5b59d977695650ec4b29e61c0faa8cc0ed5c, which executed the exploit logic.
The on-chain sequence was:
30000000000000000000000 raw USDT units from the public DODO flash-loan pool 0x9ad32e3054268B849b84a8dBcC7c8f7c52E4e69A.0x10ED43C718714eb63d5aA57B78B54704E256024E.0x1ad2cb3c2606e6d5e45c339d10f81600bdbf75c0 to create skimmable excess over reserves.pair0.skim(pair1) to move excess GSS into the GSS/GSSDAO pair 0xb4f4cd1cc2dff1a14c4aaa9e9434a92082855c64, while GSS fee logic mutates the amount in transit.pair0.sync() so the first pair records its new balances and the manipulated state persists.pair1.skim(attacker) to extract the enlarged excess from the second pair into the attacker contract, again through fee-taking token logic.This is an ACT path because every primitive used in the sequence was permissionless and public: flash liquidity, router swaps, pair skim(), and pair sync(). No privileged role, private key compromise, or attacker-only artifact was required to realize the exploit.
The immediate victimized asset was the USDT liquidity in the GSS/USDT pair. The pair balance diff shows a loss of 25964719534010397527333 raw USDT units. The attacker contract realized 24883439810865059102747 raw USDT units of profit. The gap between gross pool loss and attacker profit was redistributed into GSS-side fee destinations such as the token contract, dividend tracker, burn address, and related fee receivers during the misclassified pair transfers.
Affected public components were:
0x37e42b961ae37883bac2fc29207a5f88efa5db660x1ad2cb3c2606e6d5e45c339d10f81600bdbf75c00xb4f4cd1cc2dff1a14c4aaa9e9434a92082855c640x4f8cb9efb3cc9930bd38af5f5d34d15ce683111599a80df7ae50b003e746e3360x84f37f6cc75ccde5fe9ba99093824a11cfdc329d0x69ed5b59d977695650ec4b29e61c0faa8cc0ed5c0x37e42b961ae37883bac2fc29207a5f88efa5db660x1ad2cb3c2606e6d5e45c339d10f81600bdbf75c0, GSS/GSSDAO at 0xb4f4cd1cc2dff1a14c4aaa9e9434a92082855c640x9ad32e3054268B849b84a8dBcC7c8f7c52E4e69A0x10ED43C718714eb63d5aA57B78B54704E256024E/workspace/session/artifacts/collector/seed/56/