> 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/issuance-and-operation-layer/structured-product-architecture/product-lifecycle.md).

# Product Lifecycle

A standard product moves through seven stages.

{% stepper %}
{% step %}

#### 1. Product mandate

The issuer or curator defines the product concept.

This includes target exposure, component universe, product type, target audience, liquidity terms, risk limits, fee structure, NAV cadence, and distribution policy.

Example product types can include ETP-style products, multi-vault portfolios, thematic allocation products, model portfolios, market-neutral strategy products, stable-yield blends, copy-allocation products, or tenor-based structured yield products.
{% endstep %}

{% step %}

#### 2. Component validation

The layer checks whether each proposed component is eligible for use.

For TaaS products, this may include product status, token address, NAV source, verification records, transfer policy, supported networks, and redemption terms.

For VaaS vaults, this may include vault status, strategy whitelist, latest NAV, capacity, redemption queue, pause state, proof records, and risk controls.

For external components, this may include whitelist approval, price source, custody or reserve verification, liquidity profile, and allowed venue policy.
{% endstep %}

{% step %}

#### 3. Product issuance and configuration

The product is issued and configured according to its approved methodology.

Configuration can include:

* product token, receipt, share, or position-record design;
* component weights;
* allocation bands;
* rebalance cadence;
* rebalance triggers;
* concentration limits;
* drawdown controls;
* accepted subscription assets;
* creation/redemption rules;
* fee schedule;
* NAV cadence;
* oracle quorum;
* eligibility requirements;
* transferability;
* emergency controls.
  {% endstep %}

{% step %}

#### 4. Product-level NAV

The layer calculates product-level NAV from component values and product accounting state.

The simplified formula is:

```
Product NAV = verified component value + idle assets - liabilities - accrued fees
Product unit NAV = product NAV / product units outstanding
```

The NAV process should answer five questions:

1. What components are included in the product?
2. What value was used for each component?
3. Who verified the inputs?
4. Did the update pass deviation and freshness checks?
5. Can subscriptions and redemptions safely process at this NAV?

If a component NAV is stale, missing, disputed, or outside policy, the product can pause subscriptions, redemptions, rebalancing, or all user-facing actions until the issue is resolved.
{% endstep %}

{% step %}

#### 5. Subscription and creation

Eligible participants subscribe through a City Protocol-powered frontend, partner frontend, or NaaS integration.

The primary market module checks accepted asset, user eligibility, product status, capacity, deposit limits, current NAV, and fee rules. Depending on the product design, the participant may receive a product token, share token, receipt, or position record.

For products with asynchronous settlement, the request can remain pending until the next pricing or settlement cycle. This protects participants when the underlying components cannot be valued or allocated atomically.
{% endstep %}

{% step %}

#### 6. Rebalancing and monitoring

Rebalancing occurs only within the approved product mandate.

The rebalancing controller checks allocation bands, component eligibility, liquidity, venue rules, execution permissions, and emergency pause state. Rebalance events should be indexed and attached to the product's reporting history.

Product monitoring should include component weights, NAV history, fee accrual, capacity, redemption queue, verification status, component status, methodology version, and risk events.
{% endstep %}

{% step %}

#### 7. Redemption or wind-down

Participants redeem according to the product's liquidity terms.

Liquid products may support near-immediate redemption if component liquidity is available. Less liquid products may use epoch-based redemption, scheduled windows, or final settlement at maturity.

For wind-down, the layer should support final NAV, component liquidation or unwinding, settlement asset verification, claim readiness, product status updates, and final reporting.
{% endstep %}
{% endstepper %}