Superfortune AI Lost $15M to a Multisig That Worked Perfectly

A treasury wallet protected by multisig and address-poisoning controls transferred 14.98 million GUA tokens to a lookalike address during a single signed transaction. The contract did exactly what it was told. The bug was somewhere between the signers and the chain.

TL;DR

• On May 27, 2026, SUPERFORTUNE AI ($GUA), a Manta Network–incubated project on BNB Chain, lost approximately 14.98M GUA (~$15.18M) in a single multisig transaction.
• The funds were intended for an airdrop claim contract. They went to a lookalike address with the same first four and last four characters — but everything between was different.
• The attacker dumped the tokens on-chain for roughly 2,784 ETH (~$5.66M) and fragmented the proceeds across multiple wallets.
• GUA's price dropped ~75.8% in the 24 hours that followed.
• The contract was not exploited. This was an off-chain failure: signing tooling, signer workflow, or operational process.

The Incident

The intended action was routine. SUPERFORTUNE AI's treasury team initiated a transfer of additionally unlocked GUA tokens to an airdrop claim contract through a multisig wallet. Address verification controls were in place. Specifically — and this matters — those controls were designed to defeat address-poisoning attacks. The signers reviewed the transaction. They approved it.

The funds did not reach the airdrop contract.

Manta Network's co-founder confirmed the incident publicly within hours: a security incident had occurred, recent token unlocks were hijacked, and the team was investigating.

By the time the on-chain forensics had completed initial analysis, the picture was clear: the destination address encoded into the signed transaction was not the address the signers thought they were approving.

The Lookalike

Here is what the team intended to send to:

0x70ae7D3DECfB4C3aE996fb1c07092566F73D5c15

Here is where the funds actually landed:

0x70AE678b457C5E1b3fD7AD9537F234dFc1795C15

Read those addresses in pairs.

• First four characters: 70ae / 70AE — match.
• Last four characters: 5c15 / 5C15 — match (case-insensitive, which is how every wallet displays them).
• Middle 32 characters: completely different.

A human running a four-character prefix/suffix check passes that comparison every single time. So does an automated address-poisoning filter that watches for lookalikes in transaction history. Neither check is wrong, technically. Both are insufficient.

Why This Was Not Address Poisoning

The first reflex when seeing a lookalike address is to call this an address-poisoning attack. SUPERFORTUNE's own initial statement used that framing. The forensics don't support it.

Classic address poisoning follows a specific pattern:

1. The attacker pre-seeds a lookalike address into the victim's transaction history, typically through a zero-value transfer of a fake token.
2. The victim later copy-pastes from their transaction history, mistakenly selecting the lookalike instead of the real address.
3. Funds go to the attacker.

The poisoning vector requires history. The SUPERFORTUNE treasury wallet had zero prior interactions with the attacker's lookalike address — this is verifiable on-chain. Whatever happened during the signing process, it wasn't this.

So if it wasn't poisoning, what was it?

The Three Likely Scenarios

Post-incident analysis narrows the cause to one of three possibilities, all of which sit outside the smart contract:

1. Compromised signing tooling. A Safe interface, browser extension, or hardware-wallet display that shows the signer one destination address while encoding a different one into the transaction payload. The signer sees the intended address. The bytes that get signed and broadcast contain something else. This class of attack defeats multisig because every signer is verifying the same lie.
2. Operational error by signers. A paste-buffer hijack. A pre-flight document that was edited between drafting and execution. A copy-paste from a Slack thread or email that had been silently modified. Multisig is M-of-N humans, and humans copy and paste.
3. A vulnerability in the multisig workflow itself. Misconfigured Safe transaction guards. A batched transaction where one entry was substituted. A pre-signed transaction that was edited before final submission.

None of these are smart contract bugs. None of them are detectable by a code audit. All of them defeat multisig protection — because multisig only verifies that enough signers approved. It does not verify that what they approved is what they thought they were approving.

What Multisig Actually Verifies

This is the line worth memorizing:

Every individual control in the SUPERFORTUNE workflow was in place. Multisig was active. Address verification ran. Anti-poisoning checks fired. The signers reviewed the destination. The transaction broadcast successfully. By every system check, the transaction was valid.

The system still lost $15.18 million.

The audit surface here isn't the smart contract. It's the signer's screen, the signer's clipboard, the signer's tooling, and the operational chain of custody between the human's intent and the bytes that hit the chain. That surface is harder to audit, harder to formalize, and based on the 2026 incident data, where the money is actually going.

What Would Have Stopped This

A serious multisig workflow for high-value transfers needs all of these — not just one. Any single one would have caught the SUPERFORTUNE incident.

• Full-address verification, not prefix/suffix matching. Read every character. Better: read the address out loud in pairs ("70 — AE — 7D — 3D...") with a second person checking against an out-of-band source.
• Out-of-band destination confirmation. The destination address comes from a source that isn't on the same machine as the signer. Phone call, separate device, printed document. The attacker can compromise one channel. Compromising two is exponentially harder.
• Transaction simulation before signing. Tools like Tenderly, Phalcon, or in-house simulators decode the actual call payload and show you what the transaction will execute as. The destination shown by the wallet UI is the wallet UI's interpretation. The destination shown by simulation is what's actually in the bytes.
• Hardware wallet with full-address display. A hardware wallet that displays the entire destination address on a screen the attacker cannot render to. Not just first/last four. The full string.
• Pre-flight test transfer. For any transfer above a threshold, send a single token first. Confirm receipt at the intended address. Then send the rest. The test transfer is cheap. The mistake is not.
• Time-locked execution for treasury moves. A 24-hour delay between sign and execute, with a public on-chain announcement window. Gives the community and the team a chance to flag a wrong address before the funds move.
• A dedicated signing environment. A machine used only for signing. No browser extensions outside the Safe app. No clipboard managers. No Discord, no Telegram. Air-gapped where possible.

The point isn't paranoia. It's that any single one of these controls would have stopped the SUPERFORTUNE incident dead.

Incident Summary

• Date of incident: May 27, 2026
• Chain: BNB Chain
• Tokens drained: ~14.98M GUA
• USD value at time of theft: ~$15.18M
• ETH realized by attacker after dump: ~2,784 ETH (~$5.66M)
• GUA price drop in 24 hours: ~75.8%
• Victim project: SUPERFORTUNE AI ($GUA)
• Incubator: Manta Network