Exploit
No matter what else we write below explaining what happened, including a series of difficult decisions available … what we list may sound like excuses but they are not, responsibility lies with us and we are working to the best of our abilities even now to rectify the situation for those who have lost, which is literally thousands of DeFi investors from across the globe.
Please also note we are giving as much detail as we can publicly, but we have shared this and more with representatives of Binance to assist in this delicate process. Our goal is first and foremost the recovery of the funds and we won’t do anything to jepordize that process.
In re-launching Uranium finance after an exploit of our reward system (unrelated to the exploit of the LPs) we took security as a high priority having implemented a multi-tier audit system and test-net trials as well.
The audit included private peer review by Defiyield.info and code review by Hyperjump who are both very active in the AMM/farm space and a full audit by BSC Gemz. Not one of these audits picked this up as a critical vulnerability, but BSC Gemz did highlight an associated low level risk. The complete code base was available with not only these groups but was available on our GitHub and viewable on BSCscan.
While doing a review of the various low level risks identified by BSC Gemz audit, the dev team became concerned that a potential critical exploit existed even though it hadn’t been caught before and the code had been running unattacked for the last ~10 days without incident, having accumulated over 80m in TVL.
The exploit was made possible because during an update of the codebase for V2, we changed our swap fees from 0.20% to 0.16%, and this resulted in an unintended calculation that effected permitted swap fees. Those changes had the consequences to adapt the sanity checks of the balances, but one line wrongly stayed unchanged (in green), which lead to the possibility of an attacker draining the reserves. Literally a single 0 on a single line.
What followed happened over a 5–6 hour period of time.
The options available were: bring in more help, attempt a whitehat attack to secure the funds or try to mitigate the exploit.
Bring more help — we tried to make secure contact with BSC but without success during a very short window of time. Every additional party that we introduced would be less trusted and would rapidly expand the potential universe of people who might exploit an as at that point unidentified exploit.
Whitehat Attack — this was given serious consideration, where we would drain the funds ourselves to keep safe until the code was fixed, then we would return them to the pools. But we simply did not have the confidence that we could execute this exploit simultaneously across all pools and without possibly getting frontrun, any failed attempt would lead to a certain successful exploit by an experienced hacker in the minutes right after putting all funds at risk.
Mitigate — this was the option we painfully decided on, an announced set of actions that would have the effect of pushing and forcing as much liquidity out of the LPs as quickly as possible (a forced migration) without identifying the problem (which would all but guarantee the exploit would occur). The largest challenge in this strategy was the 24hr timelock, which could not be avoided.
We worked to wrap the circumstances within the larger plans of the project to create a misdirect in the hopes the exploit had not been identified by a bad actor, but to be clear our only focus was trying to keep users funds safe.
It turns out all our thinking and actions were irrelevant because hours before we pushed our new v2.1 code or made any announcements, the exploiter had already set the ground work including initializing a wallet which would later deploy contracts allowing them to exploit the system.
We’re not sure about whether this has been the direct consequence of a leak about the exploit from someone in our team, by an authorized third party that reviewed our codebase, or even a random dev who just happened to find the flaw.
To be fully transparent, some weird timings took place while everyone was working on the migration, with suspicious “whales” selloff that looked really strangely-timed. But right now, all of those are only suspicions, and all of those elements have already been transmitted to Binance, so that their security team can work on the case.
Everything after that, has been well covered. We immediately pushed a public campaign to get the attention of the Binance team and the AnySwap team. This was our failsafe, as the walled garden of BSC makes moving funds out difficult, but AnySwaps prior policy of not automatically transferring amounts above 1m seems to have changed and thus despite most other gateways having been closed off, AnySwap provided an off ramp for roughly 15m of funds.
What now
We have formed a telegram group, to coordinate the efforts to notify authorities in all jurisdictions, to work towards the recovery of the funds and keep users notified as information becomes available. Updates may take time, but no one is sleeping.
While we can’t say yet if this was a result of a leak or independent action from someone identifying the exploit, the perpetrator will hopefully be identified and all information made public.
We continue to work with the team at Binance and BSC who have our full cooperation, sharing with them all information, correspondence and leads that we have. We thank them for their efforts and hope they can help more than we have been able to as despite our efforts we were not able to keep the funds safe and for that we are incredibly sorry. The two wallets holding $41m of BNB, BUSD & USDT still are on BSC and are obviously under surveillance.
We also feel the need to state clearly to those that may think we should do a v3, that this will definitely not be happening. We will of course continue to help Binance and our users as much as we can via Telegram and if funds are secured will provide every assistance in the redistribution, but that is where Uranium ends. We will not be trying to make this project reborn again, doing so is not possible under these circumstances.
