> 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/how-otps-work.md).

# How OTPs work

The OTP account model, subscription and exit, and how weights and constituent lists change.

## Contract design

An OTP holds its portfolio as token balances in the participant's own onchain account. Each methodology is published as a rules-based, non-personalized rule set. It provides no individual investment advice or discretionary management, and OTPs are not offered to residents of the Republic of Korea unless authorized as required under Korean law. Three properties define the structure.

* **Direct ownership:** Each participant's constituents sit in a smart account that the participant owns, never commingled with other participants' assets.
* **Rules-based lists:** The methodology names the constituents, the weights at purchase and the third-party public source or published rule that can change the list. It is published and versioned before the product opens.
* **Single-transaction entry and exit:** One transaction converts stablecoins into the full basket at the methodology's weights, and one transaction reverses it.

A participant's position rests on two layers. At sign-in, the participant receives a self-custodial embedded wallet whose private key is split into two encrypted shares that combine only at the moment of signing, so neither City Protocol nor its wallet-infrastructure provider holds the key; a participant can also connect a supported wallet of their own. That wallet owns a portfolio smart account, a Kernel account following the [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) standard, one for each participant, portfolio and chain. The account's address is known before it is deployed, the first operation sent from it deploys it, and every constituent sits in that account.

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2Fw4ZmPX6ZpxwBV862WZkX%2Ffig-otp-account.png?alt=media" alt="The participant&#x27;s self-custodial wallet owns a smart account that holds every constituent and carries the live Approval and Trade permissions bound to the automation signer, while the next-phase Rebalancing Executor and Basket Execution Router are drawn dashed"><figcaption><p>The OTP account model. Constituents stay in the participant's own smart account, which the participant's wallet owns; the automation signer trades only within the Approval and Trade permissions, which expire after 90 days. Components drawn dashed arrive with the next phase.</p></figcaption></figure>

The participant requests every trade, and City Protocol's execution service carries it out through an automation signer. The automation signer acts only through two permissions that the participant's wallet grants, an Approval scope and a Trade scope: they allow approvals of the portfolio's tokens to the reviewed router, swaps whose proceeds land in the participant's own account and the capped execution fee, and they expire after 90 days. Withdrawals and every other transfer need the owner's own signature. The full mechanism is set out in [Technical overview](/docs/platform/product-mechanics/how-otps-work/technical-overview.md).

| Module                   | Function                                                                                                                                                                                      | Status       |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
| Portfolio registry       | Records live portfolios, constituent lists, methodology versions, fee schedules, eligibility policies and lifecycle status.                                                                   | In operation |
| Methodology              | Holds the published rule set: the constituents, the weights at purchase and the source or rule that can change the list.                                                                      | In operation |
| Account factory          | Deploys each participant's smart account, owned by the participant's wallet from creation.                                                                                                    | In operation |
| Eligibility policy       | Applies jurisdictional rules, allowlists and product-specific access requirements at subscription.                                                                                            | In operation |
| Exit router              | Converts the basket back to one asset in one transaction, or exits part of the portfolio down to a single constituent.                                                                        | In operation |
| Disclosure and lifecycle | Publishes the methodology, constituents, list changes, fees and risk disclosures, and manages launch, pauses and retirement.                                                                  | In operation |
| Permission validators    | Hold the Approval and Trade scopes through which the automation signer executes the participant's trades, each with a call policy, a limit of 16 operations per 24 hours and a 90-day expiry. | In operation |
| Rebalancing Executor     | Will apply each published list change inside every enrolled account as a session signer bound to a policy.                                                                                    | Next phase   |
| Basket Execution Router  | Will settle the legs of each list change as one price-checked atomic batch.                                                                                                                   | Next phase   |

## Subscription and exit

At subscription, the eligibility policy is checked, the participant deposits the settlement token into the smart account, and a Buy acquires every constituent at the methodology's weights. Exact-amount approvals go first where the account's allowance is short, and then one atomic transaction carries every swap leg and the execution fee, delivering the constituents into the participant's smart account. To exit, the participant sells the basket back to the settlement token with Sell Max, or sells part of it, and withdraws the cash to their wallet with an owner-signed transfer; any constituent can also be moved or traded directly from the account. Exit draws on holdings the participant already owns, so it is available at any time, including while a product is paused.

{% hint style="success" %}
**Participant custody:** Under the OTP Architecture, every constituent of a portfolio sits in the participant's own smart account from subscription to exit, and only a transaction that the participant signs can move an asset to another address, apart from the capped execution fee.

**Why it holds:** The account factory deploys each smart account with the participant's wallet as its root validator, and every trade delivers the constituents to that account. City Protocol never holds the owner key. Its automation signer acts only through the Approval and Trade validators, whose call policies allow approvals only to the reviewed router, swaps only into the participant's own account and one capped fee transfer to the fixed fee recipient, so withdrawals and every other transfer need the owner's signature.
{% endhint %}

The next phase will preserve this property. A participant will be able to add the Rebalancing Executor to the account as a session signer, a limited signing key bound to a policy, through a one-time consent. The policy will allowlist the constituent contracts and the Basket Execution Router, permit only the swap and approval functions that the router needs, and deny every other request by default, including any transfer to another address and any key export. The policy will be enforced inside a trusted execution environment before any signature is produced, and the participant will be able to remove the signer at any time, which will stop automation immediately and leave every token in the account.

## Weights and list changes

An OTP position is the set of token balances in the participant's account, so the portfolio reports its composition directly. For constituent $$i$$ with balance $$b\_i$$ and price $$p\_i(t)$$ at time $$t$$, the current weight is

$$
w\_i(t) = \frac{b\_i,p\_i(t)}{\sum\_{j=1}^{n} b\_j,p\_j(t)}
$$

The methodology sets the weights at purchase, for example one seventh each for the Magnificent Seven Index OTP. Between list changes, the balances $$b\_i$$ change only through the participant's own transactions, so the weights otherwise move with prices alone. After purchase, the weights follow the market: no scheduled trade sells a name because it grew or buys one because it lagged. Where a product enables it, the participant can request a manual Rebalance, which restores the methodology weights among existing holdings in one atomic transaction with no fee, as set out in [Trade execution specification](/docs/platform/product-mechanics/how-otps-work/technical-overview/trade-execution-specification.md).

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FBgAZT6K0Fixx66MXUZLw%2Ffig-weights.png?alt=media" alt="Weights set at purchase, weights follow the market, the list changes only on a named source or rule, and each change is published first"><figcaption><p>Weights are set at purchase and then follow the market. The list changes only on the source or rule that the methodology names, and each change is published before it executes.</p></figcaption></figure>

The constituent list changes only on the third-party public source or the published rule that the methodology names.

* **Index OTP:** The list changes when the published constituent rule adds or drops a name.
* **Guru OTP:** The list tracks a third-party public source, such as a periodic transaction report or a manager's quarterly Form 13F filing, and changes when a new filing or a disclosed trade is published; each change mirrors that disclosure, and every other position stays as it is. Guru OTPs replicate positions disclosed in public filings and are not affiliated with or endorsed by the individuals or firms they track.
* **Thematic OTP:** The list will change when a name enters or leaves the theme's published rule.

Every change is published on the product page before it executes and recorded on the portfolio's Rebalances tab. Changes are infrequent by design: quarterly for a portfolio that tracks Form 13F filings, and rarer for an index.

{% hint style="info" %}
As of October 2026, the Index OTPs and the first Guru OTP are live, and each list change is published on the product page before it executes. In the next phase, the Rebalancing Executor will apply each published change inside every enrolled account, and the Basket Execution Router will settle the legs as one atomic batch: each leg's quote will be checked against a reference market and held within a slippage cap, and the batch will settle in full or not at all. Execution will halt when a price feed is stale or a constituent is paused, impaired or unbacked. The Thematic OTP type arrives with that phase.
{% endhint %}

## Retirement and fees

When an OTP is retired, subscriptions and published list changes stop, and each participant keeps every asset held in their own account; City Protocol publishes notice before a portfolio is retired. The OTP fee is 0.1% of buy and sell volume, charged from Q4 2026, and the full fee schedule is disclosed before subscription.

## In depth

{% content-ref url="/pages/MGZPvtqy8e4QvHpac2iC" %}
[OTP modules and participants](/docs/platform/product-mechanics/how-otps-work/otp-modules-and-participants.md)
{% endcontent-ref %}

{% content-ref url="/pages/ByLRU9owx7FcDmWIvzqi" %}
[Portfolio lifecycle](/docs/platform/product-mechanics/how-otps-work/portfolio-lifecycle.md)
{% endcontent-ref %}

{% content-ref url="/pages/jKT4N0UlYRBJw1q9q1W9" %}
[List changes and the Rebalancing Executor](/docs/platform/product-mechanics/how-otps-work/list-changes-and-the-rebalancing-executor.md)
{% endcontent-ref %}

{% content-ref url="/pages/Ygv6fC8uNtoRg1NIUzd7" %}
[OTP security and risk controls](/docs/platform/product-mechanics/how-otps-work/otp-security-and-risk-controls.md)
{% endcontent-ref %}

{% content-ref url="/pages/0uLm1Yq4Cp3ZaWCuW5lK" %}
[Technical overview](/docs/platform/product-mechanics/how-otps-work/technical-overview.md)
{% endcontent-ref %}