Liquidity Management

Summary

The requestKey used for managing and tracking orders in the GmxProxy contract’s queue is overwritten in the createOrder and settle functions, which can lead to issues with order tracking and management.

Vulnerability Details

In the contract, the requestKey is used to uniquely identify and track orders in the system. However, there is an issue in how the requestKey is handled in two critical functions: createOrder and settle. Specifically, in these functions, the requestKey is overwritten rather than being used in a way that ensures each order has a unique identifier.

• Inconsistent assignment: The requestKey is assigned and used in both createOrder and settle, but there is no robust system to manage it properly. This could lead to the loss of order history, incorrect associations between orders and user requests, or even duplicate entries.

• Risk of overwriting: When the requestKey is overwritten, the previous request is essentially lost, which could prevent the contract from correctly tracking or referencing previous orders. This also increases the risk of errors in processing orders or settling transactions.

• Impacts on order matching: Since the requestKey is crucial for ensuring that orders are matched correctly (particularly in scenarios like the settlement of trades), overwriting the key can lead to mismatched orders or incomplete settlements. For instance, if the same requestKey is used for multiple orders (without proper isolation between them), it could result in executing the wrong trades, which could be detrimental to users.

• Possible attacks or vulnerabilities: A malicious actor could potentially exploit this by deliberately overwriting the requestKey to confuse the system, leading to financial exploitation or manipulation of order processing. This is especially dangerous if the contract is managing significant assets or user funds.

Impact

The impact of the issue with requestKey handling includes:

• Order tracking failure: Incorrect or missing tracking of orders due to overwritten requestKeys, which could prevent the system from processing orders or recalling them at later stages (such as settlements).

• Transaction integrity issues: Potential loss of transaction integrity, which could lead to orders being settled incorrectly or out of sequence. This is critical in decentralized finance (DeFi) platforms where order matching is essential.

• Reputation and trust risk: Any failure in correctly handling the requestKey may lead to user distrust in the platform due to a perceived lack of reliability in processing orders and managing assets.

Tools Used

Manual code review.

Recommendations

To fix the issues around requestKey handling:

1. Unique requestKey generation: Ensure that a unique requestKey is generated for each order or transaction. This key should be consistent across the entire lifecycle of the order (from creation to settlement), and no overwriting should occur.

2. Improved state management: Implement a more structured approach to managing the state of orders. This could involve storing order details (including the requestKey) in a mapping or another suitable data structure that guarantees uniqueness and consistency throughout the contract’s execution.

3. Transaction isolation: Each order should be treated independently, with clear separation between different requestKey values. This will prevent one order from affecting or overwriting another order’s state.