Hi all,
I’ve been following GMX since Gambit/GMT, and love all that the team has accomplished. I think there is a lot of potential in GMX despite how much growth and development has already been covered. In short, the future looks bright. I’m not at all attached to these suggestions as I trust X, and part of that is the willingness to listen and engage. So please be vocal, be contributive, be critical if you have any thought/suggestions/etc.
These suggestions are focused on accomplishing a few things (in no particular order): 1) additional tooling for GLP to provide further functionality to attract deposits and help the protocol increase it’s capacity to handle volume, 2) increase revenue, 3) cultivate game-theoretic scenarios which sustainably reward long term holders, 4) propose a more efficient use of the Floor Price Fund (FPF), 5) validate long term value (LTV) of GMX
The following are summary but in-depth descriptions of the proposals (labeled as OBPx so people can easily reference). The following are ordered in what I believe to level of importance:
OMBP1: Develop additional GLP Functionality Regarding Revenue Rewards
-
OMBP1.1: Auto-compounding GLP
Compounding revenue rewards for GLP can only be done manually at the present moment. This is a transaction heavy process, and I suspect it is partly responsible for the ETH-heavy bias of the GLP Basket (most straightforward thing to do is claim wETH rewards from “Total Rewards” Tab and Buy GLP with said wETH). I think it would be attractive to risk-averse investors and more institutional investors like DAOs/Treasuries etc to have a GLP account/funciton which simply compounded its rewards and accumulated more GLP; instead of seeing ETH/AVAX(soon) rewards distribute at a steady rate, your cost-effectively-diversified GLP is going up instead. an Auto-Compounding GLP would make GLP an attractive, capital-efficient asset. -
OMBP1.2 Batch De-Risking I think it would be interesting if we let users also decide during the claiming of revenue rewards to give the option to purchase a balanced batch of the over-weighted assets, essentially allowing users to diversify their rewards at-the-point-of-claim and bolster the price resilience of GLP. Further decentralization of the fund-management of the GLP Basket would be achieved, and give another functionality to GLP attractive to institutional investors.
I’m not sure if this can be accomplished by simply updating existing functionality, or if this calls for something like a wrapped GLP (wGLP). The idea of a wGLP is attractive to me also though because other protocols can incorporate it, as opposed to single-use wrappers which are protocol specific. There are further functions the protocol can handle with wGLP I’ve been messing with but will leave for later.
OMBP2: Allow traders to delegate an amount of staked GMX to discount or entirely cover fees
This is pretty straight forward: on either a flat number basis with pre-determined discount tiers, or on a volume-ratio basis, allow users to delegate a portion of their staked GMX to cover their fees for perpetuals (maybe even swaps?). This will exert continuous buy pressure on GMX and is another long-term holding incentive.
OMBP3: Assuming Auto-Compounding GLP were possible
-
OMBP3.1: Deposit 80% of FPF (on Arbitrum only? Maybe some ratio split between Arb and Avalanche?) into GLP, auto-compound GLP; 20% of FPF into regular GLP, with Batch De-Risk claim function enabled every 30 days;
-
OMBP3.2: these can go to a GLP Basket reserve, and can be on-hand assets to provide additional liquidity in the event of bottle-necking, or in the event of more quick, gas-efficient rebalancing.
The above two I think are the most proposals I had in mind, and are the ones I think the community can find some general consensus around. The following are more degen/controversial, and I don’t feel particularly strong about them, but ultimately I think would create sustainable demand for GMX/GLP and are just fun to think about.
OMBP4: Alternative to FPF and protocol-enabled backing of GMX
The FPF was originally a boot-strapped reserve during the early days of GMX when it launched at $2; superior fundamentals were validated (and have continued to be validated), and GMX price appreciation has far outstripped the rate at which the FPF grows, even when the FPF began receiving GLP as deposits. Additionally, some users are unaware of the full functionality of esGMX - this is not necessarily a problem (time usually solves this) but certain users like mid-term investors are left with the “subscription I didn’t sign up for”. Perhaps these two problems present the opportunity for an interesting and dynamic solution
Off-Shore Mining
Give the options to users to select a 25% or 50% shorter vesting period at a 25% or 50% tax of their esGMX; esGMX which has been taxed due to expedited vesting will be held accumulated from Jan 01 FY to Dec 31 FY and withheld from circulation or “shored up”; on Jan 01 of the following Fiscal Year, the esGMX collected the year prior will be distributed to staked GMX as esGMX. The FPF is currently an inefficient use of capital and will not even reach a $2 backing of GMX within a meaningful timeframe. By constantly off-setting esGMX for a year, buy pressure from expedited vestning is mitigated in the long term, and allows longer term holders to mine the taxed-offset esGMX.
OMBP5: Further Gamify Multiplier Points with "Subscription function"
Multiplier Points are ingenious in that they have neat functionality, and endless potential for further functionality. To further encourage long-term holding, what if we allowed users to “Subscribe” their MPs within the first 30 days of their first GMX stake. “Subscribing” would note to the blockchain the total number of expected MPs you are to make within a year after within the Subscription timeframe. If by a year’s end, you have the expected number of MPs (meaning you did not unstake any GMX for the year), you can user your MPs to mint a MP Plaque NFT, which represents the number of MPs contained within it. This would burn the MPs of the person who minted them, and give them an NFT representation instead. The user can then sell this NFT to other users who want MPs because they intermittently unstaked and lost MPs to release their full amount of esGMX. This would double reward long term holders, bring further attention to the protocol, and provide a solution for mid-term traders who might want to vest the full amount of their esGMX.
This also creates a scenario which incentivizes long-term holding, through Subscription NFT mining scenario. Every year with a new subscription period, even a low stack of GMX can commit to multi-year holding with the expectation that they can mint a high-demand NFT.
GMX can host an in-house marketplace for the MP Plaque NFTs and generate fees on transactions.
OMBP6: Extend InsurAce Partnership Further
Both GLP and GMX earn fees. Perhaps InsurAce could accept these assets as deposits to offer premium or deductible rebates; additonally, they could also be used to help InsurAce extend coverage capacity for the GMX platform. This is something to be considered with other coverage/insurace protocols that decide to partner with GMX in the future.
OMBP7: Assuming wGLP: Allow new/upcoming protocols to bootstrap liquidity with wGLP
This is less a proposal and more a question: would it be possible for GMX to host a Copper Launch-eqsue function using wGLP? It could be a means to vent excess ETH/AVAX or stable weightages and help new projects accelerate their bootstrap.
Thoughts, suggestions, modifications, further considerations are appreciated!
- EthereumLawyer here. Thanks for writing this up. Love the ideas, all of which are well-thought out and appear to support your goals 1-5 as stated. One suggestion I have is for the ones that find support in the community to be added to a longer term roadmap, maybe through 2023, and that the priorities are hashed out sooner than later which should help X and the team to plan ahead, and maybe consider resources which could be added to the team. Maybe a survey to determine ranking of these individual proposals (and others) could help with this. Especially in light of multi-chain expansion (which takes time) and potential referral programs and other contract and potential UI/UX updates, we should realize that despite hard-nosed dev work, these will take time to implement. Having said that, below are my thoughts on urgency of these features/proposals. (HIGH priority 2-4 months, MEDIUM 4-10 months, LOW 10 - 16 months)