The mixer trail, checked against Car’s disclosed accounts.

Start with the transfer we can prove

On October 29, C91 signed a 0.1 ETH deposit through the Tornado router. Later withdrawals are transactions by pool users; the public deposit event does not tell us which one spends C91’s note. Every card below opens its supporting records.

Root checks, coverage and transaction inputs ↗

Why the deposit does not reveal the withdrawal

A depositor creates a private note from two secret values. The deposit publishes a commitment derived from them. A withdrawal publishes a different value, the nullifier hash, and a proof that the spender knows a valid note. The secrets and the note’s position stay private. We cannot calculate the matching withdrawal nullifier from C91’s public deposit commitment. Official withdrawal circuit ↗

A withdrawal also supplies a root: a snapshot of the deposit tree. A snapshot created before C91’s deposit cannot include it. We compared the withdrawal roots with the pool’s actual pre-deposit ring. None matched that sampled earlier ring. The test therefore excludes zero withdrawals; it does not identify any withdrawal as C91’s. An older root outside the sampled ring is not covered by this comparison. Exact root results ↗

The deployed pool reports a history size of 100. The current reference repository uses 30, so this audit used the deployed getter and historical state. The root check’s assumptions and the contract’s migration state are recorded in the proof. Reference tree logic ↗

The contract keeps deposit commitments recorded after withdrawal. A true commitment getter is not proof the note remains unspent. A withdrawal can also pay less than 0.1 ETH because its declared fee is deducted. Matching the amount or using the same relayer is insufficient to connect two people. Withdrawal checks ↗ · ETH payment and fee logic ↗

What the Car comparison actually covers

We tested exact addresses and signing keys against 111 pool withdrawals. Publicly disclosed profiles, their bound controller keys, trading counterparties and general financial peers remain separate sets. A counterparty’s transaction does not make its wallet Car-controlled. These comparison sets overlap; their counts cannot be added together.

The inventory covers eight publicly disclosed profiles and eight bound controller keys. Seven controller bindings come from retained owner getters; the main key is checked against 20 retained digest/signature pairs. No exact financial-role match emerged. The earlier five-key financial set includes independent peers and is not an ownership register. Address inventory, exact tests and financial-edge coverage ↗

A stronger link would be a verified transfer involving an attributed wallet, shared signing authority, or a specific financial intermediary tied to both routes. Shared public bridges, exchange service wallets, sponsored-transaction systems and withdrawal relayers do not establish that link.

Where the checked money stands

Fresh selected balances, with their own chain cutoffs. The unchanged C91 transaction counter supplies no additional ordinary Ethereum transaction; it does not rule out sponsored actions, receipts or other assets.

The selling account’s pUSD increased by just 0.0011. The matching canonical-token transfer was part of a bulk distribution to 400 recipients. This is an incoming transfer, without evidence that the selling-account owner initiated it. Fresh state, pool events and bulk-transfer proof ↗

The pool recorded 6 more withdrawals and 1 more deposit since the earlier cutoff. Those are pool totals, not new attacker transfers.

The Base payment remains a concrete lead

The 3f701 key signed an Across instruction for 1,526.93 USDT, explicitly choosing recipient 1332 on Base. The matching 1,526.93 USDC then entered a payment authorized by the 1332 key. The payment receiver got 1,511.6607 USDC after a 15.2693 USDC fee.

That receiver later swept 2,267.694 USDC, including 756.0333 already present, to an address labelled Coinbase 14 in the retained explorer records. The payment gives us a specific financial handoff. It does not identify the receiver’s business or the attacker’s exchange account, and receiving the payment alone does not establish complicity. Signed destination ↗ · Base payment authorization ↗ · Receiver’s onward transfers ↗

Evidence and remaining gaps

The disclosed-account bindings retain their original observation times. The retained 3,485-edge actor-side graph contains no disclosed-account edge, but it does not cover every withdrawal recipient’s onward history or all Car activity. No complete indirect-link search, note-secret recovery, Groth16 proof verification, Solidity compilation or independent consensus proof is claimed. The direct payment trail does not identify a merchant’s business or exchange customer.

Prepared 2026-11-01T01:53:06.053835+00:00. Financial records retain their block, transaction and query cutoffs.