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 recorded in a pending queue until the next accounting sync mints shares.
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 griefing.

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 on three occasions:

1. Accounting sync (submitActions()): a strategist updates the vault strategy or allocation.

2. Queued deposit batch (deposit()): batched deposits are converted to shares using the pre‑sync price to avoid sandwich attacks.

3. Redeem finalisation (redeem()): any asset movements caused by the withdrawal are incorporated before burning shares.

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

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 2 steps:

1. deposit(amount, receiver)

   1. Transfers amount of the accounting asset to the vault.

   2. Records Deposit{amount, receiver, batchId} in storage.

2. finalizeDeposits(batchId) (keeper‑only, open to anyone with an incentive tip)

   1. Calls sync() to lock in a *batchPrice`.

   2. Mints amount / batchPrice shares to each receiver.

   3. Emits DepositFinalised events for indexers.

Users can cancel a queued deposit any time prior to finalisation. They pay the gas, but avoid price drift risk.

Withdrawals

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 strategists, but this action itself is timelocked by the previous timelock.

RequestRedeem

• Burns no shares yet—only records RedeemRequest{shares, owner, receiver, minRedeemTime} where minRedeemTime = block.timestamp + withdrawTimelock.

• Free to cancel or increase shares while pending.

Redeem

After the timelock expires, a user must call redeem() in order to complete the withdrawal process. When redeem is called:

1. Calls sync() to update NAV.

2. Calculates assetsOut = shares × sharePrice.

3. Burns shares from the owner.

4. Transfers assetsOut to the receiver.

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

Events & Frontend Hooks

DepositQueued(address indexed owner, uint256 amount, uint256 batchId);
DepositFinalised(address indexed owner, uint256 shares, uint256 batchId);
RedeemRequested(uint256 indexed requestId, address indexed owner, uint256 shares);
Redeemed(uint256 indexed requestId, address indexed owner, uint256 assets);

Indexers consume these events to surface pending deposits, active withdrawal requests, and real‑time share price in dashboards and portfolio trackers.