> For the complete documentation index, see [llms.txt](https://docs.origami.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.origami.finance/the-third-fold-opal/how-does-an-opal-vault-work.md).

# How Does an OPAL Vault Work?

OPAL vaults manage a live balance sheet of asset and liability positions across multiple protocol integrations. This page explains the core mechanics: the adapter layer, the allocation engine, atomic rebalances, and vault share behaviour.

### The Adapter Layer

#### What Is an Adapter?

An *adapter* is a dedicated smart contract deployment that encapsulates one specific position in one external protocol. Each adapter exposes a standardised interface to the vault manager (`OpalManager`) for reading its state and executing operations.

Adapters are not routing contracts or general-purpose integrations. Each adapter is scoped to a single position with a fixed token configuration.

#### Adapter Types

<figure><img src="/files/jT8LTgJmt3LKK3VX6hpP" alt=""><figcaption></figcaption></figure>

A single OPAL vault can register multiple adapters of different types simultaneously.

#### Live Health Metrics

Every adapter continuously exposes three health metrics to `OpalManager`:

* `currentLtv()` : the current Loan-to-Value ratio of the position
* `liquidationLtv()` : the LTV threshold at which the position becomes subject to liquidation
* `healthFactor()` : the ratio of liquidation LTV to current LTV

These are live reads from the underlying protocol, not cached or periodic snapshots. `OpalManager` uses these metrics to detect when a position is approaching unsafe territory and to trigger corrective action via a managed rebalance.

#### Immutable Configuration

Adapter configuration is encoded as immutable arguments in the contract bytecode at deployment, read at runtime via `ClonesImmutableReader`. The following parameters are fixed permanently at deployment:

* The `OpalManager` instance the adapter belongs to
* The protocol integration target (Aave V3 pool, Morpho market, etc.)
* The token configuration (collateral tokens, debt tokens, aToken pairs)
* Protocol-specific parameters (market ID, oracle address, interest rate model)

The following parameters are governance-adjustable by Elevated Access:

* EMODE category settings (Aave V3)
* `maxSafeLtv` (Morpho): the conservative LTV ceiling below liquidation LTV
* Max loan utilisation ratio on `join` operations
* Collateral usage flags (Aave V3)

If a position's token composition needs to change e.g., to accommodate a new PT market or to include a new money market pool, a new adapter is deployed with updated immutable arguments, capital is migrated atomically, and the old adapter is deprecated. A history of all active and deprecated vault adapters for a given OPAL vault can be viewed on-chain.

{% hint style="warning" %}
Every adapter's complete configuration is permanently readable from its deployed bytecode. Auditors and integrating protocols can verify any adapter's parameters by inspecting the bytecode directly.
{% endhint %}