# Vault 7540 mechanics \[How the ERC-7540 vault handles deposits, redemptions, fees, access control, and upgrades]

:::info
In Railnet smart contracts, an Advanced Strategy is implemented as a **Specialized Vehicle**. Its vault implements [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540).
:::

The vault is the capital entry point: deposits, redemptions, share pricing, fees and access control in one contract. [Accounting](/strategies/advanced/accounting) covers running the valuation cycle.

<VaultRoles />

## NAV validity

After each settlement the NAV counts as valid for `totalAssetsLifespan`, and sync operations work while it is. Once it expires, sync deposits revert with `TotalAssetsExpired` and the vault is async-only until the next settlement. The Strategy sets the window with `updateTotalAssetsLifespan(lifespan)` and ends it early with `expireTotalAssets()`.

## Deposits

`syncDeposit(assets, receiver, referral)` mints shares at the current price in one transaction: assets go straight into the Strategy wallet, the entry fee comes out of the minted shares, and the cap is enforced.

`requestDeposit(assets, controller, owner)` works whether or not the NAV is fresh, and is the only path once it has expired. Assets move into the Silo escrow with no shares and no fixed price; `cancelRequestDeposit()` works until the valuation manager's next NAV proposal rolls the epoch. Settlement locks the price, makes the shares claimable and moves the escrowed assets into the Strategy wallet. `deposit()` or `mint()` then releases the shares at the entry fee rate recorded at settlement, not the current one.

One pending request per address: if an older one is already claimable, the vault auto-claims it first. `updateMaxCap(newCap)` (Strategy only) caps vault-wide TVL, not per user — `totalAssets` plus the new deposit plus pending escrow must stay under it, on both paths.

## Redemptions

Async is the default. `requestRedeem(shares, controller, owner)` escrows shares in the Silo; the controller or an approved operator can call `cancelRequestRedeem(controller)` until a NAV proposal rolls the epoch, after which it reverts with `RequestNotCancelable`. Settlement locks the price, burns the escrowed shares and pulls assets from the Strategy into the vault. Investors claim with `redeem()` or `withdraw()`, partially if they want, at the exit fee rate recorded at settlement.

:::warning
Redemption settlement is all-or-nothing. If the Strategy cannot cover every pending redemption at the confirmed price, none settle and they carry to the next cycle.
:::

`syncRedeem(shares, receiver, minimumAssets)` is the instant liquidity buffer: one transaction, exit fee at the current rate, plus a **haircut** on the remainder, converted at the current price and pulled from the Strategy wallet. `minimumAssets` reverts the call if the output falls short. Haircut shares are burned, and the vault subtracts the pre-haircut asset value from `totalAssets`, so the price per share is unchanged at redemption and the retained value accrues to remaining holders at the next valuation. Sync redeem needs the vault open, sync mode including redemptions, a valid NAV and enough liquid assets; it hard reverts when liquidity is short.

## Settlement

Settlement rides along with NAV confirmation; you cannot settle without updating the NAV. `settleDeposit(newTotalAssets)` finalizes the NAV, takes fees, records the epoch's entry and exit rates, turns pending deposits into shares held by the vault, moves escrowed assets to the Strategy, and attempts redemptions too. `settleRedeem(newTotalAssets)` skips deposits. `claimSharesOnBehalf([controllers])` and `claimAssetsOnBehalf([controllers])` let the Strategy push results out instead of waiting for each investor.

## Fees

Every fee except the haircut is minted as shares and split on-chain in the same transaction. The protocol portion, read from the protocol-wide fee registry and capped at 30% of the fee, is Railnet's revenue; the rest goes to the vault's fee receiver, the asset manager's address, which splits it elsewhere.

| Fee | Max rate | Applied |
|---|---|---|
| Management | 10% | at settlement, time-weighted on total assets |
| Performance | 50% | at settlement, only above the high-water mark |
| Entry | 2% | on deposit, sync and async claim |
| Exit | 2% | on redeem, sync and async claim |
| Haircut | 20% | on sync redeem only, burned |

The high-water mark rises after fees are taken and never falls on its own; `resetHighWaterMark()` exists for migrations and only works if enabled at initialization. `updateRates()` changes management and performance freely; entry and exit rates can only be lowered after initial configuration.

## Access control

The vault runs in allowlist or blocklist mode, switched with `switchAccessMode()`. In allowlist mode only approved addresses can deposit or redeem (`addToWhitelist()`, `revokeFromWhitelist()`). In blocklist mode everyone is allowed except blocked addresses (`addToBlacklist()`, `revokeFromBlacklist()`), which also cannot send or receive shares. `setExternalSanctionsList()` adds an oracle such as the Chainalysis OFAC list; an address must then pass both, except the protocol fee receiver and super operator, which always pass. Requests check owner, controller and caller, sync operations check caller and receiver.

## Roles

| Role | Responsibilities |
|---|---|
| Vault owner (admin) | Assign every role below, update fees, pause, switch access mode, `initiateClosing()`, `activateAsyncOnly()` |
| Strategy (Safe) | Confirm NAV, settle queues, set lifespan and sync mode, manage the cap, `close()` |
| Valuation manager | Propose NAV updates |
| Whitelist manager | Manage access lists, set the sanctions list |
| Security Council | Set NAV guardrails, emergency NAV bypass |
| Super operator | Act for any user on claims and requests |
| Fee receiver | Receives the asset manager portion of fees |

The admin sets each address with the matching `update*` call. Ownership transfers in two steps: `transferOwnership(newOwner)`, then `acceptOwnership()`.

## NAV guardrails

The Security Council bounds annualized price-per-share change with `updateGuardrails()` and toggles enforcement with `updateActivated()`. On every `updateNewTotalAssets()` the vault annualizes the change over the elapsed time and rejects proposals outside the bounds; the first update after initialization is exempt. That blocks a compromised valuation manager or a manipulated oracle from repricing the vault. To push an extreme but legitimate move through, the Security Council proposes with `securityCouncilUpdateTotalAssets()`, which skips the check.

## Upgrades

A Delay Proxy Admin deployed alongside the vault enforces a timelock of up to 30 days between proposing and executing an implementation change. Its owner is typically a Railnet and asset-manager quorum, distinct from the vault owner, so neither upgrades unilaterally. New implementations must also be whitelisted in a protocol-wide Logic Registry.

## Next steps

<Cards>
  <Card title="Accounting" description="Run the propose-and-settle NAV cycle." icon="calculator" to="/strategies/advanced/accounting" />

  <Card title="Policy engine" description="What the asset manager may execute." icon="shield-half" to="/strategies/advanced/policy-engine" />

  <Card title="Operate an Advanced Strategy" description="Route protocol calls through it." icon="terminal" to="/strategies/advanced/operate" />
</Cards>