# Timelock Contract

OpenZeppelin Timelock Controller for governance delay on critical protocol actions.

**Source:** `contracts/timelock/`

## Overview

The Timelock enforces a **minimum delay** on governance operations. Critical protocol changes (fee updates, asset whitelisting, contract upgrades) must be scheduled, wait for the delay to pass, and then be executed. This gives protocol participants time to review and react.

## Operation Lifecycle

```
Unset → Waiting → Ready → Done
```

| State       | Description                          |
| ----------- | ------------------------------------ |
| **Unset**   | Operation doesn't exist yet          |
| **Waiting** | Scheduled, waiting for delay to pass |
| **Ready**   | Delay has passed, can be executed    |
| **Done**    | Successfully executed                |

## Roles

| Role          | Description                                    |
| ------------- | ---------------------------------------------- |
| **Proposer**  | Can schedule new operations with a delay       |
| **Executor**  | Can execute operations once they are ready     |
| **Canceller** | Can cancel pending operations before execution |

## Integration with Globals

The Timelock is set as the **admin** of the Globals contract during deployment. This means:

* All admin-gated functions on Globals (`set_settings`, `add_supported_asset`, `set_fee`, etc.) require Timelock authorisation
* To change a global setting, a Proposer must schedule the operation, wait for the delay, then an Executor executes it
* This prevents instant, unilateral changes to critical protocol parameters

## Self-Administered

The Timelock is deployed as **self-administered** — it is its own admin:

* No single external address can bypass the time delay
* The Timelock's own settings (minimum delay, roles) can only be changed through the Timelock itself
* This creates a fully decentralised governance loop

## Deployment

```
__constructor(min_delay, proposers, executors, admin: None)
```

* `min_delay` — Minimum seconds between scheduling and execution
* `proposers` — Addresses that can schedule operations
* `executors` — Addresses that can execute ready operations
* `admin: None` — Self-administered (no external admin)

## Test Coverage

14 tests covering:

* Operation lifecycle (schedule → ready → execute)
* Cancellation before execution
* Delay enforcement
* Role-based access control
* Integration with Globals contract (scheduling admin-gated operations)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.trilobyte.finance/technical-documentation/timelock-contract.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.