> For the complete documentation index, see [llms.txt](https://docs.ipor.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipor.io/build-on-fusion/atomists/vault-configuration-step-by-step/timelocks-and-execution-delays.md).

# Timelocks and Execution Delays

This guide explains the conceptual model, governance rules, and operational safeguards of **timelocks (execution delays)** in IPOR Fusion.

## 1. Executive Summary: What is a Timelock?

A **timelock** (technically referred to as an **execution delay**) is a mandatory, onchain "cooling-off" period enforced between the time an administrative action is proposed and the time it actually takes effect on the blockchain.

In IPOR Fusion, no single administrative key can immediately alter critical vault parameters (such as changing performance fees, updating assets, or modifying Fuses) if a timelock is active. This design enforces complete transparency and provides a vital window for depositors and Guardians to react before any high-impact change is executed.

## 2. The Core Value Proposition

Timelocks are not meant to slow down routine operations, but rather to establish a robust line of defense for depositors and operators. They solve three primary security problems:

| **Risk Mitigated**       | **How Timelock Solves It**                                                                                                                                                                |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Admin Key Compromise** | If an Atomist or Owner private key is stolen, the attacker cannot drain or hijack the vault instantly. They must schedule their malicious transaction, triggering public alerts.          |
| **Human Error**          | If an operator inputes an incorrect fee percentage (e.g., 50% instead of 5%), the mistake is caught while sitting in the queue and can be cancelled before execution.                     |
| **User Transparency**    | Depositors are never surprised by sudden policy shifts. If a vault owner increases performance fees, depositors have the entire timelock window to withdraw their funds if they disagree. |

## 3. The Two-Step Operational Workflow

When an account or role is subject to an execution delay, any restricted action they attempt must go through a structured, two-step lifecycle:

```
[ Step 1: PROPOSAL ]
       │
       ▼ (Atomist schedules change; event is logged on-chain)
[ Step 2: COOLING-OFF WINDOW ] ◄─── [Guardian monitors queue]
       │                            (Guardian can CANCEL if malicious)
       ▼ (Delay period must fully elapse)
[ Step 3: EXECUTION ]
       │
       ▼ (Action takes effect on the vault)

```

1. **Proposal (Schedule)**: The authorized operator proposes the change. This action is registered on-chain in a "Pending" queue. It is immediately visible to anyone monitoring the vault contracts.
2. **The Cooling-Off Window**: The transaction sits inertly in the queue. The duration of this window depends on the configured delay (e.g., 48 hours).
3. **Execution (Execute)**: Once the required time has elapsed, the proposed transaction can be executed, applying the new parameters directly to the vault.

## 4. Timelock Levels and Configuration

Timelocks are highly granular and can be configured at two distinct levels to fit your organization's security posture:

### A. Account-Role Level (Individual Delays)

You can apply different timelock durations to different accounts, even if they hold the exact same administrative role.

* **Operational Example**: A vault owner might grant the Atomist role to a **multi-signature cold wallet** with a 0**-second delay** (for rapid emergency adjustments), while granting the same Atomist role to a **single-signature hot wallet** or automated keeper with a 2**-day delay** for routine rebalancing.

### B. Minimal Role Delay (The Safety Floor)

To prevent key administrators from overriding security thresholds, the system supports a "Minimal Role Delay". Once set, no account can be granted that specific role with a delay lower than the established floor.

* **Operational Example**: If the Minimal Role Delay for the Atomist role is set to 1 day, any attempt by a compromised Owner account to grant an instant, 0-day Atomist role will be automatically rejected by the access manager.

## 5. Who Can Set, Edit, and Remove Timelocks?

The editing and removal of timelocks is governed by the **Role Admin Hierarchy**. Under this model, only the designated "Admin" of a specific role has the authority to grant that role or modify its execution delay:

```
                  ┌──────────────────────┐
                  │      OWNER ROLE      │
                  └──────────┬───────────┘
                             │ Admin of
         ┌───────────────────┼───────────────────┐
         ▼                   ▼                   ▼
┌─────────────────┐ ┌─────────────────┐ ┌───────────────────┐
│  ATOMIST ROLE   │ │  GUARDIAN ROLE  │ │  PRE HOOKS ROLE   │
└────────┬────────┘ └─────────────────┘ └───────────────────┘
         │ Admin of
         ├───────────────────┐
         ▼                   ▼
┌─────────────────┐ ┌─────────────────┐
│   ALPHA ROLE    │ │FUSE MANAGER ROLE│
└─────────────────┘ └─────────────────┘

```

* **Owners Only**: The Owner administers the Atomist and Guardian . Only Owners can set, edit, or remove timelocks on Atomists or Guardians.
* **Atomists Only**: The Atomist administers operational roles like Alpha or Fuse Manager. Only the Atomists can configure timelocks for those roles.
* **Self-Governance**: The Owner role is self-administered. Only existing Owner accounts can modify the delay settings of other Owner accounts.

## 6. The "Admin Timelock" Constraint

A common security vulnerability in DeFi occurs when an administrator with a timelock simply uses their admin power to change their own timelock to 0 seconds, bypassing the safety window.

IPOR Fusion closes this loophole using **Self-Referential Security**:

> **Rule**: Administrators are strictly bound by their own timelocks.

If a vault Owner is subject to a 3-day timelock, they cannot instantly change their own timelock or the timelock of any other user. Any attempt to modify a timelock, grant a role, or change minimal role delays must itself be scheduled as a proposed transaction and wait out the 3-day cooling-off period before taking effect.

## 7. The Guardian: The Emergency Brake

While a timelock prevents malicious changes from occurring instantly, it is only effective if there is a mechanism to stop a malicious transaction while it sits in the queue. This is the responsibility of the [**Guardian**](/build-on-fusion/atomists/vault-configuration-step-by-step/access-management.md#guardian-role).

The Guardian acts as the vault’s emergency security sentinel:

* **The Sentinel Power**: Guardians have the unilateral authority to **cancel** any pending scheduled operational and configuration transaction in the access manager's queue.
* **Instant Cancellation**: Guardians are granted roles with a 0**-day delay**, enabling them to intervene instantly.
* **Safety Isolation**: Guardians can *only* cancel pending actions; they cannot schedule new administrative configurations or authorize movements of capital.

If a monitoring bot or offline cold wallet detects an unauthorized transaction in the queue, the Guardian executes a cancellation. The malicious transaction is instantly deleted, and the compromised key is rendered harmless while the operators coordinate a key rotation.