We recently received feedback from our friends at Yield Yak on a potential vulnerability that can be caused by an improper Amplification Coefficient “A” configuration. After a detailed review and investigation, the Gondola team made the decision to adjust the parameter and delay our farming launch. Ultimately, while we believe the potential impact is limited, we feel we wanted to be extra careful in protecting the security of our users.
- Funds are SAFE. NO ACTION is required
- Start of yield farming will be postponed until Monday, May 3 2:00 pm UTC
- The Gondola team has adjusted and optimised the Amplification Coefficient, which fixes the problem by discouraging imbalanced pools
- As further precaution, the Gondola team is adding clear warnings to the frontend as a precaution to alert users when pools are particularly imbalanced, and closely monitoring pools from the start
For more technical readers, here are the details.
The Saddle launch incident
This article from Cointelegraph summarizes what happened upon Saddle’s launch. In a nutshell, a user deposited a large sum of a single-sided asset (WBTC) resulting in a highly imbalanced pool. As a result, arbitrageurs swooped in and swapped the under-deposited token (tBTC) for the over-deposited token (WBTC). This is due to the path-independence property of AMMs, where any action that changes the pool’s curvature is going to generate reward for its counter-action.
The cause for the incident was due to:
- The pool contained imbalanced assets. This can happen on occasion. For instance, WBTC is much more popular compared to tBTC, and so you can expect more WBTC than tBTC coming in a pool like this
- A user/liquidity provider came in, didn’t realise there was a significant imbalance in assets, but went ahead and deposited a large single-sided amount of WBTC. There were no guardrails to prevent this from happening
On Amplification Coefficient
The Stableswap algorithm was first published by Michael Egorov from the Curve Team, who created an automated market that provides a blended curvature that lies between Constant Product Market Maker (CPMM) used in Uniswap and Constant Sum Market Maker (CSMM) used in mStable. The reason is that the curvature in CPMM is too convex, in other words, a relatively small swap (dx) is going to create a large slippage (-dy/dx). Hence, a blended curvature is more suitable for swapping of pegged assets, such as stablecoins or z-tokens.
The Stableswap invariant is given by the formula:
where “A” is the amplification coefficient, determining whether the curve is closer to CPMM or CSMM. A large “A” will make the equation closer to CSMM (i.e.: mStable) and a smaller “A” will make the equation closer to CPMM (i.e.: Uniswap).
The default value of “A” is 200. Is this value the optimal amount? What happens if we set a bad “A”? The answer is a bad “A” is going to tolerate a more imbalanced pool. And a small, imbalanced pool is more likely to allow an incident like the Saddle launch we described above.
Gondola Team’s Action
After extensive analysis and with the help of the Yield Yak team, the Gondola team decided to change the Amplification Coefficient from 200 to 100. Based on our calculation, for a 100K + 100K USD pool, an 8:2 split pool is going to provide ~$300 USD profit for arbitrageurs. This amount is equal to the sum of bridge cost from Avalanche Ethereum Bridge and Zero Bridge.
A sudden change of “A” may lead to further vulnerabilities as disclosed here. This issue has been addressed by Saddle team as they have implemented a “Ramp Up Time Factor” to promote a gradual change of A across 14 days, which will mitigate this problem. As a result, our “A” will take 14 days to gradually change from 200 to 100. But this should not affect users to the extent that they don’t deposit or swap a large sum of money single-sided.
As a precautionary step and above and beyond the changes to the optimal Amplification Coefficient, the Gondola team is adding a further warning message when a user’s actions will lead to an imbalanced pool. Furthermore, we will be closely monitoring the pools from the start to prevent a situation where one side of the pool is completely imbalanced vs the other side of the pool.
Wait. Why it this issue related to the bridge?
Consider the following scenario: right now the Gondola USDT pool has $38,305 USDT and $162,000 zUSDT (a 2:8 split pool). As mentioned above, an arbitrageur who swaps $62,000 USDT to zUSDT is going to earn $305 in reward. Assume someone has $62,000 USDT on the Ethereum network. This someone can transfer his USDT through the AEB to Avalanche network at a cost of 0.057 ETH or ~$150 USD, then swap the $62,000 USDT in Gondola for $62,305 zUSDT, and lastly transfer it using the Zero Bridge back to the Ethereum network (which cost 5 AVAX ~$150 USD). In this situation, this person gained $5 in risk-free profit. (This is just the breakeven point and the arbitrageur can earn more with greater imbalances.)
In short, the sum of the bridge costs provide the minimum slippage threshold we want to target. And we want to find an “A” such that given the pool is x :1-x imbalanced, it will provide the necessary incentive for arbitrageurs to come and rebalance the pool. In our case, the chosen “A” (100) is going to provide sufficient incentive ($305 USD) for arbitrageur to help us to rebalance the pool once it has hit the 2:8 threshold, given the total pool size is 200K USD.
Lastly, is this problem harmful to users?
Although a suboptimal starting “A” may result in a highly imbalanced pool, we believe the impact to the user is limited. For a highly imbalanced pool, upon liquidity withdrawal, the liquidity provider may find himself getting more of the asset in surplus. For example, assume now the pools consist of 99% zUSDT and 1% USDT, the liquidity provider may get 99% zUSDT which he does not want. However, since zUSDT’s value is backed by its guaranteed convertibility back into the Ethereum network, the maximum loss that the liquidity provider realises is the bridge cost (which is around $150). Furthermore, he can always swap zUSDT in Zero Exchange to other assets (include ZERO, AVAX or others). Hence, we believe the financial loss to users due to an imbalanced pool is known and practically bounded.
We want to sincerely thank the Yield Yak team for drawing this issue to our attention; they are doing an amazing job supporting the Avalanche defi ecosystem and we are big fans. Security is our upmost concern and we want to ensure that our users’ funds are SAFU. We hope that our actions as explained in this article helps to clarify the delay in farming and addresses any concerns that you may have.
See you again on Monday, May 3 2:00 pm UTC. Enjoy your weekend and happy farming next week!