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

# Tokenization architecture

The six modules of the tokenization layer, the NAV per token formula and the participants that operate a tokenized product.

The TaaS layer sits between yield supply and distribution. It receives strategy and asset data from the asset originator or strategy manager and verification data from third parties, runs them through six modules, and outputs a tokenized product that Venzo, partner applications and DeFi integrations list across the supported networks.

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2Ff0zHq2hcrOaRbkpanhXZ%2Ffig-taas-architecture.png?alt=media" alt="The originator or strategy manager feeds the tokenization module, investor management and the NAV monitoring oracle, third-party verifiers feed the oracle and the attestation engine, all four modules feed multichain distribution, lifecycle management runs beneath them, and distribution reaches Venzo, partner applications, qualified investor channels and DeFi integrations"><figcaption><p>The TaaS layer between yield supply and distribution. The originator or manager and third-party verifiers feed the modules, and every deployment carries the token, its eligible investors, its NAV source, its redemption path and its state.</p></figcaption></figure>

## Yield asset tokenization

The tokenization module creates the onchain representation of a yield product. Depending on product design, the token represents one of six things:

* a claim on a vault share, such as a Curated Vault's Receipt Tokens;
* 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 is freely transferable, permissioned, non-transferable or restricted to eligible addresses, and the class follows from the underlying asset, the jurisdiction, the distribution channel and the investor eligibility rules. On Curated Vault rails, investor-to-investor transfers of Receipt Tokens can be disabled through `shareTransferEnabled`, which supports permissioned products that restrict secondary transfer.

For each product, the tokenization module defines seven things.

| Definition                                   | What it sets                                                                                                                                                                     |
| -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Token identity                               | The token name, symbol, decimals and network deployment                                                                                                                          |
| Product metadata                             | The product information and the issuer information                                                                                                                               |
| Subscription and redemption behaviour        | How capital enters and leaves the product, from immediate redemption to epoch-based settlement                                                                                   |
| Transfer restrictions and holder eligibility | The transferability class and the addresses that can hold the token                                                                                                              |
| Accounting basis                             | Share accounting, in which each token is a share of the product's NAV, or reference-value accounting, in which the token tracks the value of an underlying portfolio or strategy |
| Underlying relationship                      | The vaults, accounts or strategy positions behind the token                                                                                                                      |
| Integration points                           | The oracle, attestation and reporting interfaces the token connects to                                                                                                           |

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FSCl9zJdP3rSzLt2Ej6Ey%2Ffig-taas-token.png?alt=media" alt="A token represents one of six underlying exposures, carries its name, symbol, decimals, network, product metadata and issuer information, has four attached properties for transfer and eligibility, subscription and redemption, accounting basis and underlying positions, and connects to the NAV monitoring oracle, the attestation engine and reporting"><figcaption><p>What the tokenization module defines. Each token represents one underlying exposure, carries its transfer, eligibility, redemption, accounting and underlying rules, and connects to the oracle, attestations and reporting.</p></figcaption></figure>

## NAV monitoring oracle

A tokenized yield product needs a reliable method of valuation, and the NAV monitoring oracle provides it. The NAV basis follows the product type.

| Product type                | NAV basis                                                                                               |
| --------------------------- | ------------------------------------------------------------------------------------------------------- |
| Vault-style product         | The value of the assets the vault holds, minus its liabilities and accrued fees                         |
| Reference-portfolio product | The value of the underlying portfolio or strategy                                                       |
| Private credit product      | Principal outstanding, interest accrual, collateral coverage, payment status and impairment adjustments |

In each case, the value per token is

$$
\text{NAV per token} = \frac{\text{verified assets} - \text{liabilities} - \text{accrued fees}}{\text{tokens outstanding}}
$$

where verified assets are the assets that the oracle's inputs and attestations confirm, liabilities are the product's obligations, accrued fees are the fees earned and still unpaid, and tokens outstanding are the tokens in issue at the valuation point. On Curated Vault rails, the same calculation gives the NAV per share struck at each settlement, as set out in [How Curated Vaults work](/docs/platform/product-mechanics/how-curated-vaults-work.md).

The NAV monitoring oracle carries eight responsibilities:

1. collecting pricing inputs and reserve data;
2. validating the data sources;
3. checking asset eligibility;
4. applying fee and liability adjustments;
5. comparing each new NAV with the deviation threshold;
6. requiring authorized co-signers where the product needs them;
7. publishing the validated NAV or reference price onchain;
8. keeping historical NAV reports available for monitoring.

The oracle layer works as an operational control system: it decides whether subscriptions, redemptions and integrations are safe to process at the latest reported value. On Curated Vault rails, the report oracle implements these controls. It accepts a NAV report only from authorized reporters under a configurable quorum, with protection against duplicate approvals, a freshness bound, binding to the network and the contract, and epoch-timing checks, and settlement rejects a price that moves beyond the vault's deviation tolerance. The report controls are set out in [Oracle and NAV design](/docs/security/security-and-risk/oracle-and-nav-design.md).

## Investor management

Many institutional yield products require controlled access, and the investor management module applies eligibility and permissioning per product through seven controls.

| Control                                    | What it enforces                                                                                             |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
| Accreditation or qualified-investor checks | Only investors who meet the product's accreditation or qualification standard can subscribe                  |
| Jurisdictional eligibility rules           | The product admits investors only from the jurisdictions its rules allow                                     |
| Allowlists and denylists                   | Named addresses are admitted or blocked                                                                      |
| Role-based permissions                     | Each operating function sits with a defined role, such as the whitelist manager that maintains the allowlist |
| Wallet-level access control                | Access is granted or refused for each wallet address                                                         |
| Subscription limits and investor caps      | Subscriptions stay within the configured limits and caps                                                     |
| Transfer restrictions                      | Regulated or permissioned products limit who can receive the token                                           |

The same framework serves different distribution models. A public DeFi strategy can run with open access, while an RWA-backed private credit product can require accreditation and restricted transferability.

On Curated Vault rails, these controls run in the access policy and the limit module. The access policy works in open mode or policy mode, with allowlists, denylists or EIP-712 signed authorizations bound to the account, the vault, the network and an expiry, and the limit module enforces the caps on total assets and pending deposits and the minimum deposit and redemption sizes. Where a product requires KYC or KYB verification, the whitelist manager links each investor's verification status to the wallet address, and the underlying personal data stays offchain. Both modules are described in [Vault modules and roles](/docs/platform/product-mechanics/how-curated-vaults-work/vault-modules-and-roles.md).

## Attestation engine

The attestation engine makes product claims independently verifiable, and it supports eleven kinds of attestation.

| Attestation                           | What it evidences                                                                        |
| ------------------------------------- | ---------------------------------------------------------------------------------------- |
| Proof of reserves                     | The assets backing the product exist and correspond to its reported obligations          |
| Proof of deployment                   | Capital is allocated to approved strategies, accounts or venues according to the mandate |
| NAV report hashes                     | The report behind each published NAV, fixed by its hash                                  |
| Reserve account confirmations         | The balances held in the product's reserve accounts                                      |
| Service-provider confirmations        | Data confirmed by an administrator, custodian or other service provider                  |
| Collateralization levels              | Collateral coverage against the product's obligations                                    |
| Custodian reports                     | The holdings reported by the custodian                                                   |
| Audit references                      | The audits that cover the product and its contracts                                      |
| Strategy exposure reports             | The strategy's current exposures                                                         |
| Settlement records                    | The terms on which each subscription and redemption settled                              |
| Verification intervals and timestamps | When each claim was verified and how often it is verified again                          |

Attestations are produced by City Protocol, third-party verifiers, custodians, administrators, auditors or monitoring partners, depending on the product. The requirement is that every claim shown in a dashboard connects to a verifiable record that integrators can inspect.

For products that rely on private or sensitive offchain data, an attestation exposes the verification output and keeps the full underlying data set private. City Protocol thereby supports institutional-grade transparency and keeps account data, counterparty exposure and trading strategy details confidential. The attestation record and the parties that read it are set out in [Oracle, attestations and API](/docs/platform/product-mechanics/tokenization-and-verification/oracle-attestations-and-api.md).

## Multichain distribution

TaaS prepares each tokenized product for distribution across City Protocol and partner networks. Distribution covers:

* approved partner product interfaces;
* partner applications;
* qualified investor channels;
* DeFi integrations;
* vault catalogues;
* portfolio products;
* staking or liquidity modules;
* the supported EVM networks.

Distributing a product across networks takes more than bridging a token: every network needs the product metadata, access control, oracle availability, subscription and redemption routing, and consistent reporting. TaaS therefore treats distribution as an infrastructure problem, and each deployment knows five things:

* which token it represents;
* which investors are eligible;
* which NAV source is authoritative;
* which redemption path applies;
* which product state downstream applications display.

Curated Vaults apply chain abstraction: a participant deposits from a supported EVM network and receives Receipt Tokens, while strategy execution and NAV settlement stay on the vault's execution network. The networks and their roles are set out in [Cross-chain architecture](/docs/security/cross-chain-architecture.md).

## Lifecycle management

A tokenized product needs ongoing operations after launch, and the lifecycle management module runs twelve of them: 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, and product wind-down or migration. This lifecycle layer separates TaaS from a plain token deployment and gives City Protocol and its partners an operating system for tokenized yield products. The seven stages are set out in [Tokenization lifecycle](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-lifecycle.md).

## Participants

The TaaS layer coordinates six participants.

| Participant                        | Role                                                                                                                                                           |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Yield provider or asset originator | Sources the underlying asset, credit exposure, fund strategy, trading strategy or RWA-backed yield source                                                      |
| Strategy manager                   | Manages strategy execution, risk limits, performance reporting and operational updates                                                                         |
| Third-party verifier               | Verifies reserves, NAV inputs, service-provider data, collateralization and other product claims                                                               |
| City Protocol TaaS layer           | Provides token issuance, investor controls, oracle infrastructure, the attestation registry, subscription and redemption workflows and distribution interfaces |
| Integration partner                | Integrates tokenized products into user-facing applications and partner apps                                                                                   |
| Yield investor                     | Subscribes to, holds, redeems or uses the tokenized product according to eligibility and product terms                                                         |

What passes between the participants at each stage is drawn in [Tokenization lifecycle](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-lifecycle.md).