1/10

So, Uranium Finance (another Uniswap v2 fork on BSC) was exploited for $51M, right?

Nope, everything is much more complicated.

Let’s figure out what happened.

2/10

Let’s start with the stolen funds:
- 34k WBNB ($18M)
- 17.9M BUSD ($17.9M)
- 1.8k ETH ($4.7M)
- 80 BTC ($4.3M)
- 26.5k DOT ($0.8M)
- 638k ADA ($0.8M)
- 5.7M USDT ($5.7M)
- 112k U92

WBNB and BUSD remain on the exploiter’s contract since it’s problematic to cash them out

3/10

With the help of PancakeSwap, DOT and ADA were swapped to ETH.

After that, the attacker withdrew 2,438 ETH via Anyswap to Ethereum (2.4k already in Tornado Cash) and 80 BTC to Bitcoin.

U92 was staked (lol).

1M USDT and 99k DAI (bought with USDT) went to xDAI.

4/10

What was the exploit?

Pair contracts in Uranium v2 had a bug due to which anyone could interact with them and withdraw almost all tokens due to a calculation error.

The balances of pair contracts during sanity checks were a hundred times larger than the real ones.

5/10

The exploit itself looked like this:

- Before interacting with Uranium, the attacker sent the minimum amount of each token to pair contracts.

- After that, they used a low-level function swap() whose execution should drain both reserves.

6/10

The Uranium team migrated the contract to v2 about ten days ago, and the old version did not have this bug.

I wonder how the team didn’t notice this bug and why all this time, Uranium users’ funds were in danger.

7/10

For reasons not fully understood, the Uranium team decided to update the protocol to v2.1, and the liquidity migration was supposed to start today.

The only significant change in the new version is the fix of the above-mentioned bug.

8/10

The team believes that this hack is related to today’s migration, although anyone could have exploited it immediately after upgrading to v2.

Also, for some unknown reason, the Uranium contracts repository has been removed from Github.

9/10

What options do we have?

- the hacker decided to use an exploit before starting the liquidity migration to drain maximum funds

- the project team made a rug pull by adding a bug in one of the updates and then deciding to create a ‘liquidity migration’ to hide it

10/10

Since the team fixed this bug that led to the exploit, they should have known about it for sure.

In this case, the best option would be a white hack not to jeopardize users’ funds.

Since there was no white hack, I tend to believe that it was a rug pull.