[ARFC] Add gmBTC on Arbitrum V3


Title: [ARFC] Add gmBTC on Arbitrum V3
Discussions: [TEMP CHECK] Add gmBTC on Arbitrum V3
Author: @0xlide - @SaucyBlock
Date: 2024-02-05


Summary

This publication presents the community an opportunity to add gmBTC on the Arbitrum Aave v3 Liquidity Pool.

Motivation

GMX Protocol is the largest DEX offering derivatives and one of the most popular DeFi’s today. The introduction of several new features and integration with Chainlink Data Stream in GMX V2 has significantly reduced the risks of front-running and price manipulation compared to GMX V1. gmBTC is a BTC-USD’s Liquidity Token on the GMX V2 and earn fees from leverage trading, borrowing fees and swaps.

Integrating gmBTC as collateral asset in the Aave V3 Arbitrum Pool has the potential to create new demand for borrowable assets on Aave V3.

Specification

Ticker: gmBTC
Contract Adress: 0x47c031236e19d024b42f8AE6780E44A573170703
Chainlink Oracle: 0x395D5c5D552Df670dc4B2B1cef0c4EABfFba492f

The parameters shown below are supported by @Gauntlet

Parameter Recommendation
Isolation Mode Enabled *USDC
E-Mode NO
Enable Borrow Disabled
Stable Borrow Disabled
Borrowable in Isolation Disabled
Siloed Borrowing Disabled
Frash Loan Disabled
LTV 65.00%
Liquidation Threshold 70.00%
Liquidation Bonus 5.00%
Reserve Factor 25.00%
Supply Cap(gmBTC) $10.00M
Borrow Cap(gmBTC) N/A
Debt Ceiling $5.00 M
Liquidation Protocol Fee 20.00%
Uoptimal N/A
Base 0
Variable Slope1 N/A
Variable Slope2 N/A
Stable Slope1 N/A
Stable Slope2 N/A
Base Stable Rate Offset N/A
Stable Rate Excess Offset N/A
Optimal Stable To Total Debt Ratio N/A

Reference

Project: https://gmx.io/#/
GitHub: https://github.com/gmx-io
Docs: https://docs.gmx.io/docs/intro
Audit: https://github.com/gmx-io/gmx-synthetics/tree/main/audits
Twitter: https://twitter.com/GMX_IO?s=20
Telegram: https://t.me/GMX_IO
Discord: https://discord.com/invite/H5PeQru3Aa

Next Step

  • If consensus on ARFC stage is reached and risk service providers provide feedback on risk parameters, escalate to ARFC snapshot stage.
  • If ARFC snapshot stage outcome is YAE, escalate to AIP stage

Disclaimer

0xlide is not presenting this ARFC on behalf of any third party and is not compensated by any entity for creating this ARFC.

Copyright

Copyright and related rights waived via CC0.

4 Likes

Looking forward to it.

2 Likes

Listing gmBTC, gmETH on Aave Arbitrum

Intro:

GMX Protocol is a leading DEX offering derivatives and one of the most popular in DeFi today. The integration of dynamic velocity-based funding rates has led to the protocol maintaining a healthy distribution of long-short OI skew over time. Integrating gmBTC and gmETH as collateral assets in the Aave V3 Arbitrum Pool has the potential to create new demand for borrowable assets on Aave V3, such as BTC/ETH and stablecoins.

Main use cases:

Borrowing underlying assets (BTC/ETH) to hedge delta exposure when supplying liquidity in gmPools while generating yield. Specifically concerning risk on Aave, if the underlying debt asset (BTC/ETH) scales in price while the collateral asset (gmToken) maintains a delta of approximately .5, liquidations can occur. This is due to the gmToken being comprised of 50-50 BTC or ETH and USDC, assuming the distribution of OI is sufficiently balanced.

Borrowing stables to increase delta exposure when supplying liquidity in gmPools while generating yield. For example, supplying gmAsset as collateral, borrowing USDC, depositing single-sided USDC into gmAsset pool, and attempting to create a delta exposure of ~1. If the price of the gmToken, i.e., the underlying asset * ~.5, liquidations can occur.

Methodology:

Supply Cap:

Every GMX Market has a reserve factor that allows open interest to be capped to a percentage of the pool size. This reduces the impact of profits of short positions and reduces the risk that long positions cannot be fully paid out.

GMX has two separate parameters for reserve factor:

  1. open interest reserve factor - it is impossible to open a position if new OI > pool size * open interest reserve factor
  2. reserve factor - it is impossible to redeem gmTokens if current OI > pool size after withdrawal * reserve factor

For both BTC and ETH, the reserve factor is 95%, and the open interest reserve factor is 90%. Thus, to quantify the supply cap, we take the delta between the reserve factor and the open interest reserve factor (reserve factor (95%) - open interest reserve factor (90%)), i.e., 5% * pool size. Effectively, this means we assume the worst-case scenario concerning the gmToken’s ability to be liquidated and withdrawn based on the parameter values set. Put differently, in the scenario of a fully utilized pool encompassing both long and short positions and factoring in the open interest reserve factor; our methodology ensures that the protocol is equipped to manage the flow effectively. This indicates that even in the scenario where all positions are liquidated and collateral is recovered, the protocol can still manage its operational needs effectively. However, it’s important to recognize that not all borrowers are expected to employ identical strategies, contrary to this assumption.

Furthermore, the full utilization of the OI reserve factor on both sides suggests a lack of significant market movement in the underlying asset. Typically, in the presence of strong market fluctuations, either short or long positions on GMX would have been closed out. This observation is inversely correlated with the anticipated demand for gmBTC as collateral, implying that substantial market movements would be required for liquidation on Aave, due to the .5 delta.

Given the pool is valued in USD terms, taking the median of the pool value over the last 90 days and multiplying by our 5% margin, this comes out to 4.3m ($6m) for gmBTC and 3.5m ($4.5m) for gmETH.

BTC:

image

ETH:

image

Liquidation Bonus:

Unlike traditional liquidations, the liquidating & withdrawing of gmTokens from the pool is non-atomic. Thus, flashloans cannot be utilized to liquidate positions. In addition, there exists a scenario where liquidations may not occur if the collateral received by the liquidator is greater than the liquidity available to be withdrawn or redeemed, based on the reserve factor. Thus, we must provide a significantly larger liquidation bonus (LB) for liquidators, who are required to utilize their capital to liquidate positions and theoretically take on additional delta risk if they choose to liquidate when redeeming is unavailable.

Looking ahead, the implementation of atomic liquidations will represent a significant advancement, further diminishing the risks associated with listing gmTokens as collateral. This development will enhance the efficiency and safety of the protocol, paving the way for additional optimization of parameters.

Liquidation Threshold:

The gmToken underlying assets, i.e., BTC and ETH, are naturally listed on Aave with discrete LT/LTVs. Thus, to account for higher LBs, whereby more debt needs to be paid off to revert the position to a healthy state, following Chaos Labs LT framework, we recommend the values in the chart below.

Additional Note:

Other platforms like Abracadabra may offer gmTokens as collateral with more aggressive Loan-to-Value (LTV) and Liquidation Thresholds (LTs). In the edge case scenario presented above, if the underlying gmToken or the asset it represents experiences rapid price fluctuations, these platforms effectively gain priority in liquidations, potentially consuming a significant portion of the gmPool reserve factor buffer before Aave can react.

Recommendation:

Parameter gmETH gmBTC
Isolation Mode No No
Borrowable No No
Collateral Enabled Yes Yes
Supply Cap 3,500,000 gmETH 4,300,000 gmBTC
Borrow Cap N/A N/A
LTV 60% 55%
LT 65% 60%
Liquidation Bonus 12.00% 12.00%
Liquidation Protocol Fee 10.00% 10.00%
Reserve Factor N/A N/A
Variable Base N/A N/A
Variable Slope1 N/A N/A
Variable Slope2 N/A N/A
Uoptimal N/A N/A
Flashloanable No No
Siloed Borrowing No No
Borrowed in Isolation No No
Emode No No
4 Likes

Following feedback and Chaos Labs parameters recommendation, the current proposal has been escalated to ARFC Snapshot with Chaos Labs parameters.

Voting will start tomorrow.

3 Likes

When will gmBTC be online?

1 Like

Hello, is there any progress?

2 Likes

Hi @ACI.
I understand that your team are busy, but it has been over half a year since this ARFC was passed. Could you please provide an update on when you plan to submit the AIPs for onboarding gmBTC and gmETH?

1 Like

How can it be that an asset that has passed governance still has yet to be onboarded seven months after the original ARFC passed? This seems to be a critical centralization bottleneck in the governance process. It does not take much digging to find numerous other example asset listings that have had a similar delayed outcome with successful temp check and ARFC votes. It is particularly glaring when there are examples of assets from more well known protocols (that have not yet been battle tested) that seem to have a fast track towards onboarding.

In particular, it seems unclear what which party owns the responsibility for creating the AIP and what due processes are or should be guaranteed in these circumstances. It seems the standard due process for asset onboarding (and likely other governance processes) is simply a soft agreement that can be ignored when deemed fit.

Perhaps this is an area that @bgdlabs can help facilitate a solution to through automation or other engineering efforts. It would be great to get others’ perspective (@sid_areta , @eboado, @SaucyBlock) on this centralization vector as well. I think many would agree that this kind of outcome of a massively delayed asset onboarding is unfair to both the proposing protocol aand to Aave (afterall, Aave holders supported the asset onboarding in the temp check and ARFC).

1 Like

This is really valuable feedback @midapple, and definitely pointing to a clear inefficiency on asset’s onboarding that must be addressed.

To give some extra light on how we see the problem from our side:

  • Asset listings are probably the type of governance proposals that involve more contributors: risk (2 entities @ChaosLabs and @LlamaRisk ), technical (1 entity, ourselves BGD), growth (depending on the case, but generally 1 entity too with @ACI) and sometimes, even treasury for things like incentives (@karpatkey_TokenLogic). This coordination usually is not a big blocker, as all entities have communication channels between themselves and the DAO itself.
  • It is true that TEMP CHECK at the moment is too asynced with following steps. Usually the blockers are 1) important amount of candidate assets for listings, 2) assets type/morphology makes them very different from each other (e.g. listing an LRT is totally different from a governance token, different to a decentralized stablecoin, etc 3) technical dependencies on “how” to list an asset (e.g. now with Liquid eModes, becomes simpler).

High-level, aspects that could be improved are the following:

  • As commented, establish a strict upper limit for full evaluation, or at least, disclosures of any blocker. This should be very conservative, because at least from our perspective, on the current state of Aave, fullfilling very strict deadlines on new listings should not create overhead for the rest of fields, like risk maintenance or development of the protocol itself.
    Still, an upper limit to address them of let’s say 2 months before AIP sounds perfectly reasonable.
  • Better communications. This could be solved just by applying the first suggestion of stricter deadlines. From our side, it is definitely a field we see we could improve on.
  • Iteration on the on-boarding framework, for example, making it more specific depending on the asset type. New asset types appear quite frequently in DeFi, so changes on the framework should be almost continuous; but this seems necessary, for both the sake of Aave and the teams looking for listings.
    It is important to understand that still the DAO deposits certain trust in its service providers when evaluating assets, but this is also a very strong characteristic of Aave, assuring global quality on all aspects, not only listing.

From our side, we will coordinate with the other service provider to try to improve this flow, including doing the adaptations required on ourselves, BGD Labs.

4 Likes

Thank you @midapple for great feedback. We are also pleased that @bgdlabs is working on resolving this problem.

Over a week ago, our team requested an update on the progress of the AIPs for gmBTC and gmETH Onboarding. Unfortunately, there have been no updates. Repeatedly asking for progress reports on work is not pleasant task. @ACI, please provide a progress report.

Does this ARFC aim to support the gmBTC tokens backed by 100% BTC or the one backed by 50% BTC and 50% USD ? Or both ?

Details here about the token only backed by crypto token

1 Like

Hello @nyanloutre ฅ・ω・ฅ
The proposal already covers it.

Why isn’t Saucyblock creating the AIP?

1 Like

SaucyBlock does not have the proposition power needed for AIP submission.

is this dead? would it be better to make a new proposal (and include gmbtc single sided)? what’s a farmer got to do to support this asset being added?

1 Like