Across Protocol domain hijack: from aWETH to Bitcoin and Solana

On November 10, 2026, an Ethereum wallet lost 148.599522645 aWETH across four transactions during the Across Protocol domain hijack. Roughly four fifths went to one wallet and one fifth went to a second, which Bitquery identified as the drainer fee wallet. The collector later funded a wallet that sent the funds out on three routes. A downstream Bitcoin payment records the exact hash of its Ethereum input, giving investigators a way to verify one of those routes. A day later, the same address bridged 40,659.841619 USDT from X Layer to Ethereum. The bridge records identify who initiated that transfer. Four earlier liquidity withdrawals and two later swaps explain how the wallet assembled the amount bridged. A link to an Across reimbursement remains unverified.

Verified route segments. Ethereum victim → collector and fee wallet in aWETH. Separately, the collector → splitting wallet in ETH → a THORChain-linked input → Bitcoin output. The splitter’s second verified cross-chain branch reached Solana via Chainflip. The third branch went through Arbitrum to two Hyperliquid accounts, where the USDC was used to buy XMR1.

How the incident began

Across attributed the takeover of its official website address to social engineering at its domain registrar. Control of the address allowed a phishing page to appear where users expected the bridge interface. The project later reported that it had restored access and committed to compensating affected users. Bitquery's investigation describes a wallet drainer, software that uses permissions obtained from a victim to move assets. The records examined here show wallet transfers and their destinations. The registrar account compromise is described in the project's account of the incident. Across restoration update, Bitquery incident investigation.

What left the victim wallet

Aave issues aWETH to represent a WETH deposit. WETH is an Ethereum token representing ETH. Transferring the receipt token moves the claim on the deposited asset. Redeeming it or converting the proceeds later moves value already accounted for in the original loss.

Start at the top of Figure 1 and follow the two arrows to the addresses that received the aWETH. The wallet that submitted the first transaction is different from the victim address recorded in the token logs. The amounts below use the token logs to identify the source and recipients.

Figure 1. Each solid arrow represents the aggregate of four verified transfers to one recipient. Amounts are rounded for the diagram. Arrow width and spacing are schematic. The table preserves the exact amounts.

Both 20:12:23 transactions succeeded and had distinct hashes. The calculation excludes Aave accounting mints, unrelated tokens in the same receipts and later conversions. The repeated split supports the collector and fee roles assigned by Bitquery. The logs identify the receiving addresses.

The two recipients converted and moved funds separately

After the first split, Ethereum execution traces record 28.823367170220056748 ETH and 0.912049936711908441 ETH entering the fee wallet from the WETH contract. These transfers are conversion evidence. Their amounts include activity at the wallet level, so they cannot be counted as additional victim losses. The fee wallet also had ETH receipts before the incident. An incident-wide loss total cannot be derived from its balance. First WETH-to-ETH trace, second trace, pre-incident receipt.

At 20:11:35 UTC, an execution trace records 115.185264363588230966 ETH entering the collector. At 20:17:59 UTC the collector sent 146.268685820 ETH to a splitting wallet. The collector had additional inflows, including a 20.733627715165981828 ETH trace at 20:06:47 UTC whose funding origin was not established. The downstream route therefore tracks value from the collector without assigning every unit to the Ethereum victim above. Collector conversion trace, splitter funding, unattributed ETH trace.

Start at either Ethereum input in Figure 2 and read down to the corresponding settlement. The Bitcoin payment and the Chainflip swap use different records to connect the two chains.

Figure 2. Solid arrows show transaction-level matches. Each pair is a separate settlement. Blue marks the Ethereum input and the other colors distinguish the destination networks. The diagram omits intermediate protocol activity. The records below show how each match was made.

The Bitcoin output identifies the Ethereum transaction in its own data. The Solana payout is tied back through a separate Chainflip record.

The Bitcoin payment names its Ethereum input

A Bitcoin transaction can include a data-only output. Here that output contains the word OUT followed by the exact Ethereum transaction hash for the 47.000201860 ETH send. Bitquery attributes the swap to THORChain. Both Bitcoin sources show output 0 paid 1.30506375 BTC to the same address in block 975354 at 22:36:46 UTC on November 10. The output was unspent when queried. Ethereum input, Bitcoin transaction and data output, independent Bitcoin transaction view.

Solana records show both onward payments

Chainflip records a successful 48.8 ETH deposit and names the matching Solana payout signature in swap 2053940. The destination received 1,197.033564583 SOL after the broadcast fee. The two subsequent pairs of transfers are independently visible on Solana. Chainflip swap 2053940.

Bitquery labels the final address as a Rainbet wallet. The transfer is verifiable on Solana. Account ownership, a customer credit and any further withdrawal would require additional records. Bitquery service attribution.

Hyperliquid records show USDC deposits and XMR1 trades

The Ethereum funding wallet sent 25 ETH to the first address and 23.8 ETH to the second. Both addresses then used the LI.FI router with Layerswap. LI.FI's completed-route records link the Ethereum sends to the Arbitrum receipts. Each Arbitrum address then sent its exact USDC receipt amount to Hyperliquid's deposit contract. Hyperliquid's account records identify the same deposit hashes and the spot trades that followed.

The accounts bought 91.96 and 87.59 XMR1, respectively, before spot fees. XMR1 is a Hyperliquid token associated with Monero exposure. The verified route ends at the spot fills, with any redemption or withdrawal on Monero still unverified. Hyperliquid public API.

Three additional bridge settlements

All three transfers settled to the same collector address on their destination networks. The Ethereum and Arbitrum addresses have the same hexadecimal value. Each row links the transaction that started the transfer to the one that delivered the ETH.

The deBridge order IDs match the source and destination event logs. Both destination contracts forwarded ETH to the collector in internal calls. The Relay request matches both hashes and the same request data, and the Ethereum transaction paid the collector directly. These receipts establish movement of existing funds across chains.

Where the swap’s WETH came from

The 3.197251591561056299 ETH credit came from converting 3.199811440713627200 WETH taken from a separate Arbitrum victim wallet that Bitquery identified in the Across domain hijack. The collector held zero WETH at the end of the block before the victim transfer, held exactly the amount received through the block before the conversion, and returned to zero after the conversion. The ETH amount is the gross credit before gas. Incident research · Conversion receipt.

The victim had 30.919486837431786978 ETH just before the funding transfer. Its indexed Ethereum history includes two large credits from 0x1d43041cbc400ce74e54a3abf4ea93dc5fb19cf9 on July 20, 2023, totaling 112.5 ETH. Those credits establish an earlier funding source. Once ETH enters a wallet balance, the chain records what the wallet spends without assigning that spend to a particular earlier credit. 112 ETH · 0.5 ETH.

The Ethereum deposit and Arbitrum fill share the same Across deposit ID. Their chain IDs, depositor, token addresses and amounts agree. The Across status API returns both transaction hashes for that ID. The bridge funded the victim before the incident. The later ETH conversion traces the collector’s share of the loss, which is already counted in WETH. Across status record.

How much of the first Arbitrum receipt was spent?

The collector's ETH balance was zero immediately before the first payout. Before the next inflow, two approval transactions consumed 0.000003556878 ETH from that first receipt. The WETH conversion above credited 3.197251591561056299 ETH and pooled it with the remaining ETH. Arbitrum wallet history, swap and internal transfer.

The twelve transaction receipts account for 0.000027314746100000 ETH in gas, including two reverted transactions. The successful deBridge and Relay sends carried 3.001150300868641512 ETH and 0.205780917711370723 ETH on Arbitrum. Those are the native values attached on the source chain. The payout table above shows what arrived on Ethereum.

Even if the first receipt covered every gas charge and the entire ending balance, at least 0.009679627018955936 ETH from it had to enter the two bridge sends combined. The upper bound is 0.009988444722000002 ETH, the amount left from the first receipt after the two approvals. The later swap supplied enough ETH for either bridge send individually, so the ledger cannot tell which send used the first receipt or how much each used. The bounds use the collector's native ETH balance and exclude separate token movements.

Did the victim receive compensation?

Across committed to making affected users whole. A payment can be counted when a successful transaction credits an identified victim and the payer or payment batch is independently attributable to Across. The official updates reviewed by the cutoff supplied no payer or batch identifier. A fresh check of the main victim’s indexed Ethereum transactions, internal transfers and token transfers did not show a newer payout candidate. This check covers one victim address and the public records available for it. Across announcement.

The X Layer receipts explain how the wallet assembled the transfer. Before the two swaps it held 12,705.278479 USDT0. At 15:17:23 UTC the wallet swapped USDC for 16,061.785784 USDT0. At 15:17:54 UTC it swapped USDG for 11,892.777356 USDT0. The three amounts add up to 40,659.841619 USDT0, which the wallet then bridged to Ethereum. A historical balance check traced most of that funding to four Uniswap v4 liquidity removals initiated by the victim address on November 10. A liquidity position holds tokens in a trading pool. Removing liquidity returns tokens to the position holder. In each receipt the PoolManager records a negative liquidity change and sends assets to the victim address. Uniswap X Layer deployments. USDC swap, USDG swap.

The withdrawals account for 12,467.494672 USDT0, 15,890.692232 USDC and 11,647.992065 USDG before the swaps. The wallet already held smaller balances in all three tokens. The records establish the immediate sources of the bridged funds. An authenticated Across payer or batch hash would be needed to identify separate reimbursements. A subsequent Hyperliquid withdrawal would need its own receipt and, for a claim about native XMR, a matching Monero-side record.

Evidence appendix

Reproduction. Ethereum: inspect successful receipts for the exact aWETH contract and standard Transfer event, then sum base units by recipient. For native ETH moved inside a contract call, inspect execution traces. Bitcoin: compare the source hash embedded in the data output with the Ethereum input and read output 0 separately. Solana: inspect parsed system transfer instructions. Hyperliquid: query userNonFundingLedgerUpdates and userFillsByTime for the two accounts and match the deposits with the subsequent spot fills. The dollar figure is Bitquery's historical estimate. Values from successive stages describe movements of funds and should never be summed as new victim losses.