Timelock

ProtocolTimelock is the governance safety module for TRTH. It sits between day-to-day operations and high-impact control—so critical updates cannot flip instantly without community observability.

What the timelock enforces

Privileged roles (for example, admin, guardian, or parameter manager—exact names depend on deployment) often must schedule actions through ProtocolTimelock instead of calling sensitive functions directly on live modules.

Typical gated changes include:

• Reward parameters and epoch configuration for EpochRewardsV1
• Fee routing and FeeSink settings that affect buyback/burn behavior
• Adapter or oracle references for Chainlink VrfWordAdapter
• Emergency controls where governance chooses to route through delayed execution

Delay mechanics

A proposed action is submitted as an operation with a delay period. Until that time elapses, the operation remains queued and visible to monitors. After the delay, it can be executed if still valid.

Note

The exact delay is a deployment parameter—verify the current value on-chain or via tooling before relying on it for operational planning.

Security implications

The timelock reduces rug-pull velocity: even if a key is compromised, defenders may have a time window to detect, pause, or counteract downstream effects—depending on monitoring and incident response.

Caution

A timelock does not eliminate governance risk. If privileged roles are captured or misconfigured, delayed execution can still harm users—especially when changes are technically valid but economically harmful.

For related material, see Risk Factors and Audit Reports.