The deposit function assumes the full amount of collateralToken is transferred to the contract. While the currently supported tokens (WETH, WBTC, LINK, USDC) do not charge transfer fees, this logic becomes a vulnerability if the protocol ever supports fee-on-transfer tokens (e.g., USDT) in the future. The code does not account for discrepancies between the recorded deposit amount and the actual received amount, leading to systemic risks if token support expands.
Assumption of Fee-Free Transfers: The code assumes all collateralToken transfers are fee-free. This is valid for the current tokens (WETH, WBTC, LINK, USDC) but not future-proof.
No Balance Checks: The contract does not verify the actual received token amount after transfers.
| Token | Transfer Fee? |
|---|---|
| WETH | No |
| WBTC | No |
| LINK | No |
| USDC | No |
None: Since WETH, WBTC, LINK, and USDC do not charge fees, the accounting remains accurate.
Accounting Mismatch:
If a fee-charging token (e.g., USDT) is added as collateralToken, totalDepositAmount will exceed the actual contract balance.
Example: Depositing 1000 USDT (2% fee) would record +1000 in totalDepositAmount but only receive 980 USDT.
Withdrawal Failures:
Users would be unable to withdraw their full deposits due to insufficient contract balances.
Broken Share Calculations:
Shares minted based on inflated totalDepositAmount would dilute the value for existing users.
Protocol Change:
Admin sets collateralToken = USDT (hypothetically).
User Action:
User deposits 1000 USDT.
USDT contract deducts 2% (20 USDT) → Contract receives 980 USDT.
Contract State:
depositInfo[counter].amount = 1000 USDT (incorrect).
totalDepositAmount += 1000 USDT (now 1000 USDT recorded vs. 980 USDT actual).
Withdrawal Attempt:
User requests withdrawal of 1000 USDT.
Contract attempts to send 1000 USDT but only holds 980 → Transaction reverts.
Calculate the difference in the contract’s balance before and after the transfer, even for fee-free tokens:
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.