24-Hour Incident Update
Following our earlier communication, we want to share key, substantive findings from the first 24 hours of investigation. This is an on-going investigation. A full post-mortem will follow when these workstreams are complete. The findings below are what we can responsibly share now.
Tangentially, we are aware of rumors and FUD spreading and intend to address those directly with the evidence we present in our findings. First, this is not an inside job nor is there any team involvement; implications that the team is secretly selling tokens or anything of that nature is entirely false and can be proven empirically. Second and related, we have never engaged with Web3Port. Both ongoing rumors are entirely fabricated.
✅ The Details That Are Confirmed
1️⃣ The attack was not address poisoning of our transaction-construction workflow. Our earlier assessment that address poisoning was unlikely has been confirmed by direct forensic evidence. The team member who proposed the multisig transaction (Signer 1) signed the correct recipient address 0x70ae7D3DECfB4C3aE996fb1c07092566F73D5c15 at 03:17 UTC on May 27, during the internal verification call. The signed payload is preserved verbatim in the local device logs, with the correct address and correct amount.
2️⃣ The attack was a compromise of that signer's private key. A separate valid signature — for a different transaction with the attacker's address 0x70AE678b457C5E1b3fD7AD9537F234dFc1795C15 as recipient — was submitted to the Safe Transaction Service at 04:00 UTC, 43 minutes later. That second signature is cryptographically valid for the same wallet but does not appear in the Signer 1’s local device logs. The mechanism that explains this is that the attacker had independent possession of the private key and signed the substituted transaction from outside Signer 1’s infrastructure.
The remaining signers reviewed the queued transaction in the Safe interface. The attacker's address was specifically constructed to share the same first four and last four hex characters as the correct recipient — both begin with 0x70AE and end with 5C15. This vanity pattern is used to appear as the correct address in the Safe UI preview. Specifically generating these fake vanity addresses takes time and resources and implies premeditation and planning on the attacker’s end (more mention of this in point 4). Following confirmation the preview, the remaining signers signed the transaction. The on-chain execution followed at 17:59:24 UTC.
3️⃣ Funds are fully traced and currently parked on Ethereum. Within ~4 hours of execution, the attacker liquidated the stolen GUA on PancakeSwap, swept proceeds to an operational hub wallet 0xb292a7016c0008e786edca46459ccee063673afb, bridged the value to Ethereum via cross-chain protocols, and consolidated approximately 2,783.99 ETH into three cold-storage wallets that currently hold the funds with zero outflows:
- 0x111b78A86C16dBD4261FCb5C7D3A9dAF25E2b589
- 0x7b8f28Ff2E1D4DF2D8ddD1daBaFf8c3E58FE841C
- 0xfa4cb6add9da4a4b714541b98fd4b2e3da86b7c8
- A separate ~170,121 USDT was bridged out.
4️⃣ The attacker is using substantial, reusable infrastructure. The operational hub address and the three Ethereum cold-storage addresses are each surrounded by brute-forced lookalike "vanity twin" addresses that the attacker is seeding with fake transfer events using Unicode-spoofed token symbols (ETH, EṬH, ĖTḨ). The same vanity-address construction technique produced the address used against our project. The scale and pre-staging of this infrastructure indicates an industrialized operation rather than an opportunistic one-off attack.
We will continue to publish substantive updates as the investigation progresses, while protecting information that could compromise active workstreams. We continue to work closely with authorities, white hats, and tracing services. We thank the community for its patience.