Defend Against Cybercrime with the Power of Community

After Railway disclosed possible exposure of customer secrets on 21 October 2026, researcher Taylor Monahan linked wallet drains to the incident and identified a suspected receiving address. This review follows two Ethereum branches leaving that address: ETH passes through one relay, and USDC through another. Both reach the same address labelled “HitBTC: Hot Wallet 4” by Etherscan.The checked routes are suspected receiving address → separate ETH and USDC relays → one explorer-labelled exchange endpoint, and a smaller, separately matched Ink USDC burn → Ethereum mint to the seed. One earlier Ethereum inflow to the seed is also checked below, without identifying its sender as a confirmed Railway victim. The record supports these transfers more strongly than it supports the cause of every incoming payment. It stops at the labelled endpoint: it does not identify a customer account, prove conversion to cash or establish that all of the seed address's funds came from Railway customers.Before the numbers: the service, the assets and the rolesRailway is a cloud application-hosting service, not the similarly named Railgun privacy protocol. An environment variable is a value supplied to a running application; it can contain a database password, an API token or a wallet private key. Access to such a value and an unauthorized blockchain withdrawal are different observations. Linking them for a particular victim requires both service-side evidence and that victim's transaction history.ETH is Ethereum's native asset and also pays transaction fees. USDC is a token designed to track the US dollar, but this report records token units, not a historical dollar valuation. A relay is simply an intermediate address that receives and later sends funds in the selected route. It is a reading aid, not a claim that the address was created for this incident. That role does not identify its operator. A block explorer is a public interface to blockchain records; its address labels are investigative leads rather than identity certificates.Role used hereObserved functionSuspected receiving addressThe researcher-supplied starting address; sends both first-hop transfers.ETH relayReceives the selected ETH payment and later sends ETH to the endpoint.USDC relayReceives and later sends the same USDC token quantity.Labelled endpointReceives both onward payments; exchange association follows Etherscan only.What this review coversScopeBoundaryChain / selected movement windowEthereum and one matched Ink transaction; selected records span 21 October 2026, 19:36:23 UTC to 22 October, 09:47:35 UTC. This is not the duration of the wider incident.Evidence checkedSeven successful transaction-detail records: one Ethereum inflow to the seed, four Ethereum relay-path transactions, one Ethereum mint and its Ink burn; raw USDC events and the CCTP message/attestation join.Verification date23 October 2026 KST. Historical transaction times in this article are UTC.Observation boundaryHighest selected Ethereum block: 26,247,354; selected Ink block: 59,138,264. Not a fixed historical cutoff or proof of complete coverage through that block.Counting conventionCount each endpoint receipt once; exclude gas from transfer quantities. Do not add the two hops as separate losses. No incident-wide USD loss calculated.Three findings guide the account. First, the ETH and USDC branches converge at the same labelled endpoint. Second, the USDC quantity matches to all six decimal places in both event logs. Third, an Ink burn now matches the separate Ethereum mint through Circle’s message record, but victim-origin attribution remains unverified. The chronology explains what each finding does—and does not—establish.21 October: the disclosure and the wallet allegation are separate sourcesRailway's official disclosure describes possible unauthorized access to encrypted environment variables and some decrypted contents, with the affected subset under review. It supplies cloud-security context, not an independently reconciled cryptocurrency loss ledger. Railway's 21 October disclosure.Monahan's original report identifies the suspected address and describes approximately $371,000 in drains, more than 500 transactions, more than 200 distinct addresses and activity across more than 19 EVM chains. It places the first known theft at 19:36 UTC on 21 October. These are attributed researcher findings, not counts or a valuation reproduced in this bounded Ethereum review. Original researcher report.The seed's explorer label refers back to the researcher. That is not a second independent proof of incident attribution. The original victim withdrawals, their authorization status and the relevant exposed credentials have not been reconciled here. Keeping this distinction visible prevents a verified transfer from silently becoming a verified explanation of why it happened. A narrow follow-up also read Monahan’s reply that she had multiple separate victim reports. The public thread inspected here did not supply a victim-confirmed full address and withdrawal hash that could be joined to a specific Railway exposure record. This adds attributed context, not independent victim-wallet proof. Researcher’s victim-report clarification.21 October, 19:36:23 UTC: an early inflow, not yet a victim linkCan a public transaction connect an affected Railway customer to the starting address? A newly located public research repository supplies an early Ethereum transaction as a lead. Reading that record directly confirms a successful transfer of 0.0008149978451301 ETH into the seed at 19:36:23 UTC on 21 October. Its full sender and hash are preserved as Anchor 7. This is an observed sender-to-seed connection, not yet an identified victim-to-attacker connection. Early Ethereum inflow.The transaction’s sender is the address that submitted the transfer. It has nonce 2, meaning the sequence number assigned to this transaction from that address, and empty input data (0x). These fields describe an ordinary ETH payment; they do not reveal whether its owner consented, where a signing key was stored, or how someone obtained authority to use it. A transaction signed from a wallet is not, on its own, proof that its private key was stolen rather than the owner being persuaded to sign.The repository calls incoming senders victims, but it is a separate researcher’s classification, not a customer confirmation or a Railway exposure log. In the public sources inspected for this follow-up, no owner-confirmed full address and withdrawal hash were joined to a corresponding Railway key-exposure record. The initial Railway disclosure still discusses possible exposure of customer secrets rather than confirming this particular wallet loss. A developer-theft article was located at its original publisher, but its body did not load in either browser checked; its headline is not used as victim evidence. The new transfer therefore narrows the movement question while leaving the hosting-to-theft cause open. Railway’s disclosure.That is why the inflow is not added to a verified incident-loss total or drawn as a victim-origin arrow in the diagrams. A useful next record would pair an affected operator’s explicit address and unauthorized-transaction report with evidence that the relevant key was present in an exposed Railway environment. The next selected record here is the later outbound ETH relay path.22 October, 00:00:23 UTC: ETH leaves for the first relayThe first selected transaction sends 14.337416437867723544 ETH from the suspected receiving address to the ETH relay. Its successful status, block, timestamp, sender, recipient, value and fee were read directly on Etherscan. A successful status means the transaction was accepted without an overall execution reversal; it does not mean the transfer was authorized by an affected user. First ETH transfer.At 02:43:59 UTC, the same relay sends 14.337414482241887922 ETH to the labelled endpoint. The elapsed time between these selected transactions is 2 hours 43 minutes 36 seconds. That measures a relay interval, not attack speed or time available for a freeze. Onward ETH transfer.ETH branch, 22 October UTCExact amount00:00:23 · seed → ETH relay14.337416437867723544 ETH02:43:59 · ETH relay → labelled endpoint14.337414482241887922 ETHOnward transaction fee, paid by relay0.00000097028232 ETHStart Figure 1 at the suspected receiving address at the top. Follow the left branch for ETH and the right branch for USDC, then read the shared endpoint below. The USDC branch occurs later in the chronology, but is shown alongside ETH to make that shared endpoint visible.Figure 1. Solid arrows indicate directly checked asset transfers; pastel colors distinguish address roles only. Amounts on the ETH arrows are rounded to six decimals; exact values are in the tables. Layout, arrow width and spacing do not encode value or time. Sources: the four relay-path transaction records in the appendix.The shared endpoint is a concrete connection between the branches. It does not prove that the relays share an owner, that a single exchange customer was credited, or that a withdrawal from the service followed. A separate bridge sequence begins at 02:37:55 UTC on Ink, before that onward ETH transfer, and finishes at 02:44:59 on Ethereum. We now step back to its source record so the burn and mint can be read together; the two asset branches should not be mistaken for one continuous timeline.02:37:55–02:44:59 UTC: an Ink burn matches the Ethereum mintDoes the smaller Ethereum receipt really correspond to a burn on Ink? CCTP, Circle’s Cross-Chain Transfer Protocol, moves USDC by destroying units on the source chain and creating corresponding units on the destination chain. The new source record changes this part of the earlier review: it is now a matched bridge sequence, not merely an explorer’s summary.At 02:37:55 UTC on 22 October, the same address string used by the Ethereum seed submits a successful depositForBurn call on Ink. The source explorer displays 11:37:55 at UTC+09:00; subtracting nine hours gives the UTC time used here. At Ink block 59,138,264, its USDC events record 129.491197 units passing to the token-minter contract and being burned. The DepositForBurn event specifies Ethereum destination domain 0 and the seed as mint recipient. A burn removes token units; the zero address in that record is not another person receiving them. Ink source transaction · Source event logs.The connection is not based on equal rounded amounts alone. A nonce is a message identifier; here it distinguishes this CCTP message from others. Looking up the nonce in Circle’s public message API returns the source transaction hash above. Looking up that source hash returns the same message. The returned 376-byte message and its attestation—the protocol’s signed approval of that message—match the bytes submitted in Ethereum’s receiveMessage call exactly. Circle’s documented domain mapping identifies 21 as Ink and 0 as Ethereum. This uses Circle’s service as one source and the two public explorer records as the on-chain cross-check; it is not an independent re-execution or a local cryptographic signature verification. Circle source-hash lookup · Official domains and contracts · Message format.Bridge stage, 22 October UTCChecked quantity / connection02:37:55 · Ink burn129.491197 USDC; source raw amount 129491197.02:44:59 · Ethereum mint to seed129.465299 USDC; destination raw amount 129465299.Separate Ethereum fee mint0.025898 USDC; message feeExecuted 25898.Reconciliation129.491197 − 0.025898 = 129.465299 USDC; 7 minutes 4 seconds between source and destination records.Message joinSource domain 21 → destination domain 0; same recipient and exact message/attestation bytes.Read Figure 2 from top to bottom: Ink burn, matched protocol message, then Ethereum delivery and the separate fee mint. The solid arrow denotes this checked bridge correspondence, not a direct ordinary-wallet transfer between chains. The bottom panel has no onward arrow because victim allocation and the relationship to the later 9,372.183919 USDC payment remain open.Figure 2. Pastel panels distinguish chain and protocol stages. All amounts are exact USDC units; arrows are schematic and not scaled to value or time. The 0.025898 USDC fee is separate from ETH transaction gas. Sources: Ink burn Anchor 6, Ethereum mint Anchor 3 and the Circle message record. The gray panel states the remaining limit, not another transfer.The source transaction is submitted by the seed’s address on Ink and names that address as the Ethereum recipient. This establishes the recorded sender and intended recipient, not the real-world operator, lawful ownership or origin of those funds. On Ethereum the successful call mints the net amount to the seed and the separate fee amount to the other recipient in the appendix. These receipts are one bridge sequence, not two additional losses. The smaller net receipt cannot by itself be allocated to a Railway victim or said to finance the later, much larger USDC payment. Ethereum destination transaction.03:04:23–09:47:35 UTC: the USDC amount survives the relay unchangedAt 03:04:23, the seed calls the USDC token contract. The transaction's top-level recipient is therefore the token contract, while the token-transfer recipient is the USDC relay. Those are different fields. A token transfer updates a ledger inside its contract; looking only at the transaction's “to” field would miss the address that actually receives the tokens. First USDC transaction.The Transfer event at log index 150 names the seed as sender and the USDC relay as recipient. Its integer value is 9,372,183,919. USDC's explorer metadata specifies six decimal places, so dividing by one million gives 9,372.183919 USDC. At 09:47:35, log index 605 in the onward transaction names that relay as sender and the same labelled endpoint as recipient, with the same token contract and integer value. First event record · Onward event record.USDC event checkFirst hop / onward hopUTC, 22 October03:04:23 / 09:47:35Log index150 / 605Raw token value9372183919 / 9372183919Scaled quantity9372.183919 / 9372.183919 USDCTime between selected hops6 hours 43 minutes 12 secondsBoth logs use the Ethereum USDC contract listed in the appendix. The decimal setting was read from current explorer token metadata; this is not a historical contract-state call. The event comparison answers a narrow question—did the same quantity of the same token pass through the named relay? The match is stronger than a rounded visual similarity: the asset, amount and relay address agree at the raw-event level.Even an exact match is not a full accounting of the relay's history. It supports this selected two-hop route, but not the claim that every token ever held by the relay came from this seed or that all of its older activity belongs to this incident. The relay's historic service interactions are not added to the investigation's loss total.What should—and should not—be added together?Do the two relay steps represent twice the loss? No. The first and onward transfers describe the same route at different points. The endpoint receipts are 14.337414482241887922 ETH and 9,372.183919 USDC. They remain separate assets; there is no incident-time exchange-rate calculation that would justify turning them into one verified dollar-loss figure.Transaction fees are paid in ETH even when the moved asset is USDC, so USDC gas should not be deducted from the token quantity. The selected ETH input exceeds the onward ETH value by 0.000001955625835622 ETH. Subtracting the onward transaction's gas fee leaves 0.000000985343515622 ETH. That is selected-leg arithmetic, not the relay's measured balance. Its displayed normal history also contains two tiny incoming payments from look-alike addresses, and this review has not reconstructed every asset or internal movement.The useful conclusion is convergence, not a complete loss tally. Neither the mint receipt nor the relay input should be added to the endpoint receipts as new damage. Unanchored service-labelled payments found around the query are also excluded: a large transfer to a familiar exchange label is not a substitute for the missing seed-to-sender link.What connects the route, and what remains uncertain?Direct transaction fields connect the ETH branch; matching token events connect the USDC branch. Both end at the same full Ethereum address. Etherscan supplies its HitBTC label, while the researcher supplies the seed's incident association. These are different evidence classes and should not be blended into a single certainty level.QuestionMissing evidenceWhich seed receipts came from affected users?Victim-confirmed withdrawals, authorization history and corresponding cloud exposure records.Who controls the relays or endpoint account?Service records or other reliable ownership evidence; shared transfers and explorer labels are insufficient.Where did the Ink USDC come from?The burn-to-mint join is now matched; victim-origin allocation and the Ink address’s upstream asset history remain unverified.What happened after the endpoint?Account-specific credit and onward withdrawal records; no cash-out or recovery established.Does the selected route explain the reported total?A deduplicated multichain victim ledger with asset-specific quantities and pricing basis.Alternative explanations remain possible for parts of the surrounding activity: the seed may contain unrelated funds, a service address may serve multiple customers, and an intermediate address may already have other assets. These possibilities do not negate the four selected transfers. They limit what can be inferred about ownership, motive and incident-wide allocation.Response points tied to the evidenceFor affected application operators, the first concrete task is to preserve the relevant access, variable-read and deployment records alongside any wallet withdrawals. A hosting reset is not proof that an exposed blockchain signing key is safe to reuse. Whether a particular wallet key was present, accessed or used without authorization requires incident-specific evidence, not a generic address label.Railway's 22 October guidance distinguishes its own credential reset from work customers must still perform. It says bucket credentials were regenerated and dependent services need redeployment. GitHub account connections need reconnecting; registry tokens removed from Railway may still work on GitHub until revoked there. These are attributed service recommendations, not operations performed by this investigation. Official reset and redeployment guidance.For investigators, the four relay-path hashes and exact endpoint address form a narrow preservation package. Any authorized request to a service should distinguish observed address receipts from an unproven customer attribution. This report does not claim that a freeze, contact, recovery request or continuous monitoring operation has occurred.The defensible result is a reproducible Ethereum subset: two relay paths converge at one explorer-labelled endpoint, with exact USDC event agreement. The Ink-to-Ethereum join is now supported by the source burn, exact message and destination mint. The missing victim ledger and service-side account evidence are not minor details. They are precisely what separates the verified movement record from a complete explanation of the reported wallet drains.Evidence appendixFull Ethereum address registerRoleFull addressResearcher-supplied seed0xd9773325282874d18cb83f1fe50f14c39750b2eeETH relay0x78421155a6ff1adbb471672b501b715cf66ce065USDC relay0x676be7c17ac1d080d3274ab3f497620509293a44Endpoint: HitBTC label only0x80787af194c33b74a811f5e5c549316269d7ee1aUSDC token contract0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48Mint transaction called contract0x81d40f21f12a8f0e3252bccb954d722d4c464b64Separate mint recipient0x6efa3205a385420cf1cfd6b725b48f96117a7beeAnchor 7: early Ethereum inflow, sender not victim-confirmedFieldChecked valueHash0x6868f0c25cd63142a388b29ed48362305f4b537c52aa38398688eda2576c6c93UTC / block2026-10-21T19:36:23Z / 26243112Status / transaction feeSuccess / 0.000005396400429 ETHSender (not victim-confirmed)0xe56c1c45ba62733c430e8e21c148f58aad31e6cbRecipient0xd9773325282874d18cb83f1fe50f14c39750b2eeValue0.0008149978451301 ETHNonce / input2 / 0xWhat remains unverifiedOwner authorization, Railway use, storage/access of the relevant key and incident-loss allocation.Ink source register and bridge identifierInk role / identifierFull valueSource caller / intended Ethereum recipient0xd9773325282874d18cb83f1fe50f14c39750b2eeUSDC burn token0x2d270e6886d130d724215a266106e6832161eaedCalled TokenMessengerV20x28b5a0e9c621a5badaa536219b3a228c8168cf5dMessageTransmitterV20x81d40f21f12a8f0e3252bccb954d722d4c464b64TokenMinterV20xfd78ee919681417d192449715b2594ab58f5d002CCTP message nonce0x0c97ddd3c9c8696cb2172dfc3fa86860912377852c6fba4d692e56f99321933cAnchor 6: Ink USDC burnFieldChecked valueHash0x8160214bff5994b869ae814d1e5559f09674fd0fe6da2c4e2c5a52372811722eUTC / block2026-10-22T02:37:55Z / 59138264Status / transaction feeSuccess / 0.000000218583057777 ETH, including the explorer’s L1 fee component.Caller0xd9773325282874d18cb83f1fe50f14c39750b2eeCalled contract0x28b5a0e9c621a5badaa536219b3a228c8168cf5dBurn / destination129.491197 USDC / domain 0 (Ethereum)Event indices0: sender-to-minter Transfer; 1: Burn; 2: minter-to-zero Transfer; 3: MessageSent; 4: DepositForBurn.Source message versus attested messageThe source MessageSent has unset protocol fields. The exact-byte comparison is between Circle’s completed message/attestation and Ethereum calldata, not between the unfilled source message and destination calldata.Exact Ethereum transaction anchorsAnchor 1: ETH transferFieldChecked valueHash0xdee103b5b7a86f1a3ad367eadbf1139b697f494b7816dc11620b4bf4f6d90debUTC / block2026-10-22T00:00:23Z / 26244426Status / transaction feeSuccess / 0.000004054937502 ETHSender / caller0xd9773325282874d18cb83f1fe50f14c39750b2eeRecipient / called contract0x78421155a6ff1adbb471672b501b715cf66ce065Amount14.337416437867723544 ETHAnchor 2: ETH transferFieldChecked valueHash0x9ac5318283604417125cc42189a5205c75757411d0f228cfed1273fe2aa26788UTC / block2026-10-22T02:43:59Z / 26245244Status / transaction feeSuccess / 0.00000097028232 ETHSender / caller0x78421155a6ff1adbb471672b501b715cf66ce065Recipient / called contract0x80787af194c33b74a811f5e5c549316269d7ee1aAmount14.337414482241887922 ETHAnchor 3: Ethereum mint receiptFieldChecked valueHash0x00db8c04ad2ef4baf9cb00c58505279b90a6b723e915fc8c5f782526b01a324fUTC / block2026-10-22T02:44:59Z / 26245249Status / transaction feeSuccess / 0.000017076873502767 ETHSender / caller0xd9773325282874d18cb83f1fe50f14c39750b2eeRecipient / called contract0x81d40f21f12a8f0e3252bccb954d722d4c464b64Amount129.465299 USDC to seed; 0.025898 USDC separate mintAnchor 4: USDC transferFieldChecked valueHash0x1769d1c449c0b08ab5cee2117f250f967ad1d1cd775b918442ebd194c6fe6fd8UTC / block2026-10-22T03:04:23Z / 26245346Status / transaction feeSuccess / 0.000011594768181248 ETHSender / caller0xd9773325282874d18cb83f1fe50f14c39750b2eeRecipient / called contract0x676be7c17ac1d080d3274ab3f497620509293a44Amount9372.183919 USDCAnchor 5: USDC transferFieldChecked valueHash0xe1bf8a78e45daad9205cde0c8e86dc758d8352d372e83c40ca6fc70a0c27f93fUTC / block2026-10-22T09:47:35Z / 26247354Status / transaction feeSuccess / 0.000004503740002788 ETHSender / caller0x676be7c17ac1d080d3274ab3f497620509293a44Recipient / called contract0x80787af194c33b74a811f5e5c549316269d7ee1aAmount9372.183919 USDCFor the USDC transfers, the recipient above is the token recipient, not the top-level called contract. Both call the USDC contract in the address register. The seven anchors are a selected evidence set, not a complete address inventory or a new incident count. Direct checks here mean reading public explorer records and event data, not independently replaying execution on either chain.Update, 23 October 2026: the earlier source-unmatched wording and Figure 2 were replaced after the Ink burn and Circle message join were checked. The four Ethereum relay-path quantities and the victim-attribution limits are unchanged.Additional source check, 23 October 2026: Anchor 7 adds one directly read early inflow. It does not establish a victim’s Railway exposure or independently reproduce the public repository’s full wallet count, valuation or cause classification. The existing relay and CCTP quantities are unchanged.

A transaction-level review of October 20-21, 2026. Public explorer records checked October 22, 2026. All times are UTC.At 18:39:51 on October 20, a successful Base transaction paid 19,820.734002 USDC and 8.716935563284127414 ETH from the contract identified as Slice's FundsModule to the transaction sender. A subsequent swap returned 8.052201613921397406 ETH to that sender, which then transferred 16.788 ETH to another address. These are different stages of a route, not amounts to add together as separate losses.The distinction becomes more important across chains. The public records establish five later Base departures and separate Ethereum receipts. They do not, by themselves, establish the bridge request linking each departure to an arrival, or how much of a mixed address's later activity belongs to this incident.SlowMist's incident database describes a FundsModule issue involving release amounts returned by a caller-selected contract and reports an approximately US$41,000 loss. That is attributed incident context, not a loss estimate reproduced by this review. We did not replay the proposed mechanism or verify a patch. SlowMist incident recordWhat the initial transaction establishesThe seed transaction, 0x02b039…8d790a, succeeded in Base block 52,866,122. The USDC Transfer log records 19,820.734002 tokens from FundsModule 0x61bcd1…eacaaf to the sender, 0xc34572…8c892f. The independently retained RPC receipt matches the token contract, recipient, and integer amount. BaseScan's internal-transfer display separately shows an 8.716935563284127414 ETH payment between those addresses. Seed transactionThe transaction's top-level value is 0 ETH. That field measures the value submitted with the outer call, not all ETH moved by contracts during execution. It does not contradict the displayed internal payout. BaseScan also flags a reverted internal execution while marking the overall transaction successful; success should not be read as a claim that every nested call succeeded.“Sender,” “FundsModule,” and “recipient” describe roles in the selected records. They do not identify a person or establish who controlled an address. The selected payouts are also not a complete reconciliation of the module's other transfers, user liabilities, or incident-wide net loss.The swap changes the asset, not the amount of lossAt 18:41:17, the sender submitted 19,820.734002 USDC to the swap route. The token-transfer list also shows 0.000001 USDC returned to it. The resulting net USDC sent in that transaction is therefore 19,820.734001, not the full submitted amount. Swap transactionThe ETH records reconcile as follows:WETH unwrapped and passed into the payout route: 8.123274552931009529 ETH.ETH paid to the transaction sender: 8.052201613921397406 ETH.ETH paid to a separate recipient, 0xe25c63…272e42: 0.071072939009612123 ETH.The two payouts sum exactly to the unwrapped amount. The separate recipient's role is not established here, so its payment is not labeled a gas fee or a proven service fee. The sender's ETH receipt is a payout, not a gas-adjusted profit calculation. Nor should the submitted USDC and the resulting ETH be counted as two losses.Figure 1. The selected Base sequence, with the sender's actual ETH payout distinguished from the larger unwrap. Rounded ETH values carry an approximation sign; exact quantities appear in the text. The swap returned 0.000001 USDC. The later 16.788 ETH transfer came from an address that had also received pre-event funding. Sources: the seed, swap, funding, and onward-transfer records linked in this article.Why 16.788 ETH is not an exact incident allocationAt 18:45:47, the sender transferred 16.788 ETH to 0xfba873…81364a. Before the seed, at 18:26:57, it had already received 0.0195 ETH from a different address. Both transfers are visible in BaseScan. Pre-event funding · Onward transferETH is pooled in an address balance. These records show that the outgoing payment followed the incident receipts, but they do not assign an exact fraction of each prior receipt to it. We therefore report 16.788 ETH as an observed transfer, not as an independently measured amount of incident proceeds, a protocol loss total, or a recoverable balance.Two chains, two levels of evidenceBetween 23:57:03 on October 20 and 00:03:15 on October 21, 0xfba873…81364a sent five Base transactions with values of 0.5, 5, 5, 5, and 1.287 ETH. The explorer shows their route through 0x333573…4a3333 and internal transfers to an address labeled “Relay: Depository.” Their total is 16.787 ETH on the source side.A SentinelTX working record pairs the first four departures with four Ethereum payments to the same hexadecimal recipient address. We independently checked the existence, successful status, amounts, recipients, and timestamps of those public transaction pages. The four source values total 15.5 ETH; the four cited Ethereum receipts total 15.496861123458983361 ETH.The pairing itself remains a separate claim. The reviewed overview pages do not supply a request-level record that independently proves each cross-chain link. Nearby timestamps, similar amounts, and a matching destination address support a lead, but are not substitutes for that record. The fifth 1.287 ETH source transfer is observed; its destination correlation is not included in the four-pair total.Figure 2. Individual source transactions and Ethereum receipts were checked in public explorers. Dashed links show pairings reported by the SentinelTX working record, not independently established request-level links. The fifth Base transfer is separate. Values on opposite chains are not added together as a loss figure.Sources: the four Base and four Ethereum transaction pages linked in the exact-records appendix. Pairing provenance: SentinelTX working record; request-level linkage not independently established.Explorer service labels help describe the displayed route. They do not establish ownership, complicity, or the intent of any service or address. This review does not turn the paired totals into an exact allocation of the earlier Slice payout.Where this review stopsThe firmest result is the transaction-level accounting: a USDC receipt and internal ETH payout, a subsequent swap with a small USDC return, and a later ETH transfer from an address with earlier funding. The cross-chain pages add independently observable records, while the request-level linkage remains qualified.We do not establish an incident-specific exchange cash-out, a recovery, a current balance, or the identity of an operator. This is a selected-record review, not a complete address history. A missing finding is not proof that no further movement occurred.Figure 3. Publicly checked transfers and unresolved attribution are different evidence categories. The initial USDC receipt also has an independent RPC check. A transfer's existence does not establish ownership or an exact share of commingled funds.Sources: public BaseScan and Etherscan records linked in this article; retained RPC receipt for the initial USDC transfer. The diagram distinguishes observed transactions from unresolved attribution.Sources and evidence appendixThis article is a new editorial reconstruction from the linked records, not an adopted or sealed SentinelTX report. Public explorer checks were performed on October 22, 2026. The independent RPC cross-check is limited to the seed receipt; it is not a replay of the full execution or an independent verification of every downstream internal call. Cross-chain pairing provenance is identified above. Automated aggregate totals from the working draft were not used as incident amounts or balances.The article's scope ends at the selected transactions below, rather than at an asserted complete-history cutoff. The exact identifiers are provided so readers can distinguish an observed record from a proposed relationship between records.Address registerTransaction sender, Base: 0xc34572ebb26b9a4c54854aae8d2347108e8c892fFundsModule, Base: 0x61bcd1ed11fc03c958a847a6687b1875f5eacaafUSDC token, Base: 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913Onward recipient, observed on Base and Ethereum: 0xfba873b1e5d0256301b87ce74f79a30d6781364aSeparate swap payout recipient, Base: 0xe25c6353a04f9375e9cbac224fda91a90c272e42Exact cross-chain recordsThe pair numbering follows the working record, not an independently authenticated bridge-request mapping.Reported pair 1: Base 0.5 ETH, 0x6ca60f5873a2290cf7284146b4f87ab673d51183d3ba5503ab606774b17e75bb; Ethereum 0.499890262307287644 ETH, 0x4c02a7aa31c6f05662211d69d1031e5f51b5bfc350d01143aba6bb89022abde0.Reported pair 2: Base 5 ETH, 0xa05f56d4fc8484ab69ebbeb4ac4d28e40de98a8eea7244c2dcf2ed5b20b41c86; Ethereum 4.998990272562388387 ETH, 0x7125d47d1d734c5f1c253170fd1edaa72d1901c61ea3902f46e2604682150609.Reported pair 3: Base 5 ETH, 0x4ab516ee7fdca7b0985a132182412f6a860051bebc6e25f5b06db8cb8d37b4f6; Ethereum 4.998990251886325914 ETH, 0xe7ecbc6d35d72e1ec95ea16ae9491b410bff6dfb5e833b6c8c2baefffd33c212.Reported pair 4: Base 5 ETH, 0x485808ce7f4fb6f087072b179decd40aebc1177397488ababfffc8a4f8cb3d1e; Ethereum 4.998990336702981416 ETH, 0xdca2cb6c3fe5542d0447b5a98f2318b62a5a5b8b5090ebdac071fa20b34c9934.Fifth source only: Base 1.287 ETH, 0xb7ff77b677a67d251052557f8c514daaec0b013d1c31142b8674fece02796050. Destination correlation remains unconfirmed in this review.

On 17 October 2026, one Ethereum transaction repeatedly moved USDT into and out of BiFi's USDT market, exchanged most of the resulting surplus for WETH, and paid ETH to the transaction sender and a block fee recipient. This investigation asks two separate questions: how much USDT left the handler on a net basis, and how far the proceeds can be followed without assigning unrelated activity to the incident.The checked route is BiFi USDT handler → execution helper → Uniswap pool → WETH unwrap → ETH payouts. A same-transaction flash loan supplies temporary funding and is fully repaid. The asset path is supported by explorer event records and displayed internal transfers; it stops at the payouts, not at a confirmed exchange deposit or recovery.Who and what appear in the route?The handler is the contract that holds the market's USDT. The execution helper is another contract, called by the wallet that submitted and paid for the transaction. These are different roles: the wallet submits instructions, while the handler is the address whose token balance decreases. The role names below describe recorded activity, not the identity or intent of a person.USDT is a stablecoin token designed to track the US dollar, but the quantities here are tokens, not a historical dollar valuation. WETH is a token form of ETH that can be handled by contracts using the common ERC-20 token interface; unwrapping WETH releases ETH rather than creating a second asset gain. A flash loan is temporary funding that must be returned within the same transaction; otherwise the entire transaction is reversed. Its principal is not the amount lost by BiFi. An exchange pool swaps one token for another; its presence does not establish that the pool or its operator participated in an attack.RoleHow it is used hereBiFi USDT handlerSends and receives USDT during the repeated market interactions.Execution helperBorrows temporarily, interacts with the handler, swaps USDT and distributes ETH.Transaction senderSubmits Anchor A and receives its main ETH payout.Block fee recipientReceives a direct ETH payment inside Anchor A, separate from the transaction gas fee.Earlier deployerCreates a different contract one block before Anchor A; its relationship to the profitable execution remains unproven.Scope and three findingsScope itemBoundaryIncident anchors17 October 2026, 05:42:59 and 05:43:11 UTC; Ethereum mainnet.Accounting scopeAnchor A only: 142 displayed ERC-20 transfer rows; 141 USDT events independently cross-checked against decoded integer values and addresses.Follow-up window17 October 05:43:11–22 October 03:15:00 UTC; incomplete provider coverage, not a complete address history.Verification date22 October 2026; explorer and public-source reads may be later than the follow-up cutoff.Counting conventionToken quantities, no historical USD price estimate. Gas and direct builder payment reported separately.First, the handler's net outflow in Anchor A is 165,575.149730 USDT, not the much larger volume of repeated transfers. Second, the swap, residual USDT and ETH payouts can be reconciled without counting the same value twice. Third, the checked proceeds reach the transaction sender, but the reviewed records do not allocate the incident's ETH to a later cash-out or establish a completed refund.05:42:59 UTC: a deployment, not yet a proven causal linkAnchor B creates a contract from a different wallet in block 26,210,255. Twelve seconds later, Anchor A executes in the next block using a different helper. Both successful statuses, times and addresses were read directly in Etherscan. Deployment record · Execution record.The public DeFiHackLabs reconstruction describes the earlier wallet as the original exploiter and the later sender as a front-runner, meaning a participant that executes an opportunity ahead of someone else. We retain those descriptions as external claims. A twelve-second gap is not proof of copying, shared control or mempool observation. Establishing that relationship would require the relevant bytecode and execution comparison, and evidence of how the later transaction was selected or ordered.UTC / blockObserved event17 October 05:42:59 / 26,210,255Anchor B: 0x15b47e2c0daf723dec64c75b435079d3a1f8a6058b21b9a64dda4844e877a034. Deployer 0x7c78a049fff71609990017b58a959e926e6ec4c6 creates 0x8c0d729d03cb8ecbc79a62a68cdd67ccfa6a7b92.17 October 05:43:11 / 26,210,256Anchor A: 0x756c68055af7a0630aa0b56891ba4de14c56c39cbebe99e47eeb4728f4d6ad14. Sender 0xc0ffeebabe5d496b2dde509f9fa189c25cf29671 calls helper 0xe08d97e151473a848c3d9ca3f323cb720472d015.05:43:11 UTC: temporary funding and repeated market flowsHow much of the transfer volume represents money leaving the market? The helper receives 40,499,999.999997 USDT from the Morpho-labelled contract, then repeatedly sends USDT to and receives USDT from the BiFi handler. The flash-loan event records 40,499,999,999,997 base units; the final repayment returns the same principal. Anchor A events.Within this transaction, 54 transfer events run from the helper to the handler and 83 run back. These counts include zero-value events. The incoming and outgoing sums are large because the same capital is reused. Subtracting one direction from the other answers the narrower question of the handler's token movement. Think of this as reconciling one account: a large amount repeatedly entering and leaving is not the same thing as the final amount that left it. The table counts the recorded token movements, not the market's internal deposit claims.Handler ledger in Anchor AUSDTIncoming: 54 events141,270,327.667580Outgoing: 83 events141,435,902.817310Outgoing minus incoming165,575.149730Start Figure 1 at the temporary loan, move through the two-way market interaction, then read the swap stage. Solid arrows connect ordered accounting stages, not additional losses or equal time intervals.Figure 1. The flash loan nets to zero. The handler net outflow equals swap input plus helper residual. Colors group stages only; line width is not amount. Source: Anchor A decoded Transfer events and FlashLoan event.The net outflow is a transaction-level quantity, not a complete statement of protocol insolvency, affected depositors or unreimbursed user losses. The next step is to account for where that surplus went.The swap changes the asset, not the size of the incidentThe helper sends 165,574.514633 USDT to the Uniswap pool and receives 68.057203111718789216 WETH. The remaining 0.635097 USDT is the helper's net token change within Anchor A, not a current balance query. These two USDT quantities add to the handler's net outflow exactly.ReconciliationQuantityUSDT swap input165,574.514633 USDTHelper USDT net increase0.635097 USDTSum / handler net outflow165,575.149730 USDTSwap output68.057203111718789216 WETHUSDT and WETH are not added together as separate losses. They are different forms of value passing through the same execution. Likewise, the following WETH unwrap is not a new theft of ETH on top of the swap. Full transaction and event record.The ETH payout splits into two branchesWhere does the unwrapped ETH go? The WETH contract sends 68.057203111718789216 ETH to the helper. The helper also receives 145 wei with the submitted transaction. A wei is one quintillionth of an ETH; this tiny input matters when checking the payout to its final digit.Start Figure 2 at the WETH contract, then follow the helper's two payout branches. The gray box below the sender marks an allocation limit and has no onward transfer arrow. Both payout branches belong to the same transaction; their side-by-side placement is not a time axis.Figure 2. Solid arrows are ETH transfers in Anchor A. The dashed gray box is an evidence boundary, not an observed destination. Gas is not a helper payout. Sources: Etherscan internal transfers and the provider call trace.ETH accountingExact amountWETH unwrap into helper68.057203111718789216 ETHTransaction value into helper0.000000000000000145 ETHDirect payment to block fee recipient0.986829445119922310 ETHGross payout to transaction sender67.070373666598867051 ETHTransaction gas fee, paid separately by sender0.000845755321487776 ETHUnwrap plus transaction value equals the two helper payouts exactly. The sender's receipt is a gross payout, not automatically its final profit. Even subtracting transaction value and this gas fee would describe only a transaction-specific ETH change; it would not establish wider trading costs, earlier capital or the operator's incident-wide profit. A direct payment to a block fee recipient also does not establish its knowledge or involvement. Internal transfers and transaction fee.What the code supports—and what it does not yet proveA lending market records interest by updating accounting values over time. The DeFiHackLabs reconstruction proposes that an old interval without market activity was reused while the participant changed utilization—the proportion of deposits currently borrowed. In that explanation, repeatedly crediting interest at changing rates lets the participant withdraw more than it supplied. This is an external reconstruction, not a replay we independently executed. Reconstruction and assertions.Direct source inspection provides a narrower check. In Etherscan's currently published TokenHandler source, _checkFirstAction calculates the current block minus the last updated block, then calls setBlocks and syncActionEXR when the difference is positive. In the published interest-model source, _getInterestAmount reads the stored inactive interval and action accounting rates. _calcInterestAmount reads deposit/borrow totals and calculates rates from them; _getNewGlobalEXR multiplies a rate by the interval. TokenHandler source · Interest-model source.Those code relationships help explain the proposed mechanism. They do not establish the exact historical storage values or independently reproduce the exploit. The provider trace reports that the handler delegated calls to this logic address in Anchor A; delegatecall means code at another address runs using the caller's storage context. The inspected source is a present explorer publication, while the trace is provider-reported incident execution. Neither replaces a complete historical-state replay.The reconstruction also uses distinct block contexts: its comments refer to a 264,059-block interval at the deployment block, while its test rolls to the following execution block and asserts 264,060 blocks. We do not silently merge those values or present either as a historical value independently read by this investigation. The missing evidence is the incident-time storage snapshot, decoded full execution and a reproducible replay at the correct parent state.Why the onward trail stops at the senderThe bounded provider follow-up reviewed activity from 17 October 05:43:11 through 22 October 03:15:00 UTC, with limits of two outward hops and ten material transfers. Its source coverage is incomplete. The sender appears in repeated helper executions, so later balances and payments mix multiple activities. A later outgoing payment cannot simply be labelled the same 67.07 ETH because the address received it earlier.The observation window is a requested time boundary, not proof that every transaction up to that time was retrieved. No incident-specific exchange receipt or directly anchored refund was established in that review. This is not a finding that neither exists: unobserved records and unresolved allocation remain. We exclude surrounding tokens, look-alike addresses and unrelated service labels from the incident route rather than drawing a larger network that the evidence does not support.Response points and next recordsFor the market's maintainers, the concrete technical check is how an idle interval and changing utilization interact across repeated actions in one block. Historical storage, active implementation and the before/after interest accounting should be compared before a patch or root-cause statement is treated as validated. The source relationship suggests a targeted test, not a claim that every other market shares the defect.For fund-flow review, the priority is an anchored return transaction or a defensible allocation method at the mixed sender. A screenshot of its balance, a generic exchange label or an unrelated large payment would not answer that question. Full bytecode and execution records for the earlier deployment are separately needed to assess the claimed front-running relationship.The evidence supports one reconciled path: net USDT leaves the BiFi handler, most is swapped for WETH, WETH becomes ETH, and the helper distributes ETH. The accounting is substantially firmer than the attribution and historical root cause. Those differences are the conclusion of this investigation, not details to smooth away.Evidence appendixFull address registerRoleEthereum addresshandler0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3helper0xe08d97e151473a848c3d9ca3f323cb720472d015sender0xc0ffeebabe5d496b2dde509f9fa189c25cf29671builder0x4838b106fce9647bdf1e7877bf73ce8b0bad5f97deployer0x7c78a049fff71609990017b58a959e926e6ec4c6created0x8c0d729d03cb8ecbc79a62a68cdd67ccfa6a7b92morpho0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcbpool0x4e68ccd3e89f51c3074ca5072bbac773960dfa36usdt0xdac17f958d2ee523a2206206994597c13d831ec7weth0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2logic0x47be3d1def039bd85e7570864bb5148e7491a65fmodel0x29ecabde2c57b6d4183f915ebca1a25804a60db1storage0xfdc7d058bede981ea865fb64d06382a2206a1c42Full transaction anchorsAnchor / scopeTransactionB: deployment; block 26,210,255; 17 October 05:42:59 UTC0x15b47e2c0daf723dec64c75b435079d3a1f8a6058b21b9a64dda4844e877a034A: execution; block 26,210,256; 17 October 05:43:11 UTC0x756c68055af7a0630aa0b56891ba4de14c56c39cbebe99e47eeb4728f4d6ad14Transfer-event inventory for Anchor AThe tables below preserve all 142 explorer-displayed ERC-20 transfer rows in event order. They are not 142 separate transactions. USDT uses six decimal places and WETH eighteen in this inventory; the integer USDT event data were checked against every corresponding displayed amount and address. The separate WETH Withdrawal event records the subsequent unwrap; it is not an additional Transfer row. All these events share Anchor A's block and UTC time above.Event / assetFrom → toAmount12 / USDT0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcb→ 0xe08d97e151473a848c3d9ca3f323cb720472d01540,499,999.99999714 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3121,257.48502916 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3484,544.91017918 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,795,238.89221520 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e37,238,802.15538922 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e330,860,156.55718524 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3026 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50028 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50030 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50032 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50034 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50036 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50038 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50040 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50042 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50044 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50046 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500Event / assetFrom → toAmount48 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50050 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50052 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50054 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50056 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50058 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50060 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50062 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50064 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,50066 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,50068 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,00070 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,50072 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,00074 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,50076 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,00078 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,50080 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,00082 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500Event / assetFrom → toAmount84 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,00086 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,50088 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,00090 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,50092 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,00094 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,50096 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,00098 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500100 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000102 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500104 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000106 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500108 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000110 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500112 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000114 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500116 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000118 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500Event / assetFrom → toAmount120 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000122 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500124 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000126 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500128 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000130 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500132 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000134 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500136 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000138 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500140 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000142 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500144 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000146 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3165,163.833793148 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d015247,951.408655150 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3121,257.485029152 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3484,544.910179154 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,795,238.892215Event / assetFrom → toAmount156 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e37,238,802.155389158 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e330,860,156.557185160 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e30162 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500164 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500166 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500168 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500170 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500172 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500174 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500176 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500178 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500180 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500182 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500184 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500186 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500188 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500190 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500Event / assetFrom → toAmount192 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500194 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500196 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500198 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500200 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0151,498,500202 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500204 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000206 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500208 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000210 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500212 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000214 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500216 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000218 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500220 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000222 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500224 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000226 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500Event / assetFrom → toAmount228 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000230 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500232 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000234 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500236 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000238 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500240 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000242 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500244 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000246 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500248 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000250 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500252 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000254 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500256 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000258 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500260 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000262 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500Event / assetFrom → toAmount264 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000266 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500268 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000270 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500272 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000274 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500276 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000278 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e31,498,500280 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0152,025,000282 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3165,163.833793284 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d015247,951.408655286 / USDT0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3→ 0xe08d97e151473a848c3d9ca3f323cb720472d0150288 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0xe08d97e151473a848c3d9ca3f323cb720472d0150.000068289 / WETH0x4e68ccd3e89f51c3074ca5072bbac773960dfa36→ 0xe08d97e151473a848c3d9ca3f323cb720472d01568.057203111718789216290 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0x4e68ccd3e89f51c3074ca5072bbac773960dfa36165,574.514633292 / USDT0xe08d97e151473a848c3d9ca3f323cb720472d015→ 0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcb40,499,999.999997Evidence classificationClaimBasis / limitationUSDT totals, status and UTC timesDirect explorer overview and decoded event reads; integer calculations reproducible from the preserved inventory. Not an independent node consensus check.ETH payoutsDirect explorer internal-transfer display, corroborated by provider trace.Incident-time delegate targetProvider call-trace report; not independently replayed.Idle-interest exploit mechanism / front-runningExternal reconstruction plus limited direct source inspection; historical state, exact replay and ordering causality unconfirmed.Later cash-out / recoveryNot established; follow-up coverage and allocation incomplete.Sources are linked beside the claims and in the exact records above. Explorer labels are descriptive leads, not proof of human identity or culpability.