EtherVista: Two swaps and the USDC trail

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 transaction

The 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 assessment

The 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 USDC

After 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 USDC
• 04:43:11: 3.362307 ETH for 8,369.649164 USDC
• 04:44:11: 1.105714 ETH for 2,751.910344 USDC

The 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 owner

The 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 window
• Starting EOA 0xbbf8f3…2018fa: 7,590.716460 USDC inflow minus outflow

The 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 trail

The 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 lead

SentinelTX 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 movement

A 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 note

The 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.