Railway-linked wallet: two relay paths converge at a HitBTC-labelled endpoint

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 roles

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

What this review covers

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 sources

Railway'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 link

Can 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 relay

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

Start 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 mint

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

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 unchanged

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

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

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 evidence

For 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 appendix

Full Ethereum address register

Anchor 7: early Ethereum inflow, sender not victim-confirmed

Ink source register and bridge identifier

Anchor 6: Ink USDC burn

Exact Ethereum transaction anchors

Anchor 1: ETH transfer

Anchor 2: ETH transfer

Anchor 3: Ethereum mint receipt

Anchor 4: USDC transfer

Anchor 5: USDC transfer

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