> 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/tokenization-and-verification.md).

# Tokenization and verification

How Tokenization as a Service turns a yield source into an onchain product, and how the product's value and claims are verified.

Tokenization as a Service (TaaS) is City Protocol's capital-layer infrastructure for turning yield sources into programmable onchain products. It serves asset originators, strategy managers, integration partners and distribution partners that bring institutional yield assets onchain, and it supplies the issuance, oracle, investor access, verification, reporting and lifecycle infrastructure that each of them would otherwise build from scratch.

A tokenized yield product has to define who can subscribe, what the token represents, how its NAV is calculated, how its claims are verified, how subscriptions and redemptions are processed and how it is distributed across applications and networks. TaaS packages these requirements into one reusable framework, so minting the token is one step among the many that the layer runs.

## Why TaaS exists

City Protocol's thesis is that onchain finance grows beyond crypto-native yield once high-quality real-world and institutional strategies reach users through consumer-grade rails. The missing layer is infrastructure. Before a new frontend, an asset manager or yield provider needs a verifiable, distribution-ready way to convert an asset, fund, strategy or vault position into an onchain product that users and integrators understand, with eligibility controls built in. TaaS standardizes that conversion across six functions and gives every product a repeatable path from offchain or strategy-managed yield to onchain access.

## The six functions

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FotVfQZh0lx1moEtkrUQs%2Ffig-taas-functions.png?alt=media" alt="Yield supply enters Tokenization as a Service, whose six numbered functions are yield asset tokenization, NAV monitoring, investor management, attestations and verification, multichain distribution and lifecycle management, and leaves for distribution channels"><figcaption><p>The six functions of TaaS between yield supply and distribution. Together they give each product a repeatable path from offchain or strategy-managed yield to onchain access.</p></figcaption></figure>

1. **Yield asset tokenization:** The tokenization module creates the onchain representation of a yield product, such as a claim on a vault share, a tokenized fund or share class, or an RWA-backed yield position. It fixes the token's metadata, transferability, subscription and redemption behaviour, accounting basis and link to the underlying positions. The six token types and the seven definition fields are set out in [Tokenization architecture](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-architecture.md).
2. **NAV monitoring and oracle publication:** The NAV monitoring oracle collects pricing inputs and reserve data, validates them, applies fees and liabilities, and publishes a NAV per token onchain once the deviation check and the signer quorum pass. It works as an operational control that decides whether subscriptions, redemptions and integrations proceed at the latest value. The formula and the oracle's eight responsibilities are in [Tokenization architecture](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-architecture.md), and the checks behind each update in [Oracle, attestations and API](/docs/platform/product-mechanics/tokenization-and-verification/oracle-attestations-and-api.md).
3. **Investor management and access control:** Eligibility is set per product through accreditation or qualified-investor checks, jurisdictional rules, allowlists and denylists, role-based and wallet-level permissions, subscription limits and investor caps, and transfer restrictions. One framework therefore serves an open-access DeFi strategy and an accreditation-gated private credit product alike. Each control is described in [Tokenization architecture](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-architecture.md).
4. **Attestations and verification:** The attestation engine connects each product claim, such as reserves, deployment, a NAV report or a settlement, to a verifiable record that integrators can inspect. Where a claim rests on private data, the attestation publishes the verification output and the underlying data stays confidential. The attestation record and the parties that produce and read it are set out in [Oracle, attestations and API](/docs/platform/product-mechanics/tokenization-and-verification/oracle-attestations-and-api.md).
5. **Multichain distribution:** TaaS prepares each product for Venzo, partner applications, qualified investor channels and DeFi integrations across the supported networks. Every deployment carries the product metadata, the eligibility rules, the authoritative NAV source, the redemption path and the product state, so each application displays the product consistently.
6. **Lifecycle management:** The layer runs each product from creation and configuration through subscription, NAV updates, attestation publication, redemption and reporting to wind-down or migration, including emergency pauses. The seven stages and the operations between them are set out in [Tokenization lifecycle](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-lifecycle.md).

## Example use cases

TaaS supports multiple product templates, and each template configures the same framework for its yield source.

### RWA-backed lending product

An RWA-backed lending product tokenizes exposure to a pool of secured loans or receivables. It depends on borrower reporting, collateral monitoring, reserve verification, NAV calculation and redemption scheduling, and it is configured through ten fields:

* funding currency;
* collateral type;
* target collateralization ratio;
* minimum collateralization ratio;
* borrower or originator profile;
* verification partner;
* liquidity period;
* capacity;
* subscription eligibility;
* NAV reporting cadence.

### Market-neutral trading strategy

A market-neutral product tokenizes exposure to a strategy that captures pricing inefficiencies without taking broad directional exposure. It is configured through nine fields:

* approved exchanges or venues;
* approved assets;
* maximum leverage;
* drawdown limits;
* liquidity limits;
* redemption period;
* NAV calculation method;
* management and performance fees;
* strategy reporting cadence.

### Tokenized treasury or cash-management product

A treasury-style product tokenizes exposure to short-duration, high-liquidity instruments. It places more weight on reserve verification, low-duration asset eligibility, NAV stability and fast redemption, and it is configured through eight fields:

* eligible collateral;
* custodian or administrator;
* verification agent;
* reference rate;
* NAV update frequency;
* redemption capacity;
* jurisdictional eligibility;
* transferability policy.

## NAV monitoring and verification

The NAV monitoring oracle and the attestation engine together decide the value a product runs on. Every update follows the same four steps, and only a value that clears every check reaches settlement.

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FN62TUvcJIOpgSq06HDkE%2Ffig-verification.png?alt=media" alt="Asset and position data, reserve and custody data and service-provider reports feed validation and NAV calculation, a deviation check and a signer quorum before publication onchain; a failed check at any gate pauses the product for review"><figcaption><p>The NAV verification workflow. A value reaches settlement only after it clears validation, the deviation check and the signer quorum.</p></figcaption></figure>

{% stepper %}
{% step %}

### Collect

Asset and position data, reserve and custody data and service-provider reports are collected for the valuation point.
{% endstep %}

{% step %}

### Validate and calculate

The data sources are validated, asset eligibility is checked, fee and liability adjustments are applied, and the NAV per token is calculated.
{% endstep %}

{% step %}

### Check deviation

The new value is compared with the previous report against the product's deviation threshold. On Curated Vault rails, settlement rejects a price that moves beyond the vault's deviation tolerance.
{% endstep %}

{% step %}

### Sign and publish

Within policy, authorized reporters sign the report under the configured quorum, and the validated value is published onchain for subscriptions, redemptions, integrations and reporting. The report hash and its timestamp are linked to the product's attestation record, and the report joins the history of NAV reports available for monitoring.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
When an update fails verification, lacks signer approval, uses incomplete data or breaches the deviation limit, the product pauses subscriptions, redemptions or both until the issue is resolved.
{% endhint %}

NAV applies to Curated Vaults and to the products tokenized on TaaS rails. An OTP reports the token balances in each participant's account, and each constituent's price source is validated at admission. The report controls that decide which NAV report settlement can use are set out in [Oracle and NAV design](/docs/security/security-and-risk/oracle-and-nav-design.md).