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

# Tokenization lifecycle

The standard TaaS lifecycle follows seven stages.

{% stepper %}
{% step %}

### Product onboarding

The asset originator or strategy manager submits product information, including strategy mandate, target assets, expected liquidity profile, risk limits, service providers, legal structure, supported networks, and required investor eligibility.

For RWA-backed products, this stage may include borrower profile, collateral type, collateralization ratio, custodian or administrator information, reserve account structure, and verification partner setup.

For trading strategies, this stage may include approved exchanges, approved assets, leverage limits, market exposure limits, drawdown limits, settlement frequency, and reporting cadence.
{% endstep %}

{% step %}

### Product configuration

City Protocol configures the product according to its operating rules.

Configuration may include:

· accepted subscription assets;

· minimum deposit;

· maximum capacity;

· management fees;

· performance fees;

· redemption window;

· NAV update frequency;

· oracle quorum;

· eligible investor type;

· transferability;

· supported chains;

· distribution channels;

· emergency controls.
{% endstep %}

{% step %}

### Token issuance

The token contract or tokenized share representation is deployed.

The deployment connects the token to its product registry entry, oracle source, permissioning module, subscription flow, redemption flow, and reporting interface. Where applicable, the token may follow existing token or vault standards to improve compatibility with external integrations.
{% endstep %}

{% step %}

### Subscription

Eligible investors subscribe through City Neobank, a partner app, or an API integration.

The subscription flow checks investor permissions, deposit limits, accepted asset type, product capacity, and product status. Once approved, the user receives the relevant token, receipt, or vault share, depending on the product design.
{% endstep %}

{% step %}

### NAV and attestation updates

The product state is updated through the NAV oracle and attestation engine.

Each update should answer four questions:

1\. What is the current product value?

2\. What inputs were used to calculate it?

3\. Who verified the inputs?

4\. Are subscriptions and redemptions safe to process at this value?
{% endstep %}

{% step %}

### Distribution and integration

The tokenized product can be exposed through the Earn Module, partner apps, or eligible DeFi integrations.

Distribution metadata should include asset type, strategy type, expected liquidity, supported networks, verification status, risk controls, fees, capacity, historical NAV, and redemption rules.
{% endstep %}

{% step %}

### Redemption or wind-down

Investors redeem according to product terms.

Liquid products may support immediate or near-immediate redemption. Less liquid products may require epoch-based redemptions, scheduled windows, or settlement periods. If the product is closed or migrated, TaaS provides the operational path for final NAV, claim processing, and reporting.
{% endstep %}
{% endstepper %}


---

# 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/tokenization-lifecycle.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.