Defend Against Cybercrime with the Power of Community

On 15 October 2026, a single Ethereum transaction moved 2.309861111111111114 ETH out of KolanHook and ultimately paid 1.279914429958618589 ETH to its initiating address, according to the body of SentinelTX report CASE-ASYNC95E. Those figures describe different things. The first is the hook's gross native-ETH outflow; the second is the surplus paid after borrowed principal was returned.That distinction is the starting point for understanding this case. The transaction also involved a 6.7 WETH flash loan and a larger Pool Manager payout. Treating every transfer as a separate loss, or calling the entire payout profit, would misrepresent the reported flows.This article adapts the report's findings for the ChainBounty community. It preserves the distinction between recorded movements and the report's interpretation of the mechanism. It also explains the source's scope and evidentiary limits.The incident ledger: follow the amounts separatelyThe report's body places the successful transaction at 11:06:11 UTC on 15 October 2026, in Ethereum block 26197504. It reports 78 call frames and a maximum call depth of eight. The seed transaction and relevant full addresses appear in the reference key below. [1]The seed-transaction ledger is:Borrowed principal: 6.7 WETH, unwrapped into 6.7 ETH.Principal returned: 6.7 ETH re-wrapped into WETH and repaid within the same transaction.First hook payment to the Pool Manager: 2.050000000000000001 ETH.Second hook payment to the Pool Manager: 0.259861111111111113 ETH.Combined hook native outflow: 2.309861111111111114 ETH.Pool Manager payout to the helper: 7.979914429958618589 ETH.Gross surplus paid by the helper to the initiator: 1.279914429958618589 ETH.Maximum transaction-fee estimate: 0.000487737331891920 ETH.Gas-adjusted proceeds: at least 1.279426692626726669 ETH.The payout reconciles exactly as reported: 7.979914429958618589 ETH minus 6.7 ETH equals 1.279914429958618589 ETH. The hook outflow is larger than that surplus. The report attributes the difference to netting against swap legs inside the Pool Manager; these categories should remain separate.The gas-adjusted amount is a lower bound, not an exact net-profit figure. The report multiplies the gas limit of 3,105,267 by the gas price of 157,067,760 wei to obtain a fee ceiling. It does not provide the seed transaction's gasUsed in the cited evidence. [2]Figure 1. Zero-baseline comparison of hook native outflow and initiator gross surplus. The repaid 6.7 WETH principal is a separate annotation. The two bars measure different things and are not additive; the exact ledger above governs any shortened chart labels.How the transaction unfoldedThe report describes Kolan as a fixed-supply KLN token whose supply sits in a native-ETH/KLN Uniswap v4 pool. In the published design summarized by SentinelTX, the hook is the sole liquidity provider. Buyers pay a premium for a cancellation “window,” during which a purchase can be cancelled and ETH refunded. This design context comes from the report, rather than a separate review of the protocol's code. [3]The reported execution sequence has five useful stages:Deployment. The initiating address created an operation contract, which created a helper contract. The helper carried out the interactions.Funding. The helper borrowed 6.7 WETH from the address labelled Balancer, then unwrapped it into ETH.Initial pool interaction. The helper entered the Uniswap v4 Pool Manager and paid it 6.7 ETH. The Pool Manager invoked KolanHook callbacks.Repeated hook calls. The helper called the hook twice using selector 0x19b05f49. The first call triggered four Pool Manager calls with selector 0x5a6bcfda; the second triggered seven. The hook made the two ETH payments listed above during these hook-driven frames.Exit and repayment. The helper interacted with the Pool Manager again, received 7.979914429958618589 ETH, re-wrapped and returned the 6.7 ETH principal, then paid the remaining 1.279914429958618589 ETH to the initiator. [2]SentinelTX assesses this pattern as consistent with flash-loan-funded price-and-liquidity manipulation of the hook's internal accounting. Its interpretation is that the initial swap displaced the pool price, the hook interactions changed liquidity placement or withdrawal around that price, and the reverse swap captured a difference.That is an assessment, not a fully decoded root-cause demonstration. The report says selectors were not ABI-decoded. It cannot establish whether 0x19b05f49 represents buy, cancel or accept, or whether 0x42966c68 is a burn. The broader classification as a logic/accounting exploit rather than a key compromise is also the report's assessment. A decoded trace and relevant hook events remain important missing evidence. [3]Figure 2. Five-stage incident sequence, from deployment and funding through pool and hook interactions to repayment and surplus. The sequence is reported evidence; the proposed accounting mechanism remains an assessment. Pre-incident transfers do not belong in this flow.Where the traced value stoppedSection 7 names the initiating address as the endpoint in the traced set: one inbound movement and no outbound movement in that set. The body also says the initiator's transaction list was read to its end and no later outbound value transfer was identified as of the analysis. No exchange-deposit leg was identified. These are bounded findings, not a guarantee about future activity. [4]A later contract-creation transaction at 16:48:59 UTC on 15 October is described separately. It involved other contracts and no KolanHook value-bearing frame. Its proceeds are excluded from this incident ledger.The initiator's displayed native balance was 1.539598 ETH at analysis time. Appendix A gives the full address-level reconciliation as 1.539598271282627379 ETH. That balance combines unrelated activity; it is not an isolated balance of Kolan proceeds. Similarly, the report's 0.0 ETH native-balance reading for the hook does not establish its total assets or liabilities, because KLN and Pool Manager claim balances were not read. [4]Earlier transfers are context, not the exit routeThe report records three 1 ETH transfers to an address labelled Tornado.Cash Router and DAI/PAXG transfers to an address labelled Relay.link on 12 October. They happened three days before the seed transaction. They cannot be an onward route for proceeds generated on 15 October.Some source figures combine incident flows with earlier or unrelated activity. Visual proximity and connecting arrows should not override chronology. This article does not adopt the report's sanctions tag as a statement of current legal status, and does not infer a real-world identity or insider involvement from the address history. [5]Important limits inside the sourceThe abstract limits its statements to the evidence available to that summary: it does not supply a transaction date or record terminal endpoints, and its definition of “verified” does not establish the signer. The body separately gives the incident date, block and reported tx.from address (§§1 and 3), and lists the initiator as an endpoint within the traced set (§7). These are different levels of scope and detail, not competing dates or proof of a final cash-out destination. This article attributes the specific transaction details to the body and preserves the source's limits on identity, ownership and onward tracing.The abstract also defines “verified” narrowly: the transaction was retrieved and names the addresses. It explicitly says that this does not establish authorization, ownership or even that a reported asset symbol identifies the intended asset. That label should not be read as independent confirmation of every narrative claim.Appendix A records an executed query from 15 September 2026 at 11:43:17.968656 UTC to 16 October 2026 at 11:43:17.968656 UTC. Of 51 retained movement rows, 44 lack readable timestamps. The seven timestamped rows span 22 September to 12 October; separately, the body supplies the incident timestamp. Query bounds are not proof of continuous transaction coverage or enforcement of a requested historical cutoff. The report also leaves KLN quantities and the impact on individual window holders unquantified. [6]The community takeawayThe useful conclusion is specific: SentinelTX reports a repaid 6.7 WETH loan, two hook payments totaling 2.309861111111111114 ETH, and a 1.279914429958618589 ETH surplus payment to the initiator in one transaction. The proposed manipulation mechanism needs decoding; the traced endpoint does not establish a later cash-out route.For community reporting, retain those boundaries. A stronger explanation would require the decoded hook calls and WindowOpened, WindowClosed and Taxed events identified by the report. Until then, the exact ETH ledger is more informative than a single dramatic “loss” number, and the unanswered questions belong alongside the findings.Figure 3. Reported movements, assessed mechanism, unresolved impact. No later cash-out route or real-world identity is established by this adaptation.Reference key and source notesSeed transaction: 0x7b131926e6f06491ae1aead3e419b208c8aa70ed7898e8c5a33d9f52e40915a9Initiator / reported tx.from: 0x8df735014eab81905e76b87ef0c069bd8e0ae382KolanHook: 0x0136fecf49e0217bfd2d9551e8e7b05f174ba8ecHelper: 0x4d6a41f2b80fe75facf27f9d0b3dc8bd0ebc835fOperation contract: 0xebea460c6496e1a2565aab488eb005473bde5f79Uniswap v4 Pool Manager: 0x000000000004444c5dc75cb358380d2e3de08a90Balancer-labelled lender: 0xba12222222228d8ba445958a75a0704d566bf2c8WETH: 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2Adapted from SentinelTX report CASE-ASYNC95E, generated 16 Oct 2026; findings and limitations as of that report.Source sections: [1] §1 and §3B; [2] §3B and §3D; [3] §1 and §5; [4] §1, §3C, §7 and Appendix A; [5] §3A and source-figure captions; [6] Abstract, §3D and Appendix A.Explorer links are reader-navigation links constructed from the report's exact identifiers. Explorer content was not used as an additional factual source. This adaptation does not claim independent verification of the report's evidence signature.

Autheo says it discovered unauthorized issuance of its THEO token on October 12, followed by transfers to Base. Its October 13 notice describes a halt to origin-chain block production, validator nodes and the affected cross-chain relayer. The project has not yet confirmed the complete token count or financial impact. Autheo’s incident notice.The public records examined here answer a narrower question: what can be established from two Base mints, a later sale, a bulk token transfer and an identified cross-chain payment? They show 19 million and 100 million THEO issued to the same wallet, a successful sale that returned ETH to that wallet, and a Relay deposit whose request identifier also appears in an Ethereum transaction paying that same address. A later transfer sent 93,510,011 THEO to a separate address. These are stages to distinguish, not quantities to add into one loss figure.The main ETH route in brief is token issuance on Base → the receiving wallet’s sale through a swap contract → ETH deposited with Relay on Base → ETH paid to the same address on Ethereum. The bulk THEO transfer is a separate branch. The sale record is one selected conversion, and the cross-chain record is one selected deposit and payment. Neither is presented as the complete incident ledger. The 119 million figure is the exact sum of two mints to one recipient, not every mint on the route or a verified dollar loss.ScopeBoundaryIncident contextOctober 12, 2026; official notice published October 13Direct evidenceSeven selected transactions: six on Base and one Ethereum payoutReview checkpointOctober 14, 2026, 00:14 UTC; selected-record review, not continuous chain coverageCounting ruleMinted THEO, ETH sale receipts and bridge stages kept separate; gas excluded from asset amountsThree findings guide the account. First, the two selected mint receipts establish 119 million THEO issued to one address, extending the initial 19 million alert without establishing a campaign-wide total. Second, an exact identifier match and the Ethereum payment logs connect one Base deposit with actual destination delivery. Third, neither that delivered amount nor the wallet’s whole balance establishes the incident’s net proceeds. The chronology below explains the evidence behind each distinction.First, separate the token record from the people involvedTHEO is a token: its contract keeps a ledger of who owns how many units. Minting creates units in that ledger. A transfer from the all-zero address is the usual accounting sign of a mint; it is not evidence that a real wallet at that address funded the recipient. ETH, or ether, is the native asset used on Base and Ethereum. Receiving ETH after a sale is a different event from receiving newly issued THEO.The transaction submitter, the token contract and the mint recipient also have different roles. A wallet submitted a message-processing call to a contract on Base. The token contract recorded the issuance. A separate wallet received THEO and later submitted the sale. Calling the first wallet “the attacker” solely because it submitted a message would erase the unresolved question of whether it was a legitimate relayer processing an unauthorized origin-side event.A relayer carries information between chains. It does not necessarily move the same physical token from one ledger to another. A destination system can act on a message and issue a local token representation. Establishing whether that issuance was authorized requires the source message and the verification rules in force at the time, not just a destination-side Transfer event.Figure 1 is a route overview before the chronological account. Start with the blue issuance box, follow it to the receiving wallet, then read the two selected branches. The green branch pairs THEO sold with ETH received; the amber branch is a token transfer to another address. The layout groups roles rather than placing all transactions in time order.Figure 1. Selected Base records, not a complete supply reconciliation. Equal-width arrows show issuance and transfer direction. Colors distinguish record roles, not levels of certainty or asset value. The sale amount is rounded to approximately 9.501 million THEO and its ETH receipt to six decimals; the native text and tables retain exact values. Sources: mint receipts, selected sale and bulk transfer in the appendix.The overview shows why a receiving address is not automatically an owner cluster. THEO reaching a second address establishes a transfer, but not its control or consent. The next sections follow when the issuance, conversion and cross-chain payment actually occurred.17:06:59 UTC: a message-processing call records a 19 million THEO mintAt Base block 52,517,736, a successful transaction called the function displayed by BaseScan as process(bytes _metadata, bytes _message). Its receipt contains a Process event with origin domain 2127, a ProcessId event, a ReceivedTransferRemote event and a THEO Transfer from the zero address to the receiving wallet. The last two events contain the same raw amount, 19000000000000000000000000. Dividing by the token’s displayed 18-decimal precision gives exactly 19,000,000 THEO. Mint receipt; token precision.These logs place message processing and issuance inside the same successful transaction. The explorer’s decoded metadata field is empty. That observation does not, on its own, prove a verification bypass: a security module may use other state or caller rules. The origin domain and sender fields are data accepted in this execution, not independent proof of a corresponding backed transfer on the origin chain.The next question is therefore about authority. Which security module and remote sender were configured at this exact block, and what origin-side record justified this message? Current proxy implementation fields cannot substitute for a historical configuration check. The selected receipt establishes issuance, while that authorization question remains open.17:10–17:16 UTC: an unsuccessful attempt precedes a successful saleThe receiving wallet submitted a swap call at 17:10:21. It failed with the custom error SwapFailed. Its gas expenditure is real, but the failed transaction must not be counted as a completed token sale. Failed attempt.At 17:16:13, a different call to the same swap contract succeeded. The overview records 9,501,032.606830209368510124 THEO moving from the wallet to that contract and 189.059271901143347167 ETH returning from the contract to the wallet. The transaction includes many intermediary token conversions and an internal-error warning, but its overall status is Success and its final transfers are recorded. An internal failed route is not the same thing as failure of the whole transaction. Successful conversion.This is evidence of a conversion and a final ETH receipt, not a reason to add every intermediary USDC, WETH and ETH movement together. It also does not establish that every THEO unit sold originated in the selected 19 million mint. Earlier holdings and other token movements need their own reconciliation. The sale’s input is not simplified to exactly 9.5 million THEO in the evidence register.Selected conversionExact asset amountTHEO sent to swap contract9,501,032.606830209368510124 THEOETH returned to the wallet189.059271901143347167 ETHTransaction fee, not sale output0.000089389210983019 ETH17:18:15 UTC: ETH enters Relay on BaseTwo minutes and two seconds after that successful conversion, the wallet sent 280.448146679916230118 ETH to an address BaseScan labels Relay: Depository. The deposit exceeds the ETH receipt from the single sale just discussed. It must therefore be read with the other receipts and starting funds, rather than attributed wholly to that one conversion.The successful deposit’s log 227 names the sender, the exact native amount and a 32-byte request identifier. A request identifier is a reference that can help distinguish one cross-chain operation from another. It is stronger linking evidence than two transfers happening a few seconds apart or having similar amounts. Base deposit and request ID.A deposit is still only the source-side record. It does not prove what arrived on Ethereum. To answer that question, the investigation must locate an actual destination transaction and check both its recipient and the reference connecting it to the deposit.Eight seconds later: the Ethereum transaction records actual deliveryAt Ethereum block 26,177,837, timestamped 17:18:23, a successful solver-submitted transaction paid 278.520848939786734261 ETH from the Relay: Router V3-labeled contract to the same hexadecimal address as the Base depositor. Logs 54 and 55 record the recipient and exact amount. The source deposit’s 32-byte identifier also appears as the final 32 bytes of this transaction’s input data. Ethereum payout logs; input data.The destination’s decoded FundsMovement metadata is a different value. The matching source identifier was found in the transaction input, not in that event. This distinction matters for reproducibility. The evidence is an exact byte match plus an actual destination payout, rather than a claim that the explorer decoded the same identifier into both events.This supports linking the selected deposit and payment without relying only on their timing. It is not a replay of Relay’s settlement system or a complete audit of its order records. The original order response would make the identifier’s service-level meaning independently checkable as well.StageETHMeaningBase deposit280.448146679916230118Source native amount in RelayNativeDepositEthereum payment278.520848939786734261Actual recipient amount in payout logsArithmetic difference1.927297740129495857Not independently classified as a pure bridge feeThe two native amounts should not be added as separate losses. Nor should their difference automatically be called the bridge fee: solver conversions, price movement and fees can affect the delivered amount. Determining that breakdown requires the quoted route and settlement accounting.Read Figure 2 from the Base deposit at the top to the Ethereum payment at the bottom. The middle panel identifies the linking evidence: the source request ID is also present in the destination transaction input. The arrows represent the selected linked stages, not a scale of value or elapsed time.Figure 2. One source deposit and one actual payout on October 12, 2026. Values are rounded to six decimals; the table above preserves full precision. The source identifier is found in destination calldata, not in the destination FundsMovement metadata. Other deposits and their fulfillment status are outside this figure. Sources: Base deposit and Ethereum payout links above.The destination evidence goes further than a source deposit alone: it records an actual payment. It still leaves the remaining orders and the wallet’s pre-existing funds to reconcile. The chronology now returns to Base, where a second, larger mint followed.17:45:03 UTC: a second mint adds 100 million THEOAt Base block 52,518,878, the same submitter called the same message-processing target. The successful receipt again includes Process, ProcessId, ReceivedTransferRemote and Transfer events. Log 249 records 100000000000000000000000000 raw units issued from the zero address to the same receiving wallet: exactly 100,000,000 THEO at 18 decimals. Its message ID is different from the first mint, so these are two distinct transactions rather than two views of one issuance. Second mint receipt.The two mints are 38 minutes 4 seconds apart and sum to 119,000,000 THEO. This expands the observed issuance beyond the 19 million in the early alert. It does not establish the entire route’s incident-wide mint total or whether matching collateral existed on origin domain 2127. Those are separate scope and authorization questions.17:57:55 UTC: 93,510,011 THEO reaches a separate addressA later successful transaction, Base block 52,519,264, records 93,510,011 THEO moving from the mint recipient to a second address. The token’s log 591 contains the full sender, recipient and raw amount 93510011000000000000000000. Bulk transfer receipt.BaseScan displays an ENS name for that recipient. A displayed name is not evidence that the recipient shared control with the sender or knowingly participated in the incident. The diagram stops at receipt rather than extending an ownership accusation. This selected-record review does not establish the recipient’s current token balance or its later disposition.What these records do not establishPeckShield’s original alert associated the incident with 19 million minted THEO and 700.8 ETH swapped or bridged. The Ethereum address overview displayed approximately 700.8 ETH during this review, but the same address has signed activity predating the selected mint. A whole-address balance is not a transaction-specific proceeds ledger. This report does not reproduce that headline as an independently verified loss total. Original alert; Ethereum address history.The Base address list also shows several other Relay deposits and multiple swap calls. The selected payment is one linked branch, not evidence that every deposit had the same destination or was fulfilled on the same terms. A complete account reconciliation would separately identify all successful sale receipts, failed attempts, initial funds, fees, source deposits and request-linked destination receipts.The observed route does not establish a real-world operator, a completed exchange cash-out, recovery or a freeze. It also does not establish whether the minting failure was inside Autheo’s route configuration, an origin-side authorization failure or a broader messaging-system compromise. The historical verification module, approved remote sender and corresponding origin-chain message remain the specific records needed to test those explanations.The next evidence should address authority and accounting separatelyFor the mint, the useful package is the origin-chain transaction, its message identifier, the destination’s incident-block implementation and the verification-module configuration that accepted it. Comparing those records would test whether an authorized relayer handled a false or unauthorized message, rather than assuming that the transaction submitter was itself the exploiter. Autheo’s announced shutdown is a response action, not evidence resolving that cause.For the proceeds, the next step is to reconcile every successful sale receipt against the wallet’s earlier THEO and ETH holdings, then pair each Relay deposit with its own order record and destination payment. This would separate newly realized value from older receipts and explain conversion costs without assigning every unit in the Ethereum balance to this event. Any service request should name the exact deposit, payout and identifier; there is no verified exchange-freeze target in the selected records.The central finding is consequently bounded but useful: two selected mints issued 119 million THEO to one recipient, and the records distinguish an actual sale receipt, one identifier-correlated Ethereum payment and a separate bulk THEO transfer. The complete issuance scope, the authorization failure and the incident-specific net proceeds remain separate questions. Following one value-bearing route does not answer all three.Evidence appendix: selected transaction anchorsMethod and provenance: SentinelTX was used to identify investigation leads; the seven transaction anchors below were then inspected directly in BaseScan and Etherscan, including the relevant mint, deposit and payout logs. The official notice supplies the project’s incident account; explorer records supply transaction facts; arithmetic and identifier comparisons are this report’s analysis. This is a selected-record reconstruction, not an exhaustive account audit or a determination of operator identity. Explorer address labels are service annotations, not proof of ownership. The review checkpoint above is when this selection was checked, not an inferred provider-query cutoff.UTC on October 12RecordFull transaction hash17:06:59 · Base 5251773619,000,000 THEO mint0x4fdbbc5e7d18e92790a6b21d6711a12a5cbb0557b829efde3901e682cd73cd8817:10:21 · Base 52517837Failed swap; excluded from proceeds0x4f0cdcaecf1b55abf8d363b35ce705bfe965c132157f3dffce692294d6a130e017:16:13 · Base 52518013THEO input and ETH receipt0x9d2a604246abdd8b8a847049f114a670218d307a3160d37a0c4e567edde73fcb17:18:15 · Base 52518074Relay native deposit0x88728afe998c34a50f7dcbfb8e1afe1ae62e13a2952f1a30dd08b8589722215417:18:23 · Ethereum 26177837Actual native payout; source ID in calldata0x1041849f2e569c355623ecac29c99105dd7afc2638ef4b518de8d7f664b3a55717:45:03 · Base 52518878100,000,000 THEO mint0x8c8dc4d6ae3db970339eabb498e19eeaa6555999d4752f54bfdbc1483a66073017:57:55 · Base 5251926493,510,011 THEO transfer0x3662883f9f4c072566dba4f1aade3e93ae2c43dee3a7eb83e5382de9f984dfa1Address roles by chainRole and chainFull addressMint transaction submitter · Base0xeF305Ec5DF4054B15295A0389787bf671Ab930CEMessage-processing target · Base0x14b8591b00671835A2d5bb7A3B6822319e853EA7THEO token · Base0xebE516a20238F79DC20b07eaD6768e08891Ed309Mint recipient / seller / depositor · Base0x3048b4Ee5A070F33b73E3401829847255079E0ADSwap target · Base0x599bFa1039C9e22603F15642B711D56BE62071f4Relay: Depository label · Base0x4cD00E387622C35bDDB9b4c962C136462338BC31Relay: Router V3 label · Ethereum0xb92fe925DC43a0ECdE6c8b1a2709c170Ec4fFf4fActual payout recipient · Ethereum0x3048b4Ee5A070F33b73E3401829847255079E0ADBulk THEO recipient · Base; ownership unestablished0x690d7552375Fcd23Bd2a5E1d74f7445FAdfc6c83Identifiers are not transaction hashesThese values identify the selected deposit or accepted message, not a wallet or transaction. The source deposit ID is the byte sequence compared with the Ethereum input.IdentifierFull valueBase deposit request ID0x4828b9e98b0c7cf339bd2b70b8f15e34556b541dfcae90b7348e899d2ec2c0b1First mint message ID0x90f1798b12b66ceed4570ecdbea9e5e74c20f0daf9efdc4c25d4195918a2f2d8Second mint message ID0xb83af7f85b67993adf0c2ae4fdb9befa88983d1ec1890810640d89bb798b20d2

On October 9, 2026, BitBay’s StableVault on Polygon transferred 14,838.466608989136 DAI to a newly deployed contract. In the same transaction, that contract delivered 14,813.548248 USDC to the address that had deployed it. The USDC left that address 39 seconds later, passing through a MetaMask-labeled router to an unlabeled contract where the report’s incident trail stops.SentinelTX assesses the transaction as a flash-liquidity-assisted vault accounting exploit, consistent with a reported flaw that allowed a full withdrawal when liquidity equaled zero. The recorded DAI payout and USDC receipt anchor that finding. Their conversion relationship is inferred, and the report does not decode the vault’s ABI or the conversion swap.A later 4,156.374927 USDC receipt followed the same exit route. Its relationship to BitBay remains unresolved, so it is kept separate from the seed vault loss throughout this article. The receiving address’s total USDC activity is broader than the value attributed to the vault.This article adapts “BitBay StableVault Incident — Polygon Investigation Report,” SentinelTX case CASE-ASYNCA99, dated October 12, 2026. All case findings and qualifications come from that PDF. Times are UTC, and the chain is Polygon PoS, chain ID 137. The report’s “verified” transfer status means the transfer was retrieved; it does not by itself establish who signed it or whether it was authorized.Funding and deployment preceded the vault payoutAt 02:00:17 on October 9, the starting externally owned account, or EOA, 0x59ae3c…e9884b, received 2,461.5991 MATIC from 0xc1d134…18a1b5. The report identifies this as the EOA’s only inbound native transfer on Polygon in the provider list it read to its end.The funding contract is unlabeled in the consulted label database. A public-documentation search snippet associates the same address string with a Bridgers contract on Avalanche. SentinelTX treats this as a single-source lead consistent with a cross-chain payout. Its bridge check found no correlated source swap, leaving the funding chain and originating address unresolved.The EOA’s first outgoing transaction, at 02:15:12, deployed 0x8eac46…330f43b. No subsequent EOA call to that contract appears in the transaction list. SentinelTX suggests it may have been a test or failed build; its purpose remains unresolved.At 02:18:45, the EOA deployed the contract used in the incident, 0xc2c6f4…3c23e2. At 02:23:42, block 95204942, it called that contract with selector 0xde463630. This successful, zero-native-value call is the seed transaction for the report.Within that transaction, BitBay’s vault 0x048e88…f2e5a0 paid 14,838.466608989136 DAI to the deployed contract, and the contract sent 14,813.548248 USDC to the EOA. These are different assets and different quantities. The report’s vault-loss figure is the DAI payout, rather than the USDC that reached the EOA.The call sequence supports an accounting exploit assessmentThe PDF cites press snippets reporting SlowMist’s account of the flaw: StableVault’s _withdraw() function permitted a full withdrawal when liquidity == 0. In that description, a zero-liquidity reading became permission to release the full position. The primary SlowMist X post is not quoted in the report.SentinelTX’s recorded call tree contains 221 frames, reaches a maximum depth of 10, and has no revert. Its reconstruction proceeds through the following stages:Initial reads. The deployed contract reads the vault and its own DAI balance.First liquidity source. It calls Uniswap-labeled 0x5645dc…40a8cf, which transfers 106,411.49245613333 DAI to the deployed contract and calls back into it.Nested liquidity source. Inside that callback, it calls Balancer-labeled 0xba1222…6bf2c8, which supplies 1,453.5690015255825 DAI and makes another callback.Vault deposit. Within the nested callback, the deployed contract approves DAI and calls the vault. The vault pulls DAI, then interacts with Uniswap-labeled 0x673667…3e5cd6 through a session containing liquidity, take, settle and swap-type calls.Direct pool interaction. The deployed contract opens its own session with that same Uniswap-labeled address, including a USDC take and a DAI transfer.Vault withdrawal. It calls the vault again. The vault opens another pool session and receives DAI. The recorded seed movements include the vault’s 14,838.466608989136 DAI payout and the contract’s 14,813.548248 USDC payout to the EOA.Other seed-transaction receipts into the deployed contract include 93,037.23599691519 DAI and 107,843.364597 USDC from 0x673667…3e5cd6. These larger execution flows are not the reported vault loss. Adding them to the DAI payout would mix liquidity used during execution with the value attributed to the affected vault.SentinelTX assesses this as flash liquidity funding a vault deposit, followed by a direct change to the underlying position’s state and then a withdrawal. That sequence is consistent with the reported liquidity-zero flaw. The PDF leaves important parts undecoded: repayment to the liquidity sources, the vault ABI, and the swap connecting the extracted DAI to the USDC delivered to the EOA. The conversion is an inference from the observed amounts.Diagram 1. The seed transaction on October 9, 2026 at 02:23:42 UTC. The PDF separates a press-reported liquidity-zero withdrawal flaw from the observed transfer of 14,838.466608989136 DAI from the vault to the exploit contract and 14,813.548248 USDC from the contract to the EOA. It treats the DAI-to-USDC conversion as an inference, not a decoded swap, and does not decode the repayment legs. Equal-width arrows indicate mechanism or transfer direction, not value.Color key: Slate identifies the vault’s DAI payout; sage identifies the first-wave USDC delivered to the EOA. Neutral text shows the press-reported mechanism.Address/role key: Vault = 0x048E88311ca84876aeA086125825492e2AF2e5A0; exploit contract = 0xc2c6f4f7e1425be1dcb996175cf7852bf53c23e2; EOA = 0x59Ae3c8dd50063429D86BdaEBbC350fB64e9884B.Source: SentinelTX, BitBay StableVault Incident — Polygon Investigation Report, CASE-ASYNCA99, October 12, 2026, pp. 8–9, §5 “Transaction Typology.”The first USDC receipt left in 39 secondsAt 02:24:21, the EOA called 0x3a0b42…3d7a16, labeled MetaMask, immediately after an approval call to the USDC contract. The exit transaction moved 14,813.548248 USDC from the EOA to 0xfb7c74…86b025.The report describes the recipient as an unlabeled, high-volume contract. A search snippet showing a fee event supplies a possible router or settlement-address lead, but no verified operator attribution. “MetaMask-labeled” describes the router label consulted by SentinelTX; the onward recipient is a separate address.The incident’s USDC route is therefore established to that receiving contract. Its destination network and eventual recipient are not established. Bridge-correlation checks on the two USDC exits and the later MATIC exit found no correlated destination. SentinelTX assesses the pattern as typical of a swap-or-bridge exit, while retaining that unresolved boundary.A later USDC receipt cannot be added to the BitBay lossAt 03:36:48, the same EOA deployed 0x5e5b9d…ad4606. Five calls with selector 0xbb2bd489 followed between 03:38:15 and 03:41:54.At 03:42:59, block 95208113, another call to that contract produced 4,156.374927 USDC from the Uniswap-labeled 0x673667…3e5cd6 to the EOA. The transaction has 13 call frames involving the newly deployed contract, that Uniswap-labeled address, USDC and the unlabeled 0x3a9a81…20fc34. The BitBay vault does not appear in this call tree.SentinelTX assesses the pattern as settlement of a position in 0x3a9a81…20fc34, possibly built by the five preceding calls. Whether that position represents BitBay value, a second victim’s assets or the operator’s own capital is unresolved.At 03:43:27, the EOA forwarded all 4,156.374927 USDC through the same MetaMask-labeled router to the same receiving contract. The repeated route connects the activity operationally, but does not establish the source of the second receipt.Figure 2. Two separately scoped USDC receipts at the same EOA on Polygon: 14,813.548248 USDC at 02:23:42 UTC and 4,156.374927 USDC at 03:42:59 UTC on October 9, 2026. Bars share a zero baseline and an axis measured in USDC. The later wave’s relationship to BitBay is unresolved; these receipts are not a combined BitBay loss total.Color key: Sage identifies the first-wave USDC proceeds from the seed transaction; amber identifies the later USDC receipt whose BitBay relationship is unresolved.Address/role key: EOA = 0x59Ae3c8dd50063429D86BdaEBbC350fB64e9884B; first-wave sender = exploit contract 0xc2c6f4f7e1425be1dcb996175cf7852bf53c23e2; later-wave sender = Uniswap-labeled 0x67366782805870060151383f4bbff9dab53e5cd6.Source: SentinelTX, BitBay StableVault Incident — Polygon Investigation Report, CASE-ASYNCA99, October 12, 2026, pp. 4–5, §1; p. 7, §3; p. 9, §5.Keep the account totals separate from the lossThe report’s quantities describe different parts of the record:Seed vault loss: 14,838.466608989136 DAI, paid to the deployed seed contract.First EOA payout: 14,813.548248 USDC, received in the seed transaction and forwarded at 02:24:21.Later EOA payout: 4,156.374927 USDC, received at 03:42:59 and forwarded at 03:43:27, with its relationship to BitBay unresolved.Total EOA USDC movement: 18,969.923175 USDC received and 18,969.923175 USDC forwarded; net movement over the traced scope is 0. This is account-flow accounting, not an additional loss figure or a queried current balance.MATIC funding and disposal: 2,461.5991 MATIC received; 2,443.061934040620841817 MATIC sent to the MetaMask-labeled router at 03:43:51; 18.515648776563152138 MATIC spent as gas in the provider-listed rows.MATIC accounting remainder: 0.021517182816006045 MATIC, calculated as provider-list inflows minus outflows minus gas. Appendix A expressly says these provider-list totals are not a balance.The PDF’s narrative and quantity summary print the seed loss as 14,838.466608989136 DAI. Its evidence table retains additional precision in the “Transfer amount” column: 14,838.466608989135865711 DAI. This article preserves the report’s narrative figure for the main finding and identifies the more precise table value here.The whole recorded sequence runs from funding at 02:00:17 to the MATIC exit at 03:43:51, approximately 1 hour 44 minutes. The report finds no fund return, negotiation message or bounty transfer in the EOA history it describes. It identifies zero exchange deposits in the examined evidence, leaving any later exchange deposit or fiat cash-out undetermined.The exit boundary defines the next useful evidenceThe last receiving contract in a trace does not establish a final cash-out destination. At 0xfb7c74…86b025, the report records 4,467 rows read and left unwalked, a page limit and a provider page that did not answer. The router’s outbound read and the funder’s inbound read stopped at high-volume boundaries. These collection limits matter when interpreting the missing onward path.SentinelTX prioritizes routing records for the three exit transactions. It recommends seeking the route adapter, destination network and recipient from the router operator, identifying the receiving contract’s operator, and obtaining settlement records for the two separate USDC legs. These are proposed next steps, not completed information requests or established recovery routes. No exchange freeze target is anchored in the report.The funding lead is separate. SentinelTX recommends obtaining a source-chain record for the 2,461.5991 MATIC payment and examining the same address’s existing Relay history on Ethereum and BSC under a separate scope. The PDF records those cross-chain leads without linking their transaction hashes to the Polygon incident.For wave 2, it recommends classifying 0x3a9a81…20fc34 and decoding the five preceding calls. For BitBay, it recommends pausing or deprecating the affected vault, auditing sibling vaults with the same liquidity-zero withdrawal logic, and publishing a post-mortem reconciling the full vault-side loss. The report does not contain the vault’s full token history, so loss in other transactions remains unresolved.Figure 3. The PDF’s conclusion separates the seed-transaction loss of 14,838.466608989136 DAI from the traced USDC endpoint. The onward network and recipient are unknown. No exchange deposit is identified in the examined evidence; a later exchange deposit or cash-out remains undetermined. Wave 2’s relationship to BitBay is unresolved, and the full vault token history is outside the report. The priority next step shown is the report’s request for router routing records.Color key: Slate marks section headings only; conclusions and limits are stated in text.Address/role key: Unlabeled settlement contract = 0xfb7c744da69aef11dfb54f31d9db12a3b086b025; MetaMask-labeled router = 0x3a0b42ce6166abb05d30ddf12e726c95a83d7a16.Source: SentinelTX, BitBay StableVault Incident — Polygon Investigation Report, CASE-ASYNCA99, October 12, 2026, pp. 12–13, §9 “Conclusion.”Continue from the documented boundaryThe useful continuation is to establish what happened beyond the two USDC exits while preserving the distinction between the seed loss and the later receipt. In SentinelTX, start from the seed transaction and the report’s unresolved routing boundary. A focused investigation prompt is:Investigate the BitBay StableVault incident on Polygon PoS, chain ID 137, using transaction 0x5b795dc5c5e1665b712c7ccf478c1d8c59a162d698f4e0bfb40bd303e04a7ff2 and case CASE-ASYNCA99 as the October 12, 2026 baseline. State the query time, window and collection limits. Trace the onward destination of the two USDC exits, 0x397c0c95e3bea5966d9bec90bf752b7850809b8e82ff1b82b95d30011562f821 and 0xcc6be3077e62cba412d790e074e81030f4ecc188ff9d0f1408affb765d4dabb4, and the MATIC exit 0xa48e780331293f52ef5928ffeb29d5298d679861f1decc12289828ff1b96792c. Keep the 14,838.466608989136 DAI seed loss, 14,813.548248 USDC first payout and unresolved 4,156.374927 USDC wave separate. Can the route adapter, onward network and recipient be established, and what supports any exchange or bridge attribution? Distinguish retrieved transfers, decoded execution, assessments and provider-list accounting.Source and scopeThe sole factual source is the 20-page native SentinelTX PDF, “BitBay StableVault Incident — Polygon Investigation Report,” case CASE-ASYNCA99, dated October 12, 2026 and generated at 00:28:56 UTC. Its executed query windows span September 9 to October 12. The 11 retained movement rows run from October 9 at 02:00:17 to 03:43:51; a query window is not continuous transaction coverage.The article follows the PDF’s incident quantities and explicit qualifications, rather than treating every edge in its figures as incident loss. The PDF warns that a drawn edge also totals other transfers between the same addresses. That aggregate is not used here.