The 7540 Vault is the capital entry point for every Advanced Strategy. It implements the ERC-7540 standard handling deposits, redemptions, share pricing, fee collection, and access control through a single contract.This page covers the vault’s internal mechanics. For a high-level overview of how the vault fits into the Advanced Strategy architecture, see Advanced Strategies.
The vault automatically selects between sync and async deposit paths based on NAV validity. After each settlement, the NAV is considered valid for a configurable time window (totalAssetsLifespan). While valid, the vault has a reliable exchange rate and can process instant operations. Once the window expires, the vault can no longer guarantee a fair price — deposits are queued until the next valuation cycle.
When the NAV is valid, investors can deposit and receive shares instantly in a single transaction by calling syncDeposit(). The share price is computed using the vault’s current NAV — no waiting, no claim step.Sync deposits:
Transfer the deposited assets directly into the Strategy wallet (the Safe multisig that holds the fund’s capital)
Mint shares to the investor at the current price
Deduct an entry fee (if configured) from the minted shares
When the NAV has expired, deposits switch to the async path. This is a multi-step flow:
Request — The investor calls requestDeposit(assets, controller, owner). Assets move into the Silo escrow (a separate holding contract). No shares are minted yet, and the share price is not fixed.
Wait — The request stays pending until the next NAV cycle. The investor can cancel during this window by calling cancelRequestDeposit(), as long as the epoch hasn’t rolled.
Settlement — The valuation manager proposes a NAV, the Strategy confirms and settles. The share price is locked at this point, shares become claimable, and the deposited assets move from the Silo into the Strategy wallet.
Claim — The investor calls deposit() or mint() to receive their shares. An entry fee is deducted using the rate that was active at settlement time — not the current rate — protecting investors from fee changes between settlement and claim.
Each address can only have one pending deposit request at a time. If a previous request from an older epoch is already claimable, the vault auto-claims it before accepting a new request.
The vault can enforce a maximum deposit limit at the vault level via updateMaxCap(newCap) (Strategy-only). This is a global cap on total TVL — not per user. The check compares totalAssets + new deposit + pending deposits in escrow against the cap. It is enforced on both syncDeposit() and requestDeposit(). If a deposit would push the vault above the cap, it reverts.
Redemptions follow the same NAV validity model as deposits — sync redemptions require a valid NAV, while async redemptions can be requested at any time regardless of NAV status. However, unlike deposits, async redemption requests are not gated by NAV expiration — investors can submit a request whether the NAV is fresh or expired.
Async redemptions are the default withdrawal path. The flow mirrors async deposits:
Request — The investor calls requestRedeem(shares, controller, owner). Shares move into the Silo escrow. The redemption price is not fixed yet.
Wait — The request stays pending until the next NAV cycle. Unlike deposit requests, redemption requests cannot be canceled.
Settlement — The Strategy confirms the NAV and settles. The redemption price is locked, the escrowed shares are burned, and the equivalent assets are pulled from the Strategy wallet into the vault — provided the Strategy holds enough liquid assets.
Claim — The investor calls redeem() or withdraw() to receive their assets from the vault. An exit fee is deducted using the rate recorded at settlement time. Partial claims are allowed.
Sync redemptions allow investors to exit the vault instantly in a single transaction, without going through the async request/settle/claim cycle. This creates an instant liquidity buffer for platforms and investors that need immediate withdrawals.When an investor calls syncRedeem(shares, receiver, minimumAssets), the vault:
Deducts an exit fee from the shares (collected as fee shares, split with the protocol)
Applies a haircut fee on the remaining shares — these shares are burned, not collected by anyone. This raises the price-per-share for all remaining holders, creating an economic disincentive for instant withdrawals that benefits patient investors.
Converts the net shares to assets at the current price
Pulls those assets directly from the Strategy wallet and transfers them to the receiver
The minimumAssets parameter provides slippage protection — if the computed output falls below this threshold, the transaction reverts.Prerequisites for sync redemptions:
The vault must be open (not closing or closed)
The sync mode must include redemptions
The NAV must be valid (not expired)
The Strategy must hold enough liquid assets to cover the redemption
Unlike async redemption settlement (which silently defers when the Strategy lacks funds), sync redeem hard reverts if the Strategy doesn’t have enough liquid assets. There is no graceful fallback.
The vault’s Net Asset Value (NAV) determines share pricing for every operation. NAV updates follow a two-phase commit designed to separate the valuation responsibility from the settlement authority.
The valuation manager calls updateNewTotalAssets(newTotalAssets) to propose a new NAV. This function:
Snapshots all pending deposit and redemption requests from the escrow (Silo)
Creates an epoch boundary — all requests submitted before this point are included in this settlement batch
Stores the proposed value for the Strategy to confirm
This function can only be called when the current NAV has expired. If the NAV is still valid, the call reverts. The Strategy can force expiration at any time by calling expireTotalAssets().
If NAV guardrails are active, the proposed value is validated against the price-per-share bounds before being accepted.
The Strategy confirms the proposed NAV by calling either settleDeposit(newTotalAssets) or settleRedeem(newTotalAssets). The value passed must exactly match what the valuation manager proposed. This function:
Finalizes the NAV into the vault’s totalAssets
Takes management and performance fees (minting fee shares)
Records the current entry and exit fee rates for the settlement epoch
Refreshes the NAV validity window — sync operations become available again until the new expiration
Settlement cannot happen without a prior valuation proposal. The two-phase design ensures that no single role can both propose and finalize a NAV — the valuation manager proposes, and the Strategy confirms.
After settlement, the NAV remains valid for a configurable lifespan (totalAssetsLifespan). During this window, sync deposits and sync redemptions are available. Once the lifespan expires, the vault switches to async-only mode until the next NAV cycle.The Strategy can update the lifespan via updateTotalAssetsLifespan(lifespan), or force immediate expiration via expireTotalAssets() to trigger async mode on demand.
Settlement is the process of converting pending requests into claimable shares (for deposits) or claimable assets (for redemptions). It always happens as part of the NAV confirmation step — there is no way to settle without updating the NAV.
When the Strategy calls settleDeposit(newTotalAssets), the vault:
Finalizes the NAV and takes fees
Converts pending deposit assets into shares at the newly confirmed price
Mints those shares to the vault contract (held until users claim)
Moves the deposited assets from the Silo escrow to the Strategy
Attempts to settle pending redemptions as well (best-effort)
After settlement, depositors can claim their shares via deposit() or mint().
The Strategy can also push shares to users directly by calling claimSharesOnBehalf([controllers]), which batch-claims for multiple depositors without requiring each user to submit a transaction.
When the Strategy calls settleRedeem(newTotalAssets), the vault:
Finalizes the NAV and takes fees
Converts pending redemption shares into the equivalent asset amount at the confirmed price
Checks whether the Strategy holds enough liquid assets to cover the full redemption amount
If sufficient — burns the escrowed shares and pulls assets from the Strategy into the vault for claiming
If insufficient — the redemption settlement is skipped entirely (no partial fills)
After settlement, redeemers can claim their assets via redeem() or withdraw(). The Strategy can also batch-claim via claimAssetsOnBehalf([controllers]).
Redemption settlement is all-or-nothing. The Strategy must hold enough liquid assets to cover all pending redemptions at the confirmed price. If liquidity is insufficient, no redemptions are settled in that cycle — they carry over to the next NAV update.
The vault collects fees at settlement time and during sync operations. All fees flow to a single fee receiver address, with a protocol fee split applied across all fee types.
Management fees accrue based on total assets under management and time elapsed since the last settlement. They are proportional to AUM and the configured annual rate.Performance fees are charged only when the price-per-share exceeds the high-water mark (HWM) — ensuring fees are only taken on net new gains. After fees are collected, the HWM is updated if the current price-per-share is higher. The HWM never decreases under normal operation, but the Strategy can reset it via resetHighWaterMark() if enabled at initialization (useful for vault migrations).Entry and exit fees are recorded per settlement epoch. When an investor claims shares or assets, the fee rate used is the one that was active at the time of settlement — not the current rate. This protects investors from fee changes between settlement and claim.Haircut fees are unique to sync redemptions. The haircut shares are burned rather than collected, which reduces total supply and increases the price-per-share for remaining holders.
All vault fees are sent to a single fee receiver address on-chain. The Fee Splitter is an off-chain module that distributes the collected fees proportionally between the Asset Manager and Railnet. The split ratio is configured per strategy and applied automatically — the Asset Manager receives their share of management, performance, entry, and exit fees, while Railnet receives its portion as a protocol fee.
The whitelist manager manages blocked addresses using addToBlacklist() and revokeFromBlacklist(). Blocklisted addresses cannot deposit, redeem, or transfer vault shares — both sending and receiving are restricted.
The vault can integrate with an external sanctions oracle (e.g., Chainalysis OFAC sanctions list) via setExternalSanctionsList(). When configured, an address must pass both the internal access check and the external sanctions check to be allowed.
The vault owner (admin) is set at initialization and has exclusive control over the vault’s configuration. The admin manages roles, fee rates, access control, and vault lifecycle — but cannot move funds or execute strategy operations.
The admin updates fee rates via updateRates(). Management and performance rates can be changed freely. Entry and exit rates can only be decreased after initial configuration — protecting investors from fee increases post-deployment.
Ownership uses a two-step transfer pattern for safety — the current owner calls transferOwnership(newOwner), and the new owner must explicitly call acceptOwnership() to complete the transfer. This prevents accidental transfers to incorrect addresses.
A Security Council role sets upper and lower bounds on annualized price-per-share changes via updateGuardrails(). When the valuation manager calls updateNewTotalAssets(), the vault:
Computes the current price-per-share and the proposed price-per-share
Annualizes the change based on time elapsed since the last update
Rejects the proposal if the annualized change exceeds the upper bound or falls below the lower bound
The Security Council can activate or deactivate guardrails at any time. The first NAV update after vault initialization is always exempt.
In extreme market scenarios where guardrails would block a legitimate NAV update, the Security Council can call securityCouncilUpdateTotalAssets() to propose a NAV without guardrails checking. This bypasses the price-per-share bounds entirely.
The 7540 Vault is an upgradeable proxy contract. A Delay Proxy Admin is deployed alongside each vault at creation, enforcing a mandatory timelock (up to 30 days) between proposing and executing any implementation upgrade. The Delay Proxy Admin owner can be different from the vault owner — typically a quorum consisting of Railnet and the Asset Manager — so that no single party can upgrade the vault unilaterally. New implementations must also be whitelisted in a protocol-wide Logic Registry before any upgrade can proceed.
