Timelock on sensitive actions
GMX v2 (GMX Synthetics)'s assessment for RD-F-033 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Sensitive actions are partially timelocked. Signal-execute pattern (1-day) applies to role grants, oracle signer additions, fee receiver changes. Config changes route through ConfigTimelockController (1-day). However: revokeRole in RoleStore is immediate (no signal period); CONFIG_KEEPER can execute immediate config changes via Config.sol setters without any queue period. Two distinct bypass paths exist for the 1-day delay.
Sources #
- GitHubGMX v2 README — role managementREADME.md — 'New roles can be granted by timelock admins with a time delay'; 'timelock multisig should revoke the permissions of malicious or compromised accounts'retrieved 2026-05-05
- Config.sol immediate parameter changesConfig.sol — CONFIG_KEEPER immediate setters: setUint, setAddress, setBytes32, setOracleProviderForToken etc. No timelock queue.retrieved 2026-05-05
- RoleStore immediate revokeRoleRoleStore.sol — revokeRole() can be called immediately by ROLE_ADMIN without signalretrieved 2026-05-05
Methodology #
For each sensitive action category (mint / pause / rescue / setOracle / upgrade), determine whether execution requires going through the declared timelock.
See the full factor methodology and distribution across all protocols →