V2.3 Pre-Review

The largest area of risk is the ability to atomically deposit to or withdraw from a cross-margin GMX Account in a single transaction while pending position actions execute later through the standard keeper/oracle path. This weakens the two-step commitment model used for position-level actions: instead of committing margin before execution pricing is known, a trader can change the margin backing the account after observing newer market information. The concrete concern is increased exposure to short-term “risk-free trade” opportunities. If keeper execution uses a slightly stale but valid standard oracle price, a trader may be able to front-run execution by withdrawing collateral, or by deciding to deposit collateral only when required, in order to affect whether the pending action succeeds. A complete exploit normally also requires a trader-controlled condition that makes the keeper execution revert without cancelling or freezing the action for a period of time. No such non-frozen persistent failure path was identified in the reviewed normal order flow. The risk may be accepted if keeper prices are expected to be maximally fresh. Even so, integrating the existing immediate multichain-balance deposit/withdrawal model with position collateral introduces this new effect and should be an explicit product and security decision.

Clarify the product requirement for atomic cross-margin account deposits and withdrawals. If the feature is required, document the accepted oracle-freshness and selective-execution risk, and add adversarial tests covering atomic account-balance mutations immediately before all relevant keeper actions. Otherwise, consider restoring a commitment boundary by locking relevant account collateral while actions are pending or by requiring a compatible price-freshness regime for account changes and keeper execution.

An isolated position has exactly one collateral token. If that token is cross collateral and its market-level cap is exhausted, the user cannot add collateral to improve the position's health using another token. Unlike cross margin, isolated positions cannot fall back to another eligible token. This can leave users unable to restore a position's safety margin except by reducing or closing it.

Explicitly document this cap-induced top-up limitation and assess whether an isolated collateral migration or conversion mechanism is needed. Ensure UX and liquidation behavior make the risk clear.

Cross-margin liquidation eligibility aggregates marked collateral, recognized PnL, accrued fees, and maintenance requirements. It does not simulate the execution price impact of closing all account positions, including interactions among positions that share a virtual inventory. An account may appear adequately margined at mark price even though the sequence of required liquidation closes realizes materially worse outcomes.

Model conservative close price impact in account health, or add a calibrated liquidation buffer that covers correlated position unwinds and shared virtual-inventory effects. Validate the chosen model with multi-position same-market scenarios.

transferOutWithOraclePrices permits an immediate account withdrawal after checking health using atomic oracle prices. No additional buffer is applied to protect the account against valuation under the standard non-atomic execution oracle. An account can pass the fresh atomic health check while becoming liquidatable or materially weaker when evaluated by the standard price provider used by later keeper actions.

Apply a conservative buffer or dual-price health validation to atomic withdrawals, or require the post-withdrawal account to remain safe under a valuation compatible with subsequent standard-oracle actions.

An oracle-priced withdrawal from the GMX account validates only aggregate cross-margin account liquidation state. It does not apply the isolated willPositionCollateralBeSufficient safeguard, which excludes positive PnL and enforces a position-local dynamic collateral requirement intended to resist price-impact manipulation. Cross-margin users can therefore withdraw through a path that does not reproduce those per-position protections.

Document and justify the intentional replacement of the position-local safeguard, or apply an equivalent conservative per-position constraint to account withdrawals. At minimum, assess whether the aggregate test must exclude positive PnL or model the same dynamic collateral requirement.

Enabling a market for cross margin validates that both possible PnL payout tokens are whitelisted and configured. Removing a collateral token from the whitelist only checks active cross-collateral usage for that token. It does not check whether the token remains a possible PnL token for an enabled cross-margin market, and does not disable affected markets or require their positions to close. Governance can therefore leave an enabled market and open cross-margin positions in a state that violates the prerequisite used when cross margin was enabled.

Block removal of a whitelisted token while it is a long or short PnL token for any cross-margin-enabled market, or atomically disable all affected markets and require positions to be closed or migrated before removal.

Collateral-only MarketIncrease orders bypass the closed-market grace checks when sizeDeltaUsd is zero. The exception does not require an empty swap path. A user can therefore execute a zero-size increase that swaps through one or more path markets while the grace-period protections are bypassed. More generally, order swap-path validation checks markets are enabled but does not apply the path markets' closed-state, grace-period, feature-gate, or price-consistency validation.

In swaps validate every path market's closed-state, grace period, feature gate, and price consistency during execution.