When the Trail Doesn't End at the Mixer: Where the Cyrus Finance Funds Went

If you've spent any time in crypto, you've heard the same line: "the funds went into Tornado Cash, so the trail ends there." It's a convenient line. It's also, increasingly, not true. On March 22, 2026, someone drained $516,840 from Cyrus Finance through a textbook flash-loan-plus-broken-withdrawal-logic exploit — CertiK wrote the technical post-mortem the next day and, like most post-mortems, politely concluded with "funds were sent to Tornado Cash in nine batches."

That's where their report ends.

That's where this one begins.

What Actually Happened: The Exploit in One Breath

The technical mechanics are CertiK's territory, and they did a clean job — the full report is here and worth a read. The short version, for context:

On March 22, 2026 at 07:21:24 UTC, attacker EOA 0xf96eb14171b71ac16200013753dff3e91043b63b called a helper contract that did four things in a single transaction. It borrowed 1,798 ETH from PancakeSwap as a flash loan. It pulled Cyrus position NFT #15505 into itself to satisfy an ownership check. It briefly distorted the price of the PancakeSwap V3 ETH/USDT pool by trading against it. And then — while the price was conveniently sideways — it called exit(15505) on CyrusTreasury.

The bug, in plain English: the withdrawUSDTFromAny() function was supposed to pay out USDT. It instead removed both sides of the LP position and sent them along, while only accounting for the USDT side internally. So the attacker walked away with USDT and ETH, the flash loan got repaid in the same block, and the net haul landed in the attacker's wallet: 28.14 ETH + 454,170 USDT, roughly $516,840 at the time.

Seven minutes and thirty-one seconds later, the funds started flowing into Tornado Cash. Nine batches: eight of 100 BNB, one of 10 BNB. Total: 810 BNB. Sixty-five seconds for all nine deposits. Whoever this was, they weren't improvising.

The First Question: Where Did the BNB Come Out?

Tornado Cash, mechanically, does exactly what it says on the box. The cryptographic link between a deposit and a withdrawal is broken — you cannot prove, on-chain, that a specific deposit funded a specific withdrawal. This is the part where most reports end.

It is also the part where the report could continue, because people are the ones using Tornado, and people do things people do: they batch, they rush, they reuse infrastructure, they fund gas from convenient places. None of this breaks the cryptography. All of it leaks signal around the cryptography.

So: nine deposits, some of 100 BNB and some of 10 BNB, all within sixty-five seconds. If the same person controlled both sides, the withdrawals should mirror the deposits in shape. Batch in, batch out. The 100-BNB pool was the obvious place to start looking.

Dune has the data. There's a Spellbook table called tornado_cash.withdrawals that covers BSC alongside several other chains. The query is almost embarrassingly simple once you know which pool you're looking at:

SELECT block_time, amount, recipient, relayer, tx_from, tx_hash
FROM tornado_cash.withdrawals
WHERE blockchain = 'bnb'
  AND contract_address = 0x1e34a77868e19a6647b1f2f47b51ed72dede95dd
  AND block_time BETWEEN TIMESTAMP '2026-03-22 19:30:08'
                     AND TIMESTAMP '2026-03-22 19:30:08' + INTERVAL '48' HOUR
ORDER BY block_time

That contract address is the 100-BNB pool on BSC. The 100-BNB pool processes about 5 withdrawals per day on average, which set a useful baseline: in a 48-hour window, "normal" is around 10 withdrawals from random users.

6 went to the same recipient address: 0xaf73b16ce13b43f59c6907c0ec08c98cb151da06. All within a single tight cluster — the first four landed in a 2-minute-58-second window, the other two trailed by roughly 45 and 94 minutes. Six withdrawals of 100 BNB each, all to the same wallet, all inside the 48-hour window that started immediately after the deposits.

Six independent Tornado users do not accidentally withdraw to the same address. That part isn't probabilistic — it's arithmetic.

Two things about 0xaf73b16ce13b43f59c6907c0ec08c98cb151da06 are worth flagging. First: it didn't pay for its own gas. The wallet's first incoming transaction wasn't a transfer from some funding address — it was a withdrawal directly from Tornado Cash. Whoever built this address treated it as single-use, downstream-only, with no traceable on-chain provenance before the operation began.

Second: it didn't hold the money. Within the same window, all 600 BNB moved out to a new address: 0xe004f67b05F13f488bED402D6eB1B08550e8fA9C. A two-stage structure: a collector (receives from Tornado) and a splitter (does the next thing).

The splitter's next move: those 600 BNB were divided into 16 outgoing transfers, to 11 freshly-created wallets — none with any meaningful on-chain history before that moment.

Where the Bridges Hide

Eleven wallets, twelve separate transactions, all heading to the same destination: a contract at 0x1231DEB6f5749EF6cE6943a275A1D3E7486F4EaE, labeled on Bscscan as LI.FI: LiFi Diamond. A bridge aggregator — a router that takes your tokens on one chain, picks the best route through any of two dozen underlying bridges, and delivers them somewhere else.

Running a Dune query against lifi_bnb.lifidiamond_evt_lifitransferstarted filtered on the 11 attacker wallets returned nothing. So I stopped asking Dune and started asking the bridges directly.

One of the transactions showed an internal transfer to a contract labeled Across Protocol. Across has its own explorer at across.to that takes a sender address and returns the full bridge transfer. I dropped the wallet in: $126,373 USDC deposited on BSC, delivered to Arbitrum, recipient 0xdAfD1e310a8018A55C8E9f907E57F8f0D0104e6B.

One down, ten to go. Most came back from Across. One — 0xe82b5F71655BA70923eb3612235141B55628404E — had used a different LI.FI partner: KyberSwap for the same-chain swap, then Squid Router on top of Axelar. Different bridge, different explorer (axelarscan.io). If you assumed all 11 went through Across, you'd quietly miss the ones that didn't, and your tracing would silently break.

The Landing Pad

The recipients on the destination chains were not wallets that had been doing other things in life. Most had no transaction history before March 23. They sprung into existence, received the bridged USDC, and immediately did the next step.

The first thing each of them did wasn't to spend the USDC. It was to get gas — from wagyu.xyz. Wagyu is a service that lets you pay for gas on a new chain by sending stablecoins on a chain you already have funds on. From an opsec standpoint: the gas you receive has no trace back to you. It comes from Wagyu's own treasury, on a different chain. The link is broken at the funding layer, deliberately.

Every recipient wallet I checked had been funded through Wagyu. Every single one.

With gas in hand, the wallets did the next step: they deposited the USDC into Hyperliquid. Hyperliquid is a decentralized perpetual exchange with its own L1. It has a public API, a native explorer at hypurrscan.io, and an aggregator integration through Debank. The funds aren't hidden. They're just not visible to the tools most people use.

The consistent next step on Hyperliquid was the same across all wallets: convert the deposited USDC into spot positions in a token called XMR1. As of writing, the funds are still there.

A Few Notes to Close On

The cryptographic break between Tornado deposits and withdrawals is real, and nothing in this analysis crosses it. The six withdrawals to a single collector are arithmetically a single controller — that part is certain. The link between that controller and the original Cyrus attacker EOA stays in hypothesis territory, supported by the matching denomination, the batched pattern, the timing, the identical opsec posture on both sides of the mixer, and the architecture of everything that followed.

The bigger lesson is about visibility. Tornado is the part everyone talks about, but the actual trail-break in this case isn't the mixer — it's Hyperliquid. The mixer breaks one specific cryptographic link. Hyperliquid breaks the assumption that "on-chain" means "visible in the tools you already use." Funds sitting in a spot position on a DEX with its own L1, indexed by its own explorer, are functionally invisible to most automated screening — not because they're cryptographically protected, but because the screening doesn't look there.

The other 210 BNB went somewhere too. I followed them. They lead somewhere worth a separate write-up — Part 2.