I. The Customer Who Transferred to the Wrong Chain

Today I met a customer who, half a year ago, wanted to transfer SUI tokens worth 1.3 million USDT from an exchange to their own SUI wallet address but accidentally sent them to the APTOS chain address of their wallet. They asked if it was possible to recover the funds.

At first, I thought it would be as easy to fix as the Bitcoin series or EVM series wrong-chain issues I’d handled before, but after doing some research, I realized it wasn’t that simple.

With identical private keys, SUI and APTOS use different hash functions when generating addresses: the former uses Blake2b-256, and the latter uses SHA3-256. Both generate addresses that are 0x + 64-character hexadecimal strings.

So the two chains’ addresses don’t look any different, and since there’s no checksum, they can easily be mistaken for one another without any warnings from the wallet.

For example, I randomly generated a private key:

13683de5f6eb9df06230441cb616a07585637c7fd792638981d2ff34357be572

Generated the public key:

e99bd8f092a3394257898d18fe9cd2cd0e3ae7a62626a1a14f98bb6bc5fb42d3

Then, generating a Sui address from the public key using the Blake2b-256 hash function gives:

Sui address:

0x6dede27969f00f667af07557013474058306a0405da3155b790549b2f807e178

Generating an Aptos address from the public key using the SHA3-256 hash function gives:

Aptos address:

0xd426c272c0bcfc8584859b861bddaac92152d496c4276a6a882fd73ec0bc623c

The customer originally intended to transfer to the SUI address but mistakenly transferred to the APTOS address.

So, can it be recovered? Let’s analyze it.

II. Difficulty Analysis

The above problem can be transformed into the following:

Given:

privkey A -> Blake2b-256 -> B
privkey A -> SHA3-256 -> C

We want to find the SUI private key A':

privkey A' -> Blake2b-256 -> C

A' is unknown — can we derive A' from C?

Whether the original private key A exists or not no longer matters; the problem now is actually trying to crack the one-way hash function BLAKE2b-256.

Both SHA3-256 and BLAKE2b-256 are designed as “one-way functions,” meaning they have strong preimage resistance: given the hash output, finding any input that matches that output would require around 2^256 computations—far beyond current computational ability—and so far, no evident vulnerabilities have been found.

Moreover, C itself is obtained from the original private key A through SHA3-256 and is mathematically unrelated to the output of BLAKE2b-256. It’s like sending the same raw material down two completely independent assembly lines — the resulting “parts” are unrelated.

Therefore, there is no practical algorithm to find some A' such that BLAKE2b(A') = C. The only possible way is brute-forcing the entire private key space, which also requires about 2^256 attempts — practically impossible.

Brute-forcing the SUI private key space is like someone saying: “Given Satoshi Nakamoto’s Bitcoin address, can you derive the private key?” — the difficulty is the same.

Unless quantum computers become practical in the future or the BLAKE2b-256 algorithm suffers a major flaw that drastically reduces computational effort, it’s impossible to recover the assets through technical means.

However, as the customer suggested, there might be a workaround: if one has connections with the SUI Foundation, they could request a future update that supports the APTOS address generation method — then the assets could be recovered.

If this were feasible, since SUI’s 32-byte hash cannot indicate which hash function produced it, a flag would have to be added before or after the hash to identify the hash function used. This would require changing the address format — a significant modification that would depend on whether it’s worth the effort. But for 1.33 million USDT, maybe not enough motivation.

III. A Profound Lesson

1.3 million USDT — nearly 10 million RMB — just vanished like that. Truly heartbreaking. And looking online, such cases are not rare; even I made the same mistake once.

In 2022, I meant to transfer on the ETH chain but accidentally used the BSC chain, which the exchange didn’t support. After a month of communication and some fees, they finally credited it manually.

I was lucky to get mine back. But this 1.3 million USDT? Most likely gone for good.

Here are some small tips to avoid “copy-paste accidents” when transferring tokens:

1. Confirm the current network: before transferring, check the top-left corner of your wallet to see whether it says “Sui” or “Aptos.”

2. Compare prefixes and suffixes: after copying but before pasting, manually verify the first or last 6–8 characters.

3. Test with a small amount first: for the first transaction, send only 0.1 SUI or 0.1 APT; once confirmed, proceed with the full transfer.

4. Verify with a block explorer: paste the address into SuiScan or Aptos Explorer to check which chain it belongs to.

So everyone dealing with Bitcoin series, EVM series, or SUI and APTOS transfers — pay attention and never send across the wrong chain. Always remember to transfer within the same network.

Keep SAFE, Keep safe!!!