2026-05-15 · Loss: 0 · Post-Exploit On-Chain Message

On Ethereum at 2026-05-15 14:59:07 UTC, transaction 0xebeec0fba179c018d5266f6220f6a7fa2151921da6ee1f375bdbc0c1dd02e32a was an on-chain plaintext message, not the exploit transaction that drained TrustedVolumes. The calldata decodes directly to a bug-bounty / settlement demand referencing the previously stolen funds, and the transaction produced no logs, no token transfers, and no ETH transfers. The actual TrustedVolumes drain already documented in this repository occurred earlier on 2026-05-07 in transaction 0xc5c61b3ac39d854773b9dc34bd0cdbc8b5bbf75f18551802a0b5881fcb990513.

Classification

This queue item should be classified as post-exploit attacker communication rather than as a fresh exploit. The automation alert expanded to the message transaction itself, which explains why a normal exploit-investigator run would fail to find a drain path or vulnerable settlement flow in 0xebeec0....

Why This Is Not The Exploit

Transaction Behavior

• to: 0xfa4f52df02e5f3563bc4569a6b43bb6aca617e07
• value: 0
• receipt logs: none
• trace type: single top-level CALL
• asset movement: none

The top-level calldata is ASCII text. Decoded, it reads:

The company is prepared to write off the stolen funds and proceed with a criminal complaint…

The rest of the message proposes a bug-bounty settlement and includes the contact handles @trustedvolumes and [email protected]. There is no exploit logic, no router interaction, no token transferFrom, no flash-loan path, and no attacker profit generated by this transaction.

Trace Summary

trace_callTracer.json for 0xebeec0... is a single CALL from 0x1ef9bfb1e7480c01d3d00e9bca5f29625c6c4806 to 0xfa4f52df02e5f3563bc4569a6b43bb6aca617e07, with the input payload carrying the plaintext message. No nested calls execute and no contracts related to the May 7 TrustedVolumes drain appear in the trace.

Financial Impact

receipt.json contains no logs, and funds_flow.json shows:

• no ERC-20 transfers
• no approvals
• no ETH transfers
• no attacker gains

So the financial impact of 0xebeec0... itself is 0.

Canonical TrustedVolumes Exploit Reference

The real TrustedVolumes drain is the earlier validated incident already present in this repo:

• canonical exploit tx: 0xc5c61b3ac39d854773b9dc34bd0cdbc8b5bbf75f18551802a0b5881fcb990513
• canonical report: reports/trustedvolumes-rfq-proxy-drain/report.md
• canonical incident date: 2026-05-07 00:47:35 UTC
• canonical loss: approximately $5.87M

That validated report shows the actual root cause: the TrustedVolumes RFQ proxy / implementation accepted a maker-authorized signer relationship but later debited a separate calldata-controlled funding address, allowing the attacker to drain the resolver’s approved balances.

Takeaway

For queue processing, scanner links that point to post-exploit on-chain messages should not automatically be treated as exploit transactions. This transaction is best recorded as attacker settlement messaging that references the prior TrustedVolumes exploit, with the exploit analysis anchored to 0xc5c61b3ac39d854773b9dc34bd0cdbc8b5bbf75f18551802a0b5881fcb990513 instead.