> For the complete documentation index, see [llms.txt](https://steakhouse.financial/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://steakhouse.financial/docs/products/infrastructure/supervisor-v2.md).

# Supervisor v2

The Supervisor v2 is a governance contract for Steakhouse-curated Morpho Vault V2 deployments. It holds the Owner and Sentinel roles, makes the Sentinel position permanent, and routes material Owner-initiated changes through a fixed timelock that Guardians can veto.&#x20;

### Overview

* Holds the Owner and Sentinel roles on each supervised vault.
* Cannot remove itself as Sentinel, so the role is permanent once set.
* Routes material Owner actions through a fixed timelock that Guardians can veto.
* Forwards revocations for Curator initiated material changes to the vault's own timelock.
* Executes non-material vault operations (e.g. Curator, name, symbol, additional Sentinels) immediately.

### Architecture

```mermaid
flowchart LR
    Multisig[Supervisor Owner<br/>multisig]
    SV[Supervisor V2]
    Vault[Supervised Vault]
    Guardian[Guardian<br/>Aragon DAO]
    Depositors[Depositors]

    Multisig -->|controls| SV
    SV -->|Owner + Sentinel| Vault
    Depositors -->|voting weight| Guardian
    Guardian -.->|revoke| SV
```

A single Supervisor Owner (Steakhouse) controls the Supervisor v2 contract with a high-security multisig. The Supervisor v2 in turn holds the Owner and Sentinel roles on each Morpho Vault V2 it supervises. Each supervised vault maintains its own list of Guardians, readable onchain. The Supervisor v2 tracks which vaults it currently owns and exposes that list through `getVaults`, `getOwnedVaults`, and `getNonOwnedVaults`.

### Roles

The core roles are the Owner and the Guardian(s). The Pending Supervisor Owner is important for any Ownership change on the Supervisor level, while the Allowed Vault Owner may be operationally favourable (e.g. an integration partner adding additional Guardians).  <br>

* Supervisor Owner: Controls the Supervisor v2 itself. Submits and executes timelocked material changes, manages vault settings that do not require a delay, and registers or initiates removal of Guardians. Ownership transfer is two-step.
* Guardian: Can revoke any pending action (initiated by the Curator or Owner) of its assigned vault, including pending Owner changes or pending Guardian removals.
* Pending Supervisor Owner: When ownership of the Supervisor v2 is supposed to be transferred, the proposed owner must call `acceptSupervisorOwnership` to complete the transfer.
* Allowed Vault Owner: Vault Owner allowlisted by the Supervisor Owner to register additional Guardians on its own vault without going through the Supervisor Owner.

In public vaults, the default Guardian is configured as an Aragon DAO, giving vault depositors governance rights, with voting weight of individual depositors proportional to depositor shares.&#x20;

### Timelock and veto

The Supervisor v2 uses a single timelock duration that is fixed at deployment and cannot be decreased.

The Supervisor Owner calls submit(bytes data) with the full calldata of the intended action. The contract stores the calldata with an execution timestamp. A Guardian for the target vault, or the Supervisor Owner itself, can call revoke(bytes data) at any point during the timelock window. After the timelock expires, the original function call goes through, the contract validates the timelock internally and the change can be executed.&#x20;

Two actions pass through this flow:

* `setOwner`: transfer ownership of a supervised vault to a new address.
* `removeGuardian`: remove a Guardian from a vault.

The same revoke mechanism also forwards to the vault's own timelock queue (material changes initiated by the Curator). A Guardian can call revoke(address vault, bytes data) to block the pending Curator action at the vault level (e.g. absolute/relative cap increases).&#x20;

### Immediate vault operations

Non-material actions are executed without a timelock and pass through the Supervisor v2 with no delay.&#x20;

* `setCurator`: appoint or change the Curator.
* `setName`, `setSymbol`: set the vault's ERC-20 metadata.
* `addSentinel`: add Sentinel addresses.&#x20;
* `setSkimRecipient`: set the skim recipient on an adapter.
* `setSupervisorAsSentinel`: to register the Supervisor v2 as a Sentinel on a vault (permissionless).&#x20;

Note: `removeSentinel` reverts on the call, which is what makes the Sentinel role permanent

### Deployments

| Ethereum     | `0x4D7bd498Bb24098Ca281C05519629c605407f71d` |
| ------------ | -------------------------------------------- |
| Base         | `0x639bfA26472906Ccd40513408284a8aD292bC5D6` |
| Arbitrum One | `0xca9f621aAFD28d0F2decFb69Db0d9e6393A9f5ee` |

Explorer links reflect current public explorers; swap in preferred explorers if needed.

### Audit and source

* Audit report (Cantina): [Supervisor v2 audit report](https://github.com/Steakhouse-Financial/vault-v2-supervisor/blob/main/audits/2026-02-23-cantina.pdf)
* Source: [Supervisor v2 Github Repo](http://github.com/Steakhouse-Financial/vault-v2-supervisor)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://steakhouse.financial/docs/products/infrastructure/supervisor-v2.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.