---
title: "Admin Controls"
description: "The bounded administrative controls in Overlayer: what these protocol-level safeguards are for, what they are explicitly not for, and the limits on them."
keywords:
  - "admin controls"
  - "safeguards"
  - "parameter management"
  - "governance"
canonical_url: https://docs.overlayer.fi/security/admin_controls
md_url: https://docs.overlayer.fi/security/admin_controls.md
last_updated: 2026-05-05T15:42:56.000Z
---

# Admin Controls

> The bounded administrative controls in Overlayer: what these protocol-level safeguards are for, what they are explicitly not for, and the limits on them.

Overlayer includes some **bounded administrative controls**. These should be understood as **constrained protocol-level safeguards**, not as a replacement for core rules.

### What these controls are for:

* **Bounded operational safeguards**
* **Parameter management**
* Adaptation to **changing operational or legal conditions**
* Reduced exposure to **short-term manipulation**

###  What these controls are not for:

* Overriding **backing relationships** arbitrarily
* Making the protocol **depend on governance** to function
* Turning core mint, redeem, stake, or unstake into **discretionary actions**

---

## Relevant Controls at Launch

The following are the relevant user-facing controls at launch:

* **Redeem limit per block**
* **Blacklist feature activation logic**
* **Blacklist withdrawal logic**
* **Dispatcher update**
* **Venue address update**
* **Bounded parameter changes under notice**

:::info Broader Control Surface

The protocol may also include non-UI but still relevant administrative controls. These should be understood as **protocol-level controls** rather than user-facing app actions.

:::

---

## Notice Period

Selected sensitive parameter changes are subject to a **14-day Notice Period** before becoming effective.

This exists to ensure that:

* Some changes are **delayed rather than immediate**
* Users have **time to assess and exit** before meaningful changes become active

### The Notice Period applies to:

* Changes to **fee distribution parameters**
* Activation or deactivation of **blacklist logic**
* Activation or deactivation of **blacklisted-balance withdrawal logic**
* **Venue address updates**
* **Rewards dispatcher upgrades**
* Changes to the **redeem limit per block**

---

## Blacklist Logic

The protocol design includes **bounded blacklist-related functionality** so the system can adapt if regulatory conditions require it, while still giving users **time to assess and exit** before enforcement becomes possible.

The key design choice is **separation**:

* **Enabling blacklist logic** is separate from **blacklisting an address**
* **Enabling withdrawal** from blacklisted addresses is separate from **blacklisting itself**

:::caution Bounded Adaptation
This separation reduces the risk of an **instant freeze-and-seize pattern** and should be understood as a **bounded adaptation mechanism** rather than a silent control layer.
:::