> For the complete documentation index, see [llms.txt](https://city-protocol.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://city-protocol.gitbook.io/docs/platform/product-mechanics/how-curated-vaults-work.md).

# How Curated Vaults work

Contract design, epoch settlement, NAV and bounded strategy execution in a Curated Vault.

## Contract design

The Curated Vault contracts implement tokenized-vault share accounting with asynchronous request flows, following the [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626), [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540) and [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575) interface standards. Each vault is its own set of contracts with its own mandate, and every action executes atomically: a deposit, redemption, settlement or strategy execution either passes every check or reverts as a whole.

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FlQfytw6DO9aKSE56LG8t%2Ffig-vault-modules.png?alt=media&amp;token=4e0ff5d2-0e13-42f3-a792-9a200a6ab448" alt="The vault contract surrounded by its access policy, limit module, report oracle, settlement module, fee manager, strategy manager and vault registry"><figcaption><p>Each Curated Vault is its own set of contracts, with the vault contract at the centre and one module for each control.</p></figcaption></figure>

| Module            | Function                                                                                                                                              |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Vault contract    | Accepts deposits and redemption requests, issues and burns Receipt Tokens and enforces the core vault rules, in one of four liquidity configurations. |
| Access policy     | Runs in open mode or policy mode, with allowlists, denylists or signed authorizations bound to the account, the vault, the network and an expiry.     |
| Limit module      | Enforces the configured caps on total assets and pending deposits, and any configured minimum deposit or redemption size.                             |
| Report oracle     | Accepts NAV reports only from authorized reporters under a configurable quorum, with freshness, epoch-timing and price-deviation checks.              |
| Settlement module | Prices each epoch against an eligible NAV report, snapshots the price, fees and protocol split, and makes settled amounts claimable.                  |
| Fee manager       | Accrues fees within hard caps and mints them as vault shares to the fee receiver.                                                                     |
| Strategy manager  | Allocates idle assets to allowlisted strategies within per-strategy and total debt caps, executing only approved actions on approved targets.         |
| Vault registry    | Records each vault's address, asset, strategy manager, oracle, type and status as the canonical discovery source.                                     |

## Subscription, settlement and redemption

Subscriptions and redemptions run in epochs, so every request in an epoch settles at one valuation point on the same terms.

{% stepper %}
{% step %}

### Request

The participant deposits an accepted asset or transfers Receipt Tokens for redemption, and the vault checks access, limits, product status and pause state.
{% endstep %}

{% step %}

### Epoch close

At the end of the window, the epoch closes to new requests.
{% endstep %}

{% step %}

### Valuation

The valuation provider proposes the NAV and authorized reporters sign it. The report takes effect only when it meets quorum and passes the freshness, timing and deviation checks.
{% endstep %}

{% step %}

### Settlement

The settlement module prices the epoch and snapshots the report identifier, price, fees, protocol split and timestamp. Deposits mint Receipt Tokens, and redemptions fix the settlement assets owed.
{% endstep %}

{% step %}

### Claim

Once idle settlement assets cover the whole epoch, participants claim, and redeemed Receipt Tokens are burned.
{% endstep %}
{% endstepper %}

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FOTiTWghP3uzuJ6OiOfFH%2Ffig-epoch.png?alt=media&amp;token=f2aa0c15-ed12-4014-ad0b-746f8cc089b9" alt="Request, epoch close, valuation, settlement and claim"><figcaption><p>Epoch-based subscription and redemption. Every request in an epoch settles at one valuation point.</p></figcaption></figure>

Deposit requests can be cancelled before settlement where the configuration allows it, and redemption requests are final once submitted. Vaults with highly liquid assets also offer liquid redemption from idle liquidity.

## NAV and share price

At a valuation point $$t$$, NAV and the share price are

$$
\mathrm{NAV}\_t = A\_t - L\_t - F\_t, \qquad P\_t = \frac{\mathrm{NAV}\_t}{N\_t}
$$

where $$A\_t$$ is the verified value of the vault's assets, $$L\_t$$ its liabilities, $$F\_t$$ its accrued fees and $$N\_t$$ the Receipt Tokens outstanding. Liquid onchain strategies derive NAV from onchain positions and price feeds; RWA-backed and offchain strategies draw on administrator reports, reserve data, collateral values and third-party verification.

Two properties of settlement protect every participant in an epoch.

{% hint style="success" %}
**Settlement finality:** Once an epoch has settled, no later NAV report, fee change or strategy event alters the Receipt Tokens minted or the settlement assets owed for that epoch.

**Why it holds:** Every claim on the epoch derives from the settlement snapshot of report identifier, price, fees, protocol split and timestamp. Later reports, fee changes and strategy events update state that settled claims do not read.
{% endhint %}

{% hint style="success" %}
**Funded claims:** A redemption claim becomes payable only when the vault holds idle settlement assets for the entire settled epoch, and assets reserved for claims cannot be allocated to a strategy.

**Why it holds:** The settlement module marks an epoch fulfilled only after verifying that idle settlement assets cover it. Claimable redemption assets are excluded from the assets available to the strategy manager, so no allocation can draw on them.
{% endhint %}

## Strategy execution

The curator defines the mandate: allowed assets, venues and strategies, allocation limits, drawdown threshold, leverage limit, liquidity requirement, minimum collateralization and redemption period. The strategy manager makes tactical decisions inside that envelope, while structural changes stay with governance roles. Execution is bounded at contract level through strategy allowlists, debt caps, approved targets and actions, and balance-delta verification after every action; the whitelist confers execution rights only.

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2Fhg6hToJwGHPhExK3AAuA%2Ffig-mandate.png?alt=media&amp;token=47766840-6a93-46f3-a789-2b721aec4347" alt="The curator&#x27;s mandate bounds the strategy manager, which executes only approved actions on approved targets within debt caps"><figcaption><p>Curator-bound execution. The strategy manager acts only inside the curator's mandate, and any other call reverts.</p></figcaption></figure>

When a mandate is executed on a centralized trading venue, City Protocol uses an independent attestation provider to verify the assets through a read-only API and presents the results in a user-accessible dashboard. Exposure to each venue is capped at the vault level and continuously monitored against the mandate. Proof-of-deployment records and independent reserve verification provide additional assurance over the assets held at the venue.

## Configurable parameters

Each vault is configured before launch, and its configuration is disclosed on its product page.

| Parameter            | Description                                                                                  |
| -------------------- | -------------------------------------------------------------------------------------------- |
| Accepted assets      | The tokens accepted for deposit.                                                             |
| Supported networks   | The networks where participants can subscribe, hold or redeem.                               |
| Minimum deposit      | The smallest subscription the vault accepts.                                                 |
| Vault capacity       | The maximum total deposits or assets under management.                                       |
| Investor eligibility | Jurisdiction, accreditation, allowlist or other access rules.                                |
| Management fee       | The ongoing fee charged by the vault, within the fee cap.                                    |
| Performance fee      | The fee on new profits above the high-water mark, within the fee cap.                        |
| Strategy whitelist   | The approved strategies, accounts, borrowers or venues.                                      |
| Allocation quotas    | The maximum capital assigned to each strategy or venue.                                      |
| Redemption window    | Instant from idle liquidity, or daily, weekly, monthly, T+7, T+30 or another epoch schedule. |
| NAV cadence          | The frequency of NAV updates and reporting.                                                  |
| Oracle quorum        | The number and type of signers required for NAV publication.                                 |
| Deviation threshold  | The maximum NAV change accepted before review or pause.                                      |
| Emergency controls   | The conditions under which vault activity can be paused.                                     |

Fees and their caps are set out in [Fees](/docs/platform/product-mechanics/fees.md), and the contract-level controls in [Contract security](/docs/security/security-and-risk/contract-security.md).

## In depth

{% content-ref url="/pages/8dD9Z0ewaUJ8mk199QzL" %}
[Vault modules and roles](/docs/platform/product-mechanics/how-curated-vaults-work/vault-modules-and-roles.md)
{% endcontent-ref %}

{% content-ref url="/pages/7suWCxXBYmiHC78CC7IM" %}
[Deposits, capital flow and redemption](/docs/platform/product-mechanics/how-curated-vaults-work/deposits-capital-flow-and-redemption.md)
{% endcontent-ref %}

{% content-ref url="/pages/9Yt8pBEM8qN7Z0D73CZh" %}
[NAV, oracle and proof of deployment](/docs/platform/product-mechanics/how-curated-vaults-work/nav-oracle-and-proof-of-deployment.md)
{% endcontent-ref %}

{% content-ref url="/pages/1mGOt3bXtJGnpcCCHMHs" %}
[Mandate, execution and parameters](/docs/platform/product-mechanics/how-curated-vaults-work/mandate-execution-and-parameters.md)
{% endcontent-ref %}