# Configuring a Vault

Vault configuration can be set when deploying a vault. It can also be updated once the vault is deployed. To update the vault, you must get the selector and encode it with parameters provided to `submitActions()`.  Global timelocks are applied to several configuration updates. The guardian can veto any upgrade during the timelock period.

| Configuration                  | Set by |
| ------------------------------ | ------ |
| diamondCut                     | Owner  |
| transferCuratorship            | Owner  |
| transferGuardian               | Owner  |
| transferOwnership              | Owner  |
| disableDepositWhitelist        | Owner  |
| enableAssetToDeposit           | Owner  |
| setGasLimitForAccounting       | Owner  |
| setMaxSlippagePercent          | Owner  |
| setTimeLockPeriod              | Owner  |
| setFee                         | Owner  |
| setWithdrawalTimelock          | Owner  |
| setWithdrawalFee               | Owner  |
| updateWithdrawalQueueStatus    | Owner  |
| setCrossChainAccountingManager | Owner  |
| setOraclesCrossChainAccounting | Owner  |

## Adding or Removing Facets

The Vault Owner can decide which protocol and strategy facets to activate by calling `diamondCut()`  and specifying `facetAddress` and  `FacetCutAction`.

```
function diamondCut(FacetCut[] calldata _diamondCut) external;
```

with array of struct `FacetCut[]`,

```
struct FacetCut {
        address facetAddress;
        FacetCutAction action;
        bytes4[] functionSelectors;
        bytes initData;
}

enum FacetCutAction {
        Add,
        Replace,
        Remove
    }

// Add=0, Replace=1, Remove=2
```

When adding facets, you must verify that the facet exists in the Vault Registry.

## Available Assets

Available assets are the assets that can be managed by the Curator. Available assets can be added only if an Oracle Registry contains an oracle for the specified asset. Either the Vault Owner or Curator can add available assets.

```
function addAvailableAsset(address asset)
```

{% hint style="info" %}
Once an available asset is added, it cannot be removed.
{% endhint %}

Available assets are subject to gas limit overflow checks to ensure that operations do not exceed max block limits or bounds set by the Vault Owner. Gas limit checks are described further in [Risk Management](#risk-management).

## Depositable Assets

Depositable assets include any asset that can be accepted by the vault from depositors. It must first be enabled as an available asset before it can be enabled as a depositable asset. Vault Owners and Curators can add or remove a depositable asset. 

{% hint style="info" %}
These assets are not subjected to gas limits like available assets.
{% endhint %}

#### Add a depositable asset

```
function enableAssetToDeposit(address asset) external
```

#### Remove a depositable asset

```
function disableAssetToDeposit(address asset) external
```

## Risk Management

### Max Slippage Percent

The max slippage percentage defines the bounds for the maximum acceptable loss upon `executeActions()`, when a portfolio allocation or rebalance is executed. If this bound is exceeded, the transaction will revert. Only Vault Owner can modify this parameter.

```
function setMaxSlippagePercent(uint256 _newPercent) external
```

### Gas Limit for Accounting

The gas limit parameter ensures that vault operations remain under an acceptable threshold. By default, the gas limit is set to the block gas limit, 30,000,000 on most chains. Either the Vault Owner or Curator can set this parameter.

The gas limit is set for each available asset, `_availableTokenAccountingGas`, each held token, `_heldTokenAccountingGas` (e.g. LP tokens, ATokens, CTokens, debt tokens, etc.) and each facet, `_facetAccountingGas`. `_newLimit` specifies the total gas limit for total accounting. 

```
function setGasLimitForAccounting(
   uint48 _availableTokenAccountingGas,
   uint48 _heldTokenAccountingGas,
   uint48 _facetAccountingGas,
   uint48 _newLimit
) external
```

### Deposit Capacity

Vault Owners or Curators can set a global supply cap for the vault. This can support scaling new strategies or when coupled with a whitelist create competitive dynamics for liquidity provisions.

The deposit capacity sets a maximum allowance for total deposits across all depositors, specified in terms of the `UNDERLYING_ASSET`.

```
function setDepositCapacity(uint256 capacity) external
```

{% hint style="info" %}
Depositor whitelists are not directly related to the global deposit capacity. Deposit capacity will apply regardless of per user deposit capacities specified in whitelists.
{% endhint %}

## Depositor Whitelists

Both Vault Owners and Curators can enable or disable whitelists. Users can only deposit if their address is included on the whitelist. Each user can have a specific deposit capacity.

#### To enable the whitelist

```
function enableDepositWhitelist() external
```

#### To disable the whitelist

```
function disableDepositWhitelist() external
```

#### To updae the whitelist

```
function setDepositWhitelist(
    address[] calldata depositors,
    uint256[] calldata underlyingAssetCaps
) external
```

## Timelocks

### Global Timelock

Only the Vault Owner can set or update the global timelock. This parameter configures the the timelock between `submitActions()` and `executeActions()`. These functions are described in [Allocate & Rebalance](https://docs.more.markets/more-vaults/developer-workflows/allocate-and-rebalance).

#### Specify the global timelock in seconds

```
function setTimeLockPeriod(uint256 period) external
```

### Withdrawal Timelock

For asynchronous withdrawals, the withdrawal timelock sets the minimum duration that should elapse between `requestRedeem()` and `redeem()` or `requestWithdraw()` and `withdraw()`. The withdrawal timelock can be set by the Vault Owner or Curator, and is itself subject to the global timelock.

#### Specify the withdrawal timelock in seconds

```
function setWithdrawalTimelock(uint64 _duration) external
```

## Fees

Currently, only performance fees can be collected in a vault. Performance fees accrue on generated profit and are realized when a user redeems or withdraws. No fees are taken on negative profit.

#### Set the performance fee

```
function setFee(uint96 _fee) external
```

#### Set the fee recipient

```
function setFeeRecipient(address recipient) external
```

{% hint style="info" %}
While the protocol does not currently take fees, in the future, the DAO can vote to activate the fee switch. When the fee switch is activated, a portion of vault fees accrue to the protocol treasury.
{% endhint %}

## Transfer Roles

Any of the vault roles can be transferred. Only the Vault Owner may execute these actions. A Vault Owner may want to bring on a new strategist or recruit a new Guardian. The Vault Owner may also want to transfer the ownership of the vault to an acquiring party. In any of these cases, updates are subject to the global timelock, giving LPs an opportunity to exit if they disagree with the decision.

### Transfer Owner

Ownsership transfer occurs in 2 steps. The current Vault Owner must initiate the transfer and the new Vault Owner must accept it. Ownership remains with the current Vault Owner until the transfer is accepted. 

#### Initiate ownership transfer

```
function transferOwnership(address _newOwner)
```

#### Accept ownership transfer

```
function acceptOwnership() external
```

### Transfer Curator

A Vault Owner may replace a Curator.

```
function transferCuratorship(address _newCurator) external
```

### Transfer Guardian

A Vault Owner may replace a Guardian.

```
function transferGuardian(address _newGuardian) external
```