# Security & Audits

City Protocol's vault infrastructure is designed for teams integrating professionally managed onchain asset products. The system separates standard user-facing vault flows from the control plane that governs settlement, pricing, access policy, fees, strategy allocation, and registry discovery. Integrators can build against familiar vault interfaces while relying on contract-enforced controls for permissions, accounting, valuation inputs, emergency response, and monitoring.

The primary security invariant is that no single operational action should silently change user economics. Deposits, redemptions, fee accrual, NAV updates, and strategy movement are either bounded by contract checks or recorded through structured state and events so that indexers, monitoring systems, auditors, operators, and product teams can independently verify the live system.

***

### Contract Surface

The main technical surface includes `Base7540Vault`, `FullyAsyncVault`, `SyncDepositAsyncRedeemVault`, `AsyncDepositVault`, `AsyncRedeemVault`, `SettlementModule`, `PricingModule`, `ReportOracle`, `AccessController`, `AuthorizationPolicy`, `WhitelistPolicy`, `BlacklistPolicy`, `FeeManager`, `StrategyManager`, and `VaultRegistry`.&#x20;

Together, these modules cover **ERC-4626 share accounting**, **ERC-7540 asynchronous request flows**, **ERC-7575 share discovery**, policy checks, pause checks, limit checks, settlement snapshots, NAV consumption, fee math, strategy controls, oracle reporting, and canonical vault discovery.

***

### Governance And Role Separation

City Protocol uses OpenZeppelin `AccessControl` so sensitive permissions can be assigned by function and contract. Vault roles cover default administration, settlement, pricing, access policy management, emergency pause, unpause, fee management, and protocol fee management.&#x20;

* **Strategy manager** roles separately cover strategy configuration, allocation, execution, verifier management, pause, and unpause.&#x20;
* **Oracle** roles separately cover reporter membership, quorum, and freshness policy.&#x20;

{% hint style="info" %}
This split reduces blast radius: a settlement operator cannot update access policy, a pricing operator cannot allocate capital, and a strategy executor cannot arbitrarily change debt caps.
{% endhint %}

Deployment scripts initially assign administration to the deployer, but operational setup should transfer sensitive roles to a Safe or timelock. City Protocol includes an OpenZeppelin `TimelockController` deployment path with configurable delay, proposer/admin, optional open executor, and deployment metadata.&#x20;

The *default delay* is **24 hours**, with longer delays available for high-impact actions. Current vault contracts are not proxy-upgradeable, so change management focuses on role-governed configuration, manager replacement, oracle replacement, strategy policy, and registry state.

***

### Access Control

Vaults can run in `Open` mode or `Policy` mode. In policy mode, user-facing flows call `validateAccess` or `validateAccessPair`, allowing the policy to update state, consume nonces, or verify signatures. Read-only previews use `canAccess`. Policy modules include allowlists, denylists, and EIP-712 signed authorization. Signed authorization binds the call data, vault, account, nonce, expiration block, chain id, and verifying contract domain; successful validation increments the nonce and prevents replay.

***

### Deposit And Redemption Settlement

Asynchronous deposits and redemptions are epoch-based. Deposit requests transfer assets into the vault, record the controller and epoch, wait until the epoch can close, consume an eligible oracle report, snapshot the report id, price, fees, protocol split, and timestamp, mint shares to the vault, and make those shares claimable.&#x20;

Redemption requests transfer shares into the vault, record the controller and epoch, price the epoch using an eligible oracle report, verify idle assets are sufficient, make assets claimable, and burn claimed shares. Later NAV reports, fee changes, or strategy events do not alter already settled economics.

All user-facing and administrative actions are atomic Ethereum transactions. A deposit, redemption, settlement, or strategy execution either passes all checks or reverts as a whole. This avoids partial deposits, partially priced redemptions, partially minted shares, and partially executed strategy calls.

<figure><img src="/files/2ruXYEQglqBoRMsq3ODu" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/rxEyOEte20641owXNNEv" alt=""><figcaption></figcaption></figure>

***

### Oracle And NAV Controls

Settlement depends on versioned NAV reports. `ReportOracle` and `PricingModule` require authorized reporters, configurable quorum, duplicate-approval protection, report freshness, chain and contract binding, optional metadata hashes, epoch timing checks, and price-deviation checks. Reports cannot be computed in the future, older than `maxReportAge`, or earlier than the relevant epoch close.&#x20;

The default settlement price-deviation tolerance is **2,000 bps**, and governance may adjust it up to **10,000 bps** through `PRICING_ROLE`.

<figure><img src="/files/m6JK1wymXW7KtgiSGYuK" alt=""><figcaption></figcaption></figure>

***

### Pause, Limits, Fees, and Capacity

Pause controls are layered across the global vault, deposits, redemptions, share transfers, redeem cancellation, strategy allocation, and strategy execution. Pause and unpause roles are separated so emergency response can be fast while resumption can require review.

`LimitModule` enforces `maxTotalAssets`, `maxPendingDepositAssets`, `minDepositAssets`, and `minRedeemShares`.&#x20;

`FeeManager` enforces hard caps: entry fee up to 20%, exit fee up to 20%, performance fee up to 50%, annualized management fee up to 10%, and protocol share up to 100% of minted fee shares. After initialization, entry and exit fees can only decrease.&#x20;

Deposit epochs snapshot entry fee and protocol split; redeem epochs snapshot exit fee and protocol split. Management and performance fees are accrued through vault-controlled calls, with performance fees using a high-water mark assets-per-share model.

<figure><img src="/files/mlo0xLoN89e1kjkADegc" alt=""><figcaption></figcaption></figure>

***

### Strategy And Custody Controls

Strategy execution is separated from the vault. The vault can allocate idle assets to a configured `StrategyManager`, and the manager enforces strategy allowlists, strategy kind validation, adapter `vault()` and `asset()` binding, per-strategy debt caps, total strategy debt caps, allocation pause, execution pause, allowed call targets, allowed selectors, return-value validation, and vault balance-delta validation.

This is curated bounded execution. A whitelisted strategy is permitted to execute approved actions within caps; it is not a permission to take or redirect vault assets. Claimable redeem assets are excluded from `availableIdleAssetsForStrategy`, and async deposit assets are excluded from strategy availability until settlement.&#x20;

Adapter calls require an allowed strategy, onchain adapter kind, approved target, and approved selector, and failures revert the entire transaction.

***

### Share Transfer, Rescue, and Registry

Vault shares use ERC-20 semantics with 18-decimal fixed share precision. Ordinary investor-to-investor transfers can be disabled through `shareTransferEnabled`, supporting permissioned products where secondary transfer must be restricted. The restricted `rescueToken` path can recover unrelated tokens accidentally sent to the vault, but it cannot rescue the underlying vault asset; the recipient must be nonzero and the caller must hold `DEFAULT_ADMIN_ROLE`.

`VaultRegistry` is the canonical discovery registry. It records vault address, underlying asset, strategy manager, report oracle, vault type, name, symbol, and active flag. Registration and metadata refresh require `REGISTRAR_ROLE`, and registration validates that the strategy manager is bound to the same vault and asset.

***

### Transparency, Testing, and Boundaries

Core contracts expose roles, pause flags, access mode and policy, limits, oracle state, active NAV, epoch state, fee state, strategy state, and registry state. Events should be monitored for role changes, reporter changes, quorum updates, NAV updates, epoch close/price/settle events, pause events, fee changes, strategy policy updates, registry changes, and unexpected changes in idle strategy availability, claimable redemptions, pending deposits, or cached NAV.

Foundry tests cover deployment wiring, access control, authorization-based access, pause behavior, limits, fees, pricing and settlement, strategy allocation and execution policy, accounting invariants, registry behavior, fully asynchronous vault behavior, and sync-deposit async-redeem vault behavior. Standard verification commands are `forge build`, `forge test`, and `forge fmt` .

Before production deployment, each product should verify Safe or timelock role transfer, deployer role handling, oracle reporter and quorum policy, `maxReportAge`, `maxNavPriceDeviationBps`, fee disclosures, strategy allowlists and caps, pause/unpause separation, registry records, and block explorer source verification.

City Protocol's contracts enforce onchain permissions, accounting, price-consumption rules, and strategy execution constraints. Off-chain NAV components and off-chain strategy valuations still require operational controls, reporter separation, review workflows, metadata hashes, multisig or timelock governance, independent monitoring, and product-specific valuation procedures.

<figure><img src="/files/MURR1q0DKRGe99gNQ90r" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://city-protocol.gitbook.io/docs/security-audits-tokenomics/security-and-audits.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
