Timelock on sensitive actions

Babylon Protocol'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 #

All sensitive actions (software upgrades, parameter changes, mint/inflation parameters, fee parameters) route through BABY governance module. No bypass path for normal operations. However: (a) no separate timelock delay after voting ends — execution is at the specified block height immediately after vote passes; (b) expedited proposals reduce delay to 24h with higher threshold (66.7%). No rescue/emergency function exists (structurally inapplicable). Oracle not applicable (no price oracle). Governance covers all actions but expedited path reduces delay.

Sources #

Docs
Governance | Babylon DocsGovernance: standard 3-day, expedited 1-day; no bypass path documentedretrieved 2026-05-04

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 →

rubric_version v1.7.0 protocol babylon-protocol factor RD-F-033 score yellow collected_at 2026-05-04 19:43:27