GMXTrade is a decentralized leveraged trading platform built on the Solana blockchain, drawing inspiration from the technical innovations introduced by GMX V2. The platform aims to provide a seamless trading experience with fast transaction times and low fees, while maintaining security and decentralization.
Runnable PoC Required
Rewards
Rewards by Threat Level
Mainnet assets:
Reward amount is 10% of the funds directly affected up to a maximum of:
$100,000Minimum reward to discourage security researchers from withholding a bug report:
$25,000Primacy of Impact vs Primacy of Rules
GMTrade adheres to the Primacy of Rules, which means that the whole bug bounty program is run strictly under the terms and conditions stated within this page.
Reward Calculation for Critical Level Reports
For critical smart contract bugs, the reward amount is 10% of the funds directly affected up to a maximum of $100,000. The calculation of the amount of funds at risk is based on the time and date the bug report is submitted. However, a minimum reward of $25,000 is to be rewarded in order to incentivize security researchers against withholding a critical bug report.
Repeatable Attack Limitations
If the smart contract where the vulnerability exists can be upgraded or paused, only the initial attack will be considered for a reward.
The amount of funds at risk will be calculated with the impact of the first attack being at 100% and then a reduction of 50% from the amount of the first attack for every 1 hours the attack needs for subsequent attacks from the first attack, rounded down.
Reward Calculation for High Level Reports
High impacts concerning theft/permanent freezing of unclaimed yield/royalties are rewarded within a range of $10,000 to $20,000 with the reward calculated based on 100% of the funds at risk, though capped at the maximum high reward.
In the event of temporary freezing, the reward doubles from the full frozen value for every additional 1 hours that the funds are temporarily frozen, up until a max cap of the high reward.
**Maximum Payout Cap (Treasury-based). The total payout for any single valid report shall not exceed 10% of the protocol Treasury balance at the time the report is submitted. Where the standard calculation (including "% of funds at risk" for Critical) yields more, this cap controls. Minimum rewards remain payable. **
** Treasury balance is publicly verifiable on-chain at 4tf9zEjvj2BUR9ZaAr53sQdULDWGGpJTr2zngSrmjtN6.**
Program Overview
The GMTrade system primarily consists of on-chain programs and off-chain keepers, along with price and risk oracles. User market operations are generally executed in two steps: first, users submit on-chain transactions to create market operation requests; then, keepers monitor the network, submit the necessary price updates, and finalize the verification and execution of these requests via additional on-chain transactions. Protocol security is ensured by oracle-provided data and on-chain program logic that validates both user requests and keeper actions, supplemented by mechanisms such as price impacts (to mitigate price manipulation risk and maintain pool and open interest balance) and adaptive funding fees (to ensure long-term balance in open interest).
The core market operations include:
Deposits and withdrawals to market pools: Liquidity providers (LPs) contribute liquidity to a market pool by depositing long or short tokens and receive market tokens representing their share of the pool. LPs can redeem market tokens at any time to withdraw their proportional share of assets.
Opening and closing perpetual positions: Traders post collateral to open positions against the market pool's index. When closing a position, profits are withdrawn from the market pool based on index price movement, while losses are deducted from the trader's collateral. The deducted collateral is then deposited into the market pools to cover counterparty profits and maintain liquidity.
Swapping assets: Traders can swap long tokens for short tokens (or vice versa) within the market pools.
LPs primarily earn revenue from order fees and borrowing fees paid by traders when opening or closing positions, or when swapping assets. Traders can also earn by helping maintain market balance, receiving positive price impacts and funding fees paid by the side that increases the imbalance in open interest or the liquidity pool.
Audits
Completed audit reports for this project can be found at the links below.
Any unpatched or unresolved vulnerabilities disclosed in these reports are not eligible for rewards.
Known Issues
Reports covering previously identified bugs listed below are not eligible for rewards under this program.
This includes:
- Known issues that the project is aware of, even if no fix or code changes have been implemented.
- Issues the project has consciously decided not to remediate.
- Cases where operational mitigations or procedures have been implemented to reduce potential risk.
KYC not required
No KYC information is required for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
Responsible Publication
Category 3: Approval Required
Prohibited Activities
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.