> 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/tokenization-as-a-service/core-modules.md).

# Core modules

## 1. Yield asset tokenization

The tokenization module creates the onchain representation of a yield product.

**Depending on product design, the token can represent:**

· a claim on a vault share;

· an interest in a strategy;

· a receipt for subscribed capital;

· a tokenized fund or share class;

· an RWA-backed yield position;

· a wrapped exposure to an approved underlying product.

The token may be freely transferable, permissioned, non-transferable, or restricted to eligible addresses. This depends on the underlying asset, jurisdiction, distribution channel, and investor eligibility rules.

**The tokenization module defines:**

· token name, symbol, decimals, and network deployment;

· product metadata and issuer information;

· subscription and redemption behavior;

· transfer restrictions and holder eligibility;

· share accounting or reference-value accounting;

· relationship to underlying vaults, accounts, or strategy positions;

· integration points for oracles, attestations, and reporting.

***

### 2. NAV monitoring oracle

Tokenized yield products require a reliable method for valuing the product.

For vault-style products, NAV may be calculated from the value of assets held by the vault minus liabilities and accrued fees. For reference portfolio products, NAV may track the value of an underlying portfolio or strategy. For private credit products, NAV may include principal outstanding, interest accrual, collateral coverage, payment status, and impairment adjustments.

**The simplified NAV formula is:**

```
NAV per token = (verified assets - liabilities - accrued fees) / tokens outstanding
```

 **The NAV monitoring oracle is responsible for:**

· collecting pricing inputs and reserve data;

· validating data sources;

· checking asset eligibility;

· applying fee and liability adjustments;

· comparing new NAV values against deviation thresholds;

· requiring authorized co-signers where needed;

· publishing the validated NAV or reference price onchain;

· making historical NAV reports available for monitoring.

The oracle layer should not be treated as a single price feed. It is an operational control system that determines whether the product can safely process subscriptions, redemptions, and integrations at the latest reported value.

***

### 3. Investor management

Many institutional yield products require controlled access.

**TaaS supports investor eligibility and product-specific permissioning through:**

· KYC and AML provider integrations;

· accreditation or qualified investor checks;

· jurisdictional eligibility rules;

· allowlists and denylists;

· role-based permissions;

· wallet-level access control;

· subscription limits and investor caps;

· transfer restrictions for regulated or permissioned products.

The investor management module allows the same tokenization framework to support different distribution models. A public DeFi-oriented strategy may use open access, while an RWA-backed private credit product may require KYC, accreditation, and restricted transferability.

***

### 4. General-purpose attestation engine

TaaS is designed to make product claims independently verifiable.

**The attestation engine can support:**

· proof of reserves;

· proof of deployment;

· NAV report hashes;

· reserve account confirmations;

· service-provider confirmations;

· collateralization levels;

· custodian reports;

· audit references;

· strategy exposure reports;

· settlement records;

· verification intervals and timestamps.

Attestations can be generated by City Protocol, third-party verifiers, custodians, administrators, auditors, or monitoring partners depending on the product. The key requirement is that claims are not only shown in a dashboard, but connected to a verifiable record that integrators can inspect.

For products that rely on private or sensitive offchain data, attestations can expose verification outputs without exposing the full underlying data set. This allows City Protocol to support institutional-grade transparency while respecting confidentiality requirements around account data, counterparty exposure, and trading strategy details.

***

### 5. Multichain distribution

TaaS prepares tokenized products for distribution across City Protocol and partner networks.

**Distribution can include:**

· City Neobank Earn Module;

· partner neofinance applications;

· qualified investor channels;

· DeFi integrations;

· vault catalogs;

· portfolio products;

· staking or liquidity modules;

· supported EVM and non-EVM networks where available.

Multichain distribution requires more than bridging a token. It requires product metadata, access control, oracle availability, subscription and redemption routing, and reporting consistency across networks.

TaaS therefore treats distribution as an infrastructure problem: *each deployment must know what token is being represented, what investors are eligible, what NAV source is authoritative, what redemption path applies, and what product state downstream applications should display.*

***

### 6. Lifecycle management

Tokenized products require ongoing operations after launch.

**TaaS supports the product lifecycle across:**

· product creation and configuration;

· issuer and strategy onboarding;

· subscription windows;

· token issuance;

· NAV updates;

· investor permission updates;

· attestation publication;

· liquidity provisioning;

· redemption processing;

· reporting;

· emergency pauses;

· product wind-down or migration.

This lifecycle layer is what separates TaaS from simple token deployment. It gives City Protocol and its partners an operating system for tokenized yield products.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://city-protocol.gitbook.io/docs/tokenization-as-a-service/core-modules.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.