> 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.md). # Product mechanics How a Curated Vault reaches users through four layers and an OTP through two. ## System architecture A Curated Vault connects a yield source to a user through four layers, and an OTP connects tokenized assets to a user through two. Tokenization as a Service (TaaS) turns a fund, strategy, credit book or managed account into an onchain product. Vault as a Service (VaaS) provides the audited vault contracts that hold participant capital. TaaS and VaaS serve the Curated Vault Architecture only. An OTP uses neither. Its constituents are tokenized assets, such as tokenized equities, and they sit directly in each participant's own smart account. The Issuance & Operation Layer packages vault exposures and tokenized assets into products, through either the Curated Vault Architecture or the OTP Architecture. Venzo delivers each product to users.
Trading strategies, credit and lending, and real-world assets pass through the tokenization and vault rails to the Curated Vault Architecture, tokenized equities go straight to the OTP Architecture, and both reach users through Venzo

The City Protocol stack. TaaS and VaaS serve Curated Vaults only, and an OTP holds tokenized equities directly, with no tokenization or vault layer.

Each layer adds its own set of controls to what it takes in. | Layer | Used by | Takes in | Produces | | -------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | | Tokenization as a Service | Curated Vaults | Strategy and asset data from the originator or manager, and verification data from third parties | An onchain product with a defined token, investor eligibility, an authoritative NAV source and attestations | | Vault as a Service | Curated Vaults | Participant capital, the curator's mandate and NAV reports signed under quorum | Receipt Tokens priced at NAV per share, settled epochs and funded redemption claims | | Issuance & Operation Layer | Curated Vaults and OTPs | Validated components and the issuer's mandate or methodology | Curated Vault products and OTPs, each with a registry entry, reporting and a lifecycle state | | Venzo | Curated Vaults and OTPs | Live products with their disclosures and status, and each participant's instructions | Access, subscription, monitoring and exit in one application | ### Tokenization as a Service TaaS sits between yield supply and distribution. It gives an asset originator, a strategy manager or a distribution partner a repeatable path from offchain or strategy-managed yield to an onchain product, with investor access, valuation, verification and lifecycle operations built in. **Takes in:** Strategy and asset data from the originator or strategy manager, and verification data from third parties, such as reserve and custody confirmations, collateral data and service-provider reports. **Produces:** A tokenized product that applications and networks can integrate: a token with defined rights and transferability, eligibility rules, an authoritative NAV source, verifiable attestations and a lifecycle state.
ModuleFunction
Token representationDefines what the token represents, such as a vault share, an interest in a strategy, a receipt for subscribed capital, a fund share class, an RWA-backed yield position or a wrapped exposure to an approved product, with its name, symbol, decimals, network, metadata and transfer restrictions
NAV monitoring oracleCollects pricing inputs and reserve data, validates sources and asset eligibility, applies fee and liability adjustments, checks deviation thresholds, requires authorized co-signers where configured and publishes the validated value onchain with its history
Investor managementApplies accreditation or qualified-investor checks, jurisdictional rules, allowlists and denylists, role-based and wallet-level permissions, subscription limits, investor caps and transfer restrictions
Attestation engineLinks product claims to proof of reserves, proof of deployment, NAV report hashes, custodian reports, collateralization levels, audit references and settlement records, and publishes verification outputs while keeping confidential account data private
Multichain distributionCarries product metadata, access control, oracle availability, subscription and redemption routing and consistent reporting to every network and application that offers the product
Lifecycle managementRuns product creation and configuration, issuer and strategy onboarding, subscription windows, token issuance, NAV updates, permission updates, attestation publication, redemption processing, reporting, emergency pauses and wind-down or migration
The NAV monitoring oracle works as an operational control: it decides whether a product can process subscriptions, redemptions and integrations at the latest reported value. Token representation, investor eligibility and the verification workflow are set out in [Tokenization and verification](/docs/platform/product-mechanics/tokenization-and-verification.md) and its subpages. ### Vault as a Service VaaS is the operating layer for tokenized yield. It defines how capital enters a vault, how permissions are checked, how capital reaches strategies, how NAV is updated, how risk limits are enforced and how participants redeem, and it includes white-label vaults for partners. **Takes in:** Participant deposits in accepted assets, the curator's mandate and vault configuration, and NAV reports that authorized reporters sign under quorum. **Produces:** Receipt Tokens priced at NAV per share, settled epochs with fixed settlement snapshots, funded redemption claims and indexed vault state for reporting and integration. The vault contracts follow ERC-4626 share accounting with ERC-7540 asynchronous requests and ERC-7575 share discovery. Nine service modules describe the vault at the service level: the contract modules deployed with each vault implement seven of them, and offchain services run the indexing layer and the operations dashboard. | Service module | Function | Implemented by | | -------------------- | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | | Vault contract | Receives deposits, issues Receipt Tokens, tracks balances, processes withdrawals and enforces the core vault rules | The vault contract, in one of four liquidity configurations | | Policy controller | Stores the deposit caps, accepted assets, fee rates, redemption windows and risk thresholds | The module that enforces each parameter | | Security layer | Checks permissions, deposit limits, allocation rules, approved strategies and emergency conditions | The access policy and the limit module, with the pause flags | | Strategy registry | Defines whitelisted strategies, approved venues, allocation quotas and strategy limits | The strategy manager | | NAV oracle | Publishes validated NAV updates under signer, quorum and deviation policies | The report oracle and its pricing module | | Accounting engine | Tracks total assets, liabilities, fees, strategy debt, yield accrual and share pricing | The vault contract, the settlement module, the fee manager and the strategy manager | | Redemption manager | Handles redemption requests, epoch closures, price locks, liquidity checks and claims | The settlement module, with the request flow | | Indexing layer | Indexes deposits, withdrawals, fees, NAV reports, strategy debt, settlement records and events | An offchain indexer that discovers vaults through the vault registry | | Operations dashboard | Displays live data feeds, monitoring views, reports, alerts and vault status | An offchain service that reads the indexing layer | Each module, role and control is set out in [Vault modules and roles](/docs/platform/product-mechanics/how-curated-vaults-work/vault-modules-and-roles.md), and the capital path in [Deposits, capital flow and redemption](/docs/platform/product-mechanics/how-curated-vaults-work/deposits-capital-flow-and-redemption.md). ### Issuance & Operation Layer The Issuance & Operation Layer is the product layer. Issuers define the mandate or methodology, and the layer supplies the machinery that makes it verifiable, governable and distributable. **Takes in:** Components that have passed validation, meaning TaaS products, VaaS vaults and whitelisted external components for Curated Vault products and validated tokenized assets for OTPs, together with the issuer's mandate or published methodology. **Produces:** Products with a registry entry, a methodology version, fees, eligibility rules, reporting and a lifecycle state. A Curated Vault product reports product-level NAV. An OTP keeps every constituent in each participant's own smart account. | Module | Function | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Registry | Records every live product with its components or constituents, methodology version, fees, capacity, eligibility policy and lifecycle status | | Validation | Admits a component only after checks of its status, token address, price or NAV source, verification records, transfer policy and liquidity | | Issuance | Creates the product token, share, receipt or position record, or records a portfolio, and links it to its registry entry | | Methodology enforcement | Holds the mandate or methodology and keeps every allocation or list change inside it | | Reporting | Reports product-level NAV for a Curated Vault product. For an OTP, it reports the onchain composition of each account | | Primary market | Runs subscription, creation, redemption and claims for a Curated Vault product. For an OTP, one transaction buys the basket and one transaction exits it | | Eligibility | Applies KYC and AML checks where required, jurisdictional rules, allowlists, investor limits and transfer restrictions at subscription | | Disclosure | Publishes the methodology, the exposure or constituents, fees, risk disclosures, verification records and product events | | Lifecycle | Manages launch, component and list changes, methodology and fee updates, pauses, migrations, maturity, wind-down and retirement | The layer, its seven-stage lifecycle and the choice between the two architectures are set out in [Issuance & Operation Layer](/docs/platform/product-mechanics/issuance-and-operation-layer.md). ### Venzo Venzo is the flagship application for both product types. **Takes in:** Live products from the registries, with each product's mandate or methodology, fees, risk disclosures and status, and each participant's subscriptions and exits. **Produces:** One application in which users access products, subscribe from a self-custodied wallet, monitor positions and exit. * **Access:** Curated Vaults and OTPs are listed side by side, filtered by strategy type and liquidity terms. * **Review:** Each product page shows the mandate or methodology, the fees and the risk disclosures before subscription. * **Subscribe:** Subscriptions are made from a self-custodied wallet, with each product's eligibility checks applied at subscription. * **Monitor:** Positions, list changes and settlement status are visible in the application. * **Exit:** Curated Vault positions redeem through the vault's settlement window, and OTP holdings exit from the participant's own account. Partner applications reach the same products through the [City Protocol SDK](/docs/developers/city-protocol-sdk.md), and every request passes the same eligibility checks, limits and pause state whatever interface submits it. The application itself is described in [Venzo](/docs/platform/products/venzo.md). ## How state propagates between layers The modules exchange state as well as capital. Capital moves from participants through products into components, and state moves back the other way: when a component changes state, the Issuance & Operation Layer updates the status of every product that holds it, and each product pauses the functions that depend on the component until it recovers.
A component that is paused, impaired, stale, expired or ineligible reaches status propagation, which updates every Curated Vault product holding the TaaS product, VaaS vault or whitelisted asset and every OTP holding the constituent; Curated Vault products pause the affected subscriptions, redemptions or rebalancing, OTPs pause new subscriptions and list changes, and OTP exit stays open

Status propagation. A component's state change reaches every product that holds it, each architecture pauses what depends on the component, and OTP exit stays open throughout.

A component carries one of five states that propagate. * **Paused:** The component's own controls have halted its deposits, redemptions or execution. * **Impaired:** Its value, backing or collateral fails verification. * **Stale:** Its NAV or price data is older than the freshness bound, missing or disputed. * **Expired:** It has reached maturity or the end of its term. * **Ineligible:** It no longer passes component validation. What pauses depends on the architecture. * **Curated Vault products:** The subscriptions, redemptions or rebalancing that depend on the component pause. Where the product NAV cannot be struck on verified values, all user-facing actions pause until the issue is resolved. * **OTPs:** New subscriptions and published list changes pause. Exit stays open throughout, because the participant alone executes it from their own smart account. Each status change is published as a product event, and downstream applications, including Venzo, display the product state that the layer reports. The action that each state triggers in a Curated Vault product is set out in [Curated Vault product layer](/docs/platform/product-mechanics/issuance-and-operation-layer/curated-vault-product-layer.md#security-and-risk-controls). ## Two architectures The Issuance & Operation Layer runs two independent architectures, each suited to a different class of product. * **Curated Vault Architecture:** Pools capital into a vault contract, delegates execution to a curator bound by a mandate and accounts for the result as NAV per share. It applies where an operator must produce the return, for example by running a market-neutral book, a credit position or a lending strategy, and the participant subscribes to the outcome of that work. * **OTP Architecture:** Buys the constituents into the participant's own smart account in one transaction, under a published, rules-based methodology. It applies where the exposure is the assets themselves: a defined basket to hold.
On the left, three participants holding Receipt Tokens send stablecoins into one pooled vault contract, which allocates idle assets through the strategy manager to approved strategies; on the right, each of three participants buys the basket in one transaction into a smart account that they own, which holds every constituent

The capital path under each architecture. Curated Vault deposits converge on one pooled vault and reach strategies through the strategy manager. OTP capital becomes constituents inside each participant's own smart account.

The two architectures differ in where assets are held, what the participant owns, where returns originate and what constitutes failure. | | Curated Vault Architecture | OTP Architecture | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **What the participant holds** | Receipt Tokens, a claim on a pooled vault | The constituent assets themselves | | **Where assets are held** | Pooled in vault contracts with other depositors | In the participant's own smart account, never commingled | | **Custody** | Non-custodial contracts, with curator-directed execution inside the mandate | Self-custodial; the participant's wallet owns the account, and the automation signer trades only within scoped, expiring permissions | | **Who decides holdings** | The curator, within the approved mandate | The published methodology; the list changes only on the source or rule it names | | **Source of return** | Strategy income: lending interest, funding, credit spreads and fees | The market prices of the constituents | | **Accounting** | NAV per share, struck at each settlement | No unit and no unit price; the position is the set of token balances in the account | | **Entry** | Deposit stablecoins and receive Receipt Tokens, at settlement or at once in a synchronous-deposit vault | One transaction converts stablecoins into the full basket at the methodology's weights | | **Exit** | Liquid or epoch-based redemption | One transaction back to one asset, or any constituent sold on its own | | **Granularity** | An undivided claim on the pool | Each constituent can be sold, transferred or pledged on its own | | **Scope** | One strategy, run by one curator | A basket of constituents, such as tokenized equities, set by the methodology | | **Dominant failure mode** | Strategy loss, or a contract failure affecting the pool | Constituent prices falling; onchain execution risk; liquidity risk | | **Products as of October 2026** | Curated Vaults in strategy types such as market-neutral strategies, credit strategies, private credit, lending and cross-exchange arbitrage | Index OTPs and Guru OTPs; the Thematic OTP will arrive with the next phase | How to choose between the two is set out in [Selecting an architecture](/docs/platform/product-mechanics/issuance-and-operation-layer.md#selecting-an-architecture). ## Topics * [How Curated Vaults work](/docs/platform/product-mechanics/how-curated-vaults-work.md): contract design, epoch settlement, NAV and strategy execution. * [Vault modules and roles](/docs/platform/product-mechanics/how-curated-vaults-work/vault-modules-and-roles.md): the contracts, the nine service modules, the roles and the security governance layer. * [Deposits, capital flow and redemption](/docs/platform/product-mechanics/how-curated-vaults-work/deposits-capital-flow-and-redemption.md): the policy gate, asynchronous requests and the two redemption paths. * [NAV, oracle and proof of deployment](/docs/platform/product-mechanics/how-curated-vaults-work/nav-oracle-and-proof-of-deployment.md): NAV-driven accounting, the oracle quorum and proof of deployment. * [Mandate, execution and parameters](/docs/platform/product-mechanics/how-curated-vaults-work/mandate-execution-and-parameters.md): the mandate, curator-bound execution and the configurable parameters. * [How OTPs work](/docs/platform/product-mechanics/how-otps-work.md): the account model, subscription and exit, weights and list changes. * [OTP modules and participants](/docs/platform/product-mechanics/how-otps-work/otp-modules-and-participants.md): the modules in operation, the next-phase components and each participant's role. * [Portfolio lifecycle](/docs/platform/product-mechanics/how-otps-work/portfolio-lifecycle.md): the stages from the published methodology to exit or retirement. * [List changes and the Rebalancing Executor](/docs/platform/product-mechanics/how-otps-work/list-changes-and-the-rebalancing-executor.md): how the list changes and how the next-phase executor will apply each change. * [OTP security and risk controls](/docs/platform/product-mechanics/how-otps-work/otp-security-and-risk-controls.md): the controls that protect each participant's account. * [Issuance & Operation Layer](/docs/platform/product-mechanics/issuance-and-operation-layer.md): the product layer, its seven-stage lifecycle, product templates and the choice of architecture. * [Curated Vault product layer](/docs/platform/product-mechanics/issuance-and-operation-layer/curated-vault-product-layer.md): the ten product modules, the participants, product-level NAV and the controls. * [Tokenization and verification](/docs/platform/product-mechanics/tokenization-and-verification.md): token representation, NAV monitoring and verification. * [Tokenization architecture](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-architecture.md): the six TaaS modules and the participants they serve. * [Tokenization lifecycle](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-lifecycle.md): the stages from product creation to wind-down or migration. * [Oracle, attestations and API](/docs/platform/product-mechanics/tokenization-and-verification/oracle-attestations-and-api.md): the NAV workflow, the attestation engine and the integration surface. * [Fees](/docs/platform/product-mechanics/fees.md): Curated Vault fees and the OTP fee.