Defend Against Cybercrime with the Power of Community

On October 9, 2026, an Ethereum address received 7.477952467865157 WETH and 43,855.90219627576 VISTA in a transaction that made two swap-selector calls against an EtherVista liquidity pair. SentinelTX’s report follows the subsequent disposal: VISTA went to the burn address, while ETH unwrapped from WETH was converted into 18,590.716460 USDC. Its detailed chronology lists three later transfers totaling 11,000 USDC to a pre-existing wallet; a broader flow-summary figure differs.The sequence gives the approximately US$18,600 public incident estimate a concrete proceeds trail. It also leaves important boundaries. The pair’s reserve changes are not quantified in the report, the reported overflow mechanism remains an assessment, and the two ending USDC positions are calculated from flows rather than measured balances. No exchange deposit, bridge deposit, or mixer interaction was identified in the traced flow.This article adapts “EtherVista Pair Incident — Ethereum Investigation Report,” SentinelTX case CASE-ASYNC2B8, dated October 10, 2026. All incident findings and qualifications come from that PDF. Times are UTC. The report’s stated incident window ends at 00:00 on October 10; the positions below describe its record, not a current balance check.A short setup preceded the pair transactionThe starting address, 0xbbf8f3…2018fa, was a new externally owned account, or EOA. At 03:37:59, it received 0.046448 ETH in the report’s narrative accounting from an address labeled “HitBTC, UnionChain.ai.” That label is a funding lead; it does not identify the person behind the new account or establish the funding address’s wallet type.At 03:42:23, the EOA’s first transaction deployed the helper router 0x469424…83b120. The deployment establishes the reported creator relationship; it does not by itself establish continuing administrative control.A small purchase at 03:43:59 sent 0.004008 ETH through a different intermediary and returned 0.005864694170948497 VISTA. The EOA then made a VISTA-contract call at 03:47:11 using selector 0x095ea7b3, which matches the standard ERC-20 approval signature. The report does not decode the spender.The distinction between the two routers matters. The newly deployed helper executed the incident transaction. The intermediary used for the small purchases, 0x9bd63c…94a72a, also served an unrelated trader. SentinelTX assesses it as a public EtherVista router. Its appearance in the route does not make it part of the operator’s infrastructure.At 03:47:59, block 26152259, the EOA called its newly deployed helper. The report records two calls from that helper into EtherVistaPair 0xfdd055…f02041, followed by the WETH and VISTA receipts that anchor the case narrative.The two-swap structure explains the mechanism assessmentThe report describes a 35-frame call tree that did not revert. First, the helper queried the factory and pair, then called the VISTA token with a selector matching transferFrom. Its first pair call used selector 0x022c0d9f, matching the standard swap signature; within that call, the pair transferred WETH and read the two token balances.Between the two swap-selector calls, the helper called WETH’s transfer selector and the pair’s 0xfff6cae9 selector, which matches sync. Another WETH transfer preceded the second pair call, during which the pair transferred VISTA. A final WETH transfer from the helper is consistent with the reported payout to the EOA. These function names are signature matches, not ABI-decoded meanings.SentinelTX interprets the pattern as two crafted swaps with an intervening reserve update. In the model described by the report, a Uniswap V2-style pair compares an adjusted post-swap balance product against the product of its stored reserves. If the reserve multiplication can overflow its integer type, the comparison can use a wrapped, artificially small value. A manipulated reserve state could then allow a swap to pass with a disproportionately small input.The reported quantities fit that interpretation: the EOA had received only 0.005864694170948497 VISTA before the transaction, yet the transaction returned 7.477952467865157 WETH and 43,855.90219627576 VISTA. The report treats the WETH receipt as a lower anchor for extracted WETH and assesses the pair as its most plausible source.The overflow attribution remains SlowMist’s, cited through the secondary reporting retrieved by SentinelTX. The PDF does not reproduce the pair’s source code or its exact pre- and post-transaction reserves. Its call-sequence interpretation is consistent with the reported overflow, but does not independently prove that root cause or establish the pair-side net loss.Diagram 1. The report’s interpretation of the two-swap sequence. This is an explanatory adaptation of the call structure, not a screenshot of the investigation graph. Selector names are signature matches; the report qualifies the call-structure finding as unverified.Color key: Slate = router-to-pair call sequence; sage = final WETH payout. Arrows show the labeled calls, sequence, or payout, not quantities.Address/role key: EOA 0xbbf8f3…2018fa; helper router 0x469424…83b120; EtherVistaPair 0xfdd055…f02041.Source: SentinelTX, “EtherVista Pair Incident — Ethereum Investigation Report,” October 10, 2026, pp. 5–6 and 12–13.VISTA went to the burn address; ETH became USDCAfter the pair transaction, the EOA made several small VISTA purchases and a 2.0 VISTA sale. The chronology’s 03:54:11 row lists 0.006027 ETH outgoing, 2.0 VISTA sent to the pair, and 0.000341 ETH returning through the intermediary. The report interprets this activity as probing the pair’s post-incident state. Across the observed record, the EOA received 43,932.080656851984 VISTA, including the incident receipt and the small purchases, and sent 2.0 VISTA back to the pair.At 03:55:47, it sent the remaining 43,930.080656851984 VISTA to 0x000000…00dead. SentinelTX assesses the burn as destruction of that token value and describes VISTA as having no exit market for the operator through its evident liquidity venue.The WETH leg followed a different path. Six withdraw-selector calls between 03:59:35 and 04:05:11 returned 1.0, 2.0, 2.0, 2.0, 0.46, and 0.017 ETH, totaling 7.477 ETH. The report calculates 0.000952467865157 WETH as the difference between the original WETH receipt and the quantity unwrapped. That is an accounting difference, not a separately queried token balance.The EOA then used the Uniswap Universal Router to convert ETH into USDC through V3 and V4 liquidity. The three transactions were:04:41:59: 3.0 ETH for 7,469.156952 USDC04:43:11: 3.362307 ETH for 8,369.649164 USDC04:44:11: 1.105714 ETH for 2,751.910344 USDCThe report’s total is 7.468021 ETH converted into 18,590.716460 USDC. This realized USDC quantity is consistent with the approximately US$18,600 public estimate. It is not a reserve-delta calculation of the pool’s loss. Nor should the report’s gross movement totals be used as loss figures: those recount value as it moves between addresses and can include movements outside the incident’s proceeds accounting.Figure 2. USDC received in the three reported ETH conversions. The bars compare proceeds in the same unit, begin at zero, and follow transaction order; their spacing does not encode elapsed time. Exact quantities appear in the native list above. The report flags the conversion claim as unverified.Color key: Slate = USDC received.Source: SentinelTX, October 10, 2026, pp. 6 and 9, “Quantity accounting” and “Transaction Chronology.”Three transfers identify a recipient, not its ownerThe next leg consists of three identified USDC transfers to 0x043c8f…f842d3: 1,000 USDC at 05:36:47, 5,000 USDC at 05:41:47, and 5,000 USDC at 05:43:47. The chronology and quantity accounting total these transfers at 11,000 USDC. The generic Fund Flow Analysis separately lists 22,000 USDC across six transfers for the same address pair. The figures are not reconciled in the PDF. This account uses the three individually identified transfers and does not treat the generic summary as a second, established proceeds total.The receiving EOA predates the incident. SentinelTX first dates it to April 14, 2026, and records two USDC transfer calls on April 19, at blocks 24910327 and 24910339. Its earlier history makes it a useful investigative lead. It does not establish that the incident operator owns it.The report’s connectivity test found the direct USDC link, but no common funders or shared counterparties other than the pair. It therefore leaves common control unresolved. The transfer establishes where the reported funds went; the recipient’s role beyond receiving them remains open.At the end of the observed record, SentinelTX gives two flow-derived USDC positions:Receiving wallet 0x043c8f…f842d3: 11,000 USDC received in the three identified transfers, with no outbound transaction in its traced windowStarting EOA 0xbbf8f3…2018fa: 7,590.716460 USDC inflow minus outflowThe EOA’s recorded signed history ends with the third transfer, at nonce 22 and 05:43:47. Neither figure is a live balance reading. The report calls for balance confirmation before using these positions in a recovery request.Look-alike activity sits outside the proceeds trailThe PDF retains several misleading-looking transfers but excludes them from incident accounting. The report distinguishes these suspected poisoning and spam events from the movements it attributes to the incident.At 04:09:23, an event showed 43,930.080656851984 units of a token labeled “ERC” going from the EOA to a look-alike of the burn address. Its amount mirrored the genuine VISTA burn. The report says this event was emitted by a third-party contract and was absent from the EOA’s signed transaction list. It classifies it as suspected poisoning or spoofed spam.At 05:41:23, a different address that resembled the starting EOA sent 0.0001 USDC to the receiving wallet. That transfer occurred 24 seconds before the EOA’s 5,000 USDC transfer. SentinelTX classifies it as suspected address poisoning aimed at the counterparty. The small transfer does not establish a related actor or add to the incident’s three-transfer consolidation.An unsolicited receipt of 1,000,000 “PVC” was also excluded because its token contract was unclassified and the evidence supplied no value basis. These exclusions preserve the distinction between activity appearing around an address and proceeds attributed to this incident.The report’s recovery priorities follow the USDC and the funding leadSentinelTX identifies the two USDC positions as its immediate recovery targets and recommends an issuer freeze request accompanied by current balance confirmation. It records no exchange-deposit leg from either the EOA or the receiving wallet, and no bridge, mixer, or cross-chain continuation. Those are findings within the traced scope; the report does not establish where the funds may have moved after its cutoff.The funding transaction provides a separate identification lead. The sending address, 0x963737…b2ef9a, carries the label “HitBTC, UnionChain.ai.” SentinelTX recommends asking the exchange to confirm the address’s nature and the account record behind the 0.046448 ETH funding transfer. This is conditional on confirming that it was an exchange withdrawal wallet. The label alone establishes neither the account holder nor an exchange cash-out from the incident.The receiving wallet’s April history is the other priority. Its earlier counterparties could help distinguish an operator-controlled wallet from a third party. The PDF also recommends monitoring the starting EOA, receiving wallet, and helper router for the next outbound movement, approval, or bridge interaction.On the protocol side, the report recommends identifying sibling pairs that share the affected swap code and addressing their liquidity exposure. It establishes the incident against one pair only. Its requested next evidence includes verified source, the relevant Swap and Sync events, and a post-mortem quantifying reserve changes. Those steps are the report’s proposed route to establishing the arithmetic root cause and pool-side net loss more firmly.Figure 3. The report’s ending positions and next steps. The two USDC figures come from its incident quantity accounting and are flow-derived, not balance readings. The 11,000 USDC subtotal covers the three identified transfers; the report’s differing generic flow-summary figure is unreconciled. They do not establish a completed freeze, a recovery, or common control of the addresses.Color key: Sage = recipient accounting; slate = starting-EOA accounting; amber = report recommendations. Color does not grade certainty or guarantee recovery.Address/role key: Starting EOA 0xbbf8f3…2018fa; receiving wallet 0x043c8f…f842d3.Source: SentinelTX, October 10, 2026, pp. 7, 9–11, and 16–18, “Positions at the end of the observed record,” “Recommendations,” and “Conclusion.”Follow the next value-bearing movementA useful continuation begins with the incident transaction, then asks whether the two USDC positions changed after the report’s cutoff. Keep the three identified transfers distinct from look-alike activity, and distinguish a new receiving address from an established exchange or bridge endpoint.Request SentinelTX access or sign in, then use this starting prompt:Investigate the EtherVista pair incident on Ethereum mainnet (chain ID 1), using transaction 0xb2c7332d9e1be6a86d9d37083aa4cc0d94b60eb95cc9b29494555a3c09764930 as the seed and case CASE-ASYNC2B8 as the October 10, 2026 baseline. State the exact query time and cutoff. Follow value-bearing activity after 2026-10-10 00:00 UTC from 0xbbf8f3fe8e4fdf6b594e6107144d78293d2018fa and 0x043c8f2df89612f9da2d91a92d30d3295cf842d3. What happened after the three identified USDC transfers, and is there a supported exchange, bridge, issuer-freeze, or recovery event? Distinguish measured balances from the baseline’s flow-derived positions, retain suspected poisoning exclusions, and do not infer common control from the transfers alone. Include transaction links, query limits, and the basis for each endpoint label.Source noteThe sole factual source for this adaptation is the 39-page native SentinelTX PDF, “EtherVista Pair Incident — Ethereum Investigation Report,” case CASE-ASYNC2B8, dated October 10, 2026, with the document generation time printed as 00:28:05 UTC. The article uses the report’s explicit incident chronology and quantity accounting. Token names and classifications follow the report.The narrative’s incident window ends at October 10, 00:00 UTC, exclusive. The executed query record also includes historical lookbacks ending during the October 10 retrieval; these do not establish uninterrupted historical coverage. The PDF marks several central findings as unverified and flags a time-inverted routing path. This article preserves their status as reported findings. Its root-cause attribution, unestablished recipient ownership, and flow-derived ending positions remain qualified here.

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 paymentThe 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 recipientsThe 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 pullsSeller B, 0xf219d073…dd690938: 500,000 79AU in one pullThird wallet: 10,000 79AU in one pull; its purpose remains unexplained in the reportFigure 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 BNBAt 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 balancesThree 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 BNBSeller B, 0xf219d073…dd690938: 2,284.478912 BNBSecondary wallet, 0x1e2a669e…f31216a3: approximately 1,212 BNBThe 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 recoveryThe 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 issueThe 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 outflowsA 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 noteThe 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.

A fake verification step can move the attack surface into an already authenticated browser page. In this case, the decisive analytical distinction is between evidence of a malicious bookmark, evidence of token transfers, and proof of how those transfers were authorized. Those are related questions, but they are not interchangeable.Our direct explorer review identified three USDC transfers from one source owner to the recipient named in SlowMist's original technical analysis. They total exactly 45,106.851598 USDC and span 63 seconds. That matches the reported 45,106.85 USDC total when rounded to two decimal places. The match makes them strong candidate incident anchors; it does not independently establish the source wallet owner's identity or the victim's consent.Scope and evidence boundaryMeasureValue / interpretationNetworkSolanaCandidate inbound total45,106.851598 USDC; three unique successful transactionsCandidate transfer window2026-10-04 08:58:45–08:59:48 UTCReview cutoff2026-10-09 00:32 UTC; historical transaction snapshots, not a complete chain auditPublic loss reportApproximately $48,000 in assets, as relayed by SlowMist; not equated with the exact USDC subtotalIndependent victim confirmationNot obtained; attribution remains a documented candidate matchThe review deduplicates by transaction signature and counts only the single USDC transfer in each candidate transaction. SOL network fees are recorded separately and are not added to the USDC amount. Address-wide activity is kept outside the candidate incident subtotal.Three findings that matter1. The reported withdrawal total has a specific, reproducible candidate matchQuestion: can the reported three withdrawals be distinguished from the recipient's other inflows? The three transactions below share the same source owner, destination owner, USDC mint and decoded transferChecked method. Their exact sum, count and destination fit the public report. The source wallet is therefore an investigative candidate, not a newly identified person.UTC on 4 OctoberUSDC transferredEvidence08:58:4532652.960737A01: transaction detail08:59:235002.490046A02: transaction detail08:59:487451.400815A03: transaction detailThe arithmetic is 32,652.960737 + 5,002.490046 + 7,451.400815 = 45,106.851598 USDC. The 0.001598 USDC difference from the two-decimal public figure is rounding, not a separately identified transfer. What remains uncertain is independent confirmation that these exact signatures correspond to the reported victim's withdrawals.Figure 1. Directly checked candidate transfers. A dashed co-signer panel is an authorization observation, not a money-flow edge. Downstream attribution is deliberately not shown.2. A co-signer label does not resolve the compromise mechanismQuestion: does the chain tell us whether an attacker exported a key or requested remote signing? Each candidate transaction lists the source owner and a second signer that Solscan labels “Fomo Co-signer.” That is evidence about transaction signers and a provider label, not proof of who initiated the request, which authentication material was used, or whether any signing service was compromised.RolePublic address / accountSource owner / transfer authority6R6stpcbSij7scSpD7Refq1eap2gN1Qj3omFeGu3gJPcSecond signer; Solscan label “Fomo Co-signer”AgmLJBMDCqWynYnQiPCuj9ewsNNsBJXyzoUhD9LJzN51Source USDC token accountBcxGQtcyAgX1VrM8sS94aMbFridPqkJ3u8qQx4e4X3PgDestination USDC token accountEpAjLMVnttREdDiXGddym5eYgsn5hH2oPPnQcarTKajMDestination owner named by SlowMistD783JqupQ2FYhkxUfGEd1gaFEoAJDXRX1NEb4aVH2hZ6The owner-level explorer summary and the decoded instruction describe different layers: the summary resolves wallet owners, whereas the instruction names the SPL token accounts being debited and credited. A token account must not be presented as a separate attacker wallet merely because it has a different address.3. A Privacy Cash transfer is verified; its victim attribution is notQuestion: can an address-wide service exposure be treated as this victim's recovered path? A separate successful transaction sends 212.492295 SOL from the named collection owner to a pool Solscan labels Privacy Cash Pool on 5 October at 07:46:10 UTC. This directly supports an address-to-pool transfer. It does not by itself show that those SOL were purchased with the three candidate USDC transfers.ObservationEvidence / limitTransaction4YM1bkC7UjJwLX8zc6FgPbg7yFViDLQfo2hgJ8u9iGAjDDxFv9crdwJ1JkZurmE13JsD56CneJibLtvekoieT3MxAmount and UTC212.492295 SOL; 2026-10-05 07:46:10 UTCPool destination4AV2Qzp3N4c9RfzyEbNZs2wqWfW4EwKnnxFAZCndvfGhProgram9fhQBbumKEFuXtMBDw8AaQyAjCorLGJQiS3skWZdQyQDAttribution boundaryAddress-history evidence only. No independently reconciled route from candidate USDC anchors yet.SlowMist's reported 1,568.33 SOL cumulative Privacy Cash outflow concerns the address's history. It is not substituted for the incident's 45,106.85 USDC subtotal, nor independently reproduced by the single transaction checked here. The intervening swaps, balances and other inflows must be reconciled before assigning a victim-specific downstream amount.How the bookmark crosses the trust boundaryAccording to SlowMist's original technical analysis, a token-page link led to a fake human-verification page that prompted a bookmark action. The saved JavaScript then ran in the logged-in FOMO context and targeted browser storage, IndexedDB and Privy session material. We did not execute the malicious sample or connect to its collection endpoint.Figure 2. Source-based mechanism reconstruction, not an independently replayed exploit or transaction trace. The unresolved signing step is dashed.The useful security conclusion is narrower than “a wallet connection stole the funds”: the described lure sought code execution within a trusted application session. Conversely, the source's conditional MFA logic and the victim's reported absence of 2FA do not establish a demonstrated MFA bypass. Initiating an enrollment flow would also not prove successful enrollment.Timeline: observations rather than invented milestonesUTCEvent and evidence level2026-10-04 08:58:45A01: 32,652.960737 USDC, directly checked2026-10-04 08:59:23A02: 5,002.490046 USDC, directly checked2026-10-04 08:59:48A03: 7,451.400815 USDC, directly checked2026-10-05 07:46:10T01: 212.492295 SOL to provider-labeled Privacy Cash pool; separate address history2026-10-08SlowMist public alert and analysis; not the attack dateThe attack's initial browser-execution time is not established here. The collection address's reported first activity on 17 September is not assigned as the incident start time.Alternative explanations and what would resolve themThe three-transfer match could be strengthened by an original withdrawal record or source confirmation naming the signatures. A transaction's valid signatures do not reveal whether the human account owner approved it. Application-side authentication, session revocation, withdrawal and signing logs would be needed to test competing key-export and remote-signing explanations.For downstream analysis, identical asset values or nearby timestamps are insufficient to prove a bridge connection. A defensible cross-chain edge requires a source transaction, bridge order or fulfillment record, and destination transaction. Ethereum and Bitcoin candidates mentioned by the source remain external leads until that chain of evidence is available; they are not drawn as verified branches here.Case-specific response pointsFor the affected account, preserve the bookmark URL and browser/session chronology without executing the bookmark again. Application operators can correlate the three candidate signatures with withdrawal requests and signing-policy decisions, then evaluate session and refresh-token revocation. A password change alone should not be assumed to invalidate every previously issued session artifact.For investigators, preserve the full source/destination token-account mapping and block references before expanding a cluster. For any service request, provide the specific transaction and account history being queried, and distinguish the verified transfer from a claim about stolen-fund ownership. Provider labels are leads for corroboration, not legal identity findings.Evidence appendixID / slotFull transaction signatureA01Solana slot 45320947444uGoQH6KQRyVDCLuDTUHW3KxR61j9pGnnWWKoGtWFh9b3jUFRQ9t5MMVHoFr5ZWFLgEgWKmgxuR5Wq8tS36XkzNA02Solana slot 4532096174pgANnxQ2Q5139ToXuc7LvHWqBZKKsBXwAVKA4eSi1wLnYdpukbgL2ZheTxXAMevU84HVKJCe1TBTTZ1VN2TZrH9A03Solana slot 453209712xM1eCwjwhV4h9ECr2dTpL4TTDq3YafKiME3qyJcCAiLM3iqZosCVSW3rdQPcUr8AXWhzDrJzd4JKDZDWBJ6q4KMT01Solana slot 4535158714YM1bkC7UjJwLX8zc6FgPbg7yFViDLQfo2hgJ8u9iGAjDDxFv9crdwJ1JkZurmE13JsD56CneJibLtvekoieT3MxToken / technical propertyValueUSDC mintEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1vCandidate instructionSPL Token Program transferCheckedPer-candidate fee0.00001507 SOL; separate from USDC principalSource basisSlowMist's original technical analysisReproducibility limitExplorer-decoded detail checked; no raw RPC replay, victim-account access or complete downstream reconciliation claimedThis report separates directly observed chain transactions, explorer-provided labels, external reporting and analytical inference. It does not identify an attacker or attribute every historical recipient transaction to this case.