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.

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.