Chainflip says a Tron memo triggered $736,442 in duplicate refunds
Chainflip says a Tron memo triggered duplicate refunds totaling 736,442.17 USDT across six payouts. Public docs put the memo in signed transaction data; Chainflip has not explained how that signing step worked.
Chainflip says a Tron memo triggered duplicate refunds. On its count, six unauthorised payouts moved 736,442.17 USDT off the Tron route in the early hours of Saturday, September 12, 2026. Its explanation leaves an unanswered question about how the transaction was signed.
Chainflip is a cross-chain swap protocol that settles native assets across chains such as Bitcoin, Ethereum, Solana, and Tron. In the project’s framing, vaults and validators move the asset rather than minting a wrapped copy on the destination chain.
One deposit, two payouts
In “Tron USDT exploit: what happened, and what happens next” (September 13, 2026), Chainflip wrote:
On Tron, the attacker found a way to attach a memo of their own to a transaction our validators had already signed. Our systems read that memo as a separate swap, treated it as a failed one, and issued a refund. The same deposit ended up being paid out twice.
The same post says the pattern ran eight times over about ninety minutes, starting small and roughly doubling each round, and that six unauthorised payouts totaled 736,442.17 USDT under “current analysis.” A separate pending user swap of 115,654.41 USDT could not be paid during the incident, remains in the vault, and “can be on restart.” Other funds, Chainflip said, are “unaffected and secure.”
Chainflip’s matching X update on the Tron USDT exploit repeats the 736,442.17 USDT figure, the make-whole intent, and the pause. It does not restate the memo mechanism; that detail stays with the blog.
| Bucket | Figure |
|---|---|
| Attempts described | 8 over ~90 minutes (roughly doubling) |
| Unauthorised payouts | 6 |
| Taken | 736,442.17 USDT |
| Pending user swap in vault | 115,654.41 USDT (not part of the taken total) |
| Payout hashes | Not published in the Sep 13 disclosure |
Tron’s memo is part of the signed data
Chainflip’s broker docs for Tron vault swaps describe a Tron vault swap as a direct transfer to the vault, with encoded swap parameters attached as a note on the transaction. That note is how Chainflip identifies what the deposit is supposed to do. Most other Chainflip routes, per the Sep 13 disclosure, use dedicated contract functions instead.
Public Tron tooling maps that memo into the transaction’s raw_data.data field. TronWeb’s addUpdateData docs say the added memo is stored in raw_data.data, the helper is documented for an unsigned transaction, and after the update the txID changes so the new object must be signed. Tron protocol transaction docs place optional memo bytes inside raw_data. Tron signature and broadcast docs say the client computes SHA-256(raw_data) as the txID and signs with secp256k1. Chainflip’s public SDK example attaches the note with addUpdateData before tronWeb.trx.sign.
In short, public documentation places the memo inside the signed transaction data. Normal client flows set it before signing. Updating it changes the txID.
raw_data.data, unsigned-tx use, and txID change after update. Original · Enlarge.The signing step Chainflip hasn’t explained
Chainflip says the memo was attached to a transaction “our validators had already signed.” Public documentation places the memo inside the signed transaction data. Chainflip’s disclosure does not explain how the attacker-added memo interacted with that signing process.
That gap is the story’s open reporting question: which transaction and which signature stage does Chainflip mean, and can it publish the six payout hashes? Until those answers land, the article does not claim that signed Tron transaction bytes were rewritten while remaining valid.
What changed after August’s incident?
On August 24, 2026, Chainflip said it contained an attempted exploit aimed at cross-chain messaging and refund logic on Ethereum. Deposits and quoting on Ethereum, Arbitrum, and Tron were paused as a precaution. The project said no user funds were lost, then restored service after a network upgrade.
The Aug 24 post does not publish a Tron note/memo changelog. Whether August’s safeguards changed Tron note or refund handling in a way that should have blocked Saturday’s failure mode remains unanswered in the public record.
What Chainflip announced on September 13
In the September 13 disclosure, Chainflip said the network would likely remain paused until Monday at the earliest (September 14, 2026, relative to that post), that a fix had been fleshed out, and that impacted users would be made whole. The compensation mechanism was not chosen yet. A make-whole promise is not completed repayment.
Chainflip also called the event its first significant critical security event with loss of funds from Chainflip vaults.
As of a status check on September 13, 2026 (blog and Chainflip’s X update), no newer official post claimed a restart or completed user repayments. Readers should re-check those channels for later updates on live routes, the 115,654.41 USDT pending swap, payout hashes, and the field-level postmortem.
Reporting note: Amounts and the quoted mechanism paragraph follow Chainflip’s Sep 13 blog. The X post confirms amount, pause, and make-whole intent only. Field details follow Chainflip Tron vault docs, TronWeb addUpdateData, Tron protocol transaction docs, Tron signature/broadcast docs, and Chainflip’s SDK Tron vault example. Limits in one place: no published mapping of “validators had already signed” to a concrete signature step; no payout hashes; no independent expert quotation meeting our bar yet; compensation source and stolen-fund recovery unknown; August’s effect on the Tron note path unanswered. No exploit reconstruction.
