Risk Oracle

RiskOracleConfig allows the RISK_ORACLE role to directly update funding and borrowing rate parameters without first settling the market’s accrued funding and borrowing state. Since the next market update calculates elapsed time from the previous update timestamp using the current config, a newly set rate can be applied to the entire unsettled interval. This can overcharge or undercharge open positions and distort claimable funding or borrowing fees and therefore lead to step-wise jumps in positions health. This can even lead to positions being suddenly liquidatable. The more stale a market is the bigger the impact of such config changes.

Consider to update the market state (accrue funding, borrowing, etc.) before changing configurations that have any influence on a stale market state.

Guardian: The remediation for stale borrowing accrual only settles borrowing before updates to BASE_BORROWING_FACTOR and ABOVE_OPTIMAL_USAGE_BORROWING_FACTOR. However, RiskOracleConfig also allows the RISK_ORACLE role to update OPTIMAL_USAGE_FACTOR, which is part of the kink borrowing-rate formula. When it is non-zero, MarketUtils.getBorrowingFactorPerSecond uses it to route into getKinkBorrowingFactor:

uint256 optimalUsageFactor = getOptimalUsageFactor(dataStore, market.marketToken, isLong);

if (optimalUsageFactor != 0) {
    return getKinkBorrowingFactor(
        dataStore,
        market,
        isLong,
        reservedUsd,
        poolUsd,
        optimalUsageFactor
    );
}

Inside getKinkBorrowingFactor, the value controls the kink threshold and the divisor used to calculate the above-optimal portion of the borrowing rate. Despite this, _isRiskOracleBorrowingBaseKey excludes OPTIMAL_USAGE_FACTOR. As a result, _settleBorrowingIfRequired returns without settling accrued borrowing before the new OPTIMAL_USAGE_FACTOR is stored. The next borrowing update can then apply the new kink threshold to the full elapsed stale interval since cumulativeBorrowingFactorUpdatedAt. This can overcharge or undercharge open positions for the stale interval and may affect position health and liquidation eligibility. The impact depends on market staleness, utilization, and the size of the optimal usage factor change.

Recommendation Include OPTIMAL_USAGE_FACTOR in _isRiskOracleBorrowingBaseKey.

RiskOracleConfig requires the CONTROLLER role to function because it writes through DataStore and emits through EventEmitter, both of which are onlyController-gated. The deploy script deployRiskOracleConfig.ts attempts to grant CONTROLLER after deployment:

afterDeploy: async ({ deployedContract }) => {
  await grantRoleIfNotGranted(deployedContract, "CONTROLLER");
},

However, grantRoleIfNotGranted immediately returns on existing mainnet deployment networks:

if (hre.gmx.isExistingMainnetDeployment) {
  return;
}

Affected flows include:

• setRiskOracleMarketEnabled, because it calls DataStore.setBool.
• setBool, setAddress, setBytes32, setUint, and setInt, because they call the corresponding DataStore.set* method.
• All successful setter flows, because they emit through EventEmitter, which also requires CONTROLLER

Add RiskOracleConfig to requiredRolesForContracts.CONTROLLER in config/roles.ts, and ensure the mainnet role update transaction grants the deployed RiskOracleConfig address the CONTROLLER role.

RiskOracleConfig allows the RISK_ORACLE role to directly update sensitive market parameters. Right now, values are mostly checked against broad per-key bounds, but important cross-parameter invariants are not enforced. For example, MIN_COLLATERAL_FACTOR should remain greater than or equal to MIN_COLLATERAL_FACTOR_FOR_LIQUIDATION; otherwise users may be able to open or increase positions that are immediately liquidatable.

Consider to add invariant checks before applying risk oracle updates.

RiskOracleConfig.setRiskOracleMarketEnabled only checks that the given market != address(0) before setting RISK_ORACLE_MARKET_ENABLED. It does not verify that the supplied address is a registered GMX market.

Consider to validate that the given market exists in GMX.

RiskOracleConfig should only expose setUint for the currently allowlisted risk-oracle parameters, because those parameters are consumed by the protocol as uint256 configs. Instead, the contract exposes generic setters for multiple DataStore types:

• setBool
• setAddress
• setBytes32
• setUint
• setInt Because the same base-key allowlist is shared by all setters, a RISK_ORACLE account can accidentally call the wrong setter for a critical risk parameter. The transaction can succeed and emit a config event, but the actual uint config used by the protocol remains unchanged.

Remove the non-uint setters from RiskOracleConfig if the internal risk oracle only needs to update uint risk parameters.

The RISK_ORACLE is missing in multiple scripts:

• validateRolesUtils only uses the Role library and not the new Role2 library
• printRoles lacks the role in knownRoles
• validateContractDeployment lacks the role in roleLabels
• validateDeploymentUtils does not include it in the external-role allowlist

Consider to add the RISK_ORACLE to scripts wherever it is needed.

RiskOracleConfig.sol imports Keys2, Precision, Cast, and MarketUtils, but none of these are used.

Consider to remove unused code.

All public risk-oracle setters are already protected by the onlyRiskOracle modifier. However, _validateKey checks the same role again:

if (roleStore.hasRole(msg.sender, Role2.RISK_ORACLE)) {
    ...
    return;
}

revert Errors.InvalidBaseKey(baseKey);

This role check is redundant for the current setters. Additionally, if _validateKey is reused by a future function that is not protected by onlyRiskOracle, callers without the role would receive InvalidBaseKey instead of the more accurate Unauthorized error.

Remove the role check from _validateKey and rely on the external onlyRiskOracle modifier for authorization.

The older Chaos Labs risk-oracle flow used ConfigSyncer as an adapter between the external Risk Oracle and GMX config writes. Before applying an update, ConfigSyncer checked multiple operational disable flags:

• global sync feature disable;
• per-market disable;
• per-parameter disable;
• per-market-parameter disable. RiskOracleConfig uses a simpler direct-write model. A CONFIG_KEEPER can enable or disable all risk-oracle updates for a market through setRiskOracleMarketEnabled, and a RISK_ORACLE account can then write allowlisted parameters for enabled markets. This is simpler and may be intentional, but it is also less granular. If the internal risk oracle has an issue with one parameter family, such as funding, borrowing, or caps, operators can only disable the whole market or revoke the RISK_ORACLE role. They cannot pause a single base key or a single market/base-key pair while allowing other risk-oracle updates to continue.

Consider whether RiskOracleConfig should include finer emergency controls similar to ConfigSyncer, especially:

• a global risk-oracle config feature disable;
• a per-base-key disable;
• optionally, a per-market/base-key disable. If this coarser control model is intentional, document the operational runbook for pausing faulty risk-oracle updates, including whether operators should disable affected markets or revoke the RISK_ORACLE role.

The new RiskOracleConfig allowlist is not a direct replacement for the previous Chaos Labs ConfigSyncer risk-oracle surface. ConfigSyncer can apply updates for the following base keys that RiskOracleConfig does not allow:

• SWAP_IMPACT_FACTOR
• SWAP_IMPACT_EXPONENT_FACTOR
• BORROWING_FACTOR
• BORROWING_EXPONENT_FACTOR
• RESERVE_FACTOR
• OPEN_INTEREST_RESERVE_FACTOR Conversely, RiskOracleConfig adds support for some keys that ConfigSyncer did not support, including:
• MAX_POSITION_IMPACT_FACTOR
• GLV_MAX_MARKET_TOKEN_BALANCE_USD
• GLV_MAX_MARKET_TOKEN_BALANCE_AMOUNT
• FUNDING_FACTOR
• FUNDING_EXPONENT_FACTOR
• THRESHOLD_FOR_STABLE_FUNDING
• THRESHOLD_FOR_DECREASE_FUNDING
• MIN_COLLATERAL_FACTOR
• MIN_COLLATERAL_FACTOR_FOR_OPEN_INTEREST_MULTIPLIER
• MIN_COLLATERAL_FACTOR_FOR_LIQUIDATION This may be intentional if the internal Risk Oracle is meant to manage a different parameter set than the Chaos Labs integration. If not, the migration could silently remove automated risk-oracle management for swap impact, legacy borrowing, and reserve-factor parameters.

Confirm whether the new allowlist intentionally drops the ConfigSyncer-only keys.

The NatSpec of the _validateKeyAndMarket function states out that the function returns an address but it returns a market now.

Consider to update the NatSpec.

EventUtils.IntItems is unused now.

Consider to remove unused code.

The list of RISK_ORACLE managed keys in the updateMarketConfigUtils.ts script is stale.

Consider to update this script.