Chinese KOL recounts the story of liquidating $200,000 in half an hour on Alpaca Finance

On June 22, the BSC ecosystem project Alpaca Finance's native token ALPACA experienced a flash crash, with a short-term drop of over 50%. The total liquidated position value in this flash crash was approximately $900,000. One individual, Weibo influencer "Very Big Orange," suffered a loss of $200,000 (calculated based on the opening price of ALPACA).

(This article is authorized and reproduced from "The Way of DeFi," with the original title "200,000 USD, Three Lessons Learned! Weibo Influencer Exposes DeFi Liquidation Incident." Original article here.) This article was last updated on 6/30 with corrections made.

Alpaca Finance, as the largest leverage yield farming platform in the DeFi space, has a locked value exceeding $1 billion. On this platform, users can invest less capital to earn higher yields. Especially in the current sluggish market conditions, investors collateralize their long-term assets they are bullish on for mining, enabling them to generate stable cash flow even in a bear market. However, the biggest risk of leveraged mining comes from the volatility of token prices, which can easily lead to liquidation if the market moves against the investor's position.

Advertisement - Please scroll down for more content

This liquidation event holds significant research value in the DeFi market. Many investors who were familiar with and trusted the platform could not avoid losses in this event, some suffering significant losses. Additionally, Alpaca Finance's proud Oracle Guard mechanism, which had previously withstood frequent external hacker attacks, was questioned this time as the potential "culprit" behind the chain of liquidations.

Lost $200,000 in 30 Minutes, Weibo Influencer Recounts Liquidation Incident

During this liquidation event, the largest liquidation on Sheep Camel occurred with "A Very Big Orange." Here is the detailed account of the liquidation incident as narrated by him:

In DeFi, there is a saying that if you haven't done in-depth research on mining and you go ahead and mine, you become that APY.

This time, I was that APY. The biggest liquidation on Sheep Camel should be my loss of 560,000 Sheep Camels. I had actually made some predictions and had safety mechanisms in place, which now clearly seem insufficient. Our team delved into the reasons for the liquidation, and I will share my experience and the reasons for the liquidation with you; this cost me a lesson bought for $200,000.

That night, I used 2x leverage to borrow 1,176 BNB with 560,000 ALPACA to mine in the ALPACA-BNB pool. At that time, the price of ALPACA was $0.68, and BNB was $323.

Why 2x leverage? Because 2x leverage is the best in Sheep Camel. It's like borrowing $10 worth of Sheep Camel to borrow $10 worth of BNB to mine; you just match them up to mine, with no slippage and transaction fee losses. If you borrow $10 to mine with $20 worth of BNB, then $20 includes $5 to buy ALPACA, ultimately exchanging it for $15 worth of ALPACA and $15 worth of BNB, which incurs slippage and transaction fees. So, I basically always use 2x leverage.

I only trade currency pairs, not stablecoin and altcoin pairs. Because if there is a big market drop, such as the ALPACA-BNB exchange rate pair not dropping too much, that was my prediction before.

And I also specifically checked the historical data of the ALPACA-BNB exchange rate, which was basically stable at around 0.0002 before today's big drop, very stable.

Why did I leverage to mine? Because the annualized yield for staking Sheep Camel was only about 28%, but with 2x leverage to mine Sheep Camel, the annualized return was over 100%.

The return was high and stable, so that day I put in 560,000 ALPACA to mine. I didn't expect the ALPACA-BNB exchange rate to drop 50% today, directly leading to liquidation. I liquidated 560,000 ALPACA, leaving me with 150,000 ALPACA, totaling a loss of 400,000 ALPACA, nearly $200,000.

I thought I had enough risk protection, such as choosing currency pairs instead of USDT pairs. Because according to historical data, even in a big drop, the exchange rate pair wouldn't change much.

Second, I borrowed in a 1:1 ratio, which is directionless.

Third, because "5.19" and "6.17" had already experienced big drops before, I thought even in a big drop scenario, the exchange rate pair wouldn't drop too much.

The above were my predictions, but in hindsight, they were clearly wrong. The main lessons from this liquidation were:

First, I overlooked that the ALPACA-BNB pool was on WaultSwap and not on PancakeSwap. Otherwise, I wouldn't have put so much capital in it, which was my biggest mistake.

The reason Sheep Camel used WaultSwap was that the rewards were higher, as Sheep Camel is a leveraged machine gun pool. However, the liquidity of ALPACA-USDT in WaultSwap was 5.7M, while the liquidity of ALPACA-BNB was only 2.6M, less than half. This directly led to my liquidation today, which wouldn't have happened if I were on PancakeSwap.

Second, the depth of ALPACA-BNB on WaultSwap was poor, and leveraged mining might have stepped on a landmine.

That day, I borrowed 56,000 ALPACA and borrowed 1,176 BNB. In terms of the base currency, I invested 2,352 BNB.

My position would only be liquidated when the total assets became 1,470 BNB (1,176/80% = 1,470).

Based on the price on PancakeSwap, at the lowest point of the exchange rate, I should have had around 1,557 BNB, which wouldn't have led to liquidation.

On WaultSwap, due to the poor depth, the exchange rate pair dropped by 57.33%, significantly deviating from Pancake's 53%. I was liquidated at the lowest point due to this deviation.

Third, I didn't set up any alerts; since I was leveraged mining, I should have set up an alert line to monitor my position. I didn't set up any alerts today because I thought I was safe before, so I was completely relaxed, not expecting the exchange rate to drop so much today.

Now, the price of ALPACA has recovered. If I hadn't been liquidated, I wouldn't have lost much with those 500,000 ALPACA, but now that I have been liquidated, I have nothing left. This incident is equivalent to buying a $200,000 lesson.

Issues with Oracle Guard Mechanism?

During this liquidation process, some investors attempted to add collateral, only to be blocked by the Oracle Guard and could only watch the price drop, ultimately leading to passive liquidation. This mechanism has been criticized by investors as "distributed unplugging."

According to Gene, the owner of the Knowledge Planet "Zero Fork Dry Goods Store," when the on-chain price deviates 10% from the median off-chain price, the Sheep Camel's Oracle Guard mechanism is activated, and users' positions automatically enter "protection mode."

At this point, all of the user's liquidation, opening, closing, and adding collateral are restricted. The design intent was to avoid lightning loan attacks or other forms of price manipulation, allowing arbitrageurs to restore the price to normal during the protection period. Liquidation does not occur during this period. Once the price returns to normal, the system exits the liquidation mode, and if the user's asset price triggers the liquidation line at this time, the liquidation process begins.

If within the protection period, the price cannot return to normal and the user is still liquidated, the system theoretically will force liquidation.

There is a BUG here: when the deviation reaches 10% and enters automatic protection mode, and then the price continues to drop, the user's position is locked and unable to operate. Since liquidation occurs on-chain, this further leads to a significant deviation in asset prices off-chain, ultimately turning the "protection mode" into a "cage," where users can only watch their assets being liquidated.

In response to this claim, Sheep Camel user Guo Hui stated that using the term "bug" is inaccurate. "During the liquidation process, the Oracle had three interruptions in protection, during which users had the opportunity to close their positions. Otherwise, it would have been a continuous liquidation, with the final price far lower than this time."

According to Guo Hui's records, from 4:09 to 4:15, positions could be closed. The first activation of the Oracle was probably around 4:15. From the first liquidation to the final liquidation, there were four opportunities to close positions. So, calling it a cage is not objective.

"I saw a sharp drop in price and tried to close my position around 4:15, but it didn't close because the Oracle was activated. Then I kept refreshing the page, and at 4:18, the first protection was suspended. I immediately selected the highest gas fee option and closed my position in 5 seconds. Afterwards, I found out that some friends were also closing their positions, but they didn't adjust the gas fee, so it took them a minute to close."

It is evident that during the liquidation period, users were indeed given the opportunity to close their positions, but since other investors were also closing their positions during this time, it was necessary to increase gas fees to ensure smooth transactions.

So, should the Oracle Guard mechanism be abolished?

Some believe that if there is no Oracle, the price will drop to zero directly, and the liquidation speed of a chain reaction is too fast to manually add collateral. The deep reason for liquidation is that everyone is on one side of the leverage, lacking a short mechanism; once liquidation starts, the snowball effect cannot be stopped. The Oracle Guard serves as a buffer, forcibly halting the process. When the price reaches 0.25, the buy-side raises the price, stopping the liquidation.

In response to the above statement, Guo Hui stated that the bottom was not bought by users. Note: Guo Hui is a Sheep Camel group member.

According to monitoring data that day, ALPACA stayed at $0.24 for a few minutes. This was because there were no leveraged positions to be liquidated at $0.24. After there were no liquidations, funds entered to buy the dip, rather than dip-buying funds preventing liquidation. Adding collateral during liquidation is a very costly process, especially when the position is large and requires a lot of additional collateral. It is better to use a small amount of funds to buy on DEX during liquidation, avoiding liquidation and getting ALPACA at a lower price.

Others believe that with the Oracle Guard, there will be a time buffer. During the buffer period, if someone buys the dip, it can prevent liquidation that would have originally occurred, and those closer to the liquidation price can also close their positions. This is similar to a circuit breaker policy, with the idea being good and indeed guarding against price manipulation, but it is still unable to resist the collective trend of the flock.

At the bottom, approximately 6 million ALPACA were bought. Guo Hui stated that users dared to buy the dip because this drop in ALPACA was not due to hacking, project manipulation, or market manipulation by a whale, but because the product is indeed providing value, and many people did make money on it, so there were many buy orders at the bottom.

Official Explanation: Further Improving the Oracle Guard Function

After the liquidation event, the Sheep Camel project team released a detailed report on the incident.

The project team believes that the ALPACA drop occurred against the backdrop of a general decline in the cryptocurrency market and was not accidental; on the 22nd, many cryptocurrencies saw double-digit declines. The price of ALPACA dropped by 53% in less than 30 minutes, not due to security issues like a hack but because of people's panic.

During the rapid drop that day, the total position value of the liquidation was only six figures, about $900,000.

If there were no Oracle Guard, the price drop would not have occurred within a 30-minute timeframe but might have happened within a 5-minute candlestick, as a series of chain liquidations would have further suppressed prices. In such a scenario, the situation could have been even worse, far beyond the current $900,000 loss, potentially resulting in losses of millions of dollars.

In response to user feedback on the inability to add collateral during liquidation, the project team stated that they will listen to user feedback and develop multiple features, allowing users to add collateral to leveraged positions during the Oracle Guard activation period without borrowing. Additionally, regarding user feedback on setting stop-loss orders before liquidation occurs, the project team stated that this is technically challenging because it requires holding the user's private key. However, the platform will provide an option for users to set stop-loss orders to close positions in a timely manner before liquidation occurs.