19AUG21 Incident Report: Return Token & Amount Error

What Happened on Arken?

On 19 Aug 2021(9:31 AM GMT+7), Arken received an incident report from our user; there was a critical bug in the swapping process, causing an error on the return token and amount. In short, the user attempted to swap 100 BUSD to CAKE. Instead, the return amount received was 0.0026 BNB ($49.85 as of the time of swapping), where $50.15 was missing and also failed to receive CAKE as anticipated. Here is the incident timeline and preliminary measures taken by the Arken team (all time listed are GMT+7).

August 19, 2021

9:32 AM — The user reported the bug.

9:40 AM — Arken team was aware of the report.

9:45 AM — As for preliminary measures, Arken was able to reproduce the problem and took the site offline to prevent further problems.

9:56 AM — Arken team confirmed that the rest of the system performed normally, except for the ‘swapbox’ feature. The website was allowed back up, but the ‘swapbox’ was disabled until further investigation.

12:15 PM — The incident cause was found, fixed, and prevented.

2:09 PM — Testing passed and bring the swapbox feature back up for service.

Do Arken Users Have Anything to Worry About?

The problem is fully tackled and only 1 case is confirmed to be affected and damaged. Users have nothing to be concerned about.

The Investigation: Detailed Breakdown and Analysis of Events (all times listed are GMT+7).

Affected Period:
From 10:14PM,18 Aug 2021 to 9:56AM, 19 Aug 2021

Transactions During Affected Period:
- BSC: 88 cases
- Polygon: 19 cases

Damage Occurred:
- BSC: 1 case
- Polygon: 0 case

Detailed Analysis

As mentioned earlier in this report, the user intended to swap 100 BUSD to CAKE via our platform, but instead received 0.0026 BNB ($49.85). After a quick investigation, we found that the incident was caused by one of the optimizations of our web front-end.

The root cause of the problem came from the attempt to minimize server resources by optimizing the loading state of the swapbox, shown below. Before, Arken Best Rate routing required the front-end to send an API request to the back-end to get a real-time, best rate for the user, resulting in the auto-refresh at the front-end at all times and consuming extremely high resources. The team optimized the front-end to pause auto-refresh if the user is inactive for a while (for example, switching tabs or browser) and immediately refresh again once the user is back to being active.

Here was where the problem occurred. Once the user was back to active, due to the problem in the code, the front-end sent the former configuration to the back-end, instead of the new command edited by the user, resulting in a wrong transaction. What happened was that the user viewed the BNB price from the first active time frame and input a value of 1 BUSD (the system remembered this config.) Then once the user was back for the second time, switched output to CAKE and changed the new input value of 100 BUSD, but such configuration did not come through successfully. The user then accidentally executed the transaction with the former configuration (1 BUSD → BNB) instead of the new one (100 BUSD → CAKE).

Where Was the Money Gone To?

From the inspection, Arken executed the transaction through the following route: “BUSD — BELT — CAKE — ADA — BNB”. The point of the incident where the value was gone ($50.15) happened at the BUSD — BELT pool and the BELT — CAKE pool.

Considering the BUSD — BELT pool where the swap took place, it turned out that this pool is a low liquidity pool, with a reserve of ~204.24 BUSD per ~15.63 BELT (1 BELT~ $13.06), resulting in this incident.

When swapping in the pool in the following cases:

1 BUSD → ~0.076 BELT (~$1.05)
100 BUSD → ~5.1281 BELT (~$67.23)

So when swapping 100 BUSD using the “1 BUSD routing”, up to ~$33 was lost in this pool and caused a price imbalance (initially this pool started off at 204.24 BUSD per 15.63 BELT and became ~300 BUSD per ~10 BELT (1 BELT ~ $30)).

The same incident occurred in the BELT — CAKE pool.

Arken wants to ensure that this problem was due to the front-end input feature in action, not the routing engine itself. Users can rest assured that the incident was not from Arken’s routing algorithm. As if the input is sent to the back-end correctly (100 BUSD), the engine won’t be using the 1BUSD routing.

What Will Arken Do?

After the investigation, Arken reproduced the incident and found that the evidence reported by the user is true. We quickly contacted the user and fully compensated for the user’s opportunity loss.

Lastly, we’d like to offer a huge thank you to our valued User who reached out to report the bug rather quickly, and for the community’s patience and support during the incident. We apologize for the inconvenience caused and appreciate your understanding.

Thank you,
Arken Team