Based on the discussion in https://gov.gmx.io/t/task-prioritization-2022/325, we propose the following plan:
Improve platform monitoring
Review and increase operational security
Support synthetic markets
X4 / new blockchains
Improve platform monitoring
To improve the security and reliability of the platform, we will be increasing monitoring for keeper statuses and RPC issues. This will help us respond to any issues that may occur at a much faster rate.
Review and increase operational security
We routinely review operational security, but as the platform has grown considerably, we feel it is appropriate to set aside some time to thoroughly review operations, including domain name servers and site hosting configurations, to assess opportunities for additional improvements.
Support synthetic markets
After the improvements to basic operations, the next most important task is to improve the product and user experience. We mentioned the model for a PvP AMM in the X4 update. This would allow us to provide a greater range of trading options and enable users to take a directional position on any market while earning yield.
The exact implementation may differ as we refine the model. However, our goal is for the end product to support a wide variety of tokens with the deepest liquidity compared to any other platform.
X4 / new chains
X4 and new chain deployments can be worked on after the support of synthetic markets. Both tasks have a solid potential to onboard more users, and we have received positive feedback on X4 from other protocols so far.
The main reason for prioritizing synthetics over X4 is that synthetics will likely have a faster adoption, as users will be able to use it directly upon launch. Whereas for X4, it needs to be completed and protocols will then need time to build on it, so the total time for adoption will be longer.
For new chains, it is uncertain which chains will gain more users in the coming period. In our view, the chains GMX is already on have a good chance of taking the lead, so improving the product for users should take precedence. We will continue to keep in contact with teams of different blockchains, and if there is a substantial benefit to it we may launch on a new chain before proceeding with work on synthetics.
Interface improvements
Interface development will continue alongside the above tasks. Some of the planned tasks are:
Position sharing
Trading view integration
One minute charts
Trade history improvements
Close a position and receive any supported token
Translations
Long-term sustainability
Since there have been some questions on the project's long-term sustainability, we feel it is appropriate to address them here. The development treasury currently has ~1.8 million held in USDC; this is sufficient to last 18 months till March 2024. With the PvP model, we may propose directing a percentage of fees to the treasury.
For example, 10% of fees of the PvP AMM could be directed to a treasury. The purpose of this treasury is to sustain and align contributors for the long term. To achieve this, we could allow it to build up and stream 1/365 of the treasury to contributors daily. 50% would be streamed as USDC, while the other 50% would be streamed through buying back GMX and then distributing it as esGMX to contributors. This esGMX would vest over 365 days without any other requirements.
Contributors would include everyone working on development, marketing, moderation, and users posting about GMX; anyone that has helped the project would be distributed a share of the treasury. This process will continue every year.
Our vision is to have a lasting and strongly aligned community continually working toward the improvement and expansion of the protocol.
For the bug bounty on Immunefi, the initial proposal was to support this using the floor price fund. One alternative suggestion is to allow up to 2% of the GLP pool to be payable toward the bounty. A function could be created and set up such that it can only be triggered once by a multi-sig consisting of Immunefi and GMX contributors.
It is important to note that this will only be used if a significant bug is discovered. Bug bounties are capped at 10% of the potential impact, so in the event of a vulnerability, this would save a large portion of the pool’s fund. We will further evaluate this and create a proposal for discussion.
Thank you to all who have helped and supported the project. We look forward to continuing to work on it together with everyone in the community.
Connect with us
Website: https://gmx.io/
Twitter: https://twitter.com/GMX_IO
Telegram: https://t.me/GMX_IO
Announcements: https://t.me/GMX_Announcements
Discord: https://discord.gg/H5PeQru3Aa
Github: https://github.com/gmx-io
Disclaimer
The information, content, and materials provided here are for general informational purposes only and do not constitute financial or investment advice, nor a legally binding agreement.
Note that discussions and voting involving contributors may occur on GMX DAO social media platforms, but contributors are independent actors, and nothing discussed or proposed should be understood as an obligation for an individual contributor to act.
Please conduct your own research and consult with appropriate professionals before making any decisions based on the information provided on this website.
USD values for _sizeDelta and _price are multiplied by (10 ** 30), so for example to open a long position of size 1000 USD, the value 1000 * (10 ** 30) should be used
what is size delta here (why to give 10 ** 30 ) , and how to give the leverage and position size in v1 contracts
address[] memory _path,
address _indexToken,
uint256 _amountIn,
uint256 _minOut,
uint256 _sizeDelta,
bool _isLong,
uint256 _acceptablePrice,
uint256 _executionFee,
bytes32 _referralCode,
address _callbackTarget