Timelock on sensitive actions
Axelar Network'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 #
Upgrade (gateway): timelocked via InterchainGovernance 7-day. ITS upgrade: NO timelock (EOA direct call). Mint-limit setting (setTokenMintLimits): callable by Multisig without timelock. Pause: no traditional gateway pause; ITS setPauseStatus() callable by single EOA without timelock. setOracle: N/A. The 7-day timelock covers gateway upgrades but not ITS upgrades or all sensitive operational functions.
Sources #
- GitHubAxelarGateway.sol source — GitHubAxelarGateway.sol: setTokenMintLimits() callable by mintLimiter (Multisig); upgrade() gated by governanceretrieved 2026-05-17
- ITS upgrade tx — no timelock confirmedITS upgrade txs (Jul 2025, Feb 2025): direct EOA calls, no timelock intermediaryretrieved 2026-05-17
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 →