We do not have a reliable USD price for the recorded assets yet.
0x8490aa884adb08a485bc8793c17296c9e2c91294BSCThe incident was a deterministic sandwich against a public MOMO buy-order contract on BNB Chain. In tx 0x9191153c8523d97f3441a08fef1da5e4169d9c2983db9398364071daa33f59d1, attacker helper contract 0xc59d50e26aee2ca34ae11f08924c0bc619728e7c first bought MOMO with 9350000000000000000000 USD1, then called the victim's public selector 0x5ff02eae, causing victim contract 0x8490aa884adb08a485bc8793c17296c9e2c91294 to spend its full 48758887289057478885525 USD1 balance through the same Pancake V3 MOMO/USD1 fee-100 pool. The attacker then sold MOMO back into that pool, repaid 9350935000000000000000 USD1 to the temporary funder, and retained 48264803792092412941512 USD1.
The root cause was a public execution path that performed a large same-pool USD1-to-MOMO swap without a slippage guard that survived same-block price movement. That made the order atomically sandwichable by any unprivileged searcher able to source temporary liquidity and sequence buy -> victim trigger -> sell in one transaction.
The victim contract 0x8490aa884adb08a485bc8793c17296c9e2c91294 is unverified, so the analysis depends on bytecode and storage evidence. Live storage reads resolve:
slot 0 = 0x5dda362775267d2c77d8a49583751174efa47e1c
slot 1 = 0x0b9ddfca570305128d347a263d7061e1eb774444
slot 2 = 0x2c79bb8155acbaa38d96bdb5c770d2372c509a32
Origin: victim storage reads collected during the revised auditor pass.
That means the contract's beneficiary is , its output token is MOMO , and its configured pool is Pancake V3 pool .
0x118efd91bf0520d832918c57e74f0911e10f988709c27e0ce580c2cfef491cf70x5dda362775267d2c77d8a49583751174efa47e1c0x0b9ddfca570305128d347a263d7061e1eb7744440x2c79bb8155acbaa38d96bdb5c770d2372c509a32Victim runtime disassembly also exposes the public entrypoint and the swap path ingredients:
00000013: PUSH4 0x5ff02eae
0000016e: PUSH20 0x8d0d000ee44948fc98c9b98a4fa4921476f08b0d
000001cf: PUSH4 0x095ea7b3
000001d9: PUSH20 0x1b81d678ffb9c0263b24a97847620c99d213eb14
000002ca: PUSH4 0x414bf389
00000422: PUSH4 0xa9059cbb
Origin: victim runtime disassembly produced in the revised auditor iteration.
This shows the contract exposes selector 0x5ff02eae, references USD1 0x8d0d000ee44948fc98c9b98a4fa4921476f08b0d, approves router 0x1b81d678ffb9c0263b24a97847620c99d213eb14, calls Pancake V3 exactInputSingle, and then transfers the acquired MOMO.
This was an MEV exposure in a public order executor, not a protocol bug in Pancake V3. The victim contract accepted arbitrary external calls to 0x5ff02eae and, when executed, read its live USD1 balance, approved the router for that full amount, swapped the full amount through the configured MOMO/USD1 pool, and forwarded the resulting MOMO to the beneficiary. The contract did not enforce a slippage floor that could reject execution after an attacker had already moved the pool price in the same block. The attack was therefore permissionless and atomic: a searcher only needed temporary USD1, access to the same Pancake pool, and the ability to call the public victim selector. The violated invariant is straightforward: a public order executor should not spend the owner's inventory unless the output remains within the intended execution envelope despite adversarial same-block price movement. The concrete breakpoint is the victim's 0x5ff02eae path continuing into approve -> exactInputSingle -> transfer after the attacker-controlled front-run had already degraded the price.
The attack depended on BNB Chain state immediately before block 51190822. At that point the victim order already held 48758887289057478885525 USD1, and the Pancake V3 MOMO/USD1 fee-100 pool was live. The helper contract was already deployed one block earlier by EOA 0xf514c02048e9296d56d693f24dfc6780a2bdd18a.
The helper's own bytecode shows the intended exploit choreography. Its creation code hard-codes temporary funder 0xbaf9f711a39271701b837c5cc4f470d533bacf33 and Pancake smart router 0x13f4ea83d0bd40e75c8222255bc855a974568dd4. Its runtime contains the critical steps below:
000007b8: PUSH4 0x095ea7b3
00000a05: PUSH4 0x5ff02eae
00000e16: PUSH4 0xa9059cbb
Origin: helper runtime disassembly produced in the revised auditor iteration.
That matches the observed transaction behavior: approve tokens for the router, call the victim's public selector, then repay the temporary funder.
The seed trace confirms the runtime sequence on-chain. The attacker helper first routed a MOMO buy through Pancake smart router 0x13f4ea83d0bd40e75c8222255bc855a974568dd4 into pool 0x2c79bb8155acbaa38d96bdb5c770d2372c509a32. The trace then shows the helper calling victim 0x8490aa884adb08a485bc8793c17296c9e2c91294, after which the victim approved router 0x1b81d678ffb9c0263b24a97847620c99d213eb14 and executed the swap path. Representative trace lines:
0x13f4EA83D0bd40E75C8222255bc855a974568Dd4::exactInputSingle(... amountIn = 9350000000000000000000 ...)
0x8490AA884Adb08a485BC8793C17296c9E2c91294::5ff02eae()
0x1b81D678ffb9C0263b24A97847620C99d213eB14::exactInputSingle(... amountIn = 48758887289057478885525 ...)
0x13f4EA83D0bd40E75C8222255bc855a974568Dd4::exactInputSingle(... tokenIn = MOMO, tokenOut = USD1 ...)
Origin: verbose seed transaction trace.
The balance diff proves the state transition that matters economically:
victim USD1: 48758887289057478885525 -> 0
beneficiary MOMO delta: +159416187664162922432782869
helper USD1 delta: +48264803792092412941512
Origin: seed transaction balance-diff artifact.
So the exploit is not hypothetical. The victim really did consume its full USD1 balance at the manipulated price, the beneficiary really did receive MOMO, and the helper really did retain the quoted USD1 profit after repayment.
The public reachability point is also evidenced. The live contract rejects owner-only selector 0xbf1bf3f3 with Not owner, while explorer tx history shows repeated external calls to 0x5ff02eae before the exploit. This supports the conclusion that the attacker did not need privileged victim access; it only needed to call the already-public execution function at the right price state.
The adversary lifecycle has three concrete stages.
First, deployment: tx 0x87f76c61cc2caf699485e829ce2b91553ea8398eac45153d6f5bc4001e35bd44 deployed helper 0xc59d50e26aee2ca34ae11f08924c0bc619728e7c. The deployer was EOA 0xf514c02048e9296d56d693f24dfc6780a2bdd18a.
Second, atomic execution: tx 0x9191153c8523d97f3441a08fef1da5e4169d9c2983db9398364071daa33f59d1 borrowed or sourced 9350000000000000000000 USD1, bought MOMO, called victim selector 0x5ff02eae, let the victim consume 48758887289057478885525 USD1 on the worsened pool price, sold the resulting attacker-held MOMO back into the same pool for 57615738792092412941512 USD1, repaid 9350935000000000000000 USD1, and kept 48264803792092412941512 USD1.
Third, withdrawal: tx 0x118efd91bf0520d832918c57e74f0911e10f988709c27e0ce580c2cfef491cf7 withdrew the realized USD1 from the helper to the same deployer EOA.
The tx-history artifacts link the same EOA across all three stages, and the helper bytecode matches the execution pattern seen in the seed transaction. The exploit sequence is therefore fully attributable and reproducible from public on-chain evidence.
The victim order contract lost effective execution value when it spent its entire 48758887289057478885525 USD1 balance after the pool had been manipulated by the attacker. The beneficiary did receive 159416187664162922432782869 MOMO, but the trade cleared on a price surface that allowed the attacker to extract 48264803792092412941512 USD1 into the helper contract. That amount is the measurable realized loss captured by the incident analysis.
Affected components were:
0x8490aa884adb08a485bc8793c17296c9e2c912940x5dda362775267d2c77d8a49583751174efa47e1c0x2c79bb8155acbaa38d96bdb5c770d2372c509a320x9191153c8523d97f3441a08fef1da5e4169d9c2983db9398364071daa33f59d10x9191153c8523d97f3441a08fef1da5e4169d9c2983db9398364071daa33f59d10x9191153c8523d97f3441a08fef1da5e4169d9c2983db9398364071daa33f59d10x8490aa884adb08a485bc8793c17296c9e2c912940x8490aa884adb08a485bc8793c17296c9e2c912940x5ff02eae0xc59d50e26aee2ca34ae11f08924c0bc619728e7c0xc59d50e26aee2ca34ae11f08924c0bc619728e7c0x9191153c8523d97f3441a08fef1da5e4169d9c2983db9398364071daa33f59d10x118efd91bf0520d832918c57e74f0911e10f988709c27e0ce580c2cfef491cf7