> 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/mandate-execution-and-parameters.md). # Mandate, execution and parameters How the curator's mandate bounds strategy execution, how the contracts and venue controls enforce it, and what each vault configures before launch. Curator-bound execution is a core design principle of Curated Vaults. The curator defines the mandate of the vault, and the strategy manager executes within that mandate and holds no control over the base vault logic, which separates product governance from tactical execution. The contracts bound every action taken with vault capital, venue controls extend those bounds to centralized trading venues, and each vault discloses its configuration before launch. ## Curator-bound execution Curator-bound execution works in three layers: the mandate that sets the envelope, the separation of tactical from structural decisions, and the automated circuit breakers that pause the vault when its state breaches a boundary.
Three layers: the curator's mandate with its ten elements bounds the strategy manager, governance roles hold every structural change, and automated circuit breakers pause deposits, withdrawals, allocation or strategy execution on a breach

Curator-bound execution in three layers. The mandate sets the envelope, tactical and structural decisions sit with different roles, and a breach of the envelope pauses the affected functions.

### Mandate and intent The mandate defines the intended risk and strategy envelope of the vault. The curator sets it before launch, and the vault's product page discloses it before subscription. | Element | What it sets | How it is enforced | | ------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Allowed assets | The assets the vault accepts and the strategy can hold | The accepted asset in the vault contract, and the strategy allowlist | | Allowed venues | The exchanges, protocols, accounts or borrowers where capital can be deployed | The strategy allowlist, approved targets and per-vault venue caps | | Allowed strategies | The strategies the vault can allocate to | The strategy allowlist, with strategy kind validation | | Maximum allocation per strategy | The most capital any one strategy can take | Per-strategy and total debt caps on every allocation | | Drawdown threshold | The largest drawdown the mandate tolerates | A breach trips the circuit breakers | | Leverage limit | The most leverage the strategy can take | A breach trips the circuit breakers | | Liquidity requirement | The liquidity the strategy keeps to meet the redemption terms | Capital returned on the redemption schedule, and a circuit breaker on abnormal withdrawal pressure | | Minimum collateralization | The lowest collateral coverage a credit strategy accepts | Coverage below the minimum trips the circuit breakers and the mandate's liquidation policy | | Redemption period | The redemption window, from instant redemption to an epoch schedule | The vault's liquidity configuration and epoch schedule | | Reporting cadence | How often NAV and reports are published | The NAV cadence; settlement accepts no report older than `maxReportAge` | ### Separation of concerns The strategy manager makes tactical decisions inside the mandate: which approved venue to use, how to rebalance within the mandate, when to allocate idle assets within the debt caps and when to return capital for redemptions. Structural changes stay with governance roles, which act through the multisig and, for high-impact changes, the timelock. The strategy manager cannot take seven structural actions, and a separate control blocks each one. | The strategy manager cannot | Why | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Change the vault's accepted assets | The accepted asset lives in the vault contract, outside every strategy manager role | | Bypass investor permissions | The vault checks the access policy on every request, and list changes need the access policy management role | | Exceed allocation quotas | Every allocation is checked against the per-strategy and total debt caps, which only the strategy configuration role sets | | Deploy to unapproved venues | Every call needs an allowed strategy, an approved target and an approved selector | | Alter redemption logic | Redemption runs through the settlement module and the vault's request flow, in contract code that is not upgradeable | | Change oracle policy | Reporter membership, quorum and freshness belong to the oracle roles, and the deviation tolerance to `PRICING_ROLE` | | Remove emergency controls | Pause and unpause are roles of their own, separate from the allocation and execution roles | The roles and their boundaries are set out in [Vault modules and roles](/docs/platform/product-mechanics/how-curated-vaults-work/vault-modules-and-roles.md#participants-and-roles). ### Automated circuit breakers When vault state breaches a predefined boundary, automated controls pause the affected functions: deposits, withdrawals, allocation or strategy execution. Nine triggers trip them.
Nine triggers feed a circuit breaker that pauses any of six pause layers, the global vault, deposits, redemptions, share transfers, strategy allocation and strategy execution, while a separate unpause role resumes them after review

Automated circuit breakers. Any trigger pauses the affected functions at once, and only the separate unpause role resumes them, after review.

| Trigger | What it detects | | ----------------------------------- | -------------------------------------------------------------------- | | NAV deviation beyond policy | A NAV move larger than the vault's deviation policy allows | | Collateralization below the minimum | Collateral coverage in a credit strategy below the mandate's minimum | | Stale oracle data | Oracle data older than the freshness bound | | Unauthorized strategy debt | Strategy debt that the allocation policy did not authorize | | Allocation above quota | Capital at a strategy or venue above its allocation quota | | Abnormal withdrawal pressure | Redemption demand beyond the vault's normal pattern | | Signer quorum failure | A NAV report that fails to reach reporter quorum | | Suspicious transaction patterns | Transaction activity that monitoring flags as suspicious | | Emergency governance action | A pause triggered by governance or the guardian | Pause controls are layered across the global vault, deposits, redemptions, share transfers, strategy allocation and strategy execution, so a breaker pauses only the functions that a breach affects. The strategy manager's allocation pause and execution pause halt allocation or execution on their own. Pause and unpause are separate roles, so emergency response is fast and resumption requires review. Coverage below the minimum collateralization also triggers the mandate's liquidation policy, as set out in [Risk isolation and emergency controls](/docs/security/security-and-risk/risk-isolation-and-emergency-controls.md#liquidation-and-unwind-logic). ## Contract-level bounds The strategy manager module enforces the mandate at contract level, and five bounds apply to every action taken with vault capital. * **Strategy allowlists:** Capital reaches only allowlisted strategies. Each strategy's kind is validated, and each adapter is bound to the vault and its asset through its `vault()` and `asset()` values, so an adapter bound to another vault or asset cannot be used. * **Debt caps:** Every allocation is checked against a per-strategy debt cap and a total strategy debt cap, and the strategy manager records each strategy's current debt. Claimable redemption assets are excluded from `availableIdleAssetsForStrategy`, and pending deposit assets stay excluded until their epoch settles. * **Approved targets and actions:** Every adapter call needs an allowed strategy, an onchain adapter kind, an approved target and an approved selector. The whitelist confers execution rights only, and it grants no right to take or redirect vault assets. * **Balance-delta verification:** After every action, the strategy manager validates the call's return value and the vault's balance delta. * **Atomic revert:** Any failed check reverts the entire transaction, so no partially executed strategy call can exist. Separate roles cover strategy configuration, allocation, execution, verifier management, pause and unpause, so the operator that executes cannot change the caps it executes within. {% hint style="success" %} **Bounded execution:** An action with vault capital completes only when it passes every contract check, and any failed check leaves the vault as it was before the transaction. **Why it holds:** The strategy manager checks the allowlist and the debt caps on every allocation, and an allowed strategy, an onchain adapter kind, an approved target, an approved selector, the return value and the vault's balance delta on every call. Each action executes atomically, so a failure at any check reverts every effect of the transaction. {% endhint %} The contract detail of these controls is set out in [Contract security](/docs/security/security-and-risk/contract-security.md#strategy-and-custody-controls). ## Execution on centralized venues 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. Three controls keep the vault's exposure at the venue bounded and verifiable.
The vault contract allocates capital to a centralized venue within a cap for the vault, the strategy manager trades inside the mandate, an independent attestation provider verifies the assets through a read-only API and shows the results in a user dashboard, and proof of deployment and reserve verification feed reporting

Execution on a centralized venue. Exposure is capped per vault, an independent attestation provider verifies the assets through a read-only API, and proof of deployment and reserve verification add assurance.

* **Independent attestation:** An independent attestation provider verifies the assets held at the venue through a read-only API, and the results are presented in a user-accessible dashboard. The dashboards are listed in [Audits](/docs/security/security-and-risk/audits.md). * **Venue caps:** Exposure to each venue is capped at the vault level and continuously monitored against the mandate, and allocation above quota trips the circuit breakers. * **Proof of deployment and reserve verification:** Proof-of-deployment records and independent reserve verification provide additional assurance over the assets held at the venue, and the NAV process draws on them at its reserve verification step. These controls address counterparty and custody risk, the failure of a trading venue or custodian, which [Security and risk](/docs/security/security-and-risk.md#principal-risks) sets out with the other principal risks. The verification layer that publishes deployment records is set out in [NAV, oracle and proof of deployment](/docs/platform/product-mechanics/how-curated-vaults-work/nav-oracle-and-proof-of-deployment.md#proof-of-deployment). ## Configurable parameters Each vault is configured before launch, and its configuration is disclosed on its product page. Fourteen parameters define it. | Parameter | Description | How it is set and enforced | | -------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Accepted assets | The tokens accepted for deposit | The vault contract; a deposit in any other asset reverts | | Supported networks | The networks where participants can subscribe, hold or redeem | Chain abstraction: requests from supported networks reach the vault on its execution network through cross-chain messaging | | Minimum deposit | The smallest subscription the vault accepts | `minDepositAssets` in the limit module, with `minRedeemShares` for the smallest redemption | | Vault capacity | The maximum total deposits or assets under management | `maxTotalAssets` and `maxPendingDepositAssets` in the limit module | | Investor eligibility | Jurisdiction, accreditation, allowlist or other access rules | The access policy in open or policy mode, with allowlists, denylists or signed authorizations; the whitelist manager maintains KYC- or KYB-gated lists | | Management fee | The ongoing fee charged by the vault, within the fee cap | The fee manager, on assets under management, within its hard cap | | Performance fee | The fee on new profits above the high-water mark, within the fee cap | The fee manager, within its hard cap, with the high-water mark on assets per share | | Strategy whitelist | The approved strategies, accounts, borrowers or venues | The strategy allowlist, approved targets and approved selectors, set by the strategy configuration role | | Allocation quotas | The maximum capital assigned to each strategy or venue | Per-strategy and total debt caps, and per-vault venue caps | | Redemption window | Instant from idle liquidity, or daily, weekly, monthly, T+7, T+30 or another epoch schedule | The vault's liquidity configuration and epoch schedule | | NAV cadence | The frequency of NAV updates and reporting | The valuation process, with `maxReportAge` as the freshness bound at settlement | | Oracle quorum | The number and type of signers required for NAV publication | The enabled reporters and the quorum in the report oracle, governed by the oracle roles | | Deviation threshold | The maximum NAV change accepted before review or pause | `maxNavPriceDeviationBps`, at most 10,000 bps, set by `PRICING_ROLE` | | Emergency controls | The conditions under which vault activity can be paused | The circuit breakers and the layered pause flags, with separate pause and unpause roles | Each parameter lives in the module that enforces it, under the role that governs it. Sensitive governance actions need the three-of-five multisig, and high-impact changes also pass through the timelock, whose default delay is 24 hours, so participants can observe a queued change before it takes effect. Entry and exit fees can only decrease once the vault is initialized, and no parameter change reaches an epoch that has already settled. Fees are set out in [Fees](/docs/platform/product-mechanics/fees.md), and the module that holds each parameter in [Vault modules and roles](/docs/platform/product-mechanics/how-curated-vaults-work/vault-modules-and-roles.md#policy-controller). ## Example vault templates Three example configurations show how the parameters combine for different strategies. They are implementation templates: each live vault sets its own configuration and discloses it on its product page. The vault types they draw on are set out in [Vault modules and roles](/docs/platform/product-mechanics/how-curated-vaults-work/vault-modules-and-roles.md#vault-types). ### RWA-backed lending vault template An RWA-backed lending vault uses a stablecoin funding currency to finance secured private credit positions. | Field | Example configuration | | ------------------------- | ------------------------------------------------------------------------ | | Funding currency | Stablecoin | | Collateral type | Digital-asset loan receivables or RWA-backed receivables | | Collateralization target | 150% | | Minimum collateralization | 120% | | Capacity | A defined vault-level cap | | Liquidity | Monthly or scheduled redemption | | Verification | An independent data verification network | | Reporting | Collateral coverage, reserve reports, NAV history and settlement records | **Suited to:** Products whose main risk control is collateral coverage and continuous verification of assets and liabilities. Coverage below the 120% minimum trips the circuit breakers and the mandate's liquidation policy. ### Statistical arbitrage vault template A statistical arbitrage vault allocates capital to a systematic, market-neutral strategy across approved centralized and decentralized venues. | Field | Example configuration | | --------------- | ------------------------------------------------------------------------------ | | Accepted asset | An approved stablecoin | | Minimum deposit | Configured per product | | Approved venues | Selected exchanges or DeFi protocols | | Redemption | Weekly, T+7 or a product-specific cycle | | NAV per share | NAV divided by the Receipt Tokens outstanding | | Management fee | Configured per vault | | Performance fee | Configured per vault | | Controls | Drawdown limits, leverage limits, a venue whitelist and strategy debt tracking | **Suited to:** Products whose main risk control is mandate enforcement and real-time strategy monitoring. ### Market-neutral managed-account template A managed-account strategy issues no freely transferable share token, and it uses Vault as a Service for reporting, subscription handling, proof of deployment and redemption tracking. | Field | Example configuration | | -------------------- | ----------------------------------------------------------------------------- | | Base assets | Approved stablecoins, bitcoin, ether or other approved assets | | Structure | A managed account or a separately managed account (SMA) | | Reporting | Monthly statements, account-level reporting and an anonymized equity curve | | Liquidity | A monthly cycle with a notice period | | Emergency withdrawal | An optional accelerated path, subject to settlement conditions | | Monitoring | Account-level NAV, venue exposure, strategy performance and withdrawal status | **Suited to:** Institutional strategies that need onchain access and verification without becoming a fully public tokenized share product.