# Shares

MORE Vault shares are standard ERC‑20 tokens that represent a pro‑rata claim on the vault’s Net Asset Value (NAV). The generic core mints and burns shares. Strategy facets only book gains or losses that flow into the NAV calculation.

How deposits and withdrawals are handled at a glance:

| Deposits    | Assets are transferred to the vault and in return newly minted shares are transferred to the user.                                                                                                        |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Withdrawals | A two‑step process, `requestRedeem()` then `redeem()`, guarantees withdrawal price integrity, provides strategists with a timelock window for exiting positions and defends against flash‑loan arbitrage. |

## Share Price

The share price of all MORE Vaults is expressed in the vault’s underlying accounting asset, defined at vault creation.

```
sharePrice = totalAssets / totalSupply
```

The core recalculates `sharePrice` in real-time. It is updated:

1. **Upon reallocation or reabalance** `submitActions()`: the composition of the vault and its assets are updated on third party protocols.
2. **Upon passive yield generation** `totalAssets()`: as rewards or yield accrues, a view function accounts for profit or loss automatically.

## Deposits

Strategists may choose how deposits are handled on a per-vault basis. Most choose to batch deposits for two reasons:

* Prevent MEV: depositors cannot front‑run a strategy rebalance to scoop a free NAV increase.
* Reduce gas: hundreds of deposits mint in one loop rather than individually.

Deposits are handled in a single step, but may be handled in two ways:

1. Deposit `deposit(amount, receiver)` in underlying asset,
2. Deposit in any asset `deposit(address[] tokens, uint256[] assets, address receiver)` if the assets are enabled as depositable. Depositors can specify an array of tokens and amounts `assets`.

Rounding follows ERC‑4626 guidelines – round‑down for mints, round‑up for burns – to ensure the vault never over‑issues claims.

## Withdrawals

Withdrawals can only be initiated for the underlying asset. The vault separates intent from settlement to protect long‑term LPs.

### Timelock

Every vault owner specifies `withdrawTimelock` (e.g., 4 hours) upon vault creation. Once a new strategy facet is added or a strategy update occurs, withdrawals remain open so users can exit. Timelocks can be updated by Vault Owners or Curators, but this action itself is timelocked by the previous timelock.

### RequestRedeem

* Burns no shares yet — only records `RedeemRequest{shares, owner, minRedeemTime}` where `minRedeemTime` = `block.timestamp` + `withdrawTimelock`.
* Free to cancel or increase shares while pending.
* If withdrawal amount is increased during the timelock, the previous request is canceled and the withdrawal timelock resets.

### Redeem

After the timelock expires, a user must call `redeem(uint256 shares, address receiver, address owner)` in order to complete the withdrawal process. When redeem is called:

1. Calculates `assetsOut = shares × sharePrice`.
2. Burns `shares` from the owner.
3. Transfers `assetsOut` to the receiver.

If the vault’s liquid balance < `assetsOut`, the transaction reverts.

{% hint style="info" %}
Because redemptions are handled in shares, a change in share price during the timelock and before the `redeem()` action is called, may result in a change in the redeemable amount of the underlying asset.
{% endhint %}